Gestão de Projetos

COPYRIGHT 2007 Cengage Learning Edições Ltda.
, COPYRIGHT 2006 de South-Western, parte da Cengage Learning

Gestão de
PROJETOS
COPYRIGHT 2007 Cengage Learning Edições Ltda., COPYRIGHT 2006 de South-Western, parte da Cengage Learning
Dados Internacionais de Catalogação na Publicação (CIP)
(Câmara Brasileira do Livro, SP, Brasil)
Gido, Jack
Gestão de projetos / Jack Gido, James P.
Clements ; tradução Vertice Translate ;
revisão técnica Silvio Burrattino Melhado. --
São Paulo : Cengage Learning, 2007.
Título original: Successful project

management.
Bibliografia.
ISBN 978-85-221-0555-7
1. Administração de projetos I. Clements,

James P. II. Título.
07-2253 CDD-658.404
Índices para catálogo sistemático:

1. Gestão de projetos : Administração de empresas
658.404
2. Projetos : Gestão : Administração de empresas
658.404
Gestão de
PROJETOS
JACK GIDO
Penn State University
&
J A M E S P. C L E M E N T S
Towson University
Tradução
Vertice Translate
Revisão Técnica
Silvio Burrattino Melhado
Doutor em Engenharia Civil, Livre-Docente em Tecnologia de
Processos Construtivos e Professor Associado da
Escola Politécnica da Universidade de São Paulo
Austrália • Brasil • Japão • Coreia • Mexico • Cingapura • Espanha • Reino Unido • Estados Unidos
© 2006 de South-Western, parte da Cengage Learning
Gestão de Projetos – Tradução da 3ª edição © 2007 Cengage Learning Edições Ltda.
norte-americana
Jack Gido e James P. Clements Todos os direitos reservados. Nenhuma parte deste livro
poderá ser reproduzida, sejam quais forem os meios empregados,
sem a permissão, por escrito, da Editora.
Aos infratores aplicam-se as sanções previstas nos artigos
Gerente Editorial: Patricia La Rosa
102, 104, 106 e 107 da Lei no 9.610, de 19 de fevereiro de 1998.
Editora de Desenvolvimento: Danielle Mendes Sales
Supervisor de Produção Editorial: Fábio Gonçalves
Para informações sobre nossos produtos, entre em
Supervisora de Produção Gráfica: Fabiana Alencar
contato pelo telefone 0800 11 19 39
Albuquerque
Título Original: Successful Project Management – 3rd Para permissão de uso de material desta obra, envie
edition seu pedido para direitosautorais@cengage.com
Tradução: Vertice Translate e Roberta Schneider
Revisão Técnica: Silvio Burrattino Melhado © 2007 Cengage Learning. Todos os direitos reservados.
Copidesque: Andréa da Silva Medeiros
ISBN-10: 85-221-0555-3
Revisão: Alessandra Biral e Ana Paula Ribeiro ISBN-13: 978-85-221-0555-7
Editoração Eletrônica: PC Editorial Ltda.
Cengage Learning
Capa: Gabinete de Artes Condomínio E-Business Park
Rua Werner Siemens, 111 – Prédio 20 – Espaço 04
Lapa de Baixo – CEP 05069-900 – São Paulo – SP
Tel.: (11) 3665-9900 – Fax: (11) 3665-9901
SAC: 0800 11 19 39
Para suas soluções de curso e aprendizado, visite

www.cengage.com.br
Impresso no Brasil.
Printed in Brazil.
1 2 3 4 5 6 7 11 10 09 08 07
Para Rosemary, Steve, Jeff, Wendy, Matthew, Alex, Allison
e Meghan, por toda a alegria que vocês me trazem.
J. G.
Para Beth, Tyler, Hannah, Maggie e Grace,

por serem pessoas tão maravilhosas.
J. P. C
SUMÁRIO
Prefácio xiv
Parte 1 A VIDA DE UM PROJETO 1
1 Conceitos de Gestão de Projetos 2

Atributos de um Projeto 4
Ciclo de Vida do Projeto 7
O Processo de Gestão de Projetos 10
Benefícios da Gestão de Projetos 17
Resumo 18
Perguntas 19
Exercícios na Internet 20
Estudo de Caso nº 1 Uma Organização sem Fins Lucrativos 20
Estudo de Caso nº 2 E-Commerce para um Supermercado
Pequeno 21
2 Identificação de Necessidades 24
Identificação de Necessidades 26
Seleção de Projetos 27
Preparando uma Chamada de Propostas 30
Solicitando Propostas 36
Resumo 37
Perguntas 38
Estudo de Caso nº 1 Uma Empresa Farmacêutica de Médio
Porte 39
Estudo de Caso nº 2 Melhorias no Transporte 41
3 Soluções Propostas 44
Marketing de Proposta/Pré-CP 47
vii
viii Sumário
Decisão de Participar/Não Participar da Concorrência 48

Desenvolvendo uma Proposta Vencedora 51
Elaboração da Proposta 52
Conteúdo da Proposta 53
Seção Técnica 53
Seção de Gestão 55
Seção de Custos 56
Considerações sobre Preços 57
Entrega e Acompanhamento de Proposta 59
Avaliação de Propostas pelo Cliente 59
Tipos de Contrato 62
Contratos de Preço Global 62
Contratos por Administração 62
Disposições Contratuais 64
Resumo 66
Perguntas 67
Estudo de Caso nº 1 Sistemas de Informação para Área Médica 68
Estudo de Caso nº 2 Planejador de Casamentos 70
4 O Projeto 72
Planejando o Projeto 74
Gerenciando Riscos 76
Identificação de Riscos 76
Avaliação de Riscos 77
Planejamento de Resposta a Riscos 78
Monitoramento de Riscos 79
Realizando o Projeto 80
Controlando o Projeto 81
Concluindo o Projeto 83
Avaliação Interna Pós-Projeto 86
Feedback do Cliente 88
Encerramento Precoce do Projeto 89
Resumo 91
Perguntas 92
Estudo de Caso nº 1 Uma Empresa de Fabricação de Eletrônicos 93
Estudo de Caso nº 2 Projeto de Expansão de Fábrica 94
Parte 2 PLANEJAMENTO E CONTROLE DO PROJETO 97

5 Planejamento 98
Objetivo do Projeto 100
Estrutura Analítica do Projeto 101
Matriz de Responsabilidades 104
Definindo Atividades 104
Desenvolvendo o Planejamento de Redes de Atividades 106
Princípios de Redes de Atividades 108
Atividades Fictícias 110
Sumário ix
Preparando o Diagrama de Rede 114

Planejamento para Desenvolvimento de Sistemas de
Informação 118
Exemplo de SI: Desenvolvimento de Aplicativos de Internet para a ABC
Office Designs 120
Software de Gestão de Projetos 124
Resumo 126
Perguntas 127
Estudo de Caso nº 1 Um Centro de Pesquisa Médica sem Fins
Lucrativos 128
Estudo de Caso nº 2 O Casamento 130
Apêndice Microsoft Project 132
6 Cronograma 138
Estimativas de Duração das Atividades 140
Datas de Início e de Conclusão do Projeto 143
Cálculo do Cronograma 144
Início e Término Mais Cedo 145
Início e Término Mais Tarde 148
Folga Total 152
Caminho Crítico 155
Folga Livre 157
Cronograma para Desenvolvimento de Sistemas de
Informação 159
Office Designs (cont.) 160
Resumo 165
Perguntas 167
Lucrativos 170
Apêndice nº 1 Considerações sobre Probabilidades 173
Apêndice nº 2 Microsoft Project 184
7 Controle do Cronograma 190

Processo de Controle de Projetos 192
Efeitos do Desempenho do Cronograma Real 195
Incorporando Mudanças do Projeto ao Cronograma 196
Atualizando o Cronograma do Projeto 197
Abordagens para Controle do Cronograma 198
Controle de Cronograma para Desenvolvimento de Sistemas de
Informação 203
Office Designs (cont.) 204
x Sumário
Resumo 206
Perguntas 208
Lucrativos 209
Apêndice nº 1 Compensação Tempo-Custo 210
Apêndice nº 2 Microsoft Project 214
8 Considerações sobre Recursos 220

Planejamento Limitado por Recursos 222
Utilização Planejada de Recursos 223
Nivelamento de Recursos 225
Cronograma Limitado por Recursos 226
Resumo 232
Perguntas 233
Lucrativos 234
9 Planejamento e Desempenho de Custos 240

Estimativas de Custo do Projeto 242
Orçamento do Projeto 243
Alocando o Custo Orçado Total 244
Desenvolvendo o Custo Orçado Acumulado 244
Determinando o Custo Real 247
Custo Real 247
Custo Comprometido 248
Comparando o Custo Real com o Custo Orçado 249
Determinando o Valor do Trabalho Realizado 249
Análise de Desempenho de Custo 253
Índice de Desempenho de Custo 253
Variação de Custo 254
Estimativa de Custos 256
Controle de Custos 257
Gerindo o Fluxo de Caixa 259
Resumo 262
Perguntas 263
Lucrativos 265
Sumário xi
Parte 3 AS PESSOAS: O SEGREDO PARA O SUCESSO DE UM

PROJETO 277
10 O Gestor de Projetos 278
Responsabilidades do Gestor de Projetos 280
Planejamento 280
Organização 280
Controle 281
Aptidões do Gestor de Projetos 281
Capacidade de Liderança 282
Capacidade de Desenvolver Pessoas 286
Habilidades de Comunicação 288
Habilidades Interpessoais 290
Capacidade de Lidar com o Estresse 292
Capacidade de Resolver Problemas 293
Capacidade de Gerir o Tempo 293
Desenvolvendo as Aptidões Necessárias para ser Gestor de
Projetos 294
Delegação 295
Gerindo Mudanças 299
Resumo 303
Perguntas 304
Estudo de Caso nº 1 Codeword 305
Estudo de Caso nº 2 Uma Empresa de E-Business em Crescimento 307
11 A Equipe de Projeto 310
Desenvolvimento e Eficácia da Equipe de Projeto 312
Estágios de Desenvolvimento e Crescimento da Equipe 312
A Equipe de Projeto Eficaz 318
Barreiras para a Eficácia da Equipe 320
Como Ser um Membro Eficaz da Equipe 324
Construção de Equipe 327
Comportamento Ético 328
Conflito em Projetos 330
Fontes de Conflito 331
Lidando com Conflitos 332
Resolução de Problemas 334
Uma Abordagem em Nove Etapas para a Resolução de Problemas 334
Brainstorming 336
Gestão do Tempo 337
Resumo 340
Perguntas 341
Estudo de Caso nº 1 RD Processing 342
Estudo de Caso nº 2 Problemas em Equipes 344
12 Comunicação e Documentação do Projeto 346

Comunicação Pessoal 348
xii Sumário
Comunicação Oral 348

Comunicação Escrita 350
Ouvindo de Forma Eficaz 351
Reuniões 352
Tipos de Reunião de Projeto 352
Reuniões Eficazes 357
Apresentações 362
Preparando-se para uma Apresentação 362
Fazendo a Apresentação 363
Relatórios 364
Tipos de Relatórios de Projeto 365
Preparando Relatórios Úteis 367
Documentação de Projeto e Controle de Mudanças 368
Resumo 370
Perguntas 371
Estudo de Caso nº 1 Comunicação no Escritório 372
Estudo de Caso nº 2 Comunicação Internacional 374
13 Tipos de Organização de Projeto 378

Organização Funcional 380
Organização por Projetos 383
Organização Matricial 385
Vantagens e Desvantagens 391
Estrutura Organizacional Funcional 391
Estrutura Organizacional por Projetos 392
Estrutura Organizacional Matricial 393
Resumo 394
Perguntas 396
Estudo de Caso nº 1 Multi Projects 397
Estudo de Caso nº 2 Divisões Industriais 399
Apêndice A Software de Gestão de Projetos 403
Recursos do Software de Gestão de Projetos 403

Critérios para a Seleção do Software de Gestão de Projetos 407
Vantagens de se Utilizar um Software de Gestão de Projetos 408
Preocupações em Relação ao Uso de um Software de Gestão de
Projetos 409
Fornecedores de Software de Gestão de Projetos 410
Resumo 410
Perguntas 410
Apêndice B Organizações de Gestão de Projetos 412
Apêndice C Sites de Gestão de Projetos na Internet 413
Apêndice D Abreviaturas 415
Sumário xiii
Referências Bibliográficas 417
Respostas para a Seção Reforce seu Aprendizado 423
Glossário 440
PREFÁCIO
Começaremos a escavar deste lado da montanha. Você e sua equipe escavarão do outro
lado. Se nos encontrarmos no meio dela, teremos construído um túnel. Se não, teremos
construído dois!
NOSSA ABORDAGEM
Gestão de projetos é mais do que distribuir tarefas a um grupo de pessoas na expectativa
de que elas alcancem um objetivo desejado. Na verdade, projetos que poderiam ter tido
êxito, muitas vezes, fracassam devido a abordagens desse tipo. As pessoas precisam de in-
formações sólidas e aptidões reais para trabalhar com sucesso em um ambiente de projeto
e, conseqüentemente, alcançar os objetivos desse projeto. Gestão de Projetos foi escrito para
proporcionar a seus usuários ambas as coisas: a explicação de conceitos e técnicas e a enu-
meração de exemplos que mostrem como eles podem ser aplicados de forma eficaz.
Embora trate justamente de coisas práticas que os leitores devem saber para prosperar em
um ambiente de projeto, o livro não abandona a aprendizagem real; ele simplesmente desafia
os leitores a pensar criticamente sobre os princípios de gestão de projetos e a aplicá-los no
contexto do mundo real. Abordaremos lições aprendidas durante anos de gerenciamento de
projetos e de ensino sobre gestão de projetos, e com anos de textos escritos sobre o assunto.
Gestão de Projetos foi elaborado tanto para estudantes como para profissionais e voluntá-
rios. Propõe-se a apresentar as aptidões essenciais que os leitores precisam para contribuir
de maneira eficiente e para causar impacto na realização dos projetos com os quais estão
envolvidos. Assim, este livro dá suporte aos programas de educação continuada do mun-
do industrial e empresarial – os quais desenvolvem e treinam funcionários para torná-los
bem-sucedidos dentro de equipes de diferentes disciplinas e funções – e permite formar
estudantes qualificados para o mercado de trabalho.
A obra foi escrita para todos os que se envolvem com projetos, não somente os gerentes
de projetos. Mesmo os projetos com os melhores gestores podem fracassar, já que o esforço de
todos os envolvidos é essencial. Todos os integrantes da equipe precisam ter conhecimento e
capacidade para trabalhar juntos e de maneira próspera em um ambiente de projeto. Ler não
forma gestores de projetos. Em primeiro lugar, é necessário participar de modo eficaz de uma
equipe de projeto. Este livro proporciona a base para formar membros eficazes de equipes de
projeto, impulsionando-os para o desafio que é a gestão de equipes e projetos.
xiv
Prefácio xv
O livro foi escrito em estilo direto e de fácil compreensão, com o mínimo de termos
técnicos. A terminologia de gestão de projetos será adquirida gradualmente pelos leitores
durante o processo de leitura. Não há teorias matemáticas ou algoritmos complexos na des-
crição de técnicas de elaboração de cronogramas, nem a inclusão de exemplos de projetos
altamente técnicos. Uma abordagem demasiadamente técnica poderia criar uma barreira
de aprendizagem às pessoas que não têm conhecimento matemático e técnico profundo.
Nosso livro contém uma variedade de exemplos fáceis de compreender, baseados em
projetos encontrados em situações cotidianas. São exemplos de aplicações do mundo real,
como realizar uma pesquisa de trabalho, elaborar um sistema de informação e organizar um
festival municipal. A parte matemática foi propositalmente simplificada. Existem apêndices
destinados aos leitores que desejam uma abordagem mais detalhada das considerações so-
bre probabilidade e sobre a relação de compensação tempo-custo.
DIFERENCIAIS
Gestão de Projetos possui vários diferenciais que objetivam aprimorar a aprendizagem e as
aptidões do leitor.
Vinhetas do Mundo Real: Cada capítulo possui duas vinhetas do mundo real que ilustram
os tópicos do capítulo. Estas não somente reforçam os conceitos apresentados como tam-
bém encorajam a discussão entre os leitores e despertam seu interesse em aplicações da
gestão de projetos.
Apresentação dos Capítulos: Cada capítulo começa com uma apresentação dos tópicos
principais. Tais apresentações mostram ao leitor o que esperar naquele capítulo e permitem
que ele tenha uma visão geral das informações a serem apresentadas.
Exemplos e Aplicações: No decorrer do texto, aparecem exemplos e aplicações do mundo
real, além de ilustrações específicas, relevantes e atrativas.
Gráficos e Imagens: Várias apresentações de imagens e números aparecem no texto, para
ilustrar aspectos importantes e ferramentas de gestão de projetos.
Seção “Reforce seu Aprendizado”: Perguntas breves são apresentadas em destaque para
assegurar que os leitores absorvam os conceitos-chave e para que princípios fundamentais
não sejam ignorados. Tais perguntas servem como reforço e também como um guia de
estudo.
Fatores Críticos para o Sucesso: Cada capítulo possui uma lista concisa de fatores importan-
tes para que gerentes de projeto e membros da equipe façam de seus projetos um sucesso.
Resumo dos Capítulos: Ao fim de cada capítulo, há um resumo do material apresentado – um
retoque final dos conceitos básicos.
Revisão de Perguntas e Problemas: Cada capítulo contém uma série de perguntas e proble-
mas que, primeiramente, testam os conceitos para depois aplicá-los.
Exercícios na Internet: Cada capítulo apresenta uma série de exercícios que requerem
dos leitores pesquisar, em sites da Internet, informações sobre vários tópicos de gestão de
projetos. Tais exercícios convidam os aprendizes a explorar, de maneira virtual e prática,
aplicações reais da gestão de projetos. Um apêndice no final do livro fornece endereços de
todos os websites sobre gestão de projetos mencionados no texto*.
Estudos de Caso: Ao final dos capítulos, estudos de caso apresentam um panorama para
que indivíduos ou grupos façam análises críticas sobre os temas. A variedade de casos asse-
gura que todos os leitores possam se identificar com os problemas apresentados. Os casos
* Como os endereços da Internet podem sofrer alterações, a editora não se responsabiliza por quaisquer problemas nas
conexões dos sites publicados. (NE)
xvi Prefácio
são divertidos e instigam debates. Ao encorajar discussões sob diferentes pontos de vista,
eles dão aos participantes a oportunidade de descobrir como agir quando há divergências
de opinião no ambiente de trabalho. Dessa maneira, os estudantes aprendem a importância
do trabalho em equipe.
Softwares de Gestão de Projetos: Um apêndice trata do uso de softwares de gestão de projetos
como uma ferramenta para planejamento e controle de projetos. Discutem-se as características
comuns dos pacotes de software de gestão de projetos, além dos critérios de seleção.
Microsoft Project: Novos exemplos sobre como utilizar e aplicar o software Microsoft Pro-
ject estão incluídos na segunda parte do livro, assim como uma grande quantidade de telas,
entradas de dados e relatórios*.
Organizações de Gestão de Projetos: Um apêndice com uma lista de organizações de ges-
tão de projetos do mundo todo, para aqueles que desejam entrar em contato com essas
organizações e, conseqüentemente, saber mais sobre desenvolvimento profissional, acesso
a periódicos e outras publicações ou oportunidades de carreira.
ORGANIZAÇÃO
Gestão de Projetos está dividido em três partes:
• A primeira parte, A Vida de um Projeto, aborda conceitos sobre gestão de projetos,
identificação de necessidades, proposição de soluções e execução do projeto.
• A segunda parte, Planejamento e Controle do Projeto, trata de planejamento, elaboração
e controle de cronograma, considerações sobre recursos e planejamento e desempenho
de custo.
• A terceira parte, As Pessoas: O Segredo para o Sucesso de um Projeto, discute elementos
como o gestor de projetos, a equipe de projeto, os tipos de organizações de projeto
e a comunicação e documentação do projeto.
A primeira parte possui quatro capítulos. O Capítulo 1, Conceitos de Gestão de Projetos,
aborda a definição de um projeto e seus atributos, as restrições principais a que está sujeito,
o modo como “nasce”, a vida e as etapas de seu processo de gestão, exemplos de projetos
e os benefícios da gestão de projetos. O Capítulo 2, Identificação de Necessidades, inclui
a identificação de necessidades e a seleção de projetos, o desenvolvimento de um edital
de concorrência e o processo de solicitação de propostas. O Capítulo 3, Proposição de
Soluções, lida com as estratégias de marketing de propostas, a decisão de participar ou não
de uma concorrência, o desenvolvimento de propostas vencedoras, o processo de elabora-
ção da proposta, considerações sobre preços, avaliação das propostas e tipos de contratos.
O Capítulo 4, O Projeto, discute os fatores envolvidos no planejamento de um projeto, no
gerenciamento de riscos, nas etapas do processo de controle do projeto e nas ações que
devem ser tomadas quando um projeto é concluído.
A segunda parte possui cinco capítulos. O Capítulo 5, Planejamento, discute como defi-
nir claramente o objetivo do projeto, bem como desenvolver sua estrutura analítica, atribuir
responsabilidades e definir atividades detalhadas, desenvolver um diagrama de rede e utili-
zar o ciclo de vida para projetos de desenvolvimento de sistemas de informação.
O Capítulo 6, Cronograma, trata da estimativa de duração das atividades, do cálculo do
início e término mais cedo e mais tarde de cada uma dessas atividades, da determinação da
folga e da identificação do caminho crítico delas. Nesse capítulo, há também um apêndice
com considerações sobre probabilidades. No Capítulo 7, Controle do Cronograma, apre-
sentam-se as etapas do processo de controle do projeto e os efeitos do desempenho real
do cronograma conforme o projeto, a incorporação de mudanças no cronograma, o cálculo
da atualização do cronograma do projeto e as abordagens para controle do cronograma.
Nesse capítulo, há também um apêndice sobre a relação de compensação de tempo-custo.
* Como a maioria dos usuários utiliza o software Microsoft Project em inglês, optamos por manter telas, comandos
e menus nesta língua. (NRT)
Prefácio xvii
No Capítulo 8, Considerações sobre Recursos, discutem-se as limitações dos recursos quan-

do se planeja um projeto, a determinação da utilização planejada de recursos, o nivelamen-
to da utilização de recursos dentro do prazo estabelecido para a execução de um projeto e a
determinação do menor cronograma quando o número de recursos disponíveis é limitado.
No Capítulo 9, Planejamento e Desempenho de Custos, apresentam-se elementos a serem
considerados durante a estimativa de custo de um projeto, a preparação de um orçamento-
base, os custos reais acumulados, o estabelecimento do valor do trabalho realizado de fato,
a análise do desempenho de custo, o cálculo da estimativa de custo do projeto na conclu-
são, abordagens para o controle de custos e o gerenciamento do fluxo de caixa.
A terceira parte possui quatro capítulos. No Capítulo 10, O Gestor de Projetos, discutem-se
as responsabilidades do gestor de projetos, suas aptidões para a execução bem-sucedida do
projeto e as maneiras de desenvolver essas aptidões. Discutem-se também as abordagens
para uma delegação eficaz e as formas de se gerir e controlar mudanças no projeto. No
Capítulo 11, A Equipe de Projeto, abordam-se o desenvolvimento e crescimento das equi-
pes, as características das equipes eficazes e as barreiras para sua eficácia, a construção da
equipe, questões éticas, fontes de conflito durante o projeto, formas de lidar com conflitos,
a resolução de problemas e a gestão eficaz de tempo. O Capítulo 12, Comunicação e Docu-
mentação de Projeto, inclui comunicações pessoais, como ouvir de maneira eficaz, tipos de
reunião de projeto e sugestões para reuniões produtivas, apresentações formais de projetos
e sugestões para apresentações eficazes, relatórios de projetos e sugestões para a preparação
de relatórios úteis, a documentação de projetos e o controle de mudanças. No Capítulo 13,
Tipos de Organização de Projetos, são apresentadas as características, as vantagens e as
desvantagens das estruturas organizacionais do tipo funcional, por projetos e matricial.
O livro apresenta ainda um apêndice especial sobre softwares de gestão de projetos,
em que se discutem as características comuns desses programas, os critérios para seleção
de um deles e as vantagens de se utilizar esse tipo de software, bem como as preocupa-
ções relacionadas a seu uso. Há outros apêndices que fornecem uma lista de organizações
de gestão de projetos, sites sobre o tema na Internet e abreviaturas. Finalmente, o livro
apresenta referências bibliográficas para cada capítulo, respostas para a seção “Reforce seu
Aprendizado” e um glossário.
AGRADECIMENTOS
Gostaríamos de agradecer às pessoas que nos ajudaram a publicar este livro. Jason Oakman
realizou um meticuloso trabalho na preparação dos gráficos; Gloria Chou foi excelente ao
localizar e resumir as vinhetas do mundo real e ao atualizar os sites de Internet e as refe-
rências. Agradecemos a toda a equipe de projeto da South-Western College Publishing, que
ajudou a transformar nosso sonho em realidade e contribuiu para a bem-sucedida finaliza-
ção deste livro. Merecem créditos especiais: Charles McCormick Jr., editor de aquisição sê-
nior; Chris Sears, gerente de projetos de produção; Julie Klooster, assistente editorial, e Amy
Rose, gerente de projetos da Interactive Composition Corporation. Também gostaríamos de
reconhecer a importante contribuição dos revisores deste livro:
Fred K. Augustine, Jr. Craig Cowles
Stetson University Bridgewater State College
Vicki Blanchard Mike Ensby
Gibbs College of Boston Clarkson University
Thomas Bute Philip Gisi
Humboldt State University DePaul University
John H. Cable Mamoon M. Hammad
University of Maryland The George Washington University
David T. Cadden Barbara Kelley
Quinnipiac University St. Joseph’s University
xviii Prefácio
Brian M. Kleiner Joseph A. Phillips

Virginia Tech DeVry University
Shawn Krest Tim Ralston
Genesee Community College Bellevue Community College
William Milz Wade H. Shaw
Northeast Wisconsin Technical College Florida Institute of Technology
David Moore Kevin P. Shea
Colorado School of Mines Baker University
William A. Moylan William R. Sherrard
Eastern Michigan University San Diego State University
John Olson Anne Marie Smith
DePaul University La Salle University
Shrikant S. Panwalkar Frederick A. Tribble
Purdue University California State University, Long Beach
Fariborz Y. Partovi
Drexel University
Gostaríamos de agradecer a todos com quem trabalhamos e àqueles que participaram

de nossos muitos seminários sobre gestão de projetos, pois proporcionaram um ambien-
te de aprendizagem onde testamos as lições práticas presentes neste livro.
Existem pessoas que fazem acontecer,

pessoas que deixam acontecer
e pessoas que se perguntam o que aconteceu.
Esperamos que Gestão de Projetos ajude os leitores/aprendizes a ter uma experiência pra-
zerosa, estimulante e bem-sucedida durante suas futuras conquistas nos projetos a que se
dedicarem e que também seja o catalisador de suas ações.
Jack Gido
James P. Clements
SOBRE OS AUTORES
Jack Gido é diretor de Desenvolvimento Econômico e de Força de Trabalho

e diretor do PENNTAP (Pennsylvania Technical Assistance Program), na Penn
State University. Anteriormente, exerceu a dupla função de gerente do In-
dustrial Technology Extension Service na New York Science and Technology
Foundation e de diretor-adjunto do Industrial Effectiveness Program no New
York State Department of Economic Development. Seus 20 anos de experiên-
cia em gestão industrial incluem o gerenciamento de programas de melhoria
de produtividade e tecnologia de fabricação na General Electric e na Mechani-
cal Technology, Inc. Bacharel em Engenharia Elétrica pela Penn State University
e MBA pela University of Pittsburg. Autor de dois outros livros sobre gestão de
projeto e instrutor em workshops sobre o mesmo tema.
James P. Clements é vice-presidente de Superação Econômica e Comunitária

na Towson University e Distinguished Professor Robert W. Deutsch de Tecno-
logia da Informação. Atuou anteriormente como diretor-executivo do Center
for Applied Information Technology e como presidente do Department of
Computer and Information Sciences na Towson University. Mestre e doutor em
Análise de Operações pela University of Maryland Baltimore County, mestre
em Ciência da Computação pela Johns Hopkins University e bacharel em Ciên-
cia da Computação pela University of Maryland Baltimore County. Publicou
e apresentou mais de 50 trabalhos sobre vários temas relacionados a gestão
de projetos e sistemas de informação. Nos últimos 20 anos, trabalhou como
consultor para vários grupos comerciais e industriais. Dr. Clements também
ganhou quatro vezes o prêmio Faculty Member of the Year, concedido por
estudantes da Towson University.
Parte 1
A VIDA DE UM PROJETO
CAPÍTULOS
1 Conceitos de Gestão 2 Identificação de 3 Soluções Propostas 4 O Projeto
de Projetos necessidades
Oferece uma visão geral Discute a identificação Explica o desenvolvimento Discute a implementação
sobre conceitos de ges- de necessidades e a de propostas para se da solução proposta,
tão de projetos, o ciclo solicitação de propostas, abordar uma necessi- a terceira fase do ciclo
de vida do projeto a primeira fase do ciclo da-de ou resolver um de vida do projeto,
e as etapas do processo de vida do projeto. problema, a segunda incluindo os elementos
de gestão de projetos. fase do ciclo de vida do envolvidos no plane-
projeto. jamento e controle do
projeto. Cobre também
o que deve ser feito na
fase de conclusão do
ciclo de vida do projeto.
Os capítulos da Parte 1 introduzem os conceitos de gestão de projetos e de ciclo de vida

do projeto. Um projeto é um esforço para se atingir um objetivo específico por meio de
um conjunto único de tarefas inter-relacionadas e da utilização eficaz de recursos. Tem um
objetivo bem definido em termos de escopo, cronograma e custo. Os projetos “nascem”
quando uma necessidade é identificada pelo cliente, uma organização ou pessoas dispostas
a fornecer os recursos financeiros para que sua necessidade seja atendida.
A primeira fase do ciclo de vida do projeto envolve a identificação de uma necessidade,
problema ou oportunidade, que pode resultar na solicitação de propostas pelo cliente a
pessoas, a uma equipe de projeto ou a organizações (fornecedores) para atender à neces-
sidade identificada ou resolver o problema. A segunda fase do ciclo de vida do projeto é
o desenvolvimento de uma solução proposta para a necessidade ou problema. Essa fase
resulta na entrega de uma proposta ao cliente por uma ou mais pessoas ou organizações.
A terceira fase desse ciclo de vida é a implementação da solução proposta. Essa fase, co-
nhecida como execução, resulta na consecução dos objetivos, deixando o cliente satisfeito
com a conclusão do escopo total do trabalho com qualidade, sem superar o orçamento e
dentro do prazo. A fase final do ciclo de vida do projeto é sua conclusão.
A gestão de projetos envolve um processo em que primeiro se estabelece um plano, que
depois será implementado para se atingir o objetivo proposto. Utilizar o tempo necessário
para se desenvolver um plano bem concebido é fundamental para o sucesso de qualquer
projeto. Uma vez iniciado, o processo de gestão envolve o monitoramento do progresso,
de modo a garantir que tudo está caminhando conforme planejado. O segredo para um
controle eficaz do projeto é medir o progresso real e compará-lo ao progresso planejado em
intervalos regulares, adotando medidas corretivas imediatamente, se necessário.
O benefício maior da implementação de técnicas de gestão de projeto é ter um cliente
satisfeito – seja você o cliente de seu projeto, seja uma empresa (fornecedor) que paga por
um cliente para executar um projeto. A conclusão do escopo total de um projeto com quali-
dade, dentro do prazo e sem superar o orçamento, traz um grande sentimento de satisfação.
Quando um projeto é bem-sucedido, todos saem ganhando!
1
Capítulo CONCEITOS DE GESTÃO DE PROJETOS
1 Atributos de um Projeto
Ciclo de Vida do Projeto
O Processo de Gestão de Projetos
Estudo de Caso no 1 Uma
Organização sem Fins Lucrativos
Perguntas
Atividade em Grupo
Benefícios da Gestão de Projetos
Resumo Estudo de Caso no 2 E-Commerce
para um Supermercado Pequeno
Perguntas
Perguntas
Exercícios na Internet
Atividade em Grupo
Atividade Opcional
2
Ca pítulo Um
G E S TÃ O D E P R O J E T O S N O M U N D O
Gestão de Projetos para Melhorias na Saúde
Pat Ryan, secretário-chefe de informação da Interior Health Authority (IHA), na província de
British Columbia (Canadá), utilizou os conceitos básicos de gestão de projeto para imple-
mentar com sucesso dois grandes projetos de TI em um importante sistema de assistência
médica. Vejamos o que ele fez.
A IHA atende 690.000 pessoas, possui 28 unidades de tratamento intensivo, 91 unida-
des de saúde, 183 localidades, 740 contratos particulares, 17.000 funcionários e 1.200 mé-
dicos em British Columbia. O governo federal canadense, suas dez províncias e três terri-
tórios trabalham em conjunto para oferecer assistência médica aos residentes qualificados
por meio de um programa nacional de seguro-saúde. Para gerenciar e oferecer os serviços
de saúde segurados, há cinco anos a província de British Columbia formou a IHA por meio
da fusão de várias entidades: cinco regiões de saúde e 14 conselhos de saúde. A recém-for-
mada IHA precisava de um sistema de negócios único e integrado. O trabalho de Pat Ryan foi
combinar 19 sistemas clínicos e de negócios independentes e com múltiplas plataformas.
Especificamente, o objetivo do projeto de Implementação de Sistemas de Negócios
(BSI) era integrar mais de cem aplicativos financeiros independentes em um único sistema,
que seria usado para controles financeiros internos. O objetivo do segundo projeto, Im-
plementação de Sistemas Clínicos (CSI), era consolidar e padronizar o registro clínico ele-
trônico, o qual ficaria acessível aos funcionários e médicos em instalações locais e remotas
(on-site e off-site).
Ryan começou estabelecendo suporte executivo para os dois projetos. Executivos fo-
ram envolvidos neles desde o início, para resolver problemas, ajudar a eliminar barreiras e
responder por eles. A relação custo–benefício dos projetos foi analisada para confirmar se
eles se adequavam à missão da IHA. O custo estimado para o projeto BSI foi de 3,2 milhões
de dólares canadenses, mas ele iria economizar 4,3 milhões de dólares canadenses por ano
à IHA em custos administrativos. O projeto CSI custaria 20 milhões de dólares canadenses
para criar um registro clínico eletrônico acessível e padronizado.
Em seguida, Ryan concentrou-se em desenvolver equipes de projeto eficazes e com
autonomia. De modo geral, os gerentes de cada projeto estabeleceram canais abertos
de comunicação, realizaram análises freqüentes do projeto e seguiram um protocolo
visando avaliar e tomar as medidas necessárias para evitar riscos. Para o projeto BSI, as
equipes foram criadas em uma organização hierárquica, com suporte executivo no topo.
Um comitê gestor foi criado, composto de gestores de projetos atribuídos para cada mó-
dulo especializado do novo sistema financeiro, e responsabilizado por produzir relatórios
quinzenais para os executivos no topo e relatórios trimestrais para a diretoria da IHA. As
34 equipes envolvidas no projeto CSI colaboraram em um esquema de projeto, de modo
que os membros tivessem um sentimento de propriedade por esse planejamento. Elas
também criaram um plano de comunicação formal para compartilhar informações com as
principais partes interessadas.
O projeto BSI durou 14 meses e ficou abaixo do orçamento, sem grandes problemas
ou períodos de inatividade. O novo sistema financeiro integrado agora gera economia de
4,3 milhões de dólares canadenses por ano. O projeto CSI está sendo implementado em
fases, de acordo com a localização geográfica. As fases 1 e 2 foram concluídas e, até agora,
cerca de 70% dos médicos da organização utilizam o novo registro clínico eletrônico on-site
e off-site. A maior fase de implementação estava prevista para abril de 2005. O sucesso dos
dois projetos é confirmado ainda por estes resultados reais e mensuráveis: economia de
custos e elevado índice de aceitação entre os usuários.
Wyllie, T. Back to Basics – Practical Magic for Project Management Success. CMA Management, abril de 2004, p. 33-7.
3
4 Parte 1 A Vida de um Projeto
Este capítulo oferece uma visão geral dos conceitos de gestão de projeto. Você irá co-
nhecer melhor:
• a definição de um projeto e seus atributos;
• as principais limitações dentro das quais um projeto deve ser gerido;
• como “nasce” um projeto;
• a vida de um projeto;
• as etapas envolvidas no processo de gestão de projeto;
• os benefícios da gestão de projeto.
ATRIBUTOS DE UM PROJETO
Um projeto é um esforço para se atingir um objetivo específico por meio de um conjunto
único de tarefas inter-relacionadas e da utilização eficaz de recursos∗. Os seguintes atributos
ajudam a defini-lo:
• Um projeto tem um objetivo bem definido – um resultado ou produto esperado.

O objetivo de um projeto costuma ser definido em termos de escopo, cronograma e
custo. Por exemplo, o objetivo de um projeto pode ser lançar no mercado, em dez
meses e dentro de um orçamento de US$ 500 mil – um novo eletrodoméstico para
preparar alimentos que atenda a certas especificações de desempenho predefinidas.
Além disso, espera-se que o escopo do trabalho seja atingido com qualidade e que
gere a satisfação do cliente.
• Um projeto é conduzido por meio de uma série de tarefas independentes, isto é, vá-
rias tarefas não repetitivas que precisam ser cumpridas em determinada seqüência, a
fim de se atingir o objetivo do projeto.
• Um projeto utiliza vários recursos para realizar as tarefas. Tais recursos podem in-
cluir diferentes pessoas, organizações, equipamentos, materiais e instalações. Por
exemplo, uma cerimônia de casamento é um projeto que pode envolver recursos,
como um bufê, uma floricultura, um carro alugado e um espaço para a recepção.
• Um projeto apresenta um esquema de tempo específico, ou uma vida finita. Ele tem
uma data de início e uma data na qual o objetivo deve ser atingido. Por exemplo, a
reforma de uma escola precisa ser concluída entre os dias 20 de junho e 20 de agosto.
• Um projeto pode ser um esforço único ou de uma única vez. Alguns projetos, como
conceber e construir uma estação espacial, são únicos porque nunca foram tentados.
Outros, como o desenvolvimento de um novo produto, a construção de uma casa ou
o planejamento de um casamento, são únicos pelo grau de customização que exigem.
Por exemplo, uma cerimônia de casamento pode ser simples, informal, com alguns
amigos em uma capela, ou pode ser um evento espetacular digno da realeza.
• Um projeto tem um cliente. Este é a entidade que fornece os recursos financeiros
necessários para realizar o projeto. Pode ser uma pessoa, uma organização ou um
grupo de duas ou mais pessoas ou organizações. Quando uma empresa constrói uma
casa customizada para um casal, o casal é o cliente que está financiando o projeto.
Quando uma empresa recebe fundos do governo para desenvolver um dispositivo
robótico usado no manuseio de material radioativo, o cliente é a agência governa-
mental. Quando uma empresa fornece recursos para uma equipe de funcionários
*
No Brasil, o termo projeto é empregado tanto no sentido adotado neste livro (equivalendo ao termo project,
em inglês) quanto no sentido de concepção técnica (design). Em determinados setores de negócios, o emprego
do termo empreendimento pode ser mais adequado (em substituição a project), reservando-se, nesses casos, o
uso do termo projeto para designar o conjunto dos elementos descritivos das soluções técnicas adotadas, ou seu
processo de desenvolvimento. Isso ocorre, por exemplo, no setor da construção civil. Feita esta ressalva quanto à
terminologia, observe-se que todos os conceitos e métodos da gestão de projetos são aplicáveis a qualquer setor,
indiscriminadamente. (NRT)
Capítulo 1 Conceitos de Gestão de Projetos 5
atualizar o sistema de informação de sua gerência, o termo cliente passa a assumir

uma definição mais ampla, incluindo não apenas o financiador do projeto (a direto-
ria da empresa), mas também outras partes interessadas, como as pessoas que serão
os usuários finais do sistema de informação. A pessoa que faz a gestão do projeto,
e a equipe de projeto deve atingir seu objetivo com sucesso, a fim de satisfazer
o(s) cliente(s).
• Por fim, o projeto envolve certo grau de incerteza. Antes do início de um projeto,
elabora-se um plano com base em certas suposições e estimativas. É importante
documentar essas suposições, pois influenciarão o desenvolvimento do orçamento
do projeto, o cronograma e o escopo do trabalho. Um projeto baseia-se em um con-
junto único de tarefas e estimativas do tempo que cada tarefa deverá levar, vários
recursos e suposições sobre a disponibilidade e capacidade desses recursos, além de
estimativas sobre os custos associados aos recursos. Essa combinação de suposições
e estimativas causa certo grau de incerteza em relação ao cumprimento total do ob-
jetivo do projeto. Por exemplo, seu escopo pode ser realizado na data prevista, mas
o custo final pode ser muito maior que o previsto, em função de estimativas iniciais
baixas para determinados recursos. À medida que o projeto avança, algumas das su-
posições serão refinadas ou substituídas por informações reais. Por exemplo, depois
que o projeto conceitual do relatório anual de uma empresa é finalizado, pode-se
estimar melhor a quantidade de tempo e de esforço necessária para realizar o projeto
detalhado e sua impressão.
REFORCE SEU APRENDIZADO

1. Quais são os principais atributos de
um projeto?
A seguir, estão relacionados alguns exemplos de projetos:
A montagem de uma peça de teatro.

O desenvolvimento e lançamento de um novo produto.
O planejamento de um casamento.
A concepção e implementação de um sistema de computação.
A introdução de uma nova moeda.
A modernização de uma fábrica.
A consolidação de unidades de fabricação.
A transformação de um quarto em uma sala.
A realização de um congresso.
A concepção e produção de um manual.
A execução de uma limpeza ambiental em um terreno contaminado.
A organização de uma reunião de antigas turmas de colégio.
A construção de um shopping center.
A realização de uma série de cirurgias em uma vítima de acidente.
A organização de uma celebração centenária.
A reconstrução de uma cidade após um desastre natural.
A preparação de um jantar para 20 parentes.
A criação de um programa de estágio para estudantes.
A construção de uma casa na árvore.

2. Identifique cinco projetos nos quais
você esteve envolvido em sua vida.
O cumprimento bem-sucedido do objetivo do projeto normalmente é limitado por qua-

tro fatores: escopo, custo, cronograma e satisfação do cliente (veja Figura 1.1).
O escopo do projeto ou escopo do trabalho é todo o processo que deve ser realiza-
do, a fim de garantir ao cliente que os “deliverables” (itens, produtos ou serviços tangíveis
a serem fornecidos) cumpram os requisitos ou critérios de aceitação acordados no início do
projeto. Por exemplo, o escopo do projeto pode ser todo o trabalho envolvido na limpeza
do terreno, na construção da casa e no paisagismo, segundo as especificações acordadas
entre o fornecedor e o comprador. O cliente espera que o escopo do trabalho seja realizado
com qualidade. Por exemplo, em um projeto de construção de uma casa, o cliente espera
que a mão-de-obra seja da mais alta qualidade. Concluir o escopo do trabalho, mas deixar
janelas difíceis de abrir e fechar, torneiras com vazamentos ou um jardim cheio de pedras
resultará em um cliente insatisfeito.
O custo de um projeto é a quantia que o cliente concordou em pagar por itens, pro-
dutos ou serviços aceitáveis do projeto. Esse custo se baseia em um orçamento que inclui
a estimativa dos custos associados com os vários recursos utilizados na realização desse
projeto. Pode incluir os salários dos envolvidos, materiais e suprimentos, aluguel de equi-
pamentos e instalações, além das taxas dos subcontratados ou consultores que realizarão
algumas das tarefas do projeto. Por exemplo, se este for um casamento, os itens orçados
podem incluir flores, vestido de noiva, fraque, serviço de bufê, bolo, aluguel de veículo,
fotógrafo e assim por diante.
O cronograma de um projeto especifica as datas em que cada atividade deve co-
meçar e terminar. O objetivo do projeto normalmente define o prazo no qual seu escopo
deve ser concluído em termos de uma data específica acordada entre o cliente e a pessoa
ou organização que está realizando o trabalho. Pode ser a data em que irá ocorrer uma
FIGURA 1.1 Fatores que Limitam o Sucesso do Projeto
Custo Cronograma
Satisfação
Escopo do cliente
Fonte: Cortesia de Dynamics Graphics, Inc.
celebração centenária em uma cidade ou a data em que você quer que a nova sala de sua
casa esteja pronta.
O objetivo de qualquer projeto é concluir o escopo dentro do orçamento até uma data
específica, a fim de que a satisfação do cliente seja obtida. Para ajudar a garantir o cum-
primento desse objetivo, é importante desenvolver um plano antes do início do projeto; esse
plano deve incluir todas as tarefas do trabalho, os custos associados e as estimativas do tem-
po necessário para terminá-las. A falta de planejamento aumenta o risco de que o escopo
total do projeto não seja concluído dentro do orçamento e do prazo.

3. Mencione quatro fatores que limitam
o cumprimento do objetivo de um
projeto.
Na realização do projeto, algumas circunstâncias imprevistas podem pôr em risco o cum-

primento do objetivo no que se refere a escopo, custo ou cronograma.
• O custo de alguns dos materiais pode ser mais alto do que originalmente estimado.
• As chuvas podem causar atrasos.
• Alterações de projeto e mudanças em uma máquina automatizada sofisticada podem
sem necessárias para que essa máquina atenda aos requisitos de uso.
O desafio do gestor de projetos é evitar, prever ou superar essas circunstâncias, a fim de

concluir o escopo do projeto dentro do prazo e do orçamento e obter a satisfação do cliente.
Bom planejamento e comunicação são essenciais para evitar a ocorrência de problemas ou
minimizar seu impacto sobre o objetivo do projeto, quando ocorrerem. O gestor do projeto
precisa ser proativo no planejamento e na comunicação e também servir de liderança para
que sua equipe cumpra o objetivo.
Por fim, a responsabilidade do gestor do projeto é garantir a satisfação do cliente. Isso
vai além de simplesmente concluir o escopo do projeto dentro do prazo e do orçamento,
ou de perguntar ao cliente, ao final, se ele ficou satisfeito. É necessário estabelecer uma
comunicação constante com o cliente a fim de mantê-lo informado e de determinar se suas
expectativas mudaram. Reuniões regulares ou relatórios de progresso, discussões freqüen-
tes pelo telefone e e-mails são exemplos desse tipo de comunicação. A satisfação do cliente
significa transformá-lo em um parceiro do resultado bem-sucedido do projeto por meio de
sua participação ativa durante o processo. O gestor deve estar ciente do grau de satisfação
do cliente no decorrer do projeto. Ao manter uma comunicação regular com o cliente, de-
monstrará a ele que está verdadeiramente preocupado com suas expectativas. Isso também
evita surpresas desagradáveis no futuro.
CICLO DE VIDA DO PROJETO

A Figura 1.2 mostra as quatro fases do ciclo de vida do projeto e a quantidade relativa de
esforço e tempo dedicada a cada fase. À medida que o projeto avança em seu ciclo de vida,
diferentes organizações, pessoas e recursos podem desempenhar papéis dominantes.
Os projetos “nascem” quando uma necessidade é identificada pelo cliente – a pessoa ou
organização disposta a fornecer fundos para que a necessidade seja atendida. Por exemplo,
para uma família em crescimento, a necessidade pode ser por uma casa maior, enquanto,
em uma empresa, o problema pode ser um elevado índice de desperdício em seu processo
FIGURA 1.2 Etapas do Ciclo de Vida do Projeto
Esforço
Identificar Desenvolver Executar o Concluir o

uma e propor projeto projeto
necessidade uma
solução
Tempo
de fabricação, que está elevando os custos e determinando que seu tempo de produção
seja maior que o de seus concorrentes. O cliente deve primeiro identificar a necessidade
ou problema. Às vezes, o problema é rapidamente identificado, como no caso de desastre,
terremoto ou explosão. Em outras situações, pode levar meses, até que um cliente identifi-
que claramente uma necessidade, reúna dados sobre o problema e defina certos requisitos
que devem ser atendidos pela pessoa, equipe de projeto ou fornecedor, a fim de resolver
o problema.
Essa primeira fase do ciclo de vida do projeto envolve a identificação de uma necessi-
dade, problema ou oportunidade e pode resultar na solicitação de propostas pelo cliente a
pessoas, uma equipe de projeto ou organizações (fornecedores) para atender à necessidade
identificada ou resolver o problema. A necessidade e os requisitos relativos a ela normal-
mente são escritos pelo cliente em um documento denominado Chamada de Propostas (CP)
– em inglês, Request For Proposal ou RFP. Por meio da CP, o cliente pede que pessoas
ou fornecedores enviem propostas sobre como resolver o problema, com os respectivos
custos e cronogramas. Um casal que precisa de uma casa nova pode levar certo tempo para
identificar os requisitos para a casa – tamanho, estilo, número de quartos, localização, valor
máximo que querem gastar e a data na qual gostariam de se mudar. Eles podem descrever
esses requisitos e pedir que vários fornecedores enviem planos e estimativas de custo para
o projeto. Uma empresa que tenha identificado a necessidade de atualizar seu sistema de
computadores pode documentar seus requisitos em uma chamada de propostas e enviá-la
a várias empresas de consultoria de informática.
Contudo, nem todas as situações envolvem uma chamada de propostas formal. Muitas
necessidades costumam ser definidas informalmente durante reuniões ou discussões entre
grupos de pessoas. Algumas delas podem se oferecer ou receber a ordem para preparar
uma proposta que determine se um projeto deve ser realizado para atender a uma neces-
sidade. Um cenário como esse pode acontecer quando o gerente de um hospital deseja
estabelecer um day care no local para os filhos de seus funcionários. A equipe de gerência
ou um gerente específico pode relacionar os requisitos em um documento e transmiti-lo à
equipe interna de projeto, que, por sua vez, enviará a proposta de como montar o centro.
Nesse caso, o fornecedor é a própria equipe interna de projeto, e o cliente é o administra-
dor do hospital, ou até mesmo sua diretoria. Definir a necessidade certa é importante. Por
exemplo, a necessidade é oferecer um day care no local, ou simplesmente ter um lugar
onde os funcionários do hospital possam deixar seus filhos enquanto trabalham? É realmen-
te necessário que o local seja no próprio hospital?
A segunda fase do ciclo de vida do projeto é o desenvolvimento de uma solução proposta
para a necessidade ou problema. Essa fase resulta na entrega de uma proposta ao cliente
por uma ou mais pessoas ou organizações (fornecedores) que gostariam que o cliente lhes
pagasse para implementar a solução proposta. Nessa fase, o esforço do fornecedor é domi-
nante. Os fornecedores interessados em responder à chamada de propostas podem levar
várias semanas para desenvolver abordagens e resolver o problema, estimando os tipos e
a quantidade de recursos que seriam necessários, bem como o tempo gasto para conceber
e implementar a solução proposta. Cada fornecedor documenta essas informações em uma
proposta escrita. Todos os fornecedores enviam suas propostas ao cliente. Por exemplo,
vários fornecedores podem enviar propostas para um cliente desenvolver e implementar
um sistema automatizado de cobrança e recebimento. Depois que avalia as propostas en-
tregues e seleciona a vencedora, o cliente e o fornecedor vencedor negociam e assinam
um contrato (acordo). Em muitos casos, uma chamada de propostas pode não envolver
a solicitação de propostas concorrentes de fornecedores externos. A própria equipe de
projeto interna de uma empresa pode desenvolver uma proposta em resposta a uma ne-
cessidade ou requisito definido pela gestão. Nesse caso, o projeto seria conduzido pelos
próprios funcionários da empresa, não por um fornecedor externo.
A terceira fase do ciclo de vida do projeto é a implementação da solução proposta. Essa
fase começa depois que o cliente decide qual das soluções propostas melhor atende a sua
necessidade, e ele e a pessoa/fornecedor que enviou a proposta chegam a um acordo.
Essa fase, conhecida como execução, envolve o planejamento detalhado do projeto e, em
seguida, a implementação desse plano para se atingir seu objetivo. Durante a execução do
projeto, diferentes tipos de recursos serão utilizados. Por exemplo, se o projeto for conce-
ber e construir um edifício comercial, sua execução pode primeiramente envolver alguns
arquitetos e engenheiros para desenvolver e documentar as soluções técnicas de constru-
ção. Em seguida, à medida que a construção avança, os recursos necessários aumentarão
consideravelmente, incluindo empreiteiros, carpinteiros, eletricistas, pintores etc. As coisas
ficarão mais calmas depois que a construção estiver concluída, e um número menor de
trabalhadores irá terminar o paisagismo e dar os últimos retoques no interior do edifício.
Essa fase resulta no cumprimento do objetivo do projeto, deixando o cliente satisfeito com
a conclusão do escopo total do trabalho com qualidade, dentro do prazo e sem superar
o orçamento. Por exemplo, a terceira fase está completa quando um fornecedor conclui a
concepção e a instalação de um sistema customizado que seja aprovado de maneira satisfa-
tória em testes de desempenho e seja aceito pelo cliente, ou quando uma equipe interna de
uma empresa conclui um projeto, em resposta a uma solicitação da gerência, consolidando
duas de suas instalações em apenas uma.
A fase final do ciclo de vida do projeto é a conclusão. Quando é concluído, algumas
atividades de encerramento precisam ser conduzidas, como a confirmação de que todos
os itens, serviços e produtos foram fornecidos e aceitos pelo cliente, as parcelas recebidas
e as faturas pagas. Nessa fase, uma importante tarefa é avaliar o desempenho do projeto
para aprender o que poderia ser melhorado se outro projeto semelhante for conduzido
no futuro. Essa fase deve incluir a obtenção de feedback do cliente para determinar seu
nível de satisfação e se o projeto atendeu às suas expectativas. Do mesmo modo, deve-se
obter feedback da equipe, na forma de recomendações para um melhor desempenho de
projetos futuros.

4. Relacione as fases do ciclo de vida
de um projeto, na coluna de cima, com
as descrições, na coluna de baixo:
___ Primeira fase
___ Segunda fase
___ Terceira fase
___ Quarta fase
A. Desenvolvimento da solução proposta
B. Implementação da solução proposta
C. Identificação da necessidade ou
problema
D. Conclusão do projeto
Os ciclos de vida dos projetos variam de acordo com a duração, podendo levar de algu-
mas semanas até vários anos, dependendo do conteúdo, da complexidade e da magnitude
do projeto. Além do mais, nem todos passam formalmente pelas quatro fases do ciclo de
vida. Se um grupo de voluntários decide que deseja usar seu tempo, talento e recursos
para organizar um sistema de alimentação para os sem-teto, pode-se ir direto para a fase 3
– planejamento e execução do evento. As primeiras duas fases do ciclo de vida não seriam
relevantes para um projeto como esse. Da mesma maneira, se o gerente geral de uma em-
presa determina que uma mudança de leiaute nos equipamentos da fábrica irá aumentar sua
eficácia, ele pode simplesmente instruir o gerente de fabricação a iniciar o projeto e a im-
plementá-lo usando os próprios funcionários da empresa. Nesse caso, não haveria nenhuma
solicitação por escrito para recebimento de propostas de fornecedores externos.
Em outras situações, como um projeto de remodelagem residencial, para o qual um
fornecedor provavelmente seria contratado, o cliente pode passar pelas duas primeiras fa-
ses do ciclo de vida do projeto de forma menos estruturada, mais informal. Ele pode não
esboçar todos os seus requisitos e pedir que vários fornecedores enviem orçamentos. Em
vez disso, ele pode chamar um fornecedor que fez um trabalho satisfatório para ele ou para
um vizinho, no passado, explicar o que quer e pedir que o fornecedor faça alguns esboços
e passe uma estimativa de custo.
Em geral, o ciclo de vida do projeto é seguido de maneira mais formal e estruturada
quando este é conduzido no ambiente corporativo. E tende a ser menos formal quando é
realizado individualmente ou por voluntários.
O PROCESSO DE GESTÃO DE PROJETOS

Em resumo, o processo de gestão de projeto significa planejar o trabalho e depois executar
o plano. Uma comissão técnica pode levar horas preparando planos estratégicos para uma
partida; o time então executa os planos para tentar chegar ao objetivo: vencer. De maneira
semelhante, gestão de projeto envolve primeiro um processo de estabelecer um plano e
depois implementar esse plano para atingir o objetivo do projeto.
O esforço inicial na gestão de um projeto deve se concentrar no estabelecimento de um
plano-base que contém um esquema mostrando como seu escopo será concluído dentro
do prazo e de acordo com o orçamento. Esse esforço de planejamento inclui as seguintes
etapas:
1. Defina claramente o objetivo do projeto. A definição deve ser acordada entre o cliente
e a pessoa ou organização que vai conduzir o projeto.
Produzindo Filmes
Musaffar Ali, famoso cineasta indiano, estava produzindo seu filme Zooni, em janeiro de
1989. O enredo baseia-se na vida de uma mulher chamada Habba Khatoon, uma lendária
poetisa nascida na Caxemira, região montanhosa ao norte do Paquistão.
Ali foi obrigado a interromper o projeto de seus sonhos por causa de ataques violen-
tos na Caxemira, onde estava filmando. Catorze anos mais tarde, com a paz começando a
se instalar na região, Ali está se preparando para terminar o filme. Como um especialista em
gestão de projetos, o que você poderia oferecer para ajudá-lo a alcançar seu objetivo?
A produção de um filme é um bom exemplo de um projeto em grande escala. Esse
processo envolve múltiplas tarefas que são conduzidas por uma equipe, as quais precisam
atender a certos requisitos, que são documentados em um roteiro. Existe um cronogra-
ma: um longa-metragem normalmente é produzido para uma data de estréia específica.
Existe um orçamento: o sucesso de um filme costuma ser medido pela comparação dos
custos de produção com a soma arrecadada após a estréia. Você, na função de gerente de
produção cinematográfica, poderia usar os princípios da gestão de projetos para manter
a produção do filme dentro do prazo e do orçamento.
Debbie Brubaker, produtora do filme Dopamine, apresentado no Festival de Sundance
2003, tem mais de 20 anos de experiência como gerente de produção. Ela descreve o pro-
cesso de produção de um filme e oferece conselhos para uma produção bem-sucedida. No
início, a equipe de gestão realiza um “desmembramento do roteiro”, que envolve a divisão
minuciosa de tarefas e outros fatores que ajudarão a determinar o cronograma e o orça-
mento de produção. Isso inclui a contagem do número especificado no roteiro do filme
de locações de filmagem e papéis com falas, os tipos de veículos exigidos para o filme, o
número de dublês e a quantidade de efeitos especiais. Em geral, as produções que têm
menos locações e papéis com falas custarão menos. Para conter os custos, o gerente de
produção deve limitar o número de locações de filmagem, trabalhar primeiro com as cenas
externas e não programar cenas difíceis no início e no fim. As cenas difíceis, como as com
forte carga emocional ou eventos cruciais para a trama, exigem mais tempo. Também será
necessário estabelecer uma comunicação aberta com o assistente de direção. Este tem a
responsabilidade geral pelo cronograma, mas seria sua função, como gerente de produção,
garantir que as filmagens saiam de acordo com o cronograma.
Musaffar Ali pretende concluir o projeto de seus sonhos dentro de um ano. Com a
utilização de princípios sólidos de gestão de projeto, ele deve conseguir se manter dentro
do orçamento e terminar seu filme conforme planejado.
Kapoor, D. What it Takes to Complete a Project on Time and on Budget. Digital Video Magazine, 1o de agosto de 2003,
p. 26. “14 Years On, Indian Filmmaker Wants to Complete Dream Project in Kashmir”, Financial Times Information Ltd.
2. Divida e subdivida o escopo do projeto em “frações” significativas, ou pacotes de

trabalho. Embora os grandes projetos pareçam assustadores quando vistos como
um todo, uma maneira de se superar até mesmo o mais monumental dos desafios é
desmembrá-lo. Uma estrutura analítica de projeto (EAP ou WBS) é uma árvore
hierárquica de elementos ou itens de trabalho realizados ou produzidos pela equipe
durante o projeto. Essa estrutura analítica normalmente define a organização ou pes-
soa responsável pelos pacotes de trabalho. A Figura 1.3 é um exemplo de estrutura
analítica de projeto (as estruturas analíticas de projeto serão discutidas mais adiante,
no Capítulo 5).
3. Defina as atividades específicas que precisam ser conduzidas para cada pacote de
trabalho a fim de atingir o objetivo do projeto.
FIGURA 1.3 Estrutura Analítica de Projeto
Nível 0
Festival
Lynn
Nível 1
1 2 3 4
Promoção Lista de Brinquedos
Jogos
Voluntários
Lynn Beth Steve Pat
Nível 2
1.1 1.2 1.3 3.1 3.2 3.3 4.1 4.2

Anúncios Fornecedor Autorizações
Cartazes Ingressos Cabines Jogos Prêmios de Parque de
no Jornal Diversões e Alvarás
Lynn Keith Andrea Jim Steve Jeff P at Neil
Nível 3
4. Ilustre graficamente as atividades na forma de um diagrama de rede. Esse diagrama

mostra a seqüência necessária e as interdependências das atividades para atingir o
objetivo do projeto. A Figura 1.4 é um exemplo de diagrama de rede (os diagramas
de rede serão discutidos mais adiante, no Capítulo 5).
5. Faça uma estimativa de tempo de quanto levará para completar cada atividade.
Também é necessário determinar que tipos de recursos são necessários e como cada
um será usado para que cada atividade seja realizada dentro do prazo estimado.
6. Faça uma estimativa de custo para cada atividade. O custo baseia-se nos tipos e
nas quantidades de recursos necessários a cada atividade.
5 6 7
Entretenimento Alimentação Serviços
Jeff Bill Jack
5.1 5.2 6.1 6.2 7.1 7.2 7.3 7.4
Artistas Arquibancada Alimentação Instalações Estacionamento Limpeza Banheiros Segurança
Jeff Jim Bill Chris Steve Tyler Jack Rose
5.2.1 5.2.2 5.2.3 7.2.1 7.2.2 7.3.1 7.3.2

Som e Posto de
Palco Assentos Recipientes Fornecedor Banheiros Primeiros
Iluminação Socorros
Jim Joe Jim Tyler Damian Jack Beth
6.2.1 6.2.2 6.2.3

Barracas de Equipamentos Praças de
de
Alimentação Cozinha Alimentação
Chris Bill Jim
7. Calcule um cronograma e um orçamento para determinar se o projeto pode ser con-

cluído dentro do prazo necessário, com os recursos financeiros alocados e os demais
recursos disponíveis. Caso contrário, pode-se fazer ajustes no escopo do projeto,
nas estimativas de duração das atividades ou nas atribuições de recursos até que se
chegue a um plano-base (esquema para se atingir o escopo do projeto no prazo e
dentro do orçamento) viável e realista. A Figura 1.5 mostra um exemplo de crono-
grama de projeto, e a Figura 1.6 ilustra um orçamento de projeto (esses tópicos serão
tratados nos Capítulos 6 a 9).
FIGURA 1.4 Diagrama de Rede
Preparar Etiquetas
para
Correspondência
5 Steve
Desenvolver Analisar
Identificar Testar Comentários Imprimir
Esboço de e Finalizar
Clientes-Alvo Questionário Questionário Questionário
Questionário
1 Susan 2 Susan 3 Susan 4 Susan 6 Steve
Desenvolver
Software de
Análise de Dados
7 Andy
Desenvolver Dados
de Teste de
Software
8 Susan

5. O ____________ do projeto deve ser
acordado entre o ____________ e a
pessoa ou organização que irá ________
____ o projeto.
O planejamento determina o que precisa ser feito, quem irá fazê-lo, quanto tempo irá
levar e quanto irá custar. O resultado é um plano-base. Despender um pouco de tempo
para desenvolver um plano bem concebido é fundamental para a realização e o sucesso
de qualquer projeto. Muitos projetos ultrapassaram seus orçamentos, passaram da data de
conclusão ou cumpriram requisitos apenas parcialmente porque não havia um plano-base
viável antes que fossem iniciados.
O plano-base de um projeto pode ser exibido em formato gráfico ou tabular para cada
período de tempo (semana, mês), desde o início até sua conclusão (os planos serão discu-
tidos e ilustrados na Parte 2). As informações devem incluir:
• as datas de início e conclusão para cada atividade;

• as quantidades dos vários recursos que serão necessários durante cada período de
tempo;
• o orçamento para cada período de tempo, bem como o orçamento acumulado desde
o início do projeto.
Enviar Preparar
Inserir Dados Analisar
Questionário Relatório
de Respostas Resultados
e Obter Respostas
9 Steve 11 Jim 12 Jim 13 Jim
Testar
Software
10 Andy
Legenda
Descrição da
Atividade
Número da
Atividade
Responsável

6. O esforço inicial da gestão de um
projeto envolve o estabelecimento de
um _____________________.
Após seu estabelecimento, o plano-base deve ser implementado. Isso envolve a realiza-
ção do trabalho de acordo com o plano, além do controle para que o escopo do projeto seja
atingido dentro do orçamento e do cronograma, obtendo a satisfação do cliente.
Uma vez iniciado o projeto, é necessário monitorar seu progresso para garantir que tudo
ocorra conforme planejado. Nessa etapa, o processo de gestão envolve medir o progres-
so real e compará-lo ao progresso planejado. Para medir o progresso real, é importante
manter-se informado sobre quais atividades foram realmente iniciadas ou concluídas, bem
como sua data de início e fim e os recursos despendidos em sua execução. Se, a qualquer
momento, a comparação do progresso real com o planejado vier a revelar que o projeto
está atrasado em relação ao cronograma, ultrapassando o orçamento ou não cumprindo
com as especificações técnicas, deve-se tomar medidas corretivas a fim de fazê-lo voltar
aos trilhos.
FIGURA 1.5 Cronograma para Projeto de Estudo de Mercado Consumidor

Projeto de Estudo de Mercado Consumidor
Dur. Mais Cedo Mais Tarde Folga

Atividade Respon. Estim. Início Término Início Término Total
1 Identificar Clientes-Alvo Susan 3 0 3 –8 –5 –8

2 Desenvolver Esboço de
Susan 10 3 13 –5 5 –8
Questionário
3 Testar Questionário Susan 20 13 33 5 25 –8
4 Analisar Comentários e
Susan 5 33 38 25 30 –8
Finalizar Questionário
5 Preparar Material para
Steve 2 38 40 38 40 0
Correspondência
6 Imprimir Questionário Steve 10 38 48 30 40 –8
7 Desenvolver Software de
Andy 12 38 50 88 100 50
Análise de Dados
8 Desenvolver Dados de Teste
Susan 2 38 40 98 100 60
de Software
9 Enviar Questionário e Obter
Steve 65 48 113 40 105 –8
Respostas
10 Testar Software Andy 5 50 55 100 105 50
11 Inserir Dados de Respostas Jim 7 113 120 105 112 –8
12 Analisar Resultados Jim 8 120 128 112 120 –8
13 Preparar Relatório Jim 10 128 138 120 130 –8

7. A implementação do plano-base de
um projeto envolve a ____________ do
trabalho de acordo com o plano e o
____________ do trabalho para que o
escopo do projeto seja atingido dentro
do ___________ e do ___________,
obtendo a ____________.
Antes de se decidir sobre a implementação de medidas corretivas, pode ser necessário

avaliar várias ações alternativas a fim de se garantir que essas medidas permitirão que o
projeto se encaixe novamente nas limitações de escopo, prazo e orçamento do objetivo.
Assim, cuidado ao adicionar recursos para compensar atrasos e voltar ao cronograma, pois
isso pode ultrapassar o orçamento planejado. Se um projeto ficar muito fora de controle,
pode ser difícil atingir seu objetivo sem sacrificar o escopo, o orçamento, o cronograma ou
a qualidade.
O segredo para um controle eficaz de projeto é medir o progresso real e compará-lo ao
progresso planejado em intervalos regulares, adotando medidas corretivas imediatamente,
FIGURA 1.6 Curva de Custo Orçado Acumulado

Custo Orçado Acumulado (em milhares de U$S)
Custo Orçado Acumulado

(em milhares de US$)
100
90
80 Custo
Orçado
70 Total
60
50
40
30
20
10
1 2 3 4 5 6 7 8 9 10 11 12
Semanas
se necessário. Esperar que um problema desapareça sem uma intervenção corretiva é inge-
nuidade. Com base no progresso real, é possível prever um cronograma e orçamento para a
conclusão do projeto. Se esses parâmetros estiverem além dos limites do objetivo, medidas
corretivas devem ser implementadas imediatamente.
A tentativa de se realizar um projeto sem antes estabelecer um plano-base é temerária.
É como sair de férias sem ter um mapa, um itinerário e um orçamento. Você pode acabar
no meio do nada – sem dinheiro e sem tempo!
BENEFÍCIOS DA GESTÃO DE PROJETOS
O benefício maior da implementação de técnicas de gestão de projeto é ter um cliente satis-

feito – seja você o cliente de seu projeto, como para remodelar sua casa, seja uma empresa
(fornecedor) paga por um cliente para realizá-lo. A conclusão do escopo total do projeto
com qualidade, dentro do prazo e sem superar o orçamento, traz um grande sentimento de
satisfação. Para um fornecedor, isso poderia levar a mais negócios com o mesmo cliente no
futuro ou com novos clientes indicados pelo cliente previamente satisfeito.
“Ei! Ótimo para o cliente, mas e eu? O que sobra para mim?”. Se for o gestor do projeto,
você tem a satisfação de saber que liderou um projeto bem-sucedido. Você também melho-
rou sua reputação como gestor de projetos e se posicionou melhor no mercado, o que pode
lhe trazer oportunidades melhores. Se fizer parte de uma equipe que realizou um projeto
FAT O R E S E S S E N C I A I S PA R A O S U C E S S O
• Planejamento e comunicação são essenciais para uma gestão de projeto bem-suce-

dida. Isso evita a ocorrência de problemas ou minimiza seu impacto sobre o objetivo
do projeto, quando ocorrem.
• Despender um pouco de tempo para desenvolver um plano bem concebido é fun-
damental para a realização bem-sucedida de qualquer projeto.
• Um projeto deve ter um objetivo bem definido – um resultado ou produto es-
perado, definido em termos de escopo, cronograma e custo, a ser acordado com
o cliente.
• Envolver o cliente como um parceiro para o sucesso do projeto, por meio de sua
participação ativa durante o projeto.
• Conseguir a satisfação do cliente requer comunicação constante com ele para
mantê-lo informado e determinar se as expectativas mudaram.
• O segredo para um controle eficaz de projeto é medir o progresso real e compará-lo
ao progresso planejado em intervalos regulares adotando-se as medidas corretivas
imediatamente, se necessário.
• Após a conclusão de um projeto, o desempenho deste deve ser avaliado para se
aprender o que poderia ser melhorado, caso um plano semelhante seja conduzido
no futuro. Deve-se obter feedback do cliente e da equipe do projeto.
com sucesso, sentirá que está em uma equipe vencedora. Você não apenas contribuiu para
o sucesso do empreendimento, mas também provavelmente expandiu seu conhecimento e
aprimorou suas habilidades ao longo do caminho. Se optar por continuar sendo um cola-
borador individual, será capaz de oferecer uma contribuição maior em projetos futuros, mais
complicados. Se estiver interessado em eventualmente gerenciar projetos, estará em condições
de assumir outras responsabilidades no projeto.
Quando um projeto é bem-sucedido, todo mundo sai ganhando!
RESUMO
Um projeto é o esforço para se atingir um objetivo específico por meio de um conjunto úni-
co de tarefas inter-relacionadas e da utilização eficaz de recursos. Possui um objetivo bem
definido em termos de escopo, cronograma e custo. A responsabilidade do gestor do projeto
é garantir que seu objetivo seja atingido e que o escopo do trabalho seja concluído com
qualidade, dentro do orçamento e do prazo, obtendo, conseqüentemente, a satisfação do
cliente.
A primeira fase do ciclo de vida do projeto envolve a identificação de uma necessidade,
problema ou oportunidade e pode resultar na solicitação de propostas pelo cliente a pes-
soas, a uma equipe de projeto ou a organizações (fornecedores), para atender à necessidade
identificada ou resolver o problema. A segunda fase é o desenvolvimento de uma solução
proposta para a necessidade ou problema. Essa fase resulta na entrega de uma proposta ao
cliente por uma ou mais pessoas ou organizações ou pela equipe de projeto. A terceira fase
é a implementação da solução proposta. Conhecida como execução do projeto, resulta na
obtenção do objetivo do projeto, deixando o cliente satisfeito com a conclusão do escopo
total do trabalho com qualidade, sem ultrapassar o orçamento e dentro do prazo. A fase
final do ciclo de vida do projeto é a conclusão, que inclui uma avaliação dos resultados da
sua execução, a fim de aprimorar o trabalho para projetos futuros.
A gestão de projeto envolve um processo de primeiro estabelecer um plano e depois
implementá-lo para atingir o objetivo do projeto. Esse esforço de planejamento inclui a
definição clara de objetivos, a divisão e subdivisão do escopo do projeto em “frações”
significativas chamadas pacotes de trabalho, a definição das atividades específicas que de-
verão ser conduzidas para cada um deles, a representação gráfica das atividades na forma
de diagrama de rede, a estimativa do tempo que cada atividade levará para ser concluída,
a definição dos tipos de recursos e a quantidade necessária de recursos para dada ativi-
dade, a estimativa do custo de cada atividade e o cálculo do cronograma e do orçamento
do projeto.
Despender um pouco de tempo para desenvolver um plano bem concebido é funda-
mental para a realização bem-sucedida de qualquer projeto. Uma vez iniciado o projeto,
é necessário que o gestor monitore seu progresso para garantir que tudo saia conforme
planejado. O segredo para um controle eficaz de projeto é medir o progresso real e com-
pará-lo ao progresso planejado em intervalos regulares, adotando-se as devidas medidas
O benefício maior da implementação de técnicas de gestão de projeto é ter um cliente
satisfeito – seja você o cliente do próprio projeto, seja uma empresa (fornecedor) paga por
um cliente para realizar um projeto. A conclusão do escopo total do projeto com qualidade,
dentro do prazo e sem superar o orçamento, acarreta um grande sentimento de satisfação
para todos os envolvidos.
PERGUNTAS
1. Defina projeto.
2. Defina a expressão objetivo do projeto e dê alguns exemplos.
3. Relacione alguns exemplos de recursos utilizados em um projeto.
4. Qual é o papel do cliente durante o ciclo de vida do projeto?
5. Quais aspectos de um projeto podem envolver certo grau de incerteza? Por quê?
6. Defina escopo, cronograma, custo e satisfação do cliente. Por que esses itens são con-
siderados limitações para o projeto?
7. Por que é importante obter a satisfação do cliente?
8. Relacione e descreva as principais fases do ciclo de vida do projeto.
9. Relacione e descreva as etapas necessárias para se desenvolver um plano-base.
10. Por que o gerente deve monitorar o progresso de um projeto? O que pode ser feito caso
determinado projeto não esteja evoluindo conforme planejado?
11. Relacione alguns benefícios do uso de técnicas de gestão de projeto.
12. Pense em um projeto no qual você está envolvido atualmente ou um projeto do qual
participou recentemente.
a. Descreva os objetivos, o escopo, o cronograma, o custo e quaisquer suposições
feitas.
b. Qual é a sua posição no ciclo de vida do projeto?
c. Esse projeto possui um plano-base? Em caso afirmativo, descreva-o. Em caso nega-
tivo, crie-o.
d. Você ou outra pessoa está monitorando o progresso do projeto? Em caso afirmativo,
de que modo isso ocorre? Em caso negativo, como isso poderia ser feito?
e. Descreva algumas circunstâncias inesperadas que poderiam pôr em risco o sucesso

do projeto.
f. Descreva os benefícios previstos do projeto.
EXERCÍCIOS NA INTERNET
Caso tenha dificuldade para acessar algum dos sites relacionados a seguir, você pode
encontrar os exercícios (com endereços atualizados) em nosso site: www.towson.edu/
~clements.
1. Usando sua ferramenta de busca favorita na Internet (Yahoo, AskJeeves, Google,

GoTo, Lycos, Excite etc.), faça uma busca por “gestão de projetos” (ou “project mana-
gement”). Explore pelo menos cinco dos links produzidos pela busca. Dê o endereço
de cada site e descreva seu conteúdo.
2. Faça várias buscas adicionais na Internet acrescentando, na expressão “gestão de
projetos”, algumas das palavras-chave relacionadas neste capítulo. Por exemplo, bus-
que “objetivos da gestão de projetos”, “ciclo de vida da gestão de projetos”, “processo
de gestão de projetos”, “estrutura analítica de projeto” e assim por diante. O que você
encontrou?
3. Desde que foi fundado, em 1969, o Project Management Institute (PMI) cresceu e
agora conta com mais de 85.000 membros no mundo todo. O PMI, sediado na Pen-
silvânia (EUA), é de longe a maior associação profissional sem fins lucrativos na área
de gestão de projetos. Ele estabelece padrões, promove seminários, desenvolve pro-
gramas educacionais, possui um programa de certificação profissional e publica os
periódicos Project Management Journal e PM Network. Possui também um website
excelente sobre gestão de projetos na Internet, www.pmi.org. Confira as informa-
ções sobre associação, certificações, ensino e publicações. Descreva os benefícios de
ser um associado. Faça sua inscrição on-line se estiver interessado (há taxas especiais
para estudantes).
4. O PMI possui divisões em todo o mundo. Visite o link da divisão local do PMI.
Observe os membros e a organização que cada membro representa. Siga os links
para as páginas de outras divisões do PMI.
5. Visite os links PM Network Online e PMI Today Online, duas excelentes fontes de
informação sobre gestão de projetos publicadas pelo PMI. Selecione um artigo de seu
interesse, localize-o na biblioteca on-line e faça o resumo de uma página.
ESTUDO DE CASO nº 1 Uma Organização sem Fins Lucrativos
A diretoria de uma organização local sem fins lucrativos, que arrecada e compra alimentos
para distribuí-los à população carente, está realizando sua reunião de diretoria do mês de
fevereiro. Na sala de reunião, estão Beth Smith, presidente, e dois outros membros da dire-
toria, Rosemary Olsen e Steve Andrews. Beth anuncia: – Nossos fundos estão quase no fim.
As demandas do banco de alimentos e da cozinha de sopa estão aumentando. Precisamos
descobrir um modo de levantar mais fundos.
– Precisamos de um projeto para levantar fundos, responde Rosemary.
Steve sugere: – Não podemos pedir que o governo local aumente os fundos destinados
a nós?
– O governo está no limite. Eles podem até cortar nossos fundos no ano que vem, res-
ponde Beth.
– De quanto precisamos para este ano? – pergunta Rosemary.
– De cerca de US$ 10.000,00, responde Beth. – E vamos precisar desse dinheiro em mais
ou menos dois meses.
– Necessitamos de muita coisa além de dinheiro. Precisamos de mais voluntários, mais
espaço para estoque e outra geladeira para a cozinha, afirma Steve.
– Bem, acho que podemos incluir tudo isso no projeto de arrecadação de fundos. Vai
ser divertido! – afirma Rosemary, entusiasmada.
– Esse projeto está crescendo. Nós nunca iremos terminá-lo a tempo – diz Beth.
Rosemary responde: – Vamos descobrir um modo de realizá-lo. Sempre conseguimos.
– O que precisamos é mesmo de um projeto? O que vamos fazer no próximo ano, outro
projeto? – pergunta Steve. – Além do mais, estamos com dificuldades para conseguir volun-
tários. Talvez devamos pensar em como trabalhar com menos fundos. Por exemplo, como
podemos conseguir mais doações regulares de alimentos para não termos de comprar tanta
comida?
Rosemary se empolga. – Ótima idéia! Você cuida disso, enquanto nós tentamos levantar
fundos. Não podemos deixar nada de lado.
– Vamos com calma, diz Beth. – Essas idéias são todas muito boas, mas temos fundos limi-
tados, poucos voluntários e uma demanda crescente. Precisamos fazer alguma coisa agora
para garantir que não tenhamos de fechar as portas em dois meses. Acho que todos con-
cordamos que precisamos tomar uma iniciativa. Mas não estou bem certa de que todos
concordamos sobre o objetivo.
PERGUNTAS
1. Quais foram as necessidades identificadas?

2. Qual é o objetivo do projeto?
3. Quais suposições, se for o caso, deveriam ser feitas em relação ao projeto a ser reali-
zado?
4. Quais são os riscos envolvidos no projeto?
ATIVIDADE EM GRUPO
Entre em contato com uma organização sem fins lucrativos de sua comunidade. Diga aos
responsáveis que está interessado em saber mais sobre seu funcionamento. Peça que eles
descrevam um projeto no qual estejam trabalhando atualmente. Quais são os objetivos?
As limitações? Os recursos?
Se possível, faça sua equipe colaborar para o projeto durante algumas horas. Com esse
procedimento, vocês ajudarão pessoas necessitadas e, ao mesmo tempo, aprenderão em um
projeto real. Elabore um relatório resumindo o projeto e o que você aprendeu com essa
experiência.
ESTUDO DE CASO nº 2 E-Commerce para um Supermercado Pequeno
Matt e Grace são donos de um pequeno supermercado em uma cidadezinha do inte-

rior, com uma população mais velha grande e em crescimento. Em função da localiza-
ção afastada, eles não sofrem com a concorrência de grandes cadeias de supermercado.
Na cidade, também há uma pequena faculdade particular de ciências humanas, com cerca
de 1.500 alunos.
– Acho que precisamos de um site para nossa loja, Matt diz a Grace.
– Por quê?, pergunta ela.
– Todo mundo tem um site. É a tendência do futuro, responde Matt.
– Ainda não entendi completamente. O que colocaríamos em nosso site? – pergunta
Grace.
– Bem, primeiro poderíamos ter uma foto do nosso mercado com nós dois na frente,
diz Matt.
– O que mais? – pergunta Grace.
Matt responde: – Ah, talvez as pessoas poderiam pesquisar as coisas e fazer pedidos
pela Internet. Sim, esse pessoal da faculdade adoraria isso; eles usam o computador o tem-
po todo. Isso aumentará nossos negócios. Eles comprarão comida de nossa loja em vez
das pizzas e dos hambúrgueres que sempre comem ou pedem no Sam’s Sub Shop. E os
moradores do residencial da terceira idade o utilizariam também. Fiquei sabendo que eles
estão aprendendo a usar o computador. E, quem sabe, podemos até criar um serviço de
delivery?
– Espere um minuto, diz Grace. – Os alunos da faculdade pedem pizza e lanches no
Sam’s durante a noite toda, muito depois de termos fechado. E acho que os moradores mais
velhos gostam de sair um pouco. Eles têm uma van para trazê-los até aqui todos os dias
para fazer compras; e, não compram muita coisa, de qualquer modo. Como eles pagarão por
seus pedidos pela Internet? Sou totalmente a favor de nos mantermos sempre atualizados,
mas não tenho certeza se isso faz sentido para nosso mercadinho, Matt. O que tentaríamos
conseguir com um site na Internet?
– Eu só estava explicando a você, Grace. É o que todos os estabelecimentos comerciais es-
tão fazendo. Ou nós seguimos a onda dos negócios, ou vamos ficar de fora, responde Matt.
– Isso tem alguma coisa a ver com aquela reunião da Câmara de Comércio em Big Falls
a que você foi na semana passada, onde você disse que havia um consultor falando sobre
e-commerce ou algo assim? – pergunta Grace.
– Sim, talvez, diz Matt. – Acho que vou ligar para ele e pedir que nos faça uma visita,
para que eu possa lhe explicar o que quero.
– Quanto tudo isso irá nos custar, Matt? – Grace pergunta. – Acho que precisamos pensar
mais um pouco sobre isso. Você sabe que nós talvez precisemos asfaltar o estacionamento
no verão.
Matt responde: – Não se preocupe. Tudo vai dar certo. Confie em mim. Nossos negócios
vão crescer tanto que tudo irá se pagar em pouco tempo. Além do mais, não pode custar
tanto assim; provavelmente, esse consultor faz esse tipo de projeto o tempo todo.
PERGUNTAS
1. Quais foram as necessidades identificadas?

2. Qual é o objetivo do projeto?
3. O que Matt e Grace devem fazer antes de conversar com o consultor?
4. O que o consultor deve dizer a Matt e Grace?
ATIVIDADE EM GRUPO
Escolha dois participantes do curso para dramatizar essa situação interpretando Matt e
Grace. Em seguida, divida os participantes em grupos de três ou quatro para que possam
discutir as perguntas sobre o caso. Cada grupo deve eleger um porta-voz que vai apresentar
suas respostas para o restante da turma.
ATIVIDADE OPCIONAL
Peça que cada participante do curso entre em contato com um estabelecimento comercial
que criou um site na Internet e pergunte ao proprietário o que o levou a essa decisão e se
o projeto atendeu a suas expectativas iniciais.
Capítulo IDENTIFICAÇÃO DE NECESSIDADES
2 Identificação de Necessidades
Seleção de Projetos
Preparando uma Chamada de
Propostas
Estudo de Caso no 1
Uma Empresa Farmacêutica de
Médio Porte
Perguntas
Solicitando Propostas Atividade em Grupo
Resumo Estudo de Caso no 2
Melhorias no Transporte
Perguntas
Perguntas
Atividade em Grupo
24
Ca pítulo Dois
Projeto Hippodrome Theater
O recém-reformado Hippodrome Theater, em Baltimore, no Estado de Maryland (EUA), rea-
briu suas portas em 6 de fevereiro de 2004, liderando o renascimento econômico e cultural
do lado oeste da cidade, havia muito negligenciado. Em sua nova forma, diferentes espaços
foram criados para que o teatro passasse a contar com instalações modernas, como ante-
salas espaçosas, lanchonete, estacionamento, iluminação de alta tecnologia e novos equi-
pamentos de som. Além de projetar e construir essas conveniências modernas, foram gastas
várias horas de pesquisa e trabalho na preservação e restauração de detalhes ornamentais
no teto e nas paredes do teatro original. A iniciativa foi possibilitada pelos apoiadores do
projeto, que estavam a serviço de sua comunidade.
O Hippodrome Theater, concebido por Thomas W. Lamb, foi originalmente palco regular
de espetáculos de variedades. Foi inaugurado em 23 de novembro de 1914, com acrobatas,
comediantes e elefantes para entreter as platéias noturnas. No final da década de 1930, o
comediante Red Skelton e os Três Patetas originais se apresentaram no teatro. O público
também pôde assistir a musicais com Frank Sinatra e Glenn Miller e sua orquestra. Outro
evento memorável foi uma apresentação de teatro de revista que contou com celebrida-
des como Ronald Reagan e Jane Wyman. A região se tornou um agitado e próspero centro
comercial. O teatro parou de apresentar espetáculos ao vivo e transformou-se em cinema
na década de 1950. Por curto período de tempo, foi novamente transformado em teatro
para apresentações ao vivo. O ambiente começou a mudar com o advento da televisão e a
abertura das grandes lojas de departamentos fora dos centros comerciais, o que afastou as
pessoas da região e acarretou um conseqüente impacto negativo nos negócios. Nas déca-
das de 1970 e 1980, o teatro transformou-se em cinema pornô. Com o declínio econômico
da região, o prédio foi oficialmente fechado em 1990.
O Greater Baltimore Committee (GBC), formado por líderes civis e empresários, deci-
diu buscar apoio financeiro para restaurar o antigo teatro. Eles convidaram o governador
do Estado e outras autoridades estaduais para uma visita ao decadente teatro no início de
1998. Apesar da iluminação fraca e temporária, dos buracos no piso e das infiltrações no
teto de gesso, eles conseguiram enxergar seu potencial para revitalizar as atividades eco-
nômico-culturais da comunidade. Os primeiros sinais do renascimento puderam ser obser-
vados quando a University of Maryland, em Baltimore, expandiu seu campus, com mais de
US$ 200 milhões em investimentos em novos edifícios. O GBC apresentou um plano para
reconstruir o teatro e oferecer serviços para a região, que incluiu a criação da The Hippo-
drome Foundation, que apóia o relacionamento do teatro com a comunidade local. O tra-
balho da Fundação se concentra no redesenvolvimento da região, na oferta de ingressos a
preços acessíveis e em programas educacionais para incentivar o envolvimento dos jovens
com as artes. O comitê recebeu apoio financeiro do Estado, do município, de uma cidade
vizinha, de instituições financeiras e fundações privadas para o projeto de restauração. A
France-Merrick Foundation ofereceu uma doação e se tornou a maior doadora privada do
projeto. Em junho de 2002, cerimônias de abertura para o projeto de US$ 65 milhões foram
realizadas. A construção foi concluída a tempo para o espetáculo de inauguração, The Pro-
ducers, que ocorreu no dia 10 de fevereiro de 2004.
Beamon, T. The Long Road to Opening Night – Civic Leaders’ Bold Strategy Succeeded in Raising Millions for Hippodrome
Project, Setting the Stage for a Renaissance on City’s West Side. Sun Paper, 10 de fevereiro de 2004.
Donovan, D. Here, Everything Old Is Made New Again – Hippodrome: As the Vision for the Performing Arts Center Nears
Completion, a Crew Works to Restore the Building to Its Former Glory. Sun Paper, 28 de março de 2003.
Gunts, E. A Dramatic Rebirth – A Newly Restored Hippodrome Theater Complex Is a Bridge to Both a Glorious Past and a
Hopeful Future. Sun Paper, 8 de fevereiro de 2004.
25
Recapitulando, o ciclo de vida do projeto é composto de quatro fases: identificação de

necessidades, proposição de uma solução, execução e conclusão do projeto. Este capí-
tulo se concentra na identificação das necessidades, a primeira fase do ciclo de vida do
projeto (veja Figura 2.1). Vamos nos aprofundar:
• na identificação de necessidades e seleção de projetos;
• no desenvolvimento de uma chamada de propostas;
• no processo de solicitação de propostas.
IDENTIFICAÇÃO DE NECESSIDADES
A identificação de necessidades é a fase inicial do ciclo de vida do projeto. Ela começa
com o reconhecimento de uma necessidade, problema ou oportunidade e termina com a
emissão da chamada de propostas (CP). O cliente identifica uma necessidade, problema ou
oportunidade de fazer melhor alguma coisa e, a partir disso, acha vantajoso executar um
projeto que resulte em melhora ou benefício de uma situação existente.
Por exemplo, imagine que a gerência de uma empresa reconheça que o tempo gasto
com a emissão de notas fiscais e o recebimento de pagamentos de seus clientes seja longo
demais. Além disso, a falta de atualização dos registros de pagamentos da empresa provoca
o envio de novas notas fiscais a clientes que já pagaram, gerando desconforto para os bons
clientes. Da mesma maneira, à medida que os negócios crescem, mais funcionários adminis-
trativos devem ser contratados para processar as notas fiscais e os pagamentos adicionais,
e mais gabinetes de arquivos devem ser comprados para armazenar a quantidade crescente
de papéis. A gerência reconhece vários problemas e oportunidades de melhoria, então, de-
senvolve uma CP solicitando que fornecedores enviem propostas para a implementação de
um sistema de cobrança e recebimento automatizado. Em um cenário diferente, a gerência
da empresa poderia também solicitar uma proposta para um funcionário ou uma equipe de
projeto interna no lugar de um fornecedor externo.
Antes da elaboração de uma CP, o cliente deve definir claramente o problema ou a ne-
cessidade. Isso pode implicar a coleta de dados sobre a magnitude do problema. Por exem-
plo, se uma empresa acredita que o índice de desperdício ou refugo em seu processo de
fabricação é elevado demais, pode ser necessário coletar dados sobre os índices reais e seu
impacto sobre os custos e durações de ciclos. É importante tentar quantificar o problema
FIGURA 2.1 Ciclo de Vida do Projeto
Chamada de
Propostas
Objetivo
Esforço Acordo do projeto
Identificar Desenvolver Executar
uma uma o projeto Concluir o
necessidade solução projeto
proposta
Tempo
Capítulo 2 Identificação de Necessidades 27
a fim de determinar se os benefícios esperados com a implementação de uma solução são

maiores que os custos ou as conseqüências da realização do projeto e, em caso afirmativo,
até que ponto isso ocorre.
Uma vez que a magnitude do benefício ou da melhoria tenha sido estimada, o cliente
pode determinar o orçamento de um projeto para implementar essa melhoria. Por exem-
plo, se uma empresa estima que poderia economizar US$ 100.000,00 por ano, reduzindo
seu índice de desperdício de 5% para 1%, ela pode estar disposta a pagar um valor único
de US$ 200.000,00 por novos equipamentos de produção automatizados, compensando
seu investimento após dois anos de operação dos novos equipamentos. Contudo, pode ser
que não esteja disposta a gastar US$ 500.000 com uma solução. As empresas contam com
uma quantia limitada de recursos disponíveis e, portanto, normalmente querem gastar esses
recursos em projetos que proporcionem o maior retorno sobre o investimento ou benefício
global. Mesmo em um exemplo fora do mundo corporativo, como realizar um evento co-
memorativo de uma data nacional, geralmente há um orçamento dentro do qual o projeto
deve ser conduzido.

1. A fase inicial do ciclo de vida do
projeto é a _____________________,
que começa com o reconhecimento de uma
necessidade ou oportunidade e termina
com a emissão de uma ______________.
É comum haver situações em que uma empresa identifica várias necessidades, mas dis-
põe de recursos e pessoal limitados disponíveis para a realização de projetos para atender
a todas as necessidades identificadas. Nesses casos, a empresa deve passar por um proces-
so de decisão, a fim de selecionar as necessidades que, se forem atendidas, resultarão no
maior benefício global.
SELEÇÃO DE PROJETOS
A seleção de projetos envolve a avaliação de várias necessidades ou oportunidades e
uma posterior decisão sobre quais entre elas deveriam evoluir para um projeto a ser im-
plementado. Os benefícios e conseqüências, as vantagens e desvantagens, os pontos po-
sitivos e negativos de cada oportunidade precisam ser considerados e avaliados. Estes
podem ser quantitativos e qualitativos, tangíveis e intangíveis. Os benefícios quantitati-
vos podem ser financeiros, como um aumento de vendas ou uma redução de custos. Tam-
bém podem ser intangíveis, associados a uma oportunidade, como uma melhora na imagem
pública de uma empresa ou na motivação de seus funcionários. De outro lado, existem
conseqüências quantitativas associadas a cada oportunidade, como o custo necessário para
implementar o projeto ou a diminuição de produção, enquanto este estiver sendo imple-
mentado. Algumas conseqüências podem ser menos tangíveis, como barreiras legais ou
reações de um grupo militante em particular.

2. A seleção de projetos envolve a
____________ de várias necessidades ou
oportunidades, e uma posterior _______
________ sobre quais entre elas
deveriam evoluir para um ____________.

3. Os benefícios e as conseqüências
podem ser tanto__________________ e
tangíveis quanto qualitativos e _______
___________________.
As etapas de seleção de projeto são as seguintes:
1. Desenvolva um conjunto de critérios em conformidade com a oportunidade que será

avaliada. Esses critérios provavelmente incluirão tanto fatores quantitativos como
qualitativos. Por exemplo, se considerar oportunidades que envolvam o desenvolvi-
mento e o lançamento de vários novos produtos, uma empresa farmacêutica pode
avaliar cada oportunidade de acordo com os seguintes critérios:
• Alinhamento com as metas da empresa;
• Volume de vendas previsto;
• Aumento de participação de mercado (market share);
• Estabelecimento de novos mercados;
• Preço final para o consumidor (projetado);
• Investimento necessário;
• Custo de fabricação estimado por unidade;
• Tecnologia necessária;
• Retorno sobre o investimento;
• Impacto sobre os recursos humanos;
• Reação do público;
• Reação dos concorrentes;
• Tempo esperado;
• Aprovações regulamentares.
Às vezes, as oportunidades e necessidades podem não ser todas semelhantes,
como diversos produtos alternativos novos. Elas podem ser completamente diferen-
tes e competir entre si pelos recursos da empresa. Uma delas pode envolver a coloca-
ção de uma nova cobertura na fábrica, outra pode ser a implementação de um novo
sistema de informação, e a terceira pode estar relacionada ao desenvolvimento de um
novo produto que substituirá um antigo ou para o qual as vendas estejam sofrendo
uma queda significativa.
2. Relacione suposições que serão usadas como base de cada oportunidade. Por exem-
plo, se uma oportunidade envolve a construção de um day care para crianças e
parentes idosos dos funcionários de uma empresa, uma das suposições pode ser que
a esta talvez precise fazer um empréstimo bancário para a construção.
3. Reúna dados e informações sobre cada oportunidade, a fim de garantir uma decisão
inteligente no que se refere à seleção do projeto. Por exemplo, pode ser necessário
reunir algumas estimativas financeiras preliminares associadas a cada oportunidade,
como projeções estimadas de faturamento e custos operacionais e de implementa-
ção. Esses custos podem então ser analisados com base em alguns modelos finan-
ceiros matemáticos, para que sejam comparados de modo equivalente. Tais mode-
los financeiros e econômicos incluem metodologias usadas para calcular a simples
compensação, o fluxo de caixa futuro, o valor presente líquido, a taxa de retorno
interna, o retorno sobre o investimento ou custos de ciclo de vida associados a cada
oportunidade considerada.
Além da coleta de dados concretos, também será necessário obter outras informa-
ções sobre cada oportunidade. Isso pode incluir a opinião de várias partes interes-
sadas (funcionários, consumidores ou moradores da comunidade, dependendo da
oportunidade específica) que seriam afetadas por essa oportunidade. Os métodos

para a obtenção dessas informações envolvem pesquisas, grupos focais, entrevistas
ou análises de relatórios disponíveis. Por exemplo, se as oportunidades consideradas
estiverem relacionadas ao lançamento de vários produtos alimentícios alternativos
no mercado, será interessante conduzir alguns grupos focais com os consumidores
para determinar suas necessidades e preferências. No caso da construção de um day
care, valerá a pena fazer um levantamento entre os funcionários, a fim de determinar
quantos deles usariam o Centro para deixar suas crianças ou parentes idosos e com
que freqüência (todos os dias, segundo turno, antes ou depois da escola), a faixa etá-
ria das crianças, os problemas de saúde dos parentes idosos e assim por diante.
4. Avalie cada oportunidade de acordo com os critérios. Após a coleta, análise e resumo
de todos os dados e informações de cada oportunidade, estes devem ser fornecidos
aos responsáveis pela avaliação. É interessante que haja várias pessoas envolvidas na
avaliação e seleção, a fim de se obter pontos de vista variados. É importante colocar
pessoas com históricos e experiências diferentes para fazer parte da equipe ou do
comitê de avaliação, enriquecendo, conseqüentemente, o processo de tomada de de-
cisão. Pode haver uma pessoa do marketing, que entenda sobre as preferências dos
consumidores; alguém de finanças, que conheça os custos e a situação financeira da
empresa; um membro da produção, que entenda quais mudanças serão necessárias
nos processos e equipamentos; alguém de pesquisa e desenvolvimento, que opine so-
bre quanto de tecnologia adicional pode ser necessário; e alguém de recursos huma-
nos para representar qualquer impacto sobre a força de trabalho ou a comunidade.
Embora possa levar mais tempo e ser mais estressante obter o consenso do grupo sobre
a seleção do projeto e as prioridades, a decisão provavelmente será de melhor qualidade
que a decisão tomada apenas por uma pessoa. A aceitação da decisão também será maior.
Uma abordagem para o processo de avaliação e seleção seria fazer que o comitê respon-
sável desenvolvesse um conjunto de critérios de avaliação. Eles também podem elaborar
algum tipo de sistema de classificação (como Alto-Médio-Baixo, 1 a 5, 1 a 10) para classifi-
car o desempenho de cada oportunidade, segundo cada critério. Em seguida, os membros
do comitê devem receber todos os dados e informações coletados, analisados e resumidos.
Antes da reunião de todo o comitê, cada membro pode individualmente avaliar os benefí-
cios e as conseqüências, as vantagens e desvantagens de cada oportunidade, segundo os
critérios de avaliação. Isso dará a cada membro tempo suficiente para se preparar bem para
uma reunião do comitê.
É aconselhável desenvolver um formulário de avaliação de projeto que relacione os cri-
térios com espaço para comentários e uma caixa de classificação para cada critério. Todos
os membros devem, em seguida, preencher um formulário para cada oportunidade antes
da reunião com todo o comitê.
Na maioria dos casos, a seleção de projeto será baseada em uma combinação de avalia-
ção quantitativa e o que cada pessoa sente em seu “interior” com base em sua experiência.
Embora a decisão final possa ser de responsabilidade do proprietário da empresa, do presi-
dente ou do chefe do departamento, uma avaliação e seleção bem compreendidas e um bom
comitê aumentarão as chances de se tomar a decisão que trará o maior benefício global.

4. Quais são as quatro etapas do
processo de seleção de projetos?
Após a decisão sobre qual(is) oportunidade(s) aproveitar, a próxima etapa é preparar

uma CP, caso se espere que um fornecedor ou consultor seja contratado para realizar o
projeto. Se este for conduzido para uma equipe de projeto interna, deve-se elaborar um
documento descrevendo seus requisitos de maneira semelhante ao que seria incluído em
uma CP.
PREPARANDO UMA CHAMADA DE PROPOSTAS

O objetivo de se preparar uma CP é declarar, de modo abrangente e em detalhes, o que é
necessário, do ponto de vista do cliente, para se atender à necessidade identificada. Uma
boa CP permite que os fornecedores ou a equipe de projeto compreendam o que o cliente
espera, para poder elaborar uma proposta completa que atenda, por um preço realista, aos
requisitos do cliente. Por exemplo, uma CP que simplesmente peça que os fornecedores
enviem propostas para a construção de uma casa não é específica o suficiente. Os forne-
cedores não podem nem começar a preparar propostas sem informações sobre o tipo de
construção desejada. Uma CP deve ser abrangente e fornecer informações detalhadas para
que o fornecedor ou a equipe de projeto prepare uma proposta inteligente que correspon-
da às necessidades do cliente. Uma amostra de CP é apresentada na Figura 2.2.
FIGURA 2.2 Chamada de Propostas

1º de fevereiro
A quem interessar possa:
A AJACKS Information Services Company está buscando propostas de fornecedores com sólida expe-
riência para realizar uma pesquisa de mercado sobre a necessidade das empresas em todo o âmbito
nacional quanto às informações técnicas. Os objetivos desse projeto são:
1. determinar a necessidade por informações técnicas de empresas manufatureiras em todo o
âmbito nacional;
2. recomendar abordagens para promover a compra e a utilização dos serviços da AJACKS Infor-
mation Services por essas empresas.
O projeto deve fornecer informações adequadas para que a AJACKS Information Services possa de-
terminar:
• os serviços ou produtos de informação futuros;
• os melhores métodos para fornecer esses produtos ou serviços para seus clientes.
O conteúdo dessa chamada de propostas deve permanecer confidencial.
1. Especificação de serviço
O fornecedor deverá realizar as seguintes tarefas:
Tarefa 1: Identificar as necessidades de informações técnicas de empresas industriais
Realizar uma pesquisa com empresas industriais em âmbito nacional para determinar suas ne-
cessidades específicas de informações técnicas externas (de fora dessas empresas). A avaliação
deve determinar os vários tipos específicos de informação técnica necessários e a freqüência de
cada tipo de informação.
Tarefa 2: Determinar as melhores abordagens para promover a compra e a utilização
dos serviços da AJACKS Information Services por setor
A pesquisa deve incluir a identificação das percepções das empresas sobre quais são as aborda-
gens diretas e indiretas de marketing que influenciam suas decisões tanto de comprar como de
utilizar serviços ou produtos específicos, em especial serviços de informação.
2. Requisitos
A pesquisa determina os vários tipos específicos de informações técnicas necessárias e a fre-
qüência de cada tipo de informação.
A pesquisa deve identificar as fontes atuais para os vários tipos de informações técnicas utili-
zados por empresas industriais, sua freqüência de uso, além da percepção da empresa sobre
o valor (benefício, custo, precisão, oportunidade) de cada fonte. Deve-se determinar os vários
métodos usados atualmente pelas empresas para acessar essas fontes de informação. A pesquisa
deve determinar a média e a faixa de variação dos recursos financeiros (tanto internos como
FIGURA 2.2 Chamada de Propostas (cont.)

taxas externas) que as empresas gastam atualmente para obter os vários tipos de informações
técnicas.
A avaliação deve fornecer detalhes suficientes que permitam um planejamento de produto
impulsionado pela demanda por parte da AJACKS Information Services Company. Portanto,
precisa incluir: (1) o tipo de informação mais freqüentemente necessário às empresas; (2) as
aplicações para as quais as empresas usam essas informações; (3) as pessoas (cargo, nível de
competência) responsáveis tanto pelo acesso como pelo uso das informações; (4) os canais
utilizados pelas empresas para acessar os vários tipos de informação.
A AJACKS Information Services Company tem interesse em desenvolver e fornecer produtos e
serviços que sejam valorizados pelos usuários (empresas industriais). Com esses interesses em
mente, o fornecedor precisa gerar informações sobre de quais empresas (diferenciadas por porte,
setor, localização ou outros fatores relevantes) pode tirar o maior proveito de serviços ou produtos
de informação ou descrever os mercados mais apropriados para esses produtos e serviços.
O fornecedor deve determinar o tamanho do mercado para os vários tipos de informação téc-
nica e determinar sua sensibilidade em relação a preço, oportunidade, precisão e mecanismos
de entrega para suas informações.
A metodologia de pesquisa precisa incluir tanto grupos focais como pesquisas por Correios.
Os grupos focais devem ser classificados segundo os principais setores industriais e pelo porte
das empresas (grande, médio, pequeno).
Com base nos resultados dos grupos focais, desenvolve-se um questionário preliminar de pes-
quisa por Correios, que é testado nas empresas representativas. Esse instrumento de pesquisa
deve ser finalizado após um período suficiente de testes. O fornecedor também deve elaborar
uma amostra de pesquisa por Correios, estratificada por setor e porte da empresa, que seja
representativa de toda a população de empresas industriais e suficientemente grande para apre-
sentar os resultados da pesquisa para cada estrato em um nível de confiança de 90%.
3. Produtos a ser entregues (Deliverables)
A. Um relatório detalhado dos resultados da Tarefa 1 deve ser elaborado a fim de identificar
e analisar os resultados de todos os respondentes, bem como fornecer análises detalhadas:
(1) para cada setor; (2) por porte da empresa. O fornecedor deve enviar vinte cópias do
relatório. A base de dados das respostas da pesquisa usada na análise precisa ser entregue em
um formato adequado para análises futuras pela AJACKS Information Services Company.
B. Com base na análise das Tarefas 1 e 2, forneça um relatório detalhado de recomendações
sobre as abordagens mais eficazes e os custos associados. O objetivo é promover os serviços
de informações técnicas entre empresas industriais, a fim de fazer que estas comprem e usem
esses serviços. É importante discutir quaisquer diferenças de abordagem com base no setor
ou porte da empresa. O fornecedor deve enviar 20 cópias do relatório.
C. Relatórios por escrito sobre o progresso do projeto deverão ser enviados por fax para a
AJACKS Information Services Company nos dias 15 e 30 de cada mês. Os relatórios têm de
ser breves e se concentrar no progresso comparado ao plano e cronograma originais do for-
necedor. Esses relatórios devem cobrir atividades, marcos atingidos, planos para o próximo
mês, obstáculos encontrados ou previstos e horas ou dinheiro gastos. Para quaisquer itens de
trabalho atrasados em relação ao cronograma, deve-se propor um plano para a conclusão do
projeto dentro do cronograma e orçamento originais.
4. Itens fornecidos pela AJACKS Information Services Company
A AJACKS dará ao fornecedor informações detalhadas sobre seus atuais produtos e serviços de
informação, além de estatísticas relacionadas a sua base de clientes atual.
5. Aprovações necessárias
O fornecedor deve obter aprovação da AJACKS para a versão final do instrumento de pesquisa
antes de sua implementação.
6. Tipo de contrato
O contrato envolverá um preço global para todo o trabalho proposto pelo fornecedor para
cumprir com os requisitos desta chamada de propostas.
7. Data de entrega
O fornecedor deve enviar cinco cópias da proposta para a AJACKS Information Services Com-
pany até o dia 28 de fevereiro.
FIGURA 2.2 Chamada de Propostas (cont.)

8. Cronograma
A AJACKS Information Services Company pretende escolher um fornecedor até o dia 30 de
março. O período necessário de execução desse projeto é de seis meses, de 1º de maio a 30
de outubro. Todos os produtos solicitados (deliverables) devem ser fornecidos à AJACKS até o
dia 30 de outubro.
9. Condições de pagamento
A AJACKS Information Services Company fará pagamentos ao fornecedor de acordo com o
seguinte cronograma:
• Um terço do valor total quando um terço do projeto estiver comprovadamente concluído;
• Um terço do valor total quando dois terços do projeto estiverem comprovadamente concluídos;
• Um terço do valor total quando a AJACKS Information Services Company estiver de acordo
que o projeto está 100% concluído e que o fornecedor cumpriu com todas as suas obrigações
contratuais.
10. Conteúdo da proposta
A proposta do fornecedor deve incluir no mínimo:
A. Abordagem
Uma discussão indicando que o fornecedor entende claramente a chamada de propostas e o
que é esperado, além de uma discussão detalhada sobre a abordagem do fornecedor para a
condução do projeto e uma descrição detalhada de cada tarefa e de como será sua realização.
B. Produtos a ser entregues (Deliverables)
Uma descrição de cada produto ou serviço que será fornecido.
C. Cronograma
Um gráfico de barras ou diagrama de rede mostrando o cronograma semanal das tarefas
detalhadas a serem conduzidas para a conclusão do projeto até a data de término exigida.
D. Experiência
Uma discussão sobre projetos recentes semelhantes que tenham sido realizados pelo forne-
cedor, incluindo nomes de clientes, endereços e telefones.
E. Equipe
Nome e curriculum vitae detalhado das pessoas especificamente designadas para trabalhar
no projeto, destacando sua experiência em projetos semelhantes.
F. Custos
O preço global total deve ser declarado e justificado em um desmembramento detalhado
de horas, além do valor por hora para cada pessoa designada ao projeto. Também se deve
incluir uma lista de todas as despesas diretas, item por item.
11. Critérios para avaliação de propostas
A AJACKS Information Services Company irá avaliar todas as propostas de fornecedores de
acordo com os seguintes critérios:
A. Abordagem (30%)
Abordagem e metodologia propostas pelo fornecedor para conduzir a pesquisa e analisar os
resultados.
B. Experiência (30%)
Experiência do fornecedor e da equipe designada para o projeto na condução de projetos
semelhantes.
C. Preço (30%)
Preço global da proposta do fornecedor.
D. Cronograma (10%)
Detalhes e duração total do cronograma proposto pelo fornecedor para concluir o projeto até
a data de término exigida.

5. Qual é o objetivo de uma chamada de
propostas?
Deve-se observar que, em muitos casos, pode não haver uma CP formal; em vez disso, a
necessidade é comunicada informalmente – e, às vezes, oralmente, em vez de por escrito.
Isso costuma ocorrer quando o projeto é implementado pela equipe interna de uma empre-
sa, e não por um fornecedor externo. Por exemplo, se uma empresa precisa mudar o leiaute
de sua unidade fabril a fim de obter espaço para os novos equipamentos que precisam ser
incorporados ao fluxo de produção, o gerente de fabricação pode simplesmente pedir que
um dos supervisores elabore uma proposta sobre “o que será necessário para reorganizar
a linha de produção”.
A seguir, são relacionadas algumas diretrizes para o esboço de uma CP formal destinada
aos fornecedores externos:
1. Uma CP deve conter uma especificação de serviço (ES). A ES trata do escopo do

projeto, delineando as tarefas ou elementos de trabalho que o cliente deseja que o for-
necedor ou a equipe de projeto realizem. Por exemplo, se a CP for para uma casa,
o fornecedor necessita saber se vai projetar e construir a casa toda, de acordo com
um projeto do cliente ou apenas incluir o acabamento de um cômodo ou a coloca-
ção do carpete. Se um cliente precisa de um folheto de propaganda, a CP esclarece
se o fornecedor deve apenas criar o folheto ou criá-lo, imprimi-lo e enviá-lo pelos
Correios.
2. A CP deve incluir os requisitos do cliente que definem especificações e atributos.
Esses requisitos incluem tamanho, quantidade, cor, peso, velocidade e outros parâ-
metros físicos ou operacionais que a solução proposta pelo fornecedor deve cumprir.
Para o folheto de propaganda, os requisitos podem ser enviados por uma mala-direta
com três dobras, impressa em papel tipo card stock em duas cores, com uma tira-
gem de 10 mil cópias. Os requisitos para a casa podem incluir um tamanho total de
200 metros quadrados com quatro quartos, dois banheiros, uma garagem com duas
vagas, ar-condicionado central e uma lareira.
Alguns requisitos dizem respeito ao desempenho. Se a CP for para um sistema de
cobrança e recebimento automatizado, os requisitos de desempenho podem incluir
a capacidade de processar 12 mil transações por dia, além de provisões para funções
especiais, como notas fiscais múltiplas consolidadas para clientes individuais e gera-
ção automática de novas notas fiscais para pagamentos não recebidos em até 30 dias
da emissão da nota original.
Esses requisitos de desempenho também podem ser usados como critérios de
aceitação pelo cliente. Por exemplo, o fornecedor do projeto terá de executar testes
no sistema de cobrança e recebimento automatizado, a fim de provar ao cliente que
o sistema atende aos requisitos de desempenho antes da aceitação e do pagamento
final ao fornecedor.
3. A CP deve informar quais itens de produtos ou serviços (deliverables) o cliente espera
do fornecedor ou da equipe de projeto. Esses são itens tangíveis que o fornecedor
deve prover. No exemplo do folheto, o único item pode ser 10 mil cópias do folheto.
No caso do sistema de cobrança e recebimento automatizado, pode-se esperar que o
fornecedor providencie o hardware (computadores), o software (disquetes, além de
documentos impressos), manuais de operação e sessões de treinamento. Os itens a
ser entregues também podem incluir relatórios de progresso periódicos ou um rela-
tório final que o cliente exige do fornecedor.
4. A CP deve relacionar quaisquer itens fornecidos pelo cliente. Por exemplo, a CP pode
afirmar que o cliente vai fornecer uma cópia de seu logotipo para uso no folheto.
Se for referente a um equipamento automatizado para testes de placas de circuito
eletrônico, a CP pode afirmar que o cliente irá fornecer determinada quantidade de
placas para que o fornecedor possa realizar testes de fábrica no equipamento antes
de enviá-lo ao cliente.
5. A CP pode discriminar as aprovações exigidas pelo cliente. Por exemplo, o cliente do

projeto de construção de uma casa pode querer ver e aprovar as plantas antes do início
das obras. O cliente do folheto pode querer ver e aprovar o leiaute antes do início da
impressão.
6. Algumas CPs mencionam o tipo de contrato que o cliente pretende usar. Pode ser
de preço global, em que o cliente paga ao fornecedor uma quantia fixa, indepen-
dentemente de quanto o trabalho de fato custou (o fornecedor aceita o risco de ter
prejuízo). O contrato também pode ser referente a tempo e materiais. Nesse caso, o
cliente paga ao fornecedor pelos custos reais. Por exemplo, se a CP for utilizada para
remodelar um cômodo de uma casa, ela pode dispor que o fornecedor será pago
pelas horas gastas e pelo custo dos materiais.
7. Uma CP pode declarar as condições de pagamento que o cliente pretende usar. Por
exemplo, o cliente do folheto pode pretender fazer um único pagamento ao final do
projeto. De outro lado, o cliente da casa pode especificar pagamentos progressivos,
baseados em uma porcentagem do preço total, feitos à medida que determinados
pontos do projeto são alcançados – 25% quando a fundação estiver pronta, outros
25% quando a estrutura estiver pronta, e assim por diante, até que toda a execução
do projeto esteja concluída.
8. A CP deve conter o cronograma exigido para a conclusão do projeto. Ela pode simples-
mente afirmar que a casa deve estar pronta dentro de seis meses, ou incluir um cro-
nograma mais detalhado. Por exemplo, o sistema de cobrança e recebimento deve ser
concebido e desenvolvido, e uma reunião de análise crítica de projeto deve ser con-
duzida até quatro meses do início do projeto; em seguida, o sistema deve ser instalado
e testado no prazo de quatro meses após a análise crítica do projeto; e, finalmente, o
fornecedor deve providenciar toda a documentação do sistema e o treinamento dos
operadores em até um mês após sua instalação.
9. A CP deve fornecer instruções referentes ao formato e conteúdo das propostas dos for-
necedores. Se o cliente pretende comparar e avaliar propostas de vários fornecedores,
é importante que estas sejam consistentes em termos de formato e conteúdo, para
que se possa fazer uma avaliação justa. As instruções podem especificar o número
máximo de páginas, o número de detalhes que o cliente deseja que o fornecedor
explicite em relação aos custos, além de outras especificações.
10. A CP deve indicar a data de entrega até a qual o cliente espera que os fornecedores
em potencial enviem suas propostas. Os clientes querem receber todas as propostas
até uma data específica, para que possam compará-las e avaliá-las ao mesmo tempo.
Por exemplo, o cliente pode conceder aos fornecedores em potencial 30 dias cor-
ridos do momento da emissão formal da CP para o envio de propostas. Os clientes
costumam afirmar na CP que quaisquer propostas enviadas após a data de entrega
não serão levadas em consideração, já que seria injusto que alguns fornecedores
tivessem mais prazo.
11. Uma CP pode incluir os critérios de avaliação. Estes são os critérios que o cliente
usará para avaliar propostas de fornecedores concorrentes, a fim de selecionar um
para conduzir o projeto. Os critérios podem incluir:
a. A experiência do fornecedor em projetos semelhantes. Há quanto tempo o for-
necedor realizou projetos semelhantes? Foram cumpridos dentro do prazo e do
orçamento? Os clientes ficaram satisfeitos?
b. A abordagem técnica proposta pelo fornecedor. Que tipo e configuração de
hardware serão utilizados? Qual é o projeto de concepção para a base de dados?
Que linguagem de software será usada para desenvolver o sistema de informação
gerencial?
c. O Cronograma. O fornecedor conseguirá cumprir ou antecipar o cronograma
exigido?
Hospital se torna “Wireless”
No início de junho de 2004, o El Camino Hospital, em Mountain View (Califórnia), começou
a oferecer Internet sem fio de alta velocidade a pacientes e visitantes em seu prédio princi-
pal e em duas clínicas de hemodiálise. A idéia do serviço partiu de pacientes que precisa-
vam freqüentar a clínica para tratamento de hemodiálise, duas ou três vezes por semana.
Os pacientes ficavam na clínica cerca de seis horas a cada visita e agora têm a conveniên-
cia do acesso grátis a Internet sem fio, enquanto se submetem ao tratamento. O hospital
planeja oferecer acesso grátis aos pacientes, ao passo que os visitantes terão de pagar uma
taxa de US$ 3,00 ao dia.
Esse é o último serviço desenvolvido pelo projeto de tecnologia sem fio do El Camino
Hospital. Para implementar com sucesso essa revolução em tecnologia da informação, a
direção do hospital incorporou a tecnologia em seu plano estratégico de economia de cus-
tos sem deixar de oferecer atendimento de alta qualidade a seus pacientes. Há três anos, o
hospital teve um prejuízo de 13 milhões de dólares e repensou sua arquitetura empresarial
para incluir a tecnologia como o principal foco no aprimoramento de seus processos de
negócios. A equipe de gerência decidiu investir em novas tecnologias para ajudar seus
funcionários a coletar e registrar o histórico dos pacientes de maneira eficaz e precisa.
Os médicos usam computadores portáteis do tipo “tablet PC” e PDAs (palms) para re-
gistrar pedidos de atendimento aos pacientes. Um sistema de protocolo de voz sobre Inter-
net (VoIP) está sendo implementado para todos os telefones usados no hospital.
A equipe de projeto teve de lidar com questões especiais associadas à tecnologia sem fio,
como interferências nos equipamentos médicos e segurança da informação. Dois níveis de se-
gurança mantêm o acesso público à Internet separado da rede de dados interna do hospital.
O novo sistema economiza dinheiro. O sistema de registro de pedidos de prescrição
de medicamentos levou o hospital a economizar US$ 130 mil por ano em gastos com
medicamentos. Isso é possível porque o sistema é capaz de sugerir automaticamente um
medicamento alternativo mais barato, porém, igualmente eficaz, no momento em que o
pedido é feito. Além do mais, o farmacêutico pode sugerir meios de reduzir o número de
medicamentos prescritos por vários médicos para um mesmo paciente hospitalizado; os
farmacêuticos têm o recurso de acessar rapidamente todos os medicamentos prescritos
para um único paciente. Da mesma maneira, os gastos por erros relacionados às prescri-
ções diminuíram. Antes do sistema, cada incidente por esse tipo de erro custava entre 3 mil
e 12 mil dólares ao hospital.
Outro exemplo é o novo sistema de estoque do El Camino Hospital. O sistema traz
economia tanto em termos de tamanho como de custos de depósitos no hospital. Foi im-
plementada uma cadeia de fornecimento automatizada, como aquela usada em alguns
estabelecimentos varejistas: o sistema envia automaticamente um pedido para repor itens
removidos do estoque.
Por fim, além da economia de custos, os pacientes do El Camino Hospital estão mais
seguros com a nova infra-estrutura de TI, que permite que os funcionários ofereçam um
atendimento mais eficaz aos pacientes, com conseqüente aumento de produtividade.
Kollbasuk-McGee, M. Hot Spots Come to the Hospital Room. InformationWeek, 14 de junho de 2004.
Sammer, J. Wired Health. American Executive, 3 de maio de 2004.
d. Os custos. Se a estimativa for baseada em tempo e materiais, os custos são razoáveis?

Algum item ficou de fora? Parece que o fornecedor enviou uma baixa estimativa
de custos e irá adicioná-los depois que o projeto for iniciado, resultando em cus-
tos finais muito mais altos que a estimativa original?

6. Quais são alguns dos elementos que
devem ser incluídos em uma chamada
de propostas?
12. Em casos raros, uma CP pode indicar os recursos de que o cliente dispõe para gastar
no projeto. Normalmente, o cliente espera que os fornecedores enviem uma proposta
que atenda aos requisitos da CP com o custo mais razoável. Contudo, em algumas
situações, pode ser útil para o cliente indicar uma quantia “limite” a ser gasta. Por
exemplo, afirmar na CP que o custo para a construção da casa deve ser em torno de
300 mil dólares. Os fornecedores podem então enviar propostas adequadas, de acor-
do com os recursos disponíveis, em vez de propostas que custam muito mais que o
valor estipulado. Do contrário, todos os fornecedores enviarão propostas com preços
muito mais altos que a soma disponível, e o cliente, decepcionado, terá de pedir que
todos enviem novas propostas para uma casa menos cara.
SOLICITANDO PROPOSTAS
Após a elaboração da CP, o cliente solicita propostas, por meio de uma notificação, aos
fornecedores em potencial sobre a existência da CP. Uma maneira de se fazer isso é iden-
tificar um grupo selecionado de fornecedores antecipadamente e enviar a cada um deles
uma cópia da CP. Por exemplo, um cliente que tenha elaborado uma CP para o projeto
e construção de um equipamento de testes automatizado pode enviá-la a várias empre-
sas (fornecedores) conhecidas, especializadas na produção desse tipo de equipamento.
Outra abordagem para a solicitação de propostas de fornecedores é que o cliente anun-
cie em algumas publicações empresariais que a CP está disponível, com instruções sobre
como os fornecedores interessados podem obter uma cópia. Por exemplo, os órgãos do
governo federal norte-americano anunciam suas CPs em uma publicação especializada,
o Commerce Business Daily.

7. Deve-se tomar cuidado de não
fornecer _______ para apenas alguns
_____, não para todos os interessados,
já que isso daria a eles uma _________.
Clientes e fornecedores corporativos consideram o processo CP/proposta bastante com-

petitivo. Os clientes devem ter o cuidado de não fornecer a um ou mais fornecedores infor-
mações que não sejam dadas a todos os fornecedores interessados. Portanto, durante a fase
de desenvolvimento da proposta, os clientes podem não responder a perguntas de fornece-
dores individuais que também estejam preparando propostas, por receio de proporcionar-
lhes uma vantagem competitiva injusta sobre outros fornecedores que não dispõem da mes-
ma informação. Clientes corporativos ou governamentais podem realizar uma reunião com
os licitantes para explicar a CP e responder às perguntas de fornecedores interessados.
Como observação final, devemos reforçar que nem todos os ciclos de vida de projeto
incluem a preparação de uma chamada de propostas escrita e o envio de propostas pelos
fornecedores. Alguns casos passam direto da definição do que precisa ser feito para a fase
de projeto do ciclo de vida, na qual o projeto é planejado e executado para atender às
necessidades identificadas. Esse processo pula as etapas de CP/propostas. Por exemplo,
• A necessidade deve ser claramente definida antes da elaboração de uma chamada

de propostas (CP) .
• Ao se selecionar um projeto entre várias necessidades ou oportunidades, a decisão
deve ser baseada em qual projeto trará os maiores benefícios globais em relação
aos custos e possíveis conseqüências.
• Uma avaliação e seleção bem compreendidas e um bom comitê aumentarão as
chances de se tomar a melhor decisão sobre o projeto.
• Uma boa CP permite que os fornecedores ou equipe de projeto compreendam as
expectativas do cliente, para que possam preparar uma proposta abrangente que
atenda às necessidades e requisitos do cliente.
• Uma chamada de propostas deve incluir uma especificação de serviço, os requisitos
do cliente, os produtos ou serviços esperados e os critérios pelos quais o cliente irá
avaliar as propostas.
• Uma CP deve fornecer informações sobre o formato e o conteúdo das propostas
dos fornecedores para que o cliente possa fazer uma comparação justa e consistente
de todas as propostas.
• Os clientes devem tomar o cuidado de não fornecer informações a apenas alguns
fornecedores, já que isso daria a eles uma vantagem competitiva injusta na elabo-
ração de suas propostas.
quando decide iniciar e implementar um projeto para atender a determinada necessidade

ou resolver um problema em particular, uma empresa pode usar os próprios funcioná-
rios e a equipe de projeto, em vez de fornecedores externos. Ou quando um grupo de
voluntários decide realizar um festival de artes de uma semana em uma cidadezinha, eles
podem optar por fazer tudo sozinhos. Quando uma vítima de acidente precisa de uma
série de cirurgias reconstrutoras, uma equipe de cirurgiões pode determinar o que precisa
ser feito e, em seguida, planejar e executar uma série de cirurgias ao longo de vários anos.
Em todos esses exemplos, chamadas de propostas e propostas de fornecedores não seriam
adequadas.
Existem outros projetos nos quais os requisitos não são especificados em uma CP for-
mal, mas são comunicados a vários provedores ou fornecedores. Por exemplo, ao planejar
seu casamento, o noivo e a noiva podem definir seus requisitos para a recepção, o jantar,
as flores e outros itens, e depois sair às compras a fim de selecionar os fornecedores que
mais se encaixam em seus requisitos e orçamento.
Embora os projetos possam ter caráter corporativo ou formal, todos começam com a
identificação de uma necessidade, problema ou oportunidade, e depois passam para a de-
finição (por escrito ou oral), por parte do cliente, do escopo, dos requisitos, do orçamento
e do cronograma para o objetivo a ser atingido.
RESUMO
A identificação de necessidades é a fase inicial do ciclo de vida do projeto. O cliente
identifica uma necessidade, problema ou oportunidade de fazer melhor alguma coisa.
A necessidade e os requisitos associados costumam ser especificados pelo cliente em um
documento denominado “chamada de propostas” (CP).
Antes da elaboração de uma CP, o cliente deve definir claramente o problema ou a neces-
sidade. Isso pode implicar a coleta de dados sobre a magnitude do problema. É importante
que o cliente tente quantificar o problema de modo a determinar se os benefícios esperados

com a implementação de uma solução são maiores que os custos ou as conseqüências da
realização do projeto.
Haverá situações em que várias necessidades ou oportunidades são identificadas, mas
os fundos ou recursos disponíveis para a abordagem de todas elas são limitados. A seleção
de projetos envolve avaliar e selecionar diversas necessidades e oportunidades, bem como
uma posterior decisão sobre quais delas deveriam evoluir para um projeto a ser implementa-
do. As etapas da seleção de projeto são: desenvolver um conjunto de critérios de acordo com
os quais a oportunidade será avaliada; relacionar suposições sobre essa oportunidade; coletar
dados e informações sobre cada oportunidade; e avaliar cada uma de acordo com os critérios
determinados. Uma avaliação e seleção bem compreendidas e um bom comitê aumentarão
as chances de se tomar a decisão que trará o maior benefício global.
O objetivo de se preparar uma CP é declarar, de modo abrangente e em detalhes, o
que é necessário, do ponto de vista do cliente, para se abordar a necessidade identificada.
Uma boa CP permite que os fornecedores ou a equipe de projeto entendam o que o cliente
espera, para que possam elaborar uma proposta completa que atenda aos requisitos do
cliente por um preço realista.
As CPs podem conter uma especificação de serviço; os requisitos do cliente em relação
a parâmetros físicos ou operacionais, como tamanho, quantidade, cor, peso e velocidade;
os itens de produtos ou serviços que o cliente espera do fornecedor; uma relação de quais-
quer itens fornecidos pelo cliente; quaisquer aprovações exigidas pelo cliente; o tipo de
contrato que o cliente pretende usar; as condições de pagamento; o cronograma exigido
para a conclusão do projeto; instruções sobre o formato e o conteúdo das propostas dos
fornecedores; a data de entrega até a qual o cliente espera que os fornecedores em poten-
cial enviem suas propostas; e os critérios pelos quais as propostas serão avaliadas.
Após a elaboração da CP, o cliente solicita o envio de propostas notificando os for-
necedores em potencial de que a CP está disponível. Clientes e fornecedores corporativos
consideram o processo CP/proposta competitivo. Os clientes devem ter o cuidado de não
fornecer a um ou mais fornecedores informações que não sejam dadas a todos os fornece-
dores interessados.
Nem todos os ciclos de vida de projeto incluem a preparação de uma chamada de pro-
postas escrita e o envio de propostas pelos fornecedores. Alguns casos passam direto da
definição do que precisa ser feito para a fase de projeto.
PERGUNTAS
1. Por que é importante conduzir um cuidadoso e detalhado trabalho de identificação de
necessidades?
2. Descreva uma situação em que você teve de conduzir uma identificação de necessidades.
3. Por que é importante selecionar o projeto certo antes de começar a trabalhar?
4. Descreva como uma empresa seleciona quais projetos conduzir quando existem vários
entre os que poderiam ser feitos.
5. Dê exemplos de situações nas quais uma empresa pode desenvolver uma chamada de
propostas.
6. Dê exemplos de situações em que uma pessoa física pode desenvolver uma chamada
de propostas.
7. Por que é importante para uma empresa quantificar os benefícios esperados com a im-
plementação de uma solução para um problema?
8. O que uma especificação de serviço deve conter?
9. O que significa “requisitos do cliente”? Por que devem ser precisos?
10. Por que uma CP deve especificar as aprovações necessárias durante o projeto? Dê al-
guns exemplos.
11. Por que, em uma CP, um cliente poderia instruir os fornecedores a enviar suas propos-
tas de acordo com um formato-padrão?
12. Desenvolva uma CP para um projeto real, como, por exemplo, o paisagismo de um
jardim próximo a um edifício comercial, a construção de uma edícula para sua casa ou
a organização de uma grande festa de formatura. Seja criativo ao especificar suas neces-
sidades. Sinta-se à vontade para criar idéias únicas para a CP.
Caso tenha dificuldade para acessar algum dos websites relacionados a seguir, você pode
~clements.
Para responder às perguntas a seguir, faça uma busca por “chamada de propostas” (ou
request for proposal), usando sua ferramenta de busca favorita.
1. Com base nos resultados de sua busca, encontre uma CP que tenha sido colocada na
Internet. Qual empresa desenvolveu a CP? O que estão tentando conseguir?
2. Avalie a eficácia dessa CP com base nas informações estudadas neste capítulo. Co-
mente seus pontos fortes e fracos. Ficou faltando algum item que deveria ser incluído
na CP?
3. Com base no que você aprendeu neste capítulo, faça o download da proposta e re-
vise-a. Realce as áreas que você revisou. O que faz com que sua CP seja melhor que
a original?
4. Localize um site que ofereça sugestões para a preparação de CPs. Compare e contraste
essas sugestões com o que foi apresentado neste capítulo.
5. Explore e descreva pelo menos três pacotes de software que possam ajudá-lo a
desenvolver uma CP. Faça o download de uma versão de avaliação de pelo menos
um, se possível.
ESTUDO DE CASO nº 1 Uma Empresa Farmacêutica de Médio Porte

Jennifer Childs é proprietária e presidente de uma empresa farmacêutica de médio porte.
Em uma reunião de produção, realizada em outubro, ela diz aos gerentes que a expectati-
va de lucro da empresa para aquele ano é de US$ 200 mil a mais que o previsto. Informa
que gostaria de reinvestir esse lucro adicional financiando projetos dentro da empresa que
poderiam ajudar a aumentar as vendas ou reduzir custos. Então, ela pede que os três ge-
rentes principais se reúnam e desenvolvam uma lista de projetos em potencial, por ordem
de prioridade, e depois se encontrarem com ela para “venderem” suas idéias. Ela menciona
que eles não devem assumir a divisão dos recursos que serão divididos igualmente entre
os três. Também menciona que está disposta a investir todos os recursos em apenas um
projeto, caso lhe pareça apropriado.
Julie Chen, gerente de desenvolvimento de produtos, tem uma equipe de cientistas
trabalhando em um novo medicamento. Essa tarefa está levando muito mais tempo que o
esperado. Ela tem medo de que grandes empresas estejam trabalhando em um medicamento
semelhante e que possam chegar primeiro ao mercado. Sua equipe ainda não teve nenhu-
ma conquista revolucionária, e alguns testes não estão produzindo os resultados esperados.
Julie sabe que esse é um projeto arriscado, mas sente que não pode interrompê-lo agora.
Acredita que o crescimento da empresa a longo prazo depende desse novo medicamento,
que pode ser vendido no mundo todo. Ela vem tentando ser otimista nas reuniões de produ-
ção sobre o progresso desse projeto de desenvolvimento, mas sabe que Jennifer está ficando
impaciente e que seus colegas acreditam que deveria ter encerrado o projeto depois que os
primeiros testes foram negativos. Julie gostaria de usar os recursos adicionais para acelerar o
projeto de desenvolvimento. Ela contrataria um cientista bastante renomado de uma grande
empresa e compraria equipamentos laboratoriais mais sofisticados.
Tyler Ripken, gerente de produção, trabalha na empresa há apenas seis meses. Uma das
primeiras coisas que observou foi que o fluxo de produção é bastante ineficiente. Ele acre-
dita que isso seja o resultado de um planejamento inadequado quando ampliações foram
feitas à fábrica ao longo dos anos, à medida que a empresa crescia. Tyler gostaria de formar
várias equipes de funcionários para implementar um leiaute melhor para os equipamentos
da fábrica. Ele acredita que isso aumentaria a capacidade da fábrica e, ao mesmo tempo,
reduziria custos. Quando Tyler menciona essa idéia a alguns de seus supervisores, eles
lembram que, quando o pai de Jeniffer administrava os negócios, ela era encarregada da
produção e foi responsável pelo leiaute atual da fábrica. Eles também lembram a Tyler que
Jennifer não é fã de usar equipes de funcionários. Ela acredita que os funcionários de pro-
dução são pagos para fazer seu trabalho e espera que seus gerentes sejam os responsáveis
por conceber e implementar novas idéias.
Jeff Matthews, gerente de operações, é responsável pelos computadores e sistemas de
informação da empresa, assim como por suas operações contábeis. Jeff acredita que os siste-
mas informatizados da empresa estão obsoletos e, como os negócios cresceram, os compu-
tadores mais antigos não conseguem dar conta do volume de transações. Para ele, um novo
sistema de informática poderia rastrear melhor os pedidos de clientes, reduzir o número de
reclamações e proporcionar a emissão mais pontual de notas fiscais, melhorando o fluxo
de caixa. Os funcionários do departamento de Jeff fazem piadas sobre os computadores
antigos e o pressionam a comprar novos equipamentos. Certa vez, Jennifer disse a Jeff que
não tem interesse em gastar dinheiro com novos computadores só para que a empresa
tenha as máquinas mais modernas, principalmente se o sistema atual estiver funcionando
bem. Ela sugeriu que ele tentasse contratar um serviço terceirizado para fazer a contabilida-
de, reduzindo, assim, a equipe interna. Jeff gostaria de usar o lucro excedente do ano para
comprar novos computadores e contratar um programador para instalar os softwares. Ele
acredita que isso traria uma boa relação custo–benefício.
Após essa reunião de produção com Jennifer, Joe Sanchez, gerente de marketing, vai até
a sala dela. Ele diz que, embora ninguém tenha lhe pedido para conceber idéias de projetos
para lucros adicionais, ele acredita que ela deveria esquecer essa besteira de projeto e sim-
plesmente dar-lhe um orçamento maior para contratar mais alguns representantes de vendas.
“Isso iria aumentar as vendas mais rápido que qualquer outra coisa”, Joe diz a ela. E, além do
mais, é o que seu pai faria!” Joe está contando com divergências entre os outros três gerentes
em relação a prioridades. Ele espera que, se Jennifer observar uma falta de consenso, ela
pode lhe conceder os recursos para contratar os representantes de vendas adicionais.
PERGUNTAS
1. Como Jennifer deve se orientar para tomar a decisão?
2. Que tipo de dados e informações extras ela deve coletar?
3. O que exatamente Jennifer deve exigir que as pessoas enviem sob a forma de propostas?
4. O que você acha que Jennifer deveria fazer com os US$ 200 mil? Ao explicar sua res-
posta, comente as preocupações e posições de Julie, Tyler, Jeff e Joe.
ATIVIDADE EM GRUPO
Escolha cinco alunos do curso para interpretar os papéis de Jennifer, Julie, Tyler, Jeff e Joe.
Com Jennifer e Joe fora da sala, Julie, Tyler e Jeff devem simular (de preferência, na frente
dos demais alunos) uma reunião na qual discutem suas propostas de projetos e desenvol-
vem uma lista, por ordem de prioridade, para “vender” a Jennifer.
Após Jennifer e Joe retornarem à sala, os cinco participantes devem simular (de pre-
ferência, na frente da classe) uma reunião com Jennifer, na qual Julie, Tyler e Jeff tentam
vender suas idéias de acordo com a lista de prioridades de projetos, enquanto Joe tenta
promover sua idéia.
Discuta o que aconteceu. Quais posições os “atores” assumiram? Como foi tomada a
decisão final? Qual foi ela?
ESTUDO DE CASO nº 2 Melhorias no Transporte

Polk County é um dos maiores, porém, menos populosos, distritos do Estado. Com territó-
rio bastante montanhoso, seus lagos e florestas oferecem excelentes opções de caça e pesca
para muitos de seus habitantes, e também para as pessoas de fora da região. Lá, os invernos
são bastante rigorosos. O índice de desemprego é o maior do estado. Tanto a média de ida-
de da população como a porcentagem de pessoas acima de 65 anos são substancialmente
mais altas que no resto do Estado, segundo as estatísticas.
Mainville, localizada a leste de Polk County, é a sede administrativa do distrito. Com
uma população de 15 mil habitantes, é a maior cidade do distrito. Muitos dos habitantes de
Mainville trabalham no hospital, na rede escolar, em órgãos públicos, ou na megaloja Big
John, que fica perto dos limites da cidade. O maior empregador do distrito é uma peniten-
ciária feminina estadual, localizada na região sudoeste.
O distrito é governado por um conselho eleito composto de três membros. Eles recebem
uma remuneração mínima para trabalhar no Conselho. Os membros atuais são Thomas,
Richardson e Harold. Nenhum deles é de Mainville; todos são de locais mais remotos do
distrito. Eles não se interessam muito pela cidade, a não ser quando têm de viajar até lá,
uma vez por semana, para a reunião do Conselho. Tanto Thomas como Harold são apo-
sentados. Richardson vive na fronteira oeste do distrito e é o chefe do Ye Olde Saw Mill,
no distrito vizinho.
JR é supervisor do Departamento de Transportes do distrito e mora em Mainville. A
maior parte do orçamento do departamento é usada para limpar as rodovias e cobri-las de
sal durante os longos invernos (para que os veículos não derrapem sobre a pista), bem como
para manutenções mínimas. Até cerca de cinco anos atrás, o Departamento de Transpor-
tes do distrito recebia uma alocação especial dos fundos estaduais, graças ao senador Joe
Smoozer, natural de Mainville. Vinte anos antes, Joe havia sido supervisor do Departamento
de Transportes do distrito e, em seguida, foi eleito para o senado estadual. JR havia traba-
lhado para Joe no departamento, e eles se tornaram bons amigos. Após anos de reeleições,
Joe ganhou tempo suficiente de casa para ser nomeado chefe do Comitê de Transporte.
Com esse cargo, conseguiu fazer Polk County receber uma alocação especial dos fundos
estaduais para seu Departamento de Transportes. Contudo, Joe falecera havia cerca de cin-
co anos, e a alocação especial foi cortada. O novo senador estadual que representa Polk
County está concentrado no desenvolvimento econômico do distrito, não em transportes.
Sem a alocação estadual especial, as rodovias do distrito estão ficando cada vez piores.
JR está preocupado. Ele sabe que diversos projetos importantes precisam ser conduzidos.
Contudo, com seu orçamento, ele tem medo de não conseguir realizar um deles sequer. Os
membros do Conselho tomarão a decisão final. JR também sabe que eles não estão dispos-
tos a aumentar os impostos para financiar esses projetos. No entanto, eles podem realocar
parte dos recursos do orçamento de outro departamento.
Um dos projetos se refere à entrada da megaloja Big John, inaugurada três anos antes.
A loja fica em uma rodovia de pista dupla. Todos parecem fazer compras lá, já que não
há nenhum shopping center no distrito. O tráfego na rodovia aumentou consideravelmente
nos últimos três anos. A entrada da loja fica na base de uma colina, o que dificulta que
veículos trafegando em um sentido vejam os que trafegam em sentido oposto antes de
alcançar o topo da montanha. Como conseqüência, as pessoas que dobram à esquerda
para entrar na loja precisam tomar cuidado com os carros trafegando pelo topo na direção
oposta. Desde que a loja foi inaugurada, vários acidentes ocorreram no local. JR sabe que a
rodovia precisa ser ampliada, para que uma faixa de conversão possa ser adicionada; outra
opção é a instalação de semáforos.
JR consultou o gerente da loja sobre a possibilidade de ela pagar pelas melhorias na ro-
dovia na frente de sua entrada. Contudo, o gerente disse que o estabelecimento já era uma
boa cidadã da comunidade; havia criado emprego para as pessoas, mantinha os preços bai-
xos, dava descontos aos idosos e doava uma porcentagem de suas vendas para várias insti-
tuições de caridade e aos arrecadadores de recursos do distrito. Como resultado, ele alegou
que a loja mal estava tendo lucro. Se os lucros não viessem, a matriz iria fechá-la, e muitas
pessoas perderiam o emprego (aliás, a esposa de Thomas trabalha na loja meio período).
Embora tivesse se solidarizado com JR, o gerente disse que a loja não poderia pagar pela
adição de uma faixa de conversão à rodovia. No passado, a preocupação com o aumento
no número de acidentes foi levantada por vários moradores em reuniões de conselho, mas
nada foi feito. Os antigos membros do Conselho disseram apenas que as pessoas deveriam
ter mais cuidado. No entanto, meses atrás, uma pessoa ficou gravemente ferida em um aci-
dente. JR sabe que, se alguma coisa não for feita, alguém acabará sendo morto lá.
Um segundo projeto se refere ao reparo e à ampliação da Elk Mountain Road, na região
noroeste do distrito. Muitas pessoas usam a rodovia para chegar aos lagos de Elk Mountain
e para caçar. JR não consegue se lembrar da última vez em que foi asfaltada ou sofreu qual-
quer reparo. Invernos rigorosos deixaram-na cheia de buracos, que a cada inverno, ficam
maiores e mais profundos, e novos buracos aparecem. Em função do desemprego no distri-
to, nos últimos tempos, madeireiros independentes começaram a usar a rodovia para subir
até Elk Mountain para cortar árvores e levar a madeira para várias serrarias. Os caminhões
que transportam a madeira estão deteriorando ainda mais a rodovia. Uma das serrarias com-
pradora da madeira é a Ye Olde Saw Mill, no distrito vizinho, pela qual Richardson é respon-
sável. Tanto Thomas como Richardson conhecem as condições precárias da Elk Mountain
Road; afinal de contas, eles a utilizam com freqüência para ir pescar e caçar. Eles também
recebem várias queixas de amigos que usam a rodovia.
Por fim, a County Route 1045 é a principal rodovia de acesso à penitenciária femini-
na, no noroeste do distrito. É uma rodovia de pista dupla, assim como todas as outras
do distrito. Próxima à prisão, existe uma ponte que atravessa o córrego Crockett Creek.
Há quatro anos, a ponte mal passou na inspeção estadual. Na época, disseram a JR que
ela precisava passar por melhorias consideráveis até a próxima inspeção; caso contrário,
teria de ser interditada. A inspeção está programada para o próximo ano. Após o degelo
de inverno, a água do córrego pode ficar bastante alta e fluir rapidamente. A população
expressou sua preocupação sobre a ponte ser levada pela correnteza. Se isso acontecesse,
o tráfego precisaria ser desviado em cerca de 25 quilômetros para a maioria das pessoas
que trabalham na prisão.
Em uma das reuniões do Conselho no último ano, Thomas disse para esperarem até que
a ponte fosse levada pela água, assim talvez o Estado daria ao distrito o dinheiro para cons-
truir uma nova ponte. Além disso, informou que todas as pessoas que trabalhavam na prisão
eram funcionárias estaduais propriamente ditas e que ganhavam bem em relação à popula-
ção aposentada que vivia de renda fixa. Isso despertou a ira de Harold, cuja filha trabalha
na penitenciária; ele e Thomas travaram uma discussão calorosa durante a reunião.
Estamos no mês de junho; nele, os membros do Conselho analisarão o orçamento do
Departamento de Transportes para o próximo ano, na reunião do Conselho a ser realizada
em 15 de setembro. JR tem receio de que, se não apresentar um bom projeto que deva re-
ceber prioridade, os membros do Conselho provavelmente não aumentarão seu orçamento
para nenhum deles. Ele teme que os três projetos sejam desastres iminentes.
Zachary estuda engenharia civil na universidade estadual e está indo para o último ano.
Ele é de Mainville e trabalha no Departamento de Transportes do distrito durante as férias.
No dia 15 de junho, JR pede que ele o ajude a reunir algumas informações sobre os três pro-
jetos até o dia 15 de agosto, quando Zachary tem de voltar à universidade. Assim, JR estaria
preparado para a reunião de análise de orçamento do dia 15 de setembro.
Como viveu em Mainville a vida toda, Zachary está familiarizado com as três situações,
embora nunca tenha refletido muito sobre elas. Contudo, quanto mais pensa sobre o assun-
to, mais percebe sua ligação pessoal com cada caso.
Naquele grave acidente na entrada da Big John, meses atrás, a pessoa que ficou gra-
vemente ferida foi Peggy Sue Suite, uma das melhores amigas de colégio de Zachary. Ela
tentou virar à esquerda para entrar na loja quando seu carro foi atingido atrás por uma ca-
minhonete que havia se desgovernado, por causa do gelo na pista e não conseguiu frear a
tempo. Ela ainda está em tratamento de reabilitação e tem de usar um colar cervical.
Na última temporada de caça, Zachary estava subindo até Elk Mountain em seu velho
carro. Na semana anterior, ele havia amarrado com pedaços de arame o escapamento, que
estava caído, à carroceria do veículo. Seu trabalho não foi dos melhores, já que o escapa-
mento ainda estava praticamente arrastando no chão. Na semana seguinte, enquanto subia
a Elk Mountain, ele quase foi empurrado para fora da pista por um caminhão de madeira que
estava descendo a montanha e parecia se divertir com a vantagem que tinha sobre o carrinho
de Zachary. Este passou por cima de um buraco, arrancando o escapamento do carro de
vez. Embora tenha ficado bravo com o motorista do caminhão e com os madeireiros que
estavam voando na estrada, Zachary também ficou feliz por não ter se machucado e por
não ter sofrido uma colisão lateral com o caminhão.
O irmão de Zachary trabalha na penitenciária. Ele lhe disse que era apenas uma questão
de tempo até que a ponte de Crockett Creek desmoronasse ou fosse levada pela correnteza.
Ele jura que sente a ponte tremer quando passa sobre ela. Disse também que espera que ele
e sua namorada (a filha de Harold) não estejam lá quando isso acontecer.
– Por que o Conselho não lhe dá dinheiro para os três projetos? – Zachary perguntou a JR.
– Queria que fosse simples assim – respondeu JR. – Eles não querem aumentar os im-
postos e, ainda que aumentassem, somos um distrito pobre, e a população provavelmente
não teria dinheiro para pagar mais nada de imposto. E eles também têm outros orçamentos
para considerar além do Departamento de Transportes. Tenho a certeza de que todos os
outros departamentos também gostariam de receber mais dinheiro.
– Zachary, espero que o que você aprendeu na faculdade nos ajude a fazer o que preci-
so: uma lista de prioridades para os três projetos e as informações que fundamentam cada
um deles. Sei que o Conselho vai me fazer muitas perguntas e preciso estar preparado. Se
tivermos sorte, eles aprovarão o projeto recomendado por nós. Se não tivermos uma boa
história para ajudá-los na decisão, eles podem simplesmente argumentar e acabar não to-
mando nenhuma decisão. Então, não receberemos dinheiro para nenhum dos projetos. É,
acho que isso vai lhe dar uma oportunidade de aprender coisas diferentes das que aprende
na faculdade. Por que não nos reunimos na próxima semana, e você me conta suas idéias
para lidar com esse problema? Esse pode ser um trabalho maior do que você imagina. Que-
ro que trabalhe nele em período integral nos próximos dois meses. Isso é muito importante.
Quero que você faça um trabalho minucioso.
PERGUNTAS
1. Quais critérios Zachary deve usar para avaliar os projetos?
2. Quais suposições ele deve fazer?
3. Quais são os dados e informações que deve coletar? Como ele deve fazer isso?
4. Depois de avaliar cada projeto segundo os critérios de avaliação, como ele deve decidir
sobre a prioridade dos três projetos?
ATIVIDADE EM GRUPO
Peça que cada aluno do curso responda individualmente à primeira pergunta. Em seguida,
divida os alunos em grupos de três ou quatro integrantes para discutir as perguntas. Cada
grupo deve eleger um porta-voz para apresentar suas respostas à classe.
Capítulo SOLUÇÕES PROPOSTAS
3 Marketing de Proposta/Pré-CP
Decisão de Participar/
Não Participar da Concorrência
Desenvolvendo uma Proposta
Tipos de Contratos
Contratos de Preço Global
Contratos por Administração
Disposições Contratuais
Vencedora
Resumo
Elaboração da Proposta
Perguntas
Conteúdo da Proposta
Seção Técnica
Estudo de Caso no 1 Sistemas de
Seção de Gestão Informação para a Área Médica
Seção de Custos Perguntas
Considerações sobre Preços Atividade em Grupo
Entrega e Acompanhamento Estudo de Caso no 2 Planejador
da Proposta de Casamento
Avaliação das Propostas Perguntas
pelo Cliente
Atividade em Grupo
44
Ca pítulo Trê s
Voluntários Limpam Monte Fuji
O Monte Fuji, a montanha mais alta do Japão e símbolo de pureza, está coberto de sujeira.
No verão, todos os dias, o vulcão atrai cerca de 5 mil pessoas que escalam 3.775 metros até
o topo. Nele estão instaladas cerca de 2 mil organizações religiosas, 117 campos de golfe
e um zoológico com montanha-russa e carrossel. A maioria dos visitantes é turista, mas
um menor número é composto pelos que continuam a tradição de fazer peregrinações
espirituais até o topo.
Acredita-se que o nome Fuji tenha se originado de uma palavra de língua indígena
que significa “deus do fogo”. Esse vulcão, que costumava ter erupções freqüentes, ultima-
mente está inativo. Porém, cientistas acreditam que pode sair de seu estado de dormência
em breve. Mesmo com a introdução de diferentes crenças religiosas na cultura japonesa, a
reverência ao vulcão manteve-se constante. Desde os tempos antigos, as montanhas são
consideradas lugares sagrados. Segundo a crença Shinto, os espíritos que respondem a
orações e rituais humanos moram nas montanhas. Os santuários no Monte Fuji indicam
lugares sagrados onde vivem os espíritos. No budismo, o ato de escalar montanhas re-
presenta a ascensão espiritual ao esclarecimento; dessa forma, o Monte Fuji tornou-se um
destino para peregrinação. A crença Shugendo sustenta a ligação espiritual com o ato de
escalar, que permite ao indivíduo entrar em contato com as divindades das montanhas e
ganhar poderes sobrenaturais.
Na década de 1960, a sensação de paz do Monte Fuji foi interrompida por uma estra-
da, construída da base até o centro da montanha, que abriu caminho ao turismo interna-
cional e o planejamento comercial. Entretanto, esse lugar turístico aparentemente não teve
um bom plano para o controle de resíduos. A montanha ficou coberta pelo lixo e esgoto
produzidos. Depósitos coletam resíduos deixados por pessoas na alta temporada, quando
o tráfego é elevado. Em seguida, quando a temporada termina, esses reservatórios são
esvaziados, seu conteúdo descarregado na encosta da montanha.
Toyohiro Watanabe, ambientalista e alpinista, liderou a tentativa de incluir o Monte
Fuji na lista de Patrimônios da Humanidade, como um dos mais impressionantes locais
naturais e culturais. Em 1995, membros da Organização Cultural, Científica e Educacional
da ONU visitaram o Monte Fuji, mas não conseguiram assegurar ao local o status de Patri-
mônio da Humanidade. O comitê recomendou ao Japão que limpasse o local e controlasse
sua poluição.
O público respondeu a essa necessidade por meio de esforços voluntários, recolhendo
o lixo no Monte Fuji. Watanabe fundou o Clube Fujisan, cuja missão é limpar o monte.
Essa associação formou alianças com outras montanhas pelo mundo: o Monte Rainier,
nos Estados Unidos, o Monte Ngauruhoe, na Nova Zelândia, e o Monte Kinabalu, na Malá-
sia. A instituição espera aprender como esses locais mantêm um bem-sucedido controle de
resíduos. Para estimular as pessoas a aderir à campanha de limpeza, Watanabe televisionou
suas expedições mostrando garrafas de oxigênio, barracas e latas jogadas e esquecidas.
O Clube Fujisan, até agora, já recolheu 17 toneladas de lixo. O clube também preocupa-se
em limpar e prevenir o descarte de resíduos industriais e domésticos na base da monta-
nha. Também instalou dois banheiros biológicos com bacias feitas de cedro. Corporações
japonesas e outros grupos voluntários foram formados para ajudar no projeto. Em 2003,
cerca de 400 quilos de lixo foram coletados do topo. Quatro toneladas de lixo foram cole-
tadas das trilhas próximas à área de descanso dos visitantes. Para tratar do problema do
controle de esgoto, em julho de 2004, o governo japonês planeja instalar, no topo, banhei-
ros equipados com dispositivo de incineração, que transformarão resíduos humanos em
cinzas, fáceis de descartar. O governo também planeja instalar mais banheiros biológicos,
cada um custando cerca de US$ 40 mil.
45
Voluntários podem implementar, com sucesso, um plano. Esforços voluntários reque-

rem um líder forte, capaz de demonstrar comprometimento e amor pelos objetivos da or-
ganização. Watanabe e o Clube Fujisan têm conseguido mudar a maneira como as pessoas
tratam o meio ambiente, por meio do ativismo comunitário e do aprendizado com o sucesso
de outros modelos.
Volunteers in Japan Give Mount Fuji a Makeover. New York Times, 8 de dezembro de 2003.
O desenvolvimento de soluções propostas por fornecedores interessados ou pela equipe

de projeto interna do cliente, em resposta a uma requisição de um cliente, corresponde
à segunda fase do ciclo de vida do projeto. Este capítulo abrange essa fase, que começa
quando a CP é disponibilizada após a conclusão da fase de identificação das necessida-
des e termina quando um acordo é feito com a pessoa, organização ou fornecedor sele-
cionado para implementar a solução proposta (veja Figura 3.1). Você irá conhecer:
• estratégias de marketing e a decisão de participar/não participar da concorrência;
• o desenvolvimento de propostas vencedoras;
• o processo de elaboração da proposta e os elementos que pode incluir;
• considerações sobre preços;
• avaliação das propostas;
• tipos de contratos entre o cliente e o fornecedor.
Em muitas situações, uma chamada de propostas não envolve solicitar propostas de con-
correntes externos. Por exemplo, imagine que os gerentes de uma empresa considerem
necessário desenvolver novos materiais de marketing (panfletos, fitas de vídeo, CDs de
amostra de software) ou rearranjar a disposição do escritório. Os gerentes podem pedir
que uma pessoa ou equipe prepare uma proposta que defina o que deve ser feito, que
recursos da empresa seriam necessários, quais seriam os gastos e quanto tempo levaria.
Depois que a pessoa ou a equipe elaboram a proposta, os gerentes decidem se conti-
nuarão com o projeto, talvez modificando-o durante o processo. Em caso afirmativo, este
passa diretamente para a terceira fase de seu ciclo de vida: o planejamento detalhado e,
em seguida, a implementação desse planejamento para alcançar o objetivo do projeto.
Chamada de
Propostas Objetivo
Esforço Acordo do Projeto
Identificar Desenvolver Concluir o
uma Executar
uma projeto
solução o projeto
necessidade
proposta
Tempo
Capítulo 3 Soluções Propostas 47
A segunda fase do ciclo de vida pode ser completamente ignorada para alguns tipos de
projeto. Por exemplo, alguns são realizados por uma ou duas pessoas, como a constru-
ção de um balanço, ou para um projeto conduzido por um grupo de voluntários, como
a organização de um evento de caridade. Nessas situações, não existe uma chamada de
propostas nem uma proposta real; em vez disso, depois que a necessidade é identificada,
o projeto passa diretamente para a fase de planejamento e implementação de seu ciclo
de vida.
MARKETING DE PROPOSTA/PRÉ-CP
Os fornecedores cujo sustento depende da criação de propostas vencedoras em resposta a
CPs empresariais ou governamentais não devem esperar até que solicitações formais sejam
comunicadas pelos clientes; ao contrário, precisam começar a elaborar propostas. De pre-
ferência, esses fornecedores devem desenvolver relações com clientes em potencial muito
antes desses últimos preparar as chamadas de propostas.
Os fornecedores devem manter contatos freqüentes com clientes antigos e atuais e ini-
ciar contatos com clientes em potencial. Nesses contatos, os fornecedores têm de ajudar
os clientes a identificar as áreas em que eles poderiam se beneficiar da implementação de
projetos para sanar necessidades e problemas ou aproveitar oportunidades. Ter uma rela-
ção próxima com um cliente em potencial deixa o fornecedor em uma posição privilegiada
quando o cliente de fato emite uma CP. Um fornecedor familiarizado com as necessidades,
exigências e expectativas de um cliente pode preparar uma proposta mais direcionada, em
resposta à CP do cliente. Esses esforços pré-CP (ou pré-proposta) por parte do fornecedor
são considerados desenvolvimentos de marketing ou de negócios e são realizados sem ne-
nhum custo para o cliente. O fornecedor espera ser recompensado por esses esforços no
futuro – quando for escolhido como vencedor em resposta à CP do cliente.
Durante essa atividade pré-proposta, o fornecedor deve aprender o máximo possível
sobre necessidades e problemas do cliente e sobre o processo de tomada de decisões.
O fornecedor deve solicitar ao cliente informações, dados e a documentação sobre o pro-
blema ou necessidade identificados. O fornecedor poderá, em seguida, elaborar algumas
abordagens ou conceitos pré-proposta e apresentá-los ao cliente ou estudá-los com ele. Ao
obter reações do cliente a esses conceitos, o fornecedor pode começar a entender e escla-
recer o que o cliente espera, além de desenvolver uma imagem favorável e responsiva aos
olhos do cliente. O fornecedor poderá convidar o cliente a visitar outro de seus clientes
que tenha apresentado uma necessidade ou problema semelhante, para o qual foi proposta
e implementada uma solução bem-sucedida. Essa atitude pode melhorar a reputação do
fornecedor perante o cliente.
Em alguns casos, o fornecedor pode preparar uma proposta não solicitada e apresentá-la
ao cliente. Se estiver certo de que a proposta resolverá seu problema, com um custo razoá-
vel, ele pode simplesmente negociar um contrato de implementação da proposta, eliminan-
do, assim, a elaboração de uma CP e o processo de concorrência subseqüente. Em alguns
casos, ao fazer um bom trabalho no marketing pré-proposta, o fornecedor pode conseguir
um contrato com um cliente sem ter de competir com outros fornecedores.

1. Os fornecedores precisam ________
com clientes em potencial __________
de preparar uma CP.
Se o objetivo for ganhar uma CP ou conseguir um contrato não competitivo com um

cliente, os esforços pré-proposta são fundamentais para o estabelecimento do alicerce que
conduz, no fim, à obtenção de um contrato com o cliente e à realização do projeto.
DECISÃO DE PARTICIPAR/NÃO PARTICIPAR DA CONCORRÊNCIA

Como o desenvolvimento e a elaboração de uma proposta podem levar tempo e ser caros,
os fornecedores interessados em apresentar uma proposta em resposta à CP devem ser
realistas quanto à probabilidade de serem escolhidos como vencedores. Algumas vezes,
a avaliação sobre prosseguir ou não com a elaboração de uma proposta é chamada de
decisão de participar/não participar da concorrência. Alguns fatores que podem ser
considerados por um fornecedor na hora de decidir participar ou não do processo são:

2. Qual é o resultado de um esforço de
marketing pré-proposta bem-sucedido?
1. Concorrência. Que outros fornecedores poderiam também apresentar uma proposta

em resposta à CP? Algum deles tem uma vantagem competitiva em função de es-
forços de marketing pré-proposta, de trabalhos anteriores para o cliente ou por sua
reputação perante este?
2. Risco. Existe o risco de o projeto fracassar – técnica ou financeiramente? Por exem-
plo, há muitas incertezas quanto à possibilidade tecnológica de se elaborar um circui-
to eletrônico integrado que atenda aos requisitos do cliente? Ou o cliente quer que
os fornecedores apresentem uma proposta baseada em um contrato de preço global,
para um projeto que envolva o esforço de pesquisa e desenvolvimento, com somente
50% de probabilidade de ser bem-sucedido tecnicamente?
3. Missão. O projeto está coerente com a missão de negócios do fornecedor? Por exem-
plo, se o negócio consiste em desenvolver e implementar sistemas automatizados de
aplicativos para processos empresariais, como contabilidade, rastreamento de pedi-
dos ou relatórios financeiros, desenvolver um sistema automatizado para monitora-
mento, teste e controle de um processo químico em uma indústria farmacêutica não
seria uma das missões desse fornecedor.
4. Aumento de capacidade. O projeto proposto daria ao fornecedor a oportunidade de
aumentar e melhorar sua capacidade? Por exemplo, se um fornecedor tem oferecido
sistemas de controle de estoque automatizados para indústrias alimentícias individuais,
uma CP para o fornecimento de um sistema de controle de estoque integrado para
uma rede de supermercados com dez lojas pode dar ao fornecedor a oportunidade de
aumentar sua capacidade e expandir seus negócios para uma clientela maior.
5. Reputação. O fornecedor já realizou, com sucesso, projetos para esse mesmo cliente
ou existiram problemas que deixaram o cliente insatisfeito? O fornecedor, alguma
vez, participou, sem sucesso, de concorrências do cliente?
6. Fundos do cliente. O cliente realmente possui fundos para levar o projeto adiante?
Ou está em uma “expedição de pesca”, na qual emite uma CP, sem a certeza de
que haverá fundos para o projeto? Um cliente pode emitir uma CP na melhor das
intenções, mas de forma prematura, acreditando que a diretoria vai aprovar o finan-
ciamento para o projeto. No entanto, se a empresa estiver passando por dificulda-
des financeiras, a diretoria poderá adiar o projeto indefinidamente, mesmo depois
de receber propostas de fornecedores interessados. Se o fornecedor fizer um bom
marketing pré-proposta, fica mais fácil determinar se um projeto é viável ou não.
Os fornecedores não devem perder tempo respondendo a CPs e elaborando propos-
tas que provavelmente não serão financiadas.
7. Recursos da proposta. Os recursos disponíveis são adequados para a preparação de

uma proposta de qualidade? Somente preparar uma proposta não é o suficiente.
É muito importante que ela possua qualidade suficiente para ter uma boa chance de
vencer. Para preparar uma proposta de qualidade, o fornecedor deve contar com as
pessoas certas – ou seja, recursos – para o trabalho. Se a organização do fornecedor
não possuir os recursos certos para preparar uma proposta de qualidade, ele deve
tomar providências que garantam outros recursos a fim de preparar a melhor pro-
posta possível. Um fornecedor não deve usar recursos inadequados para elaborar
uma proposta, simplesmente para poder apresentar qualquer uma. Uma proposta de
pouca qualidade pode causar no cliente uma má impressão, o que pode prejudicar
as chances de o fornecedor conseguir contratos futuros com esse cliente.

3. Quais são alguns dos fatores que o
fornecedor deve levar em consideração
ao decidir sobre participar ou não de
uma CP?
8. Recursos do projeto. Existem recursos adequados disponíveis para a realização do

projeto no caso de o fornecedor ser escolhido como vencedor? Os fornecedores
precisam ter a certeza de que haverá pessoas adequadas, dentro da organização,
disponíveis para trabalhar no projeto. Se, depois de fechado o contrato, o fornecedor
descobrir que a equipe deverá ser formada por pessoas diferentes das anteriormente
escolhidas para o projeto, as chances de concluí-lo com sucesso podem diminuir.
O resultado poderá ser um cliente insatisfeito que pode não solicitar futuras propos-
tas ao fornecedor. Se o fornecedor não estiver certo de que possui os recursos sufi-
cientes para a execução do projeto, ele deve ter um plano que garanta a realização
bem-sucedida do projeto (como contratar novas pessoas ou possuir consultores ou
subcontratados para executar certas tarefas).
Os fornecedores precisam ser realistas quanto a sua capacidade de preparar propostas

e quanto à probabilidade de conseguir o contrato. O processo de seleção de propostas é
competitivo – o cliente escolhe um vencedor entre as propostas concorrentes. Para um
fornecedor, o sucesso está em conseguir o contrato, não em meramente apresentar uma
proposta. A apresentação de várias propostas não vencedoras em resposta a CPs pode pre-
judicar a reputação do fornecedor. Portanto, mesmo que seja a coisa certa a fazer, às vezes
é mais difícil para um fornecedor ter de decidir não participar de uma concorrência.

4. Os fornecedores precisam ser _______
_____________ sobre sua capacidade de
preparar propostas e sobre a _________
_____________ de ganhar o contrato.
A Figura 3.2 é um exemplo de um checklist sobre participar/não participar, que pode ser
utilizado por um fornecedor durante a apresentação ou não de uma proposta em resposta
a uma CP. Esse modelo pode ser usado na organização do fornecedor para que haja um
FIGURA 3.2 Checklist Participar/Não Participar
Checklist Participar/Não Participar
Título do Projeto: Programa de Treinamento de Supervisão
Cliente: Ace Manufacturing, Inc. Data de Entrega: 31/5
Avaliar cada fator como Alto, Médio ou Baixo
Fator Avaliação Comentários

Universidade local forneceu a maior
1. Concorrência A parte do treinamento para a ACE,
no passado.
As exigências da CP estão bem
2. Risco B definidas.
3. Coerente com nossa missão A Treinamento é o nosso negócio.
4. Oportunidade para ampliar

Algumas tarefas requerem
nossa capacidade
A videoconferências, algo que nunca
fizemos.
Nunca fizemos um treinamento para a
5. Reputação com o cliente B ACE.
6. Disponibilidade de recursos
A ACE possui recursos financeiros
financeiros
A destinados a implementar o
treinamento.
Lynn terá de remarcar suas férias.
7. Recursos disponíveis
Provavelmente, precisará trabalhar
para a elaboração de uma M
proposta de qualidade no fim de semana do Dia dos Pais para
concluir a proposta.
8. Recursos disponíveis
Será necessário subcontratar pessoas
para a execução do projeto
M para vários tópicos específicos de
treinamento.
Nossas vantagens, pontos fortes e diferenciais
• Bom histórico em treinamento de supervisão – temos muitos clientes que
nos procuraram mais de uma vez.
• Mais flexível que a universidade local em relação à necessidade da ACE
por treinamento na empresa durante o segundo e terceiro turnos das
operações.
Nossos pontos fracos
• A maioria de nossos clientes pertence ao setor de serviços, como
hospitais. A ACE é um fabricante.
• O presidente da ACE é formado na universidade local e
contribui muito para ela.
consenso na decisão. A Figura 3.2 ilustra o consenso entre pessoas-chave em uma firma
de consultoria de treinamento. Ela resume suas considerações sobre participar ou não de
uma CP da Ace Manufacturing, Inc. e tem por objetivo conduzir um importante programa
de treinamento de supervisão para empregados em sete fábricas espalhadas pelo país. Você
acha que eles deveriam apresentar uma proposta para a Ace?
DESENVOLVENDO UMA PROPOSTA VENCEDORA

É importante lembrar-se de que o processo de proposta é competitivo. O cliente usa a CP para
solicitar propostas concorrentes de fornecedores. Cada fornecedor, portanto, deve ter em
mente que a sua concorrerá com as de outros fornecedores, e o cliente escolherá a vence-
dora. A apresentação de uma proposta que atenda às especificações de trabalho do cliente
e aos requisitos da CP não é suficiente para garantir o posto de vencedor ao fornecedor.
Muitas ou mesmo todas as propostas provavelmente atenderão às exigências. O cliente vai
escolher aquela que oferece o melhor valor agregado.
Uma proposta é um documento de venda, não um relatório técnico. Na proposta, o for-
necedor deverá convencer o cliente de que ele:
• entende o que o cliente procura;

• é capaz de conduzir o projeto proposto;
• proporcionará o melhor valor agregado ao cliente;
• é o melhor fornecedor para resolver o problema;
• fará proveito de suas experiências bem-sucedidas em projetos anteriores relacionados;
• fará um trabalho profissional;
• alcançará os resultados pretendidos;
• completará o projeto dentro do orçamento e do prazo previstos;
• satisfará o cliente.

5. O processo de proposta é um processo
_______________. Uma proposta é um
documento de _______________.
Na proposta, o fornecedor destaca os fatores singulares que o diferenciam dos fornece-

dores concorrentes. A proposta do fornecedor deve enfatizar os benefícios para o cliente,
caso este o escolha para executar o projeto.
As propostas devem ser escritas de maneira simples e concisa, sem ser prolixas ou re-
dundantes. Deve-se usar uma terminologia com a qual o cliente esteja familiarizado e evitar
abreviações, acrônimos, jargões e outras palavras que o cliente possa não conhecer ou
compreender. Sempre que possível, fazer uso de gráficos e ilustrações simples. Ilustrações
demasiadamente complicadas devem ser evitadas; vários gráficos simples provavelmente
serão entendidos com mais facilidade pelo cliente do que um gráfico complicado. Ao sus-
tentarmos um argumento ou propormos uma abordagem ou conceito, devemos apoiá-lo
com lógica, fundamentos ou dados. As propostas devem especificamente abordar os requi-
sitos do cliente, conforme disposto na CP. Propostas muito generalizadas levarão o cliente
a questionar se o fornecedor realmente entende o que precisa ser feito e como fazê-lo. Por
exemplo, imagine que um dos requisitos na CP do cliente seja o desenvolvimento de uma
máquina que produza 20 peças por minuto. A proposta do fornecedor afirmando que “a má-
quina a ser desenvolvida produzirá de fato 20 peças por minuto” é mais convincente do que
aquela que afirma que “a máquina será desenvolvida para produzir um número máximo
de peças por minuto”. O cliente ficará em dúvida em relação à última afirmação, porque o
máximo poderia ser menos que 20 peças por minuto.

6. Em uma proposta, o fornecedor
deve ressaltar os fatores _______ que o
________ das propostas de ________.
Por fim, as propostas devem ser realistas, em termos de escopo, custo e cronograma, aos
olhos do cliente. Propostas recheadas de promessas ou demasiadamente otimistas podem
parecer sem credibilidade e, mais uma vez, levantar dúvidas sobre se o fornecedor entende
o que precisa ser feito e como fazê-lo.
ELABORAÇÃO DA PROPOSTA
A elaboração de uma proposta pode ser uma tarefa breve realizada por uma pessoa ou um
esforço intensivo que requer uma equipe de organizações ou pessoas com experiências
e habilidades diferentes. No caso simples de conceber e imprimir um relatório anual, um
profissional experiente da área gráfica (o fornecedor), após se reunir com o cliente para
discutir os requisitos, é capaz de elaborar uma proposta em pouco tempo sem envolver
outras pessoas. Contudo, quando uma agência governamental emite uma CP de um projeto
multimilionário para a concepção e construção de um novo sistema de tráfego expresso,
cada fornecedor interessado pode ter de montar uma equipe de várias pessoas e subcon-
tratados para ajudar no desenvolvimento da proposta. Nesses casos, ele pode designar um
gerente de proposta para coordenar o trabalho da equipe, a fim de garantir a elaboração de
uma proposta consistente e abrangente dentro do prazo estipulado pelo cliente.
O desenvolvimento de uma proposta abrangente para um projeto de grande porte deve
ser tratado como um projeto em si; assim, o gerente de proposta precisa se reunir com a
equipe de proposta e desenvolver um cronograma para sua conclusão até a data de entrega
especificada. O cronograma deve incluir as datas nas quais as pessoas envolvidas devem
entregar rascunhos da parte da proposta que lhes é atribuída, datas para revisões com os
respectivos membros da equipe e a data na qual a proposta será finalizada. O cronograma
da proposta deve permitir tempo para revisão e aprovação pela gerência dentro da organi-
zação do fornecedor. Também precisa haver tempo para a elaboração de eventuais gráficos,
digitação, cópia e entrega da proposta ao cliente, que pode estar a quilômetros de distância
do fornecedor.
As propostas em resposta a CPs para projetos técnicos muito grandes podem envolver
documentos de vários volumes que incluam desenhos de engenharia e centenas de páginas
de texto. E vale citar que o prazo de entrega para essas propostas costuma ser de 30 dias
após a emissão da CP! Normalmente, os fornecedores que participam desse tipo de projeto
fazem marketing pré-proposta, a fim de ter um rascunho de proposta pronto antes mesmo
de o cliente emitir uma CP formal. Durante o período de resposta de 30 dias, o fornecedor
primeiro pode revisar a proposta para incorporar quaisquer requisitos não previstos e, em
seguida, usar o tempo restante para “montar” uma proposta profissional de primeira linha.
Os clientes não pagam aos fornecedores para elaborar propostas. Estes últimos absor-
vem os custos como normais de marketing, antecipando os contratos vencedores e tirando
lucro deles.
Conforme dito anteriormente, a proposta é um documento de venda, não um relatório
técnico. Pode ser composta por várias páginas ou volumes, com centenas de páginas,
ilustrações e tabelas. Além disso, deve conter detalhes suficientes para convencer o clien-
te de que o fornecedor vai oferecer o melhor valor para ele. O excesso de detalhes na
proposta, contudo, pode “sufocar” o cliente e aumentar desnecessariamente os custos de
elaboração para o fornecedor.
CONTEÚDO DA PROPOSTA
As propostas costumam ser organizadas em três seções: técnica, de gestão e de custos. Para
as de grande porte, as seções podem estar em três volumes separados. A quantidade de
detalhes incluída pelo fornecedor dependerá da complexidade do projeto e do conteúdo da
CP. Algumas CPs, entretanto, afirmam que as propostas que excederem certo número de pá-
ginas não serão aceitas pelo cliente. Afinal, os clientes querem fazer uma avaliação breve de
todas as propostas enviadas e talvez não tenham tempo para analisar um grande número
de propostas volumosas.

7. Uma proposta deve abordar três
tópicos ou conter três seções.
Quais são elas?
Seção Técnica
O objetivo da seção técnica da proposta do fornecedor é convencer o cliente de que ele
entende sua necessidade ou problema e é capaz de oferecer a solução menos arriscada e de
maior benefício. A seção técnica deve conter os seguintes elementos:
1. Entendimento do problema. O fornecedor deve afirmar seu entendimento em relação

ao problema ou necessidade do cliente mediante as próprias palavras. Ele não deve
simplesmente copiar a declaração de problema contida da CP do cliente. A primeira
parte da seção técnica tem por objetivo mostrar ao cliente que o fornecedor entende
completamente o problema a ser resolvido ou a necessidade a ser abordada e estabe-
lecer, mais adiante, a base para a solução proposta. O fornecedor pode descrever, de
forma narrativa ou gráfica, a condição atual do cliente. Por exemplo, se o problema
for o alto índice de perdas em um processo de fabricação, o fornecedor incorpora o
fluxograma desse processo atual do cliente, que indica em que lugar as perdas estão
ocorrendo e quais outros problemas isso pode causar, como atrasos na produção. Os
clientes se sentirão mais seguros trabalhando com um fornecedor que acreditam que
realmente entenda seu problema.
2. Abordagem ou solução proposta. Alguns problemas já vêm acompanhados de uma
solução específica proposta – por exemplo, uma CP para redistribuir um grande es-
critório que acomode 10% mais pessoas. Contudo, em outros casos, isso não ocorre.
Um problema pode exigir a condução de uma tarefa de análise e desenvolvimento
como parte do projeto proposto antes que uma solução específica seja descrita em
detalhes. Nesses casos, a proposta do fornecedor deve descrever a abordagem ou
metodologia que seriam usadas no desenvolvimento da solução. Por exemplo, se
a CP for para um sistema especialista de inspeção sem contato destinado a calcular
certas características de um produto de formato complexo feito de material avança-
do, não seria realista que o cliente esperasse que os fornecedores desenvolvessem
o sistema como parte da proposta em si; em vez disso, a concepção e o desenvol-
vimento de engenharia ocorreriam como parte do projeto proposto. Contudo, na
proposta, o fornecedor deve convencer o cliente de que a abordagem apresentada

para a concepção, o desenvolvimento e a construção do sistema é lógica e realista.
Isso o levaria a oferecer um sistema que atende aos requisitos do cliente de forma
satisfatória.
Essa parte da seção técnica pode conter:
a. Uma descrição de como o fornecedor coletará, analisará e avaliará dados e infor-
mações sobre o problema.
b. Métodos que seriam usados pelo fornecedor para avaliar soluções alternativas
ou desenvolver mais a fundo a solução proposta para o problema. Essa porção
poderia incluir uma discussão de vários experimentos, testes ou modelos físicos
ou computadorizados que o fornecedor iria utilizar ou já utilizou em projetos
semelhantes.
c. Os fundamentos para a abordagem ou solução proposta. Esses fundamentos po-
dem se basear em experimentos anteriormente conduzidos pelo fornecedor, sua
experiência em resolver problemas semelhantes ou uma tecnologia exclusiva pa-
tenteada que usaria para resolver o problema.
d. A confirmação de que a solução ou abordagem proposta iria cumprir cada um dos
requisitos físicos, operacionais e de desempenho especificados na CP do cliente.
Por exemplo, se a CP para a concepção e construção de um day care especifi-
car que certos móveis precisam ser de um determinado tamanho para acomodar
crianças com menos de 1,20 metro de altura, a proposta deve afirmar que o for-
necedor atenderá a essa exigência. Não abordar cada um dos requisitos do cliente
levantará dúvidas em relação à solução proposta e pode arriscar as chances de o
fornecedor ganhar o contrato, principalmente se as propostas dos concorrentes
afirmarem que atenderão a todas as exigências.

8. Qual é o objetivo da seção técnica de
uma proposta?
Caso o fornecedor não possa atender a uma exigência específica do cliente, isso deve
ser declarado em sua proposta. Uma variação em relação ao requisito específico é
chamada de exceção. Para cada exceção feita a um requisito do cliente, o fornecedor
deve explicar por que esse requisito não pode ou não será atendido e propor uma
alternativa. Embora os fornecedores devam evitar fazer exceções aos requisitos do
cliente, poderá haver circunstâncias nas quais uma exceção é apropriada. Por exem-
plo, se o cliente requer um sistema de aquecimento elétrico para um edifício comer-
cial, o fornecedor pode abrir uma exceção e mostrar, na proposta, que os custos
iniciais e operacionais para um sistema de aquecimento movido a gás natural seriam
mais baixos para o cliente. Contudo, o cliente pode ter motivos bastante razoáveis,
além do custo, para querer um sistema de aquecimento elétrico e rejeitar propostas
que façam exceção a esse requisito.
3. Benefícios para o cliente. O fornecedor deve afirmar como a solução ou abordagem
proposta beneficiaria o cliente. Os benefícios podem ser quantitativos ou qualitativos
e podem incluir economia de custos, redução no tempo de processamento, redução
de estoques, melhor atendimento ao cliente, menos desperdício, perdas ou erros,
melhores condições de segurança, informações mais oportunas e manutenção redu-
zida. Essa parte da proposta deve ajudar a convencer o cliente sobre o valor dessa
abordagem proposta comparada com as propostas concorrentes.
Seção de Gestão
O objetivo da seção de gestão da proposta do fornecedor é convencer o cliente de que o for-
necedor é capaz de executar o trabalho proposto (o projeto) e atingir os resultados esperados.
A seção de gestão deve conter os seguintes elementos:
1. Descrição das atividades. O fornecedor precisa definir as principais atividades que

serão conduzidas durante a execução do projeto, além de fornecer uma breve descri-
ção de cada uma delas. Ele não deve simplesmente copiar a especificação de serviço,
caso a CP contenha uma. A proposta não precisa incluir detalhadamente uma lista
extensa das atividades, a qual deve ser desenvolvida durante a fase de planejamento
inicial do projeto, depois que o contrato for fechado.
2. “Deliverables”. O fornecedor deve incluir uma lista de todos os deliverables (itens ou
produtos tangíveis) que serão fornecidos durante o projeto, como relatórios, dese-
nhos, manuais e equipamentos.
3. Cronograma do projeto. O fornecedor deve disponibilizar um cronograma para a
execução das principais tarefas necessárias para concluir o projeto. O cronograma
deve mostrar que o fornecedor é capaz de concluir o projeto dentro do prazo estipu-
lado na CP. O cronograma de atividades pode ser fornecido em vários formatos: uma
lista de atividades com suas datas estimadas de início e término, um gráfico de barras,
normalmente chamado de gráfico de Gantt (tratado no Capítulo 5), com a duração
estimada de cada atividade representada por uma barra sobre uma linha de tempo
horizontal, ou um diagrama de rede no qual as atividades são ilustradas graficamente,
mostrando a seqüência e suas interdependências.
Além das principais atividades, o cronograma pode incluir datas para outros even-
tos-chave, como reuniões de análise de status, atividades de aprovação do cliente
e conclusão de itens devidos, como relatórios de progresso, desenhos, manuais ou
equipamentos.
4. Organização do projeto. O fornecedor deve descrever como o trabalho e os recursos
serão organizados para execução do projeto. Para grandes projetos envolvendo vá-
rias pessoas e subcontratados, pode ser adequado incluir um organograma (tratado
no Capítulo 13), mostrando as principais funções do projeto com o nome da pessoa
específica que ficará responsável em cada função. Currículos das pessoas-chave que
serão designadas para o projeto devem ser incluídos para convencer o cliente de que
sua experiência na área ajudará a garantir o sucesso do projeto. Além de um organo-
grama, ou, em vez desse, o fornecedor pode incluir uma matriz de responsabilidades
(tratada no Capítulo 5), relacionando as principais atividades do projeto e o nome da
pessoa, organização ou subcontratado responsável pelo cumprimento de cada uma
delas.
5. Experiência relacionada. Para ajudar a convencer o cliente de que é capaz de realizar
o projeto, o fornecedor deve disponibilizar uma lista de projetos semelhantes con-
duzidos por ele. Também deve descrever resumidamente cada projeto já realizado e
explicar como a experiência com esse projeto ajudará na execução bem-sucedida do
projeto proposto. O valor contratual para cada projeto também deve ser fornecido,
para dar ao cliente uma noção da capacidade de o fornecedor gerenciar projetos
do tamanho do projeto proposto. A probabilidade de ele ganhar um contrato para
um projeto milionário não é muito grande se todas as suas experiências anteriores
relacionadas forem com projetos de valores muito mais inferiores. Para cada projeto
semelhante já realizado, o fornecedor pode, opcionalmente, incluir o nome, cargo
e telefone de uma pessoa com a qual o cliente atual possa entrar em contato para
confirmar o desempenho do fornecedor. Cartas de referência de clientes satisfeitos
também podem ser incluídas. Esse tipo de informação será particularmente útil se o
fornecedor tiver um histórico de bons desempenhos.
6. Equipamentos e instalações. Alguns projetos exigem que o cliente use ou tenha aces-
so a equipamentos específicos, como computadores, softwares, equipamentos de fa-
bricação ou instalações de teste. Nesses casos, o fornecedor pode disponibilizar uma
lista dos equipamentos e instalações específicas, a fim de convencer o cliente de que
possui os recursos necessários para o sucesso do empreendimento.

9. Qual é o objetivo da seção de gestão
de uma proposta?
Seção de Custos
O objetivo da seção de custos da proposta do fornecedor é convencer o cliente de que o pre-
ço do fornecedor em questão para o projeto proposto é realista e razoável. Em alguns casos,
o cliente talvez deseje saber apenas o custo total final do projeto. Alguns outros clientes
também querem ser informados sobre os custos de itens opcionais. Por exemplo, um casal
que solicita propostas a vários fornecedores para a construção de uma casa pode desejar
saber o custo total acrescido de custos opcionais, como, por exemplo, custos da execução
de um jardim, de uma varanda, de um porão, de uma piscina ou de uma cerca no jardim
dos fundos. CPs de agências governamentais geralmente exigem que os fornecedores for-
neçam uma análise detalhada dos diversos custos.

10. Qual é o objetivo da seção de custos
de uma proposta?
A seção de custos geralmente possui um sistema de tabelas que inclui os custos estima-
dos do fornecedor para os seguintes elementos:
1. Mão-de-obra. Essa parte fornece os custos estimados das várias classes de funcioná-
rios previstas para trabalhar no projeto. Pode incluir as horas estimadas e o valor por
hora para cada pessoa ou classe; por exemplo, para um engenheiro, um técnico, um
operador de máquina ou um programador. As horas estimadas devem ser realistas.
Se a carga horária é muito elevada e tem muita “gordura” (é superestimada), os cus-
tos estimados totais podem ser maiores do que o cliente está disposto a pagar. Por
outro lado, se a carga horária total estimada for muito baixa, o cliente poderá perder
dinheiro no projeto. O valor por hora geralmente baseia-se no salário anual de cada
pessoa ou no salário médio de cada classe, acrescido de uma porcentagem para
cobrir os benefícios adicionais do funcionário (seguro de saúde, aposentadoria etc.).
Em seguida, são divididos pelo número de horas de trabalho regulares por ano (por
exemplo, 40 horas semanais × 52 semanas equivalem a 2.080 horas) para determinar
a carga horária de trabalho de cada funcionário ou classe de funcionários.
2. Materiais. Nessa parte, são fornecidos os custos dos materiais que o cliente precisa
comprar para o projeto. Por exemplo, o custo dos materiais para um projeto de reforma
podem incluir os relativos à alvenaria, novas janelas, componentes elétricos e hidráuli-
cos e materiais de revestimento.
3. Subcontratados e consultores. Se não possuem conhecimento e habilidades suficien-
tes ou recursos para executar determinadas tarefas do projeto, os fornecedores pode-
rão empregar subcontratados ou consultores no seu lugar. Por exemplo, um projeto

para renovar o porão de uma igreja e transformá-lo em um day care poderá exigir
que o fornecedor subcontrate a remoção de revestimentos antigos e contrate um
consultor para analisar códigos e regulamentos relacionados a day cares. O forne-
cedor geralmente pede que os subcontratados e consultores enviem um escopo da
proposta de trabalho, bem como os custos de suas tarefas. Em seguida, ele inclui
esses custos no custo geral do projeto.
4. Equipamentos e aluguel de espaços. Muitas vezes, o fornecedor terá de alugar equi-
pamentos especiais, ferramentas ou instalações exclusivamente para a realização
do projeto.
5. Viagens. Se há necessidade de uma viagem durante o projeto (que não seja local), os
custos relativos (como preço de passagens), acomodação (quartos de hotel) e refei-
ções precisam ser incluídos. O fornecedor deve, primeiramente, calcular a quantida-
de e a duração das viagens. Por exemplo, se o cliente é uma agência governamental
em Washington, DC, e o fornecedor está na Califórnia, deve-se considerar os custos
relacionados à viagem para Washington, necessária para reuniões de análise do pro-
jeto com o cliente.
6. Documentação. Alguns clientes desejam que o fornecedor indique separadamente
os custos relacionados à documentação do projeto (deliverables). Pode tratar-se do
custo de desenhos, relatórios e manuais impressos ou do custo para a produção de
fitas de vídeo ou CD-Roms.
7. “Overhead”. Os fornecedores acrescentarão uma porcentagem sobre os custos dos
itens 1 ao 6 para compensar seu overhead normal – custos indiretos no ramo de
negócios como seguros, desvalorizações, contabilidade, administração geral, marke-
ting e recursos humanos. Obviamente, em projetos informais – como uma festa em
uma cidadezinha, organizada por um grupo de voluntários – os custos de overhead
não são aplicáveis.
8. Aumento de custos. Para projetos maiores, com duração prevista de vários anos, o
fornecedor precisa incluir o aumento dos custos sobre o valor dos salários e mate-
riais utilizados conforme a duração do projeto. Por exemplo, para um projeto de três
anos, o fornecedor poderá prever um aumento salarial de 4% nos últimos dois anos
do projeto. Se, no mesmo projeto, ele precisa comprar a maior parte dos materiais
no terceiro ano, as estimativas de custos dos materiais usados naquele momento
podem sofrer um aumento percentual (para compensar o custo previsto em sua
aquisição).
9. Contingência. A contingência ou reserva de gerenciamento corresponde a um
valor que poderá ser acrescentado pelo fornecedor para compensar acontecimentos
inesperados – itens que tenham sido ignorados ou tarefas que possivelmente terão
de ser refeitas, por não terem apresentado bons resultados da primeira vez.
10. Taxa ou lucro. Dos itens 9 ao 10, falou-se de custos. Agora o fornecedor deve acres-
centar um valor a seu lucro. O custo total mais o lucro é o preço do fornecedor para
o projeto proposto.

11. Quais elementos cada uma dessas
três seções pode conter?
CONSIDERAÇÕES SOBRE PREÇOS

Ao elaborar uma proposta, os fornecedores estão geralmente competindo entre si para con-
seguir ganhar um contrato. Portanto, precisam ser cautelosos e não exigir um preço muito
elevado para o projeto proposto. No entanto, eles também têm de tomar cuidado para não
cobrar um valor muito reduzido. Do contrário, poderão perder dinheiro em vez de lucrar,
ou talvez precisem requisitar fundos adicionais ao cliente, o que poderia ser constrangedor
ou abalar a reputação do fornecedor.
O fornecedor deve considerar os itens a seguir ao determinar o preço para o projeto
proposto:
1. Confiabilidade nas estimativas de custo. O fornecedor está seguro de que o custo
total do projeto proposto está completo e apresenta um valor preciso? É aconselhável
que ele reserve um tempo para repensar, de forma detalhada, o projeto e os cus-
tos estimados, em vez de realizar um cálculo aproximado. O ideal seria que os custos
fossem baseados em um projeto recente semelhante ou – no caso de estimativas de
custos e materiais – em cotações, catálogos ou tabelas de preços atuais. Aqui reco-
menda-se consultar pessoas experientes ou especialistas para auxiliar no cálculo do
esforço de trabalho. Em geral, quanto mais detalhadas forem as estimativas de custos,
melhor o resultado dos empreendimentos.
2. Riscos. Se o projeto proposto envolve uma medida não empregada anteriormente –
por exemplo, o projeto de pesquisa e desenvolvimento de um medicamento para o
controle de uma doença –, é preciso incluir uma grande quantidade de fundos para
contingências ou reservas de gerenciamento.
3. Valores de projeto para o fornecedor. Pode haver circunstâncias em que o fornecedor
esteja disposto a se sujeitar a um preço apertado ou baixo. Por exemplo, se deter-
minado fornecedor não possui grande número de projetos, possivelmente precisará
demitir empregados, a não ser que novos contratos sejam obtidos. Em uma situação
como essa, ele poderá incluir uma taxa bem pequena, a fim de ampliar as chances
de ganhar o contrato e evitar a dispensa das pessoas. Um outro exemplo de projeto
que pode ser particularmente valioso para o fornecedor é aquele que possibilita o
aumento de capacidades ou sua expansão em novos tipos de projeto. Um fornecedor
de construção que tem feito apenas projetos de reforma pode querer construir casas
completas e estar disposto a obter um lucro reduzido, visando à entrada no mercado
e ao estabelecimento de sua reputação.
4. Orçamento do cliente. Se sabe quanto dinheiro o cliente possui orçado para um
projeto, o fornecedor não deve oferecer um preço que ultrapasse o valor disponibi-
lizado pelo cliente. Nesse momento, um bom marketing pré-proposta é importante.
Ao ajudar um cliente em potencial a identificar uma necessidade ou ao apresentar
propostas não solicitadas (incluindo estimativas de custo), o fornecedor pode auxi-
liar um cliente a estabelecer o orçamento para o projeto. Então, caso o cliente emita
uma CP competitiva (e sem revelar o valor orçado para o projeto), o fornecedor que
tiver as informações “secretas” do orçamento do cliente poderá ter mais chances de
apresentar uma proposta com um preço aceitável, em relação a outros fornecedores
que agiram da mesma forma.

12. Quais são alguns itens que o
fornecedor deve levar em consideração
ao determinar um preço para um projeto
proposto?
5. Concorrência. Se há expectativas de que muitos fornecedores apresentem propostas

em resposta a uma mesma CP ou se alguns concorrentes estão ávidos por trabalho,
pode ser necessária a oferta de preço com uma perspectiva de lucro pequena, au-
mentando-se, assim, as chances de ganhar o contrato.
ENTREGA E ACOMPANHAMENTO DE PROPOSTA

A CP do cliente normalmente fornece instruções sobre a data do vencimento da entrega das
propostas e sobre o nome e o endereço da pessoa a quem devem ser entregues. Alguns
clientes desejam que o fornecedor providencie várias cópias da proposta, que serão distri-
buídas a várias pessoas da organização, para serem revisadas e avaliadas. Para o cliente, é
mais fácil e mais barato quando o fornecedor faz as cópias necessárias; esse fato é espe-
cialmente válido aos projetos de grande porte, em que as propostas podem ter centenas
de páginas ou desenhos grandes e gráficos coloridos. Agências governamentais são muito
exigentes em relação a prazos; por isso, propostas entregues com atraso não serão aceitas,
e os esforços do fornecedor terão sido desperdiçados. Em vez de enviar as propostas pelos
Correios, alguns fornecedores as entregam pessoalmente para garantir que cheguem dentro
do prazo estipulado. Outros fornecedores enviam duas vias da mesma proposta, valendo-
se de distintos serviços dos Correios, para assegurar que pelo menos uma cópia chegue ao
local de destino a tempo. Precauções como essas são tomadas no caso de projetos multi-
milionários ou quando milhares de horas foram gastas durante o marketing pré-proposta e
a preparação da proposta. Os clientes podem solicitar o envio dessas propostas por e-mail.
Essa alternativa pode poupar aos fornecedores participantes e ao cliente tempo e dinheiro
relacionado à impressão, correspondência e distribuição.
É importante que os fornecedores continuem tomando iniciativas mesmo depois da en-
trega da proposta. É recomendável que o fornecedor ligue para o cliente e confirme se este
a recebeu. Após vários dias, aconselha-se que entre em contato com o cliente mais uma vez
para saber se ele tem alguma pergunta a fazer ou se necessita de algum esclarecimento so-
bre qualquer ponto da proposta. Esse acompanhamento precisa ser feito de modo profissio-
nal, para causar uma boa impressão ao cliente. Se o fornecedor parecer agressivo, em vez
de compreensivo, o cliente poderá interpretá-lo como um elemento inoportuno que está
influenciando o processo de avaliação da proposta. Um fornecedor deve sempre considerar
se os concorrentes estão sendo agressivos (bem como a proporção dessa agressividade) no
processo de acompanhamento, depois que a proposta foi entregue.

13. Os fornecedores devem continuar a
ser ________________ mesmo depois do
envio da proposta.
Clientes industriais, especialmente os governamentais, normalmente não respondem a

subseqüentes tentativas de comunicação dos fornecedores, pois não querem que nenhum
fornecedor ganhe uma vantagem desleal ao influenciar o processo de avaliação da proposta.
Esses clientes darão início a quaisquer comunicações necessárias. Em geral, o contato será
uma lista de perguntas específicas que precisam ser respondidas ou pontos que devem ser
esclarecidos, relativos à proposta de um fornecedor em particular. Exige-se uma resposta
por escrito do fornecedor até certa data.
AVALIAÇÃO DE PROPOSTAS PELO CLIENTE

Os clientes avaliam as propostas dos fornecedores de maneiras distintas. Alguns primeira-
mente vêem os preços das várias propostas e selecionam, por exemplo – para fins de ava-
liação futura –, apenas as com os preços mais baixos. Outros clientes descartam, no início,
aquelas que ultrapassam o valor de seu orçamento ou as propostas cuja seção técnica não
atende às requisições da CP. Outros, especialmente em projetos de grande porte, formam
uma equipe para análise de propostas. Eles usam um sistema de pontuação para determi-
nar se cada proposta atende às requisições da CP e classificá-la conforme um critério de
avaliação preestabelecido.
A Figura 3.3 ilustra esse sistema de pontuação para avaliar propostas. Ele foi utilizado
pela empresa AJACKS Information Services na análise de propostas entregues pelos forne-
cedores em resposta à chamada de propostas do Capítulo 2 (Figura 2.2). Trata-se da ava-
liação de uma proposta da Galaxy Market Research, Inc., um dos cinco fornecedores que
entregaram propostas à AJACKS. Cada membro da equipe de análise de proposta do cliente
completa uma ficha de pontuação para todas as propostas do fornecedor. Em seguida, essas
fichas são utilizadas pela equipe de análise de propostas, para que todos cheguem a um
acordo sobre qual será o fornecedor vencedor, se houver algum. As fichas de pontuação
não constituem o único mecanismo para se avaliar propostas e selecionar vencedores. São
normalmente o pontapé inicial no processo de tomada de decisões.
Algumas vezes, as propostas da seção técnica e da seção de gestão são avaliadas primei-
ro, sem considerar os custos. Aquelas com maior pontuação na análise técnica/de gestão
são, em seguida, avaliadas conforme seus custos. O cliente compara o mérito técnico/de
gestão com os custos a fim de determinar a proposta que oferece o melhor valor.
Entre os critérios que poderão ser utilizados pelos clientes na avaliação das propostas
do fornecedor, estão:
• Consistência com a declaração de trabalho do cliente e com as requisições da cha-

mada de propostas.
• Compreensão do problema ou da necessidade do cliente, por parte do fornecedor.
• Efeito e praticidade na abordagem proposta pelo fornecedor para a resolução do
problema.
• Experiência do fornecedor e seu êxito em projetos semelhantes.
• Experiência de pessoas-chave, que serão designadas para trabalhar no projeto.
• Capacidade de gestão, incluindo a habilidade do fornecedor em planejar e controlar
o projeto; garantindo, portanto, que o escopo do trabalho seja concluído dentro do
orçamento e do cronograma previstos.
• Realismo do cronograma do fornecedor. O cronograma é realista, considerando-se os
recursos que o fornecedor planeja aplicar ao projeto? Atende ao prazo do cronogra-
ma do cliente, conforme requisitado na CP? O projeto está bem detalhado?
• Preço. Clientes podem avaliar não somente o preço total do cliente para o projeto,
mas também os custos detalhados da seção de custos da proposta. Os clientes preocu-
pam-se com a sensatez, o realismo e a integridade relativos aos custos do fornecedor.
Este usou uma metodologia razoável para a estimativa de custos? As horas de traba-
lho, as classificações e as taxas são apropriadas para o tipo de projeto? Algum item
ficou de fora? O cliente quer ter a certeza de que o fornecedor não está “diminuindo”
o preço para ganhar o contrato, nem espera recorrer a ele para fundos adicionais
se o projeto ultrapassar seu custo proposto. Não é ético e pode ser ilegal fazer uma
redução intencional do preço.
Em alguns casos, principalmente quando um grande número de propostas é recebido,

seu processo de avaliação irá produzir uma pequena lista daquelas que o cliente considera
aceitáveis e de bom valor. Em seguida, o cliente pode pedir a cada um desses fornecedores
a apresentação oral da proposta. Isso oferece uma oportunidade final para cada fornecedor
convencer o cliente de que sua proposta irá oferecer o melhor valor agregado. O cliente
também pode pedir que cada um desses fornecedores lhe envie uma melhor oferta final
(MOF). Isso dá ao fornecedor uma última chance de reduzir seu preço e, possivelmente,
ganhar o contrato. Contudo, o cliente normalmente exige que o fornecedor apresente uma
argumentação por escrito para quaisquer reduções de custo que possam garantir que são
razoáveis. O fornecedor, por exemplo, pode repensar as pessoas que serão designadas
para o projeto e determinar que, para algumas tarefas, pessoas com menor custo salarial
FIGURA 3.3 Ficha para Avaliação de Propostas
Empresa AJACKS Information Services
Título do Projeto: Necessidades de Informação Técnica de Fabricantes
Fornecedor: Galaxy Market Research Inc.
Avaliar todos os critérios em uma escala de 1 (alto) a 10 (baixo)
Critérios para Peso Avaliação Pontuação Comentários

avaliação (A) (B) (AxB)
Descrição superficial dos
1. Abordagem 30 4 120
métodos.
Pouca experiência com
2. Experiência 30 3 90
empresas industriais.
Menor preço proposto
3. Preço 30 9 270
demonstrado em detalhes.
O cronograma é
4. Cronograma 10 5 50
demasiadamente otimista.
Total 100 530
Vantagens dessa proposta
• Esta é a proposta com o preço mais baixo recebido. Parece que os salários
dos empregados da Galaxy são baixos, em comparação com os de outros
proponentes.
Preocupações relativas a essa proposta
• A Galaxy pode não compreender totalmente os requisitos.

• Baixos salários no orçamento podem ser reflexo de pouca experiência dos
funcionários que a Galaxy planeja empregar.
• Um cronograma otimista (3 meses) pode indicar que a Galaxy não
compreende totalmente o escopo do trabalho.
poderiam ser empregadas ou pode decidir que alguma viagem poderia ser eliminada, ou
viagens poderiam ser combinadas, para reduzir os custos.
Após a escolha do cliente, o fornecedor vencedor, é informado do fato, estando sujeito
à negociação bem-sucedida do contrato.
TIPOS DE CONTRATO
Só porque o fornecedor foi escolhido como vencedor não significa que ele pode começar a
fazer o trabalho. Antes que o projeto possa prosseguir, um contrato deve ser assinado entre
o consumidor e o fornecedor – a etapa final nessa segunda fase do ciclo de vida.
O contrato é um veículo para o estabelecimento de uma boa comunicação cliente-for-
necedor e para que estes cheguem a um entendimento mútuo, com expectativas claras que
garantam o sucesso do projeto. Trata-se de um acordo entre o fornecedor, que concorda
em fornecer um produto ou serviço (deliverables), e o cliente, que concorda em pagar ao
fornecedor determinada quantia em troca. O contrato deve especificar claramente os deli-
verables esperados do fornecedor. Por exemplo, este vai afirmar que o resultado do pro-
jeto atenderá a certas especificações e que determinadas documentações serão fornecidas.
O contrato também deve afirmar os prazos nos quais o cliente fará pagamentos ao fornece-
dor. Existem basicamente dois tipos de contratos: de preço global e por administração.
Contratos de Preço Global

Em um contrato de preço global, o cliente e o fornecedor concordam com um preço para
um trabalho proposto. O preço permanece fixo, a menos que cliente e fornecedor concor-
dem em alterá-lo. Esse tipo de contrato é de baixo risco para o cliente, pois este não pagará
mais do que o preço estipulado, independentemente de quanto o projeto realmente custou
para o fornecedor. No entanto, um contrato de preço global é de alto risco para o fornece-
dor, pois, se o custo de conclusão do projeto for maior do que o planejado originalmente,
ele terá um lucro menor que o previsto ou até mesmo perderá dinheiro.
Um fornecedor que concorre por um contrato de preço global deve estabelecer estima-
tivas de custos completas e exatas e incluir custos de contingência suficientes. No entanto,
ele precisa ser cuidadoso para não estipular um preço muito alto para o projeto proposto,
ou, então, um fornecedor concorrente com um preço menor pode ser escolhido.

14. Um fornecedor concorrendo para
um contrato de preço global deve
desenvolver estimativas de custo ______
________ e ____________ além de incluir
custos de ______________ suficientes.
Os contratos de preço global são apropriados para projetos mais bem definidos e de pequeno
risco. Exemplos desse tipo de contrato são a construção de uma casa modelo-padrão ou proje-
to e produção de um panfleto para o qual o cliente estabelece especificações detalhadas com
relação a formato, conteúdo, fotos, cor, número de páginas e quantidade de cópias.
Contratos por Administração

Em um contrato por administração, o cliente concorda em pagar ao fornecedor todos
os custos reais (mão-de-obra, materiais e assim por diante), independentemente de quan-
Ajudando Aqueles que Precisam
A Pura Vida Partners vende café orgânico, cultivado na sombra, sob a marca Fair Trade, para
uma cadeia de cafeterias em campi universitários nos Estados Unidos. A empresa é um em-
preendimento sem fins lucrativos administrada por John Sage e Chris Dearnley. Cem por
cento de todo o lucro é destinado às comunidades agrícolas carentes nas regiões produto-
ras de café. O dinheiro é revertido a ligas de futebol, cozinhas que fazem “sopão” e centros
de informática na Costa Rica, na Nicarágua e na Guatemala. Sage usa sua habilidade em
negócios para ajudar aqueles que precisam. Ele conta com o conhecimento empresarial
e o treinamento que recebeu enquanto cursava Administração de Empresas na Harvard
Business School e com sua experiência como profissional de marketing na Starbucks, na
Disney e na Microsoft para transformar seu negócio em sucesso.
A competitividade de Sage, seu comprometimento com o sucesso e a paixão por pro-
dutos de qualidade ajudam a Pura Vida a garantir receita e promover a consciência social
por meio de marketing e tecnologia. Jovens de 55 campi universitários param nas cafeterias
para saborear o café Fair Trade. Esse grupo alvo de consumidores é tipicamente formado
por pessoas que consomem uma grande quantidade de café. Além disso, eles têm interes-
se nas questões sociais e estão cientes delas. A Pura Vida se uniu a outras cem empresas
norte-americanas no movimento Fair Trade. A instituição tenta garantir condições justas de
trabalho para os pequenos agricultores produtores de café, assegurando um preço justo ao
produto. Os consumidores também são estimulados a fazer doações para projetos comu-
nitários da Pura Vida na Costa Rica. Aqueles que compram pela Internet podem contribuir
a cada vez que adquirir o café. O site gera de mil a três mil dólares por mês em doações de
consumidores. A empresa gerou um total de US$ 200 mil em doações, em 2003, mediante
seu website.
O dinheiro é destinado a programas de financiamento para ajudar crianças e famílias
em situação periclitante. A Pura Vida patrocina programas na Costa Rica, onde mantém
uma equipe local de funcionários e voluntários. Eles formaram parcerias com agências lo-
cais para ajudar comunidades específicas de baixa renda naquele país. O programa trata de
questões relacionadas à pobreza. As crianças dessas comunidades correm o risco de sofrer
de dependência de drogas, violência e negligência. Elas vivem em um ambiente de medo
e insegurança. Para incentivar mudanças, a Pura Vida patrocina programas que ofereçam
um ambiente acolhedor, onde adultos responsáveis interagem com as crianças e se tor-
nam modelos de maturidade e crescimento. Isso cria um ambiente com segurança e apoio.
A Microsoft ajudou a montar quatro centros de informática nas comunidades, a fim de
incentivar o estudo e o estabelecimento de objetivos futuros. As cozinhas de “sopão” ofere-
cem refeições saudáveis para crianças e mães. Um clube infantil de fim de semana propor-
ciona um ambiente seguro para as crianças brincarem. Times infantis de futebol ajudam a
formar a confiança das crianças e sua capacidade de trabalhar em equipe.
A empresa está fundada na fidelidade dos consumidores e em seu interesse pelos
produtos e pela missão social que ela representa. Por meio do raciocínio crítico e criativo –
habilidades desenvolvidas durante o tempo que passou trabalhando com marketing em
grandes empresas –, Sage tem ajudado a Pura Vida Partners a usar com sucesso essa visão
de agente de mudança social.
Chou, A. Changing Minds a Cup at a Time. CEO Magazine, junho de 2004.
tidade, mais algum lucro acordado. Esse tipo de contrato é de alto risco para o cliente,
pois os custos do fornecedor podem superar o valor proposto – assim como quando uma
oficina mecânica estipula uma estimativa para consertar um eixo de transmissão, mas apre-
senta uma conta final superior ao orçamento original. Em contratos por administração, o
cliente geralmente exige que, no prazo do projeto, o fornecedor compare regularmente os
gastos reais com o orçamento proposto e preveja novamente os custos na conclusão, com-
parando-o com o preço original proposto. Isso permite que o cliente tome providências caso
pareça que o projeto vá superar os custos do orçamento originalmente proposto. Esse tipo
de contrato é de baixo risco para o fornecedor, pois todos os custos serão reembolsados
pelo cliente. O fornecedor não perde dinheiro com esse tipo de contrato. No entanto, se
seus custos realmente superarem o orçamento proposto, a reputação desse fornecedor será
afetada e, por sua vez, reduzirá as chances de que ele possa fechar contratos no futuro.

15. Escreva as palavras “baixo” e “alto”
em cada espaço, dependendo do grau de
risco para o cliente e para o fornecedor
associado a cada tipo de contrato.
Cliente Fornecedor
Preço global
Por administração
Os contratos por administração (ou a preço de custo) são mais apropriados para projetos
que envolvem risco. Exemplos desse tipo de contrato são o desenvolvimento de um novo apa-
relho de robótica para auxiliar uma cirurgia ou a limpeza total de um ambiente contaminado.
DISPOSIÇÕES CONTRATUAIS
A seguir, são apresentadas algumas das disposições contratuais gerais que podem estar
incluídas no projeto:
1. Declaração enganosa de custos. Declara ilegal ao fornecedor exagerar as horas ou os
custos gastos no projeto.
2. Aviso sobre custos excedentes ou atraso de cronograma. Delineia as situações em que
o fornecedor deve notificar o cliente imediatamente sobre quaisquer custos exce-
dentes antecipados ou reais ou sobre atrasos de cronograma, emitindo por escrito as
razões de tal fato e um plano para corrigi-lo, a fim de recuperar os custos dentro do
orçamento e de reajustar o cronograma.
3. Aprovação do subcontratado. Indica quando o fornecedor precisa obter uma aprova-
ção antecipada do cliente, antes de convocar um subcontratado para executar uma
tarefa do projeto.
4. Informações ou equipamentos fornecidos pelo cliente. Especifica os itens (como peças
para a condução de testes) que o cliente vai providenciar ao fornecedor durante o
projeto e as datas em que disponibilizará esses itens. Essa disposição impede que
o fornecedor seja responsabilizado por desvios no cronograma causados por atrasos
do cliente na provisão de informações, peças ou outros itens.
5. Patentes. Abrange a posse de patentes que podem resultar da condução do projeto.
6. Divulgação de informações proprietárias. Proíbe, a uma das partes, a divulgação para
outras pessoas de informações confidenciais relativas ao projeto, de tecnologias e de
processos utilizados por outra parte durante o projeto, vetando também seu uso para
quaisquer outros fins que não estejam relacionados ao trabalho.
7. Considerações internacionais. Especifica ajustes a serem feitos a clientes de outros
países. Contratos de projetos elaborados para um cliente estrangeiro ou conduzidos, em
parte, em um outro país podem exigir que o fornecedor realize certos ajustes, como:
• Esforços pré-proposta são essenciais para estabelecer o alicerce necessário à finali-

zação do contrato com o cliente.
• Não espere que solicitações de CPs sejam divulgadas pelos clientes antes de co-
meçar a elaborar propostas. Ao contrário, faça contatos com clientes em potencial
muito antes de estes prepararem suas CPs.
• Trabalhar próximo a um cliente em potencial coloca o fornecedor em uma melhor
posição, aumentando as chances de este ser escolhido como vencedor. Por isso,
aprenda o máximo que puder acerca das necessidades e dos problemas do cliente,
bem como do processo de tomada de decisões durante o marketing pré-proposta.
• A familiarização com as necessidades, exigências e expectativas do cliente ajudará
na elaboração de uma proposta mais claramente direcionada.
• Seja realista quanto à capacidade para elaborar uma proposta de qualidade e à
probabilidade de ganhar o contrato. A simples preparação de uma proposta não é o
suficiente; ao contrário, esta deve apresentar qualidade suficiente para ter chances
de vencer.
• Uma proposta é um documento de venda, não um relatório técnico. Por isso, deve
ser escrita de maneira simples e concisa, utilizando a terminologia com a qual o
cliente está familiarizado.
• Em uma proposta, é importante destacar os fatores singulares que a diferenciam
das propostas de concorrentes.
• As propostas devem ser realistas. Aquelas que prometem demais ou que são exces-
sivamente otimistas podem parecer inacreditáveis aos olhos do cliente, que poderá
duvidar da capacidade de o fornecedor saber ou não o que precisa ser feito e de
que forma será executado.
• Ao participar de um projeto de preço global, o fornecedor deve desenvolver esti-
mativas de custo exatas e completas e incluir suficientes custos de contingência.
• observar determinados feriados ou regras de trabalho;

• dispor de certa porcentagem dos custos do contrato para mão-de-obra ou para
materiais dentro do país do cliente;
• fornecer documentações do projeto, como manuais e relatórios, no idioma do
cliente.
8. Conclusão. Declara as condições em que o cliente pode encerrar o projeto, como,
por exemplo, a não-execução do projeto pelo fornecedor.
9. Condições de pagamento. Discute os princípios em que o cliente vai fundamentar-se
para pagar o fornecedor. Alguns tipos de pagamentos são:
• mensais, baseados nos custos reais contratados pelo fornecedor;
• pagamentos quinzenais ou mensais uniformes, baseados na duração total estima-
da do cronograma do projeto;
• porcentagens sobre o valor total do contrato, pagas quando o fornecedor finalizar
marcos importantes predeterminados;
• pagamento único, quando o projeto for concluído.
Em alguns casos, por exemplo, quando um fornecedor precisa comprar uma quan-
tidade significativa de materiais e suprimentos durante os estágios iniciais do projeto,
o cliente oferece um pagamento inicial reduzido no início do contrato.
10. Bônus/Penalidades. Alguns contratos apresentam a incursão de um bônus, que o clien-
te pagará ao fornecedor, caso o projeto seja concluído antes do tempo estimado ou
caso ele supere outras requisições do cliente relativas à execução do projeto. Por
outro lado, alguns contratos incluem a incursão de uma penalidade, por meio da qual
o cliente poderá reduzir o pagamento final ao fornecedor caso o projeto não seja
concluído dentro do prazo estimado ou se as exigências relativas a sua execução não
sejam atendidas. Algumas dessas penalidades podem ser substanciais, por exemplo,
de 1% sobre o preço total do contrato para cada semana extra de duração do projeto,
considerando-se o prazo estipulado para sua conclusão, atingindo o máximo de 10%.
Se o projeto for estendido por dez semanas, o fornecedor poderá perder seu lucro e
uma grande perda será observada.
11. Mudanças. Envolve os procedimentos relativos à apresentação e à aprovação do
projeto, bem como os relacionados à implementação de mudanças no cronograma
ou escopo do projeto. As mudanças podem ser iniciadas pelo cliente ou propostas
pelo fornecedor. Algumas delas podem precisar de alterações nos preços (aumento
ou redução); outras, não. Todas as mudanças devem ser documentadas e aprovadas
pelo cliente antes de serem incorporadas ao projeto. Geralmente, os clientes desejam
que o fornecedor ofereça um preço estimado – com uma indicação do impacto das
mudanças no cronograma – para uma mudança proposta, antes de permitir que o
fornecedor implemente essa mudança. Se um fornecedor realizar mudanças sem a
aprovação do cliente ou apenas mediante as aprovações verbais emitidas por algum
integrante de sua organização que possa não estar autorizado para isso, o fornecedor
correrá o risco de não receber pelas mudanças realizadas.
RESUMO
O desenvolvimento de soluções propostas, realizado pelos fornecedores interessados ou
pela equipe interna do projeto, é a segunda fase do ciclo de vida do projeto. Essa fase se
inicia quando uma CP é disponibilizada no fim da fase de identificação das necessidades
e termina quando um acordo é estipulado com a pessoa, a organização ou o fornecedor
escolhido para implementar a solução proposta.
Os fornecedores devem estabelecer relações com clientes em potencial antes de ela-
borar uma chamada de proposta. Precisam ter contato freqüente com clientes antigos e
atuais, além de iniciar contatos com clientes em potencial. Durante esses contatos, os for-
necedores devem ajudar os clientes a identificar as áreas em que estes podem se beneficiar
da implementação de projetos que tratam de necessidades, problemas ou oportunidades.
Esses esforços pré-CP são cruciais para definir se um contrato será, no final, estabelecido
com o cliente.
Como o desenvolvimento e a elaboração de uma proposta requerem tempo e dinheiro,
os fornecedores interessados em apresentar uma proposta em resposta a uma CP devem ser
realistas sobre a probabilidade de serem escolhidos como vencedores. Avaliar se uma pro-
posta tem ou não de ser levada adiante é uma ação que se denomina, às vezes, decisão de
participar/não participar. Alguns fatores que um fornecedor deve considerar ao tomar uma
decisão de participar/não participar são a concorrência, os riscos, a missão de negócios, a
habilidade para manter sua capacidade, sua reputação diante do cliente, a disponibilidade
de rercursos financeiros do cliente e a disponibilidade de recursos para a proposta e para
o projeto.
É importante lembrar que o processo da proposta é competitivo, a qual um documento de
venda que deve ser escrito de maneira simples e concisa. Nela, o fornecedor precisa destacar
os fatores singulares que o diferenciam dos fornecedores concorrentes. A proposta do for-
necedor deve também enfatizar os benefícios para o cliente, caso este escolha o fornecedor
em questão para executar o projeto. O cliente escolherá o fornecedor que ofereça o melhor
valor agregado.
As propostas estão geralmente organizadas em três seções: seção técnica, seção de ges-
tão e seção de custos. O objetivo da seção técnica da proposta é convencer o cliente de
que o fornecedor entende sua necessidade ou problema e de que pode oferecer a solução
menos arriscada e mais eficiente. A seção técnica deve mostrar que o problema é compre-
endido; e propor uma abordagem ou solução e demonstrar os benefícios para o cliente. O
objetivo da seção de gestão é convencer o cliente de que o fornecedor pode realizar o tra-
balho proposto e alcançar os resultados desejados. A seção de gestão deve conter a descri-
ção das tarefas de trabalho, a lista das deliverables, o cronograma do projeto, a descrição da
organização do projeto, o resumo de uma experiência relacionada e uma lista de qualquer
equipamento ou recurso do fornecedor. O objetivo da seção de custo é convencer o cliente
de que o preço do fornecedor, para o projeto proposto, é realista e aceitável. A seção de
custo geralmente contém tabelas dos custos estimados pelo fornecedor de fatores, como
mão-de-obra, materiais, subcontratados, consultores, equipamentos, aluguel de espaços,
viagem, documentação, overhead, aumento de custos, contingência e uma taxa ou lucro.
Quando elaboram propostas, os fornecedores geralmente competem com outros forne-
cedores para ganhar um contrato. Portanto, devem estar seguros em relação às estimativas
de custo, aos riscos, ao valor do projeto para o cliente, ao orçamento do cliente e à concor-
rência, a fim de determinar o preço para o projeto proposto.
Os clientes avaliam as propostas dos fornecedores de várias maneiras diferentes. Algumas
vezes, as propostas técnicas e de gestão são avaliadas primeiro, sem se considerar os custos.
As propostas com melhor pontuação na análise da seção técnica/de gestão são, em seguida,
avaliadas em função de seus custos. O cliente compara o mérito técnico/de gestão com os
custos para determinar a proposta que oferece o melhor valor. Alguns dos critérios que po-
dem ser usados pelos clientes, ao avaliar as propostas do fornecedor, incluem a consistência
com a especificação de serviço do cliente; a compreensão do problema ou necessidade do
cliente pelo fornecedor; o efeito e a praticidade da solução proposta pelo fornecedor para o
projeto; a experiência do fornecedor e seu êxito em projetos semelhantes, a experiência de
pessoas-chave, designadas para trabalhar no projeto; a capacidade de o fornecedor planejar
e controlar o projeto; o realismo do cronograma do fornecedor e o preço.
Depois que o cliente escolhe, o fornecedor vencedor fica sabendo que ganhou e que
estará sujeito à negociação bem-sucedida de um contrato. O contrato é o acordo entre o
fornecedor, que aceita fornecer um produto (deliverables), e o cliente, que aceita pagar
certa quantia em troca ao fornecedor.
Existem basicamente dois tipos de contrato: de preço global e por administração (ou a
preço de custo). Em um contrato de preço global, o cliente e o fornecedor entram em acor-
do sobre um preço para o trabalho proposto. O preço permanece o mesmo até que ambos
concordem em realizar mudanças. Esse tipo de contrato é de baixo risco para o cliente e
de alto risco para o fornecedor. Em um contrato por administração (ou a preço de custo),
o cliente concorda em pagar ao fornecedor os custos reais (mão-de-obra, materiais etc.),
independentemente da quantia; além de certo lucro pré-acordado. Esse tipo de contrato
é de alto risco para o cliente, pois custos deste podem ultrapassar o preço proposto, e de
baixo risco para o fornecedor.
Um contrato pode incluir disposições gerais sobre itens como a declaração enganosa de
custos; aviso sobre custos excedentes ou atraso do cronograma; aprovações para quaisquer
subcontratados; informações ou equipamentos fornecidos pelo cliente; posse de patentes;
divulgação de informações de propriedade do cliente; considerações internacionais; con-
clusão; condições de pagamento; bônus ou penalidades e procedimentos para a execução
de mudanças.
PERGUNTAS
1. Descreva o que se quer dizer com o termo marketing pré-proposta. Por que os forne-
cedores devem realizá-lo?
2. Comente por que os fornecedores devem tomar decisões sobre participar/não participar
de uma concorrência e os fatores envolvidos no processo de tomada dessas decisões.
3. Dê um exemplo de quando o fornecedor deve participar e um outro exemplo de quando

ele não deve participar.
4. Defina proposta e descreva um objetivo para ela.
5. Elabore uma lista das três seções mais importantes de uma proposta, bem como o objetivo
e os elementos de cada uma.
6. Quais são os fatores considerados quando um fornecedor elabora o preço da proposta?
Por que essa não é uma tarefa fácil?
7. O fornecedor deve entrar em contato com o cliente depois de apresentar uma proposta?
Por quê?
8. Como os clientes avaliam as propostas? Que fatores devem ser considerados por eles?
9. As propostas com o preço mais baixo devem sempre ser escolhidas como vencedoras?
Por quê? Dê exemplos.
10. Descreva dois tipos diferentes de contrato, quando se deve utilizar um e outro e os
riscos associados a cada um deles.
11. Dê exemplos de algumas disposições gerais que podem ser encontradas em um contrato.
12. Elabore uma proposta completa em resposta a uma CP que você criou para responder
à pergunta 10 no final do Capítulo 2.
~clements.
Para responder às questões seguintes, faça uma pesquisa na Internet e procure por mo-
delos de propostas, usando seu mecanismo de busca favorito.
1. Com base nos resultados de sua pesquisa, encontre um modelo de proposta que foi
postado na Internet. Que empresa elaborou a proposta e que objetivo estava procu-
rando alcançar?
2. Avalie a eficácia dessa proposta com base nas informações estudadas neste capítulo.
Comente os pontos fracos e os pontos fortes da proposta. Existem alguns itens fal-
tando que deveriam ser incluídos?
3. Com base no que você aprendeu neste capítulo, faça o download da proposta e
revise-a. Destaque as áreas revisadas. O que torna a proposta revisada melhor que a
original?
4. Localize um site na Internet que ofereça sugestões para o desenvolvimento de pro-
postas eficientes. Compare e contraste as informações encontradas com o que foi
apresentado no capítulo.
5. Explore e descreva pelo menos três pacotes de software que podem ajudá-lo a es-
crever uma proposta eficiente. Que características esses softwares oferecem? Faça o
download de uma cópia de pelo menos um deles, se possível.
ESTUDO DE CASO nº 1 Sistemas de Informação para Área Médica

Maggie Pressman, Paul Goldberg e Steve Youngblood são sócios igualitários de um negócio
de consultoria, especializado no planejamento e na instalação de sistemas de informação
computacional para médicos. Esses sistemas geralmente incluem registros dos pacientes,
receitas médicas, faturamento e processamento para seguro médico. Em alguns casos, os
clientes do médico possuem um sistema manual e desejam computadorizá-lo; em outros,
existe um sistema computacional que, no entanto, precisa ser atualizado e melhorado.
Na maioria dos casos, a firma de consultoria compra o hardware necessário, bem como
um pacote de software. Eles acrescentam dados do próprio software personalizado, para
atender às demandas específicas do médico e instalam o sistema completo e integrado.
Também oferecem treinamento para os funcionários no consultório médico. O custo da
maioria dos projetos varia de $ 10.000 a $ 40.000, dependendo da quantidade de hardware
necessária. A maioria dos médicos está disposta a gastar essa quantia em vez de contratar
alguém extra no consultório para lidar com uma papelada que não pára de aumentar.
A doutora Houser, uma das médicas para quem Paul realizou um projeto no passado,
abandonou suas práticas particulares para aderir a uma prática médica regional de grande
porte. Essa organização possui seis consultórios espalhados pela região, com uma média
de oito médicos por consultório. Dois desses consultórios são farmácias. A organização
emprega um total de 200 pessoas. A doutora Houser contratou Paul e perguntou se sua
firma de consultoria estaria interessada em apresentar/sugerir uma proposta para atualizar
o sistema de informação da prática médica regional inteira. O projeto incluirá a integração
dos seis consultórios e das duas farmácias em um só sistema; os médicos, posteriormente,
contratarão alguém para lidar com os sistemas de informação, a fim de supervisionar sua
operação. No momento, cada consultório possui o próprio sistema.
A doutora Houser diz a Paul que alguns dos outros médicos possuem pacientes que tra-
balham para firmas de consultoria de grande porte e que, segundo eles, poderiam executar o
trabalho. Ela diz que uma equipe de representantes dos seis escritórios e das duas farmácias,
com a ajuda do gerente de compras da organização, preparou uma chamada de propostas,
que devem ser entregues em duas semanas. A CP foi emitida há duas semanas para firmas
de consultoria de maior porte, que estão trabalhando em suas propostas. Como o gerente de
compras não conhecia sua firma de consultoria, Paul não recebeu uma cópia da CP.
A doutora Houser pede desculpas a Paul por não poder conversar mais sobre o assunto.
Ela não está tão envolvida, como os outros médicos, que discutiram idéias com seus pacien-
tes empregados nas firmas de consultoria de maior porte antes da emissão de CP. A doutora
Houser diz que o gerente de compras enviará a CP a Paul, caso ele esteja interessado, e que
este poderá apresentar uma proposta dentro de duas semanas.
– Certamente, responde Paul. – Passo aí hoje para buscá-la!
Ele pergunta se a doutora Houser sabe quanto dinheiro a prática médica tem utilizado
no projeto, mas ela não sabe. Paul busca a CP e faz cópias para Maggie e Steve. Ele está
entusiasmado com a oportunidade quando os encontra:
– Se realizarmos esse projeto, seremos impulsionados a uma área de negócios totalmen-
te nova, Paul diz a eles. – É a grande abertura pela qual estávamos esperando!, grita.
Maggie lamenta:
– Isso não poderia acontecer em momento pior. Estou trabalhando em três projetos para
outros médicos, que estão me pressionando para concluí-lo. Na verdade, um deles não está
muito satisfeito. Disse que, se eu não terminar esse projeto em duas semanas, ele não vai
aceitar o projeto e não irá nos recomendar para outros médicos. Tenho trabalhado 16 horas
por dia nesse propósito. Simplesmente me comprometi com mais do que deveria. Concordo
com você, Paul, trata-se de uma ótima oportunidade, mas não disponho de nenhum tempo
para ajudar com a proposta.
Steve surpreende-se:
– Elaborar a proposta é uma coisa, mas será que podemos executar o projeto? Acredito
que temos conhecimento suficiente para realizá-lo, mas esse projeto é realmente grande.
Além do mais, temos outros clientes.
Paul responde:
– Podemos contratar mais pessoas. Tenho alguns amigos que provavelmente gostariam
de trabalhar meio período. A gente consegue! Se não procurarmos por projetos como esse,
sempre seremos uma firma pequena; cada um de nós trabalhando 12 horas por dia por uma
mixaria. E trabalhos pequenos para escritórios individuais não vão durar para sempre. Algum
dia, serão todos computadorizados e não teremos mais trabalho. O que temos a perder se
apresentarmos uma proposta? Não podemos ganhar se não apresentarmos/sugerirmos uma!
PERGUNTAS
1. Por que essa equipe não recebeu a CP no mesmo momento que outras firmas de con-
sultoria?
2. Por que essa equipe é considerada candidata a apresentar uma proposta?
3. Elabore um checklist sobre participar/não participar da concorrência para ajudar a de-
terminar se eles deveriam apresentar uma proposta.
4. O que Maggie, Paul e Steve deveriam fazer? Ao explicar sua resposta, refira-se às preo-
cupações individuais dos três membros da equipe.
ATIVIDADE EM GRUPO
Distribua, em grupos de três ou quatro pessoas, os participantes do curso para discutir o
caso e decidir se a firma de consultoria deve ou não apresentar uma proposta. Cada grupo
apresentará as razões de sua decisão e, em seguida, escolherá um porta-voz para apresentar
a decisão do grupo e suas razões para toda a classe.
ESTUDO DE CASO nº 2 Planejador de Casamentos

Wendy e Suli são amigas desde o ensino médio. Estão trabalhando há aproximadamente dez
anos. Elas ainda mantêm contato e se reúnem com freqüência. Wendy casou-se recentemen-
te. Certa vez, no almoço, ela conversou com Suli sobre todas as coisas envolvidas no plane-
jamento de seu casamento, bem como sobre as que não saíram como o planejado e sobre
todo o estresse ocasionado. Suli disse que teve a mesma experiência quando se casou há
oito anos. Quanto mais conversavam, mais comentavam sobre o que teriam feito de forma
diferente, durante o planejamento de seus casamentos, se tivessem de fazer tudo de novo.
– Apesar de ter lido todos aqueles artigos de revistas e feito listas, ainda foi difícil pensar
em todas as coisas e acompanhar tudo, disse Wendy.
– Pois é, especialmente se o trabalho do homem e da mulher exige que eles viajem e
estejam fora da cidade ou se o casamento for realizado na cidade natal da noiva, em algum
outro estado. Fica difícil ter tudo pronto à longa distância ou fazer tudo correndo nos fins
de semana, respondeu Suli.
Concordaram que, se pais e amigos também estiverem envolvidos, o estresse pode ser
maior. – Gostaria que alguém tivesse me dado um conselho objetivo e me poupado da
confusão e de boa parte do tempo gasto na hora de procurar por floristas, instalações para
recepção, fornecedor, bolo, convites, planos para a viagem de lua-de-mel e todas essas
coisas, disse Wendy.
Suli respondeu: – Sabe que seria até divertido – fazer isso para alguém, isso sim!
– Tenho certeza de que existem casais que pagariam para outros executarem todo o
trabalho por eles, Wendy respondeu.
– É, se soubermos o tipo de casamento e de preparativos desejados pelo casal, podere-
mos analisar opiniões, lugares e preços diferentes e consultar o casal para tomar as decisões
finais. Além disso, provavelmente poderemos conseguir melhores negociações para eles.
Então, fica possível continuar e assegurar que tudo fique pronto, disse Suli.
– Isso os pouparia de muita dor de cabeça, respondeu Wendy.
– E de muito estresse, acrescentou Suli.
– Não existem mais pessoas que fazem esse tipo de serviço?, perguntou Wendy.
– Talvez, respondeu Suli, mas não deve haver muitas.
– Ei, talvez devêssemos entrar no ramo – Planejadores de Casamento Ltda., sugeriu

Wendy.
Suli respondeu: – Você está falando sério, Wendy? Seria divertido. Além do mais, eu já
estou me cansando do meu trabalho atual.
Wendy disse: – Sempre quis estar envolvida no ramo dos negócios. Talvez essa seja uma
ótima oportunidade para nós, Suli.
Elas se olharam e disseram: – Vamos começar!
Depois de conversar um pouco mais sobre o assunto, decidiram que precisavam ela-
borar uma lista de serviços que poderiam oferecer, determinar o preço a ser cobrado por
seus serviços de planejamento de casamento e, finalmente, apresentar alguns motivos para
convencer os casais a comprar seus serviços.
PERGUNTAS
1. Por que o casamento é como um projeto? Eles não são praticamente a mesma coisa?
2. Quais são as razões para um casal desejar ou não utilizar os serviços de planejamento
de casamento?
3. Como Wendy e Suli deveriam identificar clientes em potencial e vender seus serviços
a eles?
4. Como devem determinar o preço a ser cobrado por seus serviços?
ATIVIDADE EM GRUPO
Distribua, em grupos de quatro ou cinco pessoas, os participantes do curso para a elabora-
ção de uma proposta semelhante aos serviços que Wendy e Suli deveriam oferecer. Além
disso, prepare uma lista contendo as razões (que podem ser utilizadas por Wendy e Suli
ao se encontrar com clientes em potencial) para persuadi-los a contratá-las como plane-
jadoras de seus casamentos. Finalmente, o que Wendy e Suli deveriam exigir de um casal
para assegurar o sucesso dos preparativos? Cada grupo precisa escolher um porta-voz para
apresentar suas respostas.
Capítulo O PROJETO
4 Planejando o Projeto
Gerindo Riscos
Identificação de Riscos
Avaliação de Riscos
Resumo
Perguntas
Estudo de Caso no 1 Uma
Planejamento de Resposta a Empresa de Fabricação de
Riscos Eletrônicos
Monitoramento de Riscos Perguntas
Realizando o Projeto Atividade em Grupo
Controlando o Projeto Estudo de Caso no 2 Projeto de
Expansão de Fábrica
Concluindo o Projeto
Perguntas
Avaliação Interna Pós-Projeto
Atividade em Grupo
Feedback do Cliente
Encerramento Precoce do Projeto
72
Ca pítulo Qua tro
Principais Problemas da AT&T Wireless
Na primavera de 2003, a AT&T Wireless formou uma equipe para atualizar seu sistema de
Gestão de Relacionamento com o Cliente (CRM). A meta era modernizar seus processos
de serviços ao cliente em contas individuais. Com um melhor sistema CRM, os funcioná-
rios poderiam acessar e processar com eficiência as informações dos clientes. A equipe
de projeto tinha o plano de controlar os diferentes grupos de clientes organizando o CRM
em fases, uma fase para cada grupo. Esse projeto de atualização ajudaria a AT&T Wireless a
posicionar-se como o provedor de serviço de telefonia móvel líder no mercado norte-ame-
ricano, o que é altamente competitivo.
No entanto, a tentativa de atualização fracassou e todo o sistema CRM quebrou. A
empresa perdeu clientes e sofreu um prejuízo estimado em cem milhões de dólares em
termos de faturamento.
O que saiu errado? Um dos principais fatores que contribuíram para esse resultado foi
o baixo estado de ânimo da equipe. Durante o projeto, uma mudança de pessoal nos cargos
executivos espalhou boatos de demissões de funcionários e terceirização, com utilização
de recursos externos à empresa para implantar e gerenciar o novo sistema. Os membros da
equipe do projeto não se sentiam mais parte do projeto e, por sentirem-se dispensáveis,
muitos membros importantes para o projeto deixaram a empresa. Um segundo fator foi
o mandato federal de 24 de novembro de 2003, prazo final para a mudança do sistema
telefônico. Os cronogramas do projeto de atualização do CRM e do projeto de mudança do
sistema coincidiram. Os requisitos de teste para essa atualização do CRM bastante complexa
foram simplificados, na tentativa de acelerar o cronograma. Como resultado, os dois proje-
tos não conseguiram cumprir o prazo final. Um terceiro fator foi que a AT&T não tinha um
plano de contingência para ser utilizado em caso de falha. O antigo CRM não foi preservado
e não pôde ser utilizado depois da fracassada tentativa de atualização.
O que você pode aprender com esse exemplo? Uma melhor gestão para esse projeto
teria mantido os membros importantes da equipe, desmentido todos os boatos e adiadas
as demissões de funcionários, até que esse difícil projeto fosse concluído. Além disso, todos
os projetos da empresa poderiam ter sido analisados e priorizados a fim de se ajustar aos
prazos inflexíveis. Facilitar os testes do sistema, simplificando seus requisitos, foi um desas-
tre para esse projeto. Os requisitos de teste devem ser sempre rigorosos. E, finalmente, ter
um plano de backup é vital para preservar a sobrevivência e a continuidade do processo
dos negócios.
Koch, C. AT&T Wireless Self Destructs. CIO Magazine, 15 de abril de 2004.
73
Executar, ou realizar o projeto – implementando a solução proposta – é a terceira fase

do ciclo de vida do projeto mostrada na Figura 4.1. Essa fase começa depois que um
contrato ou um acordo é firmado entre o cliente e o fornecedor ou a equipe de projeto,
e termina quando o objetivo é alcançado e o cliente está satisfeito porque o trabalho foi
concluído com qualidade, dentro do orçamento e no prazo. A quarta fase é a fase final
do ciclo de vida do projeto e envolve sua conclusão. Este capítulo examina essas duas
fases finais do ciclo de vida do projeto. Você irá conhecer melhor:
• os elementos envolvidos no estabelecimento de um plano de projeto;
• as etapas do processo de controle do projeto;
• as ações que devem ser tomadas quando um projeto é concluído.
PLANEJANDO O PROJETO
A terceira fase do ciclo de vida do projeto tem duas partes: o planejamento detalhado do
projeto e, em seguida, a implementação desse plano para cumprir com seu objetivo. An-
tes de pôr mãos à obra e começar o projeto propriamente dito, o fornecedor ou a equipe
do projeto deve reservar tempo suficiente para planejá-lo adequadamente. É necessário
elaborar um esquema, ou uma estratégia, que demonstre como as tarefas do projeto serão
executadas dentro do orçamento e do prazo. Tentar realizar um projeto sem um plano é
como tentar montar uma bicicleta sem primeiramente ler as instruções. Pessoas que pensam
que o planejamento é desnecessário ou perda de tempo, mais tarde, invariavelmente pre-
cisam encontrar um tempo para refazer as coisas. É importante planejar o trabalho e depois
realizar o plano. Caso contrário, o resultado será caos e frustração, e o risco de o projeto
fracassar será maior.

1. Quais são as duas partes da fase de
projeto do ciclo de vida?
FIGURA 4.1 Etapas do Ciclo de Vida do Projeto
Chamada Objetivo
Esforço de Propostas Acordo do Projeto
Identificar Desenvolver Concluir
uma Executar
uma o projeto
solução o projeto
necessidade
proposta
Tempo
Capítulo 4 O Projeto 75
A parte de planejamento da fase de execução do projeto envolve o maior detalhamento

do plano, do cronograma e do orçamento da proposta. O tempo e os custos necessários
para elaborar esse planejamento detalhado geralmente não são assegurados durante a fase
de proposta (segunda fase) do ciclo de vida. O planejamento detalhado envolve as mesmas
etapas do planejamento inicial discutidas no Capítulo 1:
1. Defina claramente o objetivo do projeto. A definição deve ser acordada entre o cliente
e a pessoa ou organização que vai executar o projeto.
2. Divida e subdivida o escopo do projeto em “frações” significativas ou pacotes de traba-
lho. Embora os grandes projetos pareçam assustadores, quando vistos como um todo,
uma forma de superar até mesmo o mais monumental dos desafios é desmembrá-lo.
A estrutura analítica de projeto é uma árvore hierárquica de elementos ou itens de
trabalho realizados ou produzidos pela equipe. A estrutura analítica de projeto nor-
malmente define a organização ou pessoa responsável de cada pacote de trabalho.
(As estruturas analíticas de projeto serão discutidas mais adiante, no Capítulo 5.)
3. Defina as atividades específicas que precisam ser executadas para cada pacote de
trabalho, a fim de atingir o objetivo do projeto.
4. Ilustre graficamente as atividades na forma de um diagrama de rede. Esse diagrama
mostra a seqüência necessária e as interdependências das atividades para atingir o
objetivo do projeto. (Os diagramas de rede serão discutidos mais adiante, no Capí-
tulo 5.)
5. Faça uma estimativa de quanto tempo cada atividade levará para ser completada.
Também é necessário determinar que tipos de recursos são necessários e como serão
usados, para que cada atividade seja realizada no prazo estimado.

2. A primeira parte da fase de projeto do
ciclo de vida envolve o estabelecimento
de __________________________.
6. Faça uma estimativa de custo para cada atividade. O custo baseia-se nos tipos e nas
quantidades de recursos necessários para cada atividade.
7. Calcule um cronograma e um orçamento para determinar se o projeto pode ser con-
cluído dentro do prazo necessário, com os fundos alocados e os recursos disponíveis.
Caso contrário, podem-se fazer ajustes no escopo do projeto, nas estimativas de
duração das atividades ou nas atribuições de recursos até que se chegue a um plano-
base (esquema para se atingir o escopo do projeto no prazo e dentro do orçamento)
viável e realista.
O planejamento determina o que precisa ser feito, quem irá fazê-lo, quanto tempo vai
levar e quanto irá custar. O resultado dessa etapa é um plano-base. Reservar tempo para
desenvolver um plano bem concebido é crucial para a realização bem-sucedida de qual-
quer projeto. Muitos projetos excedem seus orçamentos, perdem as datas de conclusão ou
cumprem parcialmente com suas especificações técnicas porque não têm nenhum plano-
base adequado antes do início.

3. O planejamento determina: ________
precisa ser feito, ________ irá fazê-lo,
quanto ________ irá levar e quanto irá
________.
É importante que os envolvidos com a execução do projeto também participem do pla-

nejamento do trabalho. Eles geralmente são os mais informados sobre quais atividades de-
talhadas precisam ser realizadas. Além disso, ao participarem do planejamento do trabalho,
essas pessoas se comprometem com a execução do projeto de acordo com o plano. Vale
mencionar que participação constrói o compromisso.
GERENCIANDO RISCOS
Como foi mencionado no Capítulo 1, qualquer aspecto de um projeto pode envolver certo
grau de incerteza, que pode impactar o resultado de um projeto. Durante o projeto, é
possível acontecer casos que podem ter um efeito adverso para seu sucesso. Risco é a
possibilidade de ocorrer uma circunstância indesejada, que resulte em algum prejuízo.
O gerenciamento de riscos envolve identificação, avaliação e resposta aos riscos do pro-
jeto, a fim de minimizar a probabilidade e o impacto das conseqüências de eventos adver-
sos durante a realização do objetivo do projeto. Controlar os riscos proativamente aumenta
as chances de alcançar o objetivo. Esperar que ocorram eventos adversos para depois reagir
pode resultar em reações custosas e de pânico. O gerenciamento de riscos inclui ações para
evitar ou minimizar as chances de ocorrência ou o impacto dos eventos desfavoráveis.

4. A gestão de riscos envolve ________, _
_______ e ________ os riscos do projeto,
a fim de minimizar a _________ e o
______________ das conseqüências de
eventos adversos sobre o cumprimento
do ______________ do projeto.
Um certo grau de planejamento de riscos deve ser feito na fase de proposta do ciclo de
vida do projeto para se ter certeza, por exemplo, de que um fornecedor reconhece os riscos
envolvidos na cotação de preço para um projeto proposto. Ao conhecer os riscos em po-
tencial, o fornecedor pode incluir valores de reserva de contingência ou gerenciamento no
preço cotado. Por outro lado, se os riscos parecem ser grandes demais, o fornecedor pode
decidir por não participar de um projeto proposto, como foi discutido na seção Decisão de
Participar/Não Participar da Concorrência do Capítulo 3. Posteriormente, um planejamento
de riscos mais detalhado deve ser feito no início de um projeto.
Um gestor de projeto não pode ser adverso a riscos. Ele deve aceitar o risco como uma
parte do gerenciamento de projeto que tem de ser enfrentado. Além disso, o gestor de pro-
jeto precisa estabelecer o tom para promover uma discussão oportuna e aberta sobre riscos
com a equipe do projeto.
Identificação de Riscos
A identificação de riscos inclui a determinação de quais riscos podem afetar desfavoravel-
mente o objetivo do projeto e quais são as conseqüências de cada risco, caso ocorram.
A maneira mais comum de identificar a fonte de riscos é a técnica de brainstorming
(a técnica de brainstorming é discutida no Capítulo 11). O gestor do projeto deve envolver
os principais membros da equipe do projeto na identificação das fontes de riscos em poten-
cial – coisas que poderiam acontecer e ter um impacto negativo para a conquista do obje-
tivo do projeto. Cada membro da equipe do projeto pode oferecer sua própria experiência
e discernimento para ajudar a desenvolver uma ampla lista de fontes possíveis de riscos.
Quantos riscos devem ser identificados? Uma equipe pode superar-se e identificar centenas
de riscos possíveis. Por exemplo, existe uma chance de que cada atividade leve mais tempo
que o planejado ou custe mais do que foi orçado e existem riscos altamente indesejáveis,
como “o que acontece se nosso edifício for destruído pelo fogo durante o projeto?”. O sen-
so comum e a razão devem prevalecer durante a identificação dos riscos. Estes envolvem
prováveis contratempos, bem como o impacto negativo significativo no cumprimento bem-
sucedido do objetivo do projeto.
Outra fonte que pode ser útil para a identificação de possíveis riscos é a informação
histórica sobre projetos anteriores. Se avaliações pós-projeto (discutidas mais tarde neste
capítulo) foram feitas em projetos inteiros, elas podem ser uma boa fonte de identificação
de riscos possíveis, e também de informação sobre como gerenciar esses riscos, se ocorre-
rem novamente.
São exemplos de riscos específicos:
• Incorporar tecnologia avançada em um novo produto.

• Atender a requisitos de desempenho para se realizar medições dez vezes mais rápi-
das que as atuais.
• Avanços tecnológicos que poderiam transformar a tecnologia escolhida originalmente
em obsoleta antes de o projeto ser concluído.
• Usar pela primeira vez um novo equipamento de robótica em procedimento cirúrgico
raro e complexo.
• Obter a mão-de-obra de certos tipos de profissionais necessários, quando se tem uma
economia local forte e baixo índice de desemprego.
• Em uma escavação, encontrar mais formações rochosas que o esperado.
• Número excessivo de revisões em um website antes que a versão final seja aprovada
pelo cliente.
• Uma greve pode ocorrer durante o auge de um projeto de construção.
• Pode haver tempo ruim (como temporais) durante a fase de construção de um pro-
jeto de expansão.
• O banco pode não aprovar o valor total de financiamento para o projeto.
• Significativo aumento de preço de um material especial de revestimento de proteção
contra incêndio.
• O paciente pode ter uma hemorragia durante a cirurgia.
• Pode não haver vacinas suficientes para as necessidades de emergência.
• Um novo produto pode não passar nos ensaios para sua certificação.
• A entrega atrasada de peças fundamentais por parte de um fornecedor estrangeiro.
• O cliente não providenciar peças de amostra para testes, quando necessário.
• Chover durante o fim de semana de um festival.
Para cada risco identificado, deve-se relacionar uma conseqüência em potencial. Essas
conseqüências poderiam incluir atrasos no cronograma, despesas adicionais substanciais, o
não-cumprimento de requisitos técnicos ou um impacto negativo na satisfação do cliente.
Avaliação de Riscos
A avaliação de cada risco envolve a determinação da probabilidade de que o evento de
risco ocorra e do grau de impacto que este teria sobre o objetivo do projeto. A esses dois
fatores, pode-se atribuir uma classificação de Alto, Médio e Baixo. O gestor de projeto, após
consulta prévia com os membros apropriados da equipe, que estão mais informados sobre
os riscos em potencial, deve determinar uma classificação para cada risco. Dados históricos
de projetos similares anteriores também são úteis. Por exemplo, se o mau tempo é um risco,
é bom consultar o histórico de clima no local ou um serviço de previsão do tempo.
FIGURA 4.2 Matriz de Avaliação de Riscos
Chance de Fator
Impacto Responsa- Plano de
Risco Conseqüência Ocorrência Desencadeador
(B, M, A) bilidade Resposta
(B, M, A) de Ação
Chuva • Baixo compa- M A Previsão do Laura • Reservar um espaço
no dia recimento de tempo dois dias coberto imediata-
do público antes do evento mente
evento • Prejuízo fi- • Recrutar voluntários
nanceiro extras para trabalhar
contra o relógio
na montagem do
evento em um local
coberto
• Desenvolver um
plano detalhado
Constru- • Compareci- A A O Departamen- Allison • Identificar rotas
ção de mento reduzi- to de Estradas alternativas
rodovia do de público divulga o crono- • Providenciar placas
• Faturamento grama da cons- de sinalização
reduzido trução • Fixar placas de sina-
lização em todas
as rotas
• Anunciar nos meios
de comunicação
Baseados na probabilidade em potencial de ocorrência e do impacto em potencial,

os riscos podem ser priorizados. Por exemplo, àqueles com maior probabilidade de ocor-
rência e impacto, pode ser dada uma consideração maior no desenvolvimento de um plano
de resposta.
Uma ferramenta para avaliar riscos é a matriz de avaliação de riscos, como mostra a
Figura 4.2.
Planejamento de Resposta a Riscos

O planejamento de resposta a riscos envolve o desenvolvimento de um plano de ação para
reduzir o impacto ou a probabilidade de cada risco, estabelecendo um ponto de desencadea-
mento para, quando implementar as ações, direcionar cada situação e atribuir responsabi-
lidades a pessoas específicas na implementação de cada plano de resposta.

5. O planejamento de resposta
a riscos envolve o desenvolvimento
de um ______ para reduzir o impacto
ou a probabilidade de cada risco,
o estabelecimento de um _______ para
saber quando implementar as ações
e a atribuição de _______ para as
pessoas poderem implementar cada
plano de resposta.
Um plano de resposta a riscos pode ser evitar o risco, diminuir o risco ou aceitar o
risco. Evitar significa eliminar o risco ao se escolher um caminho diferente. Como exem-
plos, estão: para um novo produto, decidir-se por uma tecnologia convencional em vez
de tecnologia de ponta ou optar por produzir um festival de fim de semana em local co-
berto para evitar a possibilidade de a chuva atrapalhar. Diminuir o risco envolve tomar
ações para reduzir a probabilidade de que o evento de risco ocorra ou reduzir seu impacto
em potencial. Por exemplo, para reduzir o risco de reformulações múltiplas do website
de um cliente, deve-se examinar com ele outras amostras de leiaute do site anteriores ao
projeto. Aceitar um risco pode incluir a aceitação da conseqüência em circunstâncias nas
quais a probabilidade de ocorrência e do impacto em potencial seja baixa e depois lidar
com ela se e onde ocorrer, ou pode incluir também o desenvolvimento de um plano de
contingência, que será executado caso haja uma grande probabilidade de ocorrer um evento
de risco.

6. Um __________________________
é um conjunto predefinido de ações
que seriam implementadas mediante
a ocorrência do evento de risco.
Um plano de contingência é o conjunto de ações predefinido que será implementado

se ocorrer o evento de risco. A maioria dos planos de contingência exige o gasto de fundos
adicionais com o uso de recursos adicionais, horas extras, gastos com despacho de merca-
dorias, compra de materiais adicionais, aumentos inesperados de preços e assim por diante.
Os orçamentos e preços do projeto devem incluir uma reserva de gestão ou contingência
para pagar os custos adicionais de implementação de planos de contingência.
Um plano de resposta a riscos deve incluir um ponto de desencadeamento ou um si-
nal de advertência que avise quando implementar o plano de ação para cada risco. Um
ponto desencadeador ao comprar um material especial pode ser o aumento do preço atual
em mais de 5% acima do valor orçado para a compra. O ponto desencadeador para decidir
incorporar tecnologia avançada em um novo produto pode ser a conclusão de um estudo
de viabilidade de engenharia. Outro exemplo seria autorizar horas extras se o projeto esti-
ver atrasado em mais de 5% da duração restante do projeto.
Monitoramento de Riscos
O monitoramento de riscos envolve a revisão regular da matriz de avaliação de riscos du-

rante todo o projeto. Nesse período, é importante avaliar todos os riscos para determinar
se há alguma probabilidade de ocorrência ou de impacto em potencial de qualquer dos
riscos. Esses fatores podem determinar se um risco em particular aumentou em prioridade
para atenção ou se o risco diminuiu em importância. Além disso, novos riscos, inicialmente
não considerados, podem ser identificados como prejudiciais para o projeto e depois serão
adicionados à matriz de avaliação de riscos. Por exemplo, os testes iniciais para um protóti-
po de um novo produto agora indicam que este pode não cumprir com as especificações de
desempenho originais. Outra situação pode ocorrer quando, pelos atrasos anteriores na fase
de concepção, a fase de construção de um projeto de expansão passa a ser realizada em
meio à temporada de mau tempo. Durante um projeto, o cliente pode aprovar mudanças no
escopo do trabalho do projeto, no cronograma ou no orçamento que também podem afetar
a avaliação de riscos definidos previamente ou resultar na identificação de novos riscos.
As pautas para as reuniões de análise do status do projeto (veja Capítulo 12) devem
incluir um item para avaliação de riscos. Deve-se dedicar particular atenção para a revisão
de pontos de desencadeamento para cada risco, a fim de determinar se algum plano de
resposta a riscos está prestes a ser implementado.
REALIZANDO O PROJETO
Uma vez que o plano-base foi desenvolvido, pode-se proceder à execução do projeto. Essa
equipe, liderada pelo gestor de projeto, implementará o plano e executará as atividades ou
os elementos de trabalho, de acordo com o plano. O ritmo de execução do projeto aumen-
tará à medida que recursos mais variados e em maior número estiverem envolvidos com
a realização das tarefas do projeto. Para o projeto de um festival municipal, os principais
elementos de trabalho devem ser os seguintes:
1. Preparação de promoções – anúncios em jornal, cartazes, entradas e assim por diante.

2. Seleção de voluntários.
3. Organização de jogos, com construção de tendas e entrega de prêmios.
4. Aluguel de brinquedos (como montanha-russa) e obtenção das licenças necessárias.
5. Construção de um palco e contratação de artistas para entretenimento.
6. Organização da parte de alimentação, incluindo a preparação dos alimentos e a cons-
trução de barracas autorizadas.
7. Organização de todos os serviços de suporte, como estacionamento, limpeza, segu-
rança e banheiros.
Para projetos mais técnicos de concepção, construção e instalação de uma máquina de

embalagem de alta velocidade automatizada e especializada na fábrica do cliente, os prin-
cipais elementos de trabalho devem ser os seguintes:
1. Desenvolvimento dos projetos preliminar e detalhado, incluindo preparação de espe-

cificações, desenhos, fluxogramas e uma lista de materiais.
2. Preparação de planos para os ensaios de componentes, subsistemas e sistema pelo
fornecedor, antes de enviar o equipamento para a fábrica do cliente e depois de ser
instalada na fábrica dele, para assegurar que o equipamento cumpra com os requisi-
tos do cliente. Este pode, ainda, querer revisar e aprovar os planos de ensaios antes
de seu início.
3. Condução de reuniões de análise crítica do projeto, internamente e com o cliente.
Baseado nessas reuniões de análise crítica do projeto, o cliente pode propor ou
aprovar mudanças na proposta original, que podem ter um impacto no escopo, no
cronograma e no preço. O cliente pode precisar retificar o contrato, e talvez o for-
necedor seja obrigado a fazer algum replanejamento do projeto para incorporar as
mudanças.
4. Encomenda de materiais e peças.
5. Fabricação de componentes e peças.
6. Elaborar e testar softwares.
7. Montagem e teste de hardware, incluindo teste de componentes, montagem de com-
ponentes em submontagens, teste das submontagens, montagem das submontagens
no sistema e teste de todo o sistema de hardware.
8. Integração de hardware e software e teste do sistema. Representantes de clientes
podem querer atestar e documentar os resultados dos testes para assegurar que estes
cumpram com as especificações do contrato.
9. Preparação dos requisitos para a instalação, como plantas do local e outros serviços
(elétricos, de soldagem e assim por diante) e identificação de itens pelos quais o
cliente será responsável durante a instalação.
10. Preparação de materiais de treinamento (manuais, fitas de vídeo, simulações no com-
putador) para instruir os clientes de como operar e manter o novo equipamento.
11. Envio do equipamento para a fábrica do cliente e, em seguida, instalá-lo.
12. Realização de um treinamento para o cliente.
13. Execução de testes finais de aceitação para mostrar que o equipamento cumpre com
todos os requisitos especificados do cliente.
CONTROLANDO O PROJETO
Enquanto o trabalho de projeto está sendo realizado, é necessário monitorar seu progresso
para assegurar que tudo está de acordo com o plano. Isso envolve a medição do progresso
real e sua comparação com o planejado. Para medir o progresso real, é importante in-
formar-se sobre quais atividades foram verdadeiramente iniciadas e concluídas, quando
começaram e terminaram e quanto foi gasto ou comprometido. Se, a qualquer momento
durante o projeto, a comparação do progresso real com o planejado revelar que este está
se atrasando, ultrapassando o orçamento ou não está cumprindo as especificações técnicas,
deve-se adotar uma ação corretiva para trazer o projeto de volta aos trilhos (o tópico “ação
corretiva” será discutido mais adiante, na Parte 2).
Antes de se adotar a decisão de implementar uma ação corretiva, pode ser necessário
avaliar várias ações alternativas para certificar-se de que a ação corretiva trará o projeto de
volta para os limites de orçamento, tempo e escopo do objetivo. Esteja atento, por exemplo,
para que a adição de recursos usada na compensação do tempo e no ajuste do cronograma
não exceda o orçamento planejado. Se um projeto ficar muito fora de controle, pode ser
difícil alcançar seu objetivo sem o sacrifício do escopo, do orçamento, do cronograma ou
da qualidade.
O segredo para um controle de projeto eficaz é medir o progresso real e compará-lo
ao progresso planejado de forma regular e oportuna, tomando uma ação corretiva imediata,
se necessário. É ingênuo esperar que um problema desapareça sem uma intervenção cor-
retiva. Quanto antes um problema for identificado e corrigido, melhor será. Baseado no
progresso real, é possível prever um cronograma e um orçamento para a conclusão do
projeto. Se esses parâmetros estão ultrapassando os limites do objetivo proposto, devem-se
imediatamente implementar ações corretivas.
O processo de controle de projeto envolve a coleta regular de dados sobre o de-
sempenho do projeto, a comparação do desempenho real com o planejado e a aplicação
de ações corretivas se o desempenho real está abaixo do planejado. Esse processo deve
ocorrer com regularidade durante todo o projeto.
A Figura 4.3 ilustra as etapas do processo de controle de projeto. Ela inicia com o estabe-
lecimento de um plano-base que mostra como o escopo do projeto (tarefas) será cumprido
a tempo (cronograma) e dentro do orçamento (recursos, custos). Uma vez que o cliente e o
fornecedor ou a equipe do projeto estão de acordo com esse plano-base, pode-se iniciar
o projeto.
Um período para emissão regular de relatórios deve ser estabelecido para a compara-
ção do progresso real com o planejado. O relatório pode ser diário, semanal, quinzenal ou
mensal, dependendo da complexidade ou da duração total do projeto. Se for esperado que
um projeto tenha a duração total de um mês, o período de relatório pode ser de apenas um
dia. De outro lado, se é esperado que um projeto dure cinco anos, o período de relatório
pode ser de um mês.
Em cada período de relatório, dois tipos de dados ou informações precisam ser coletados:

7. Quais são os dois tipos de dados ou
informações que precisam ser coletados
durante cada período de relatório?
1. Dados de desempenho real. Isso inclui:

• o tempo real de início e término das atividades;
• os custos reais gastos e comprometidos.
FIGURA 4.3 Processo de Controle de Projeto
Estabelecer plano-base
(cronograma, orçamento)
Iniciar o projeto
Esperar até o
próximo
período
de relatório Durante cada
período de relatório
Coletar dados do Incorporar mudanças no

plano do projeto
desempenho real
(escopo, cronograma,
(cronograma, custos) orçamento)
Calcular cronogramas,
orçamentos e previsões
atualizados para o projeto
Analisar o status atual

comparado como o plano
Não São necessárias

ações corretivas?
Sim
Identificar ações corretivas

e incorporar
mudanças associadas
2. Informações sobre qualquer mudança no orçamento, cronograma e escopo do projeto.

Essas mudanças poderiam ser iniciadas pelo cliente ou pela equipe do projeto, ou
poderiam ser o resultado de uma ocorrência imprevista, como um desastre natural,
uma greve de trabalhadores ou a demissão de um membro importante da equipe.
Deve-se notar que, após as mudanças serem incorporadas ao plano e acordadas pelo
cliente, um novo plano-base tem de ser estabelecido. O escopo, o cronograma e o orça-
mento do novo plano-base podem ser diferentes daqueles do original.
É crucial que os dados e informações discutidos acima sejam coletados de maneira
oportuna e usados para calcular o cronograma e orçamento atualizados para o projeto. Por
exemplo, se o relatório de projeto é feito mensalmente, dados e informações devem ser
obtidos o mais tarde possível naquele período mensal, pois, quando o cronograma e orça-
mento atualizados forem calculados, serão baseados na informação mais recente possível.
Em outras palavras, um gestor de projeto não deve coletar dados no início do mês e depois
esperar até seu final para usá-los no cálculo do cronograma e do orçamento atualizados,
já que os dados serão obsoletos e poderiam levar à tomada de decisões incorretas sobre o
status do projeto e as ações corretivas.
Uma vez que o orçamento e cronograma atualizados são calculados, precisam ser compa-
rados com o cronograma e orçamento básicos e analisados para se verificar quaisquer varia-
ções e, assim, determinar se o projeto está avançado ou atrasado em relação ao cronograma e
dentro ou fora do orçamento. Se o status do projeto estiver certo, não é preciso nenhuma
ação corretiva, o status será analisado novamente para o próximo período de relatório.
No entanto, se é determinado que são necessárias ações corretivas, devem-se tomar de-
cisões a respeito de como revisar o cronograma ou o orçamento. Essas decisões geralmente
significam uma compensação que envolve tempo, custo e escopo. Por exemplo, a redução
da duração de uma atividade pode exigir o aumento de custos para pagar mais recursos
ou a redução do escopo da tarefa (e possivelmente o não-cumprimento dos requisitos téc-
nicos do cliente). Da mesma forma, a redução dos custos do projeto pode exigir o uso de
materiais de qualidade inferior à originalmente planejada. Uma vez tomada a decisão sobre
quais ações corretivas aplicar, estas devem ser incorporadas ao cronograma e ao orçamen-
to. É necessário calcular um cronograma e um orçamento revisados para determinar se as
medidas corretivas planejadas resultam em um cronograma e orçamento aceitáveis. Se não,
serão necessárias revisões mais adiante.
O processo de controle de projeto continua por toda a fase de realização do projeto. Em
geral, quanto menor é o período de relatório, maiores são as chances de identificar anteci-
padamente os problemas e de adotar efetivas ações corretivas. Como foi mencionado an-
teriormente, se um projeto ficar muito fora de controle, pode ser difícil alcançar o objetivo
do projeto sem o sacrifício do escopo, do orçamento, do cronograma ou da qualidade.
Pode haver situações nas quais é recomendável aumentar a freqüência de relatórios até
que o projeto volte a caminhar nos trilhos. Por exemplo, se um projeto de cinco anos com
relatório mensal estiver comprometido por um erro no cronograma ou por um aumento no
excedente do orçamento, seria prudente reduzir o período de relatório para uma semana,
a fim de monitorar mais rigorosamente o projeto e o impacto das ações corretivas.

8. Além de estabelecer um plano-base,
também é necessário ________ o projeto
de forma proativa a fim de garantir que
seu _________ seja atingido e que o
cliente fique ____________.
O processo de controle de projeto é uma parte importante e necessária de sua realiza-

ção. Apenas estabelecer um bom plano-base não é suficiente, visto que até mesmo os pla-
nos mais bem concebidos nem sempre funcionam. A gestão de projetos é uma abordagem
proativa para controlar um projeto e assegurar que seu objetivo será alcançado até mesmo
quando as coisas não acontecem conforme o planejado.
Essa terceira fase do ciclo de vida termina quando o cliente está satisfeito, pois os requi-
sitos foram cumpridos e o objetivo do projeto alcançado.
CONCLUINDO O PROJETO
A quarta e última fase do ciclo de vida do projeto é sua conclusão. Ela começa depois que
o trabalho do projeto foi concluído, como mostra a Figura 4.4, e inclui várias ações para
encerrar de forma adequada o projeto.
Chamada de Objetivo
Esforço Propostas Acordo do Projeto
Identificar Desenvolver
uma Executar Concluir
uma
solução o projeto o projeto
necessidade
proposta
Tempo
O objetivo de concluir de forma adequada um projeto é aprender com a experiência

nele adquirida a fim de melhorar o desempenho de futuros projetos. Portanto, as atividades
associadas à conclusão do projeto precisam ser identificadas e incluídas no plano-base do
projeto – elas não devem ser feitas meramente como uma reflexão espontânea posterior.
Essas atividades podem incluir organização e arquivamento de documentos do projeto,
recebimentos e pagamentos finais e condução de reuniões de avaliação pós-projeto com as
organizações do fornecedor e do cliente.

9. Qual é o objetivo de uma conclusão
adequada para o projeto?
A fase de conclusão começa quando o desempenho do projeto é terminado e o resulta-

do aceito pelo cliente. Em algumas situações, isso pode ser um evento mais formal no qual
um sistema automatizado satisfaz um conjunto de critérios ou passa nos testes determinados
no contrato. Outros projetos, como um fim de semana de atividades de boas-vindas em uma
universidade, são terminados meramente ao final de sua agenda.
Quando conclui um projeto para o cliente, o fornecedor deve verificar se todas as entre-
gas acordadas foram realmente feitas. Estas podem incluir treinamento ou manuais técnicos,
desenhos, fluxogramas, equipamentos, softwares, folhetos, relatórios e dados. Durante a
conclusão do projeto, o contratante ou a organização que o executou devem assegurar que
cópias da documentação apropriada relacionada ao projeto está adequadamente organiza-
da e arquivada para que possam ser facilmente recuperadas para uso futuro, se necessário.
No futuro, talvez o fornecedor queira usar alguma informação de custo e cronograma reais
desse projeto acabado para ajudar a desenvolver as estimativas de custos e cronograma
para um projeto proposto. Ou, se o projeto envolve, digamos, a preparação de um festival
de artes, a equipe deve organizar toda a documentação – incluindo sugestões para aspec-
tos de melhorias do festival – para ser usada pela próxima equipe que fará o festival no
ano seguinte.
Projeto de Túnel de Desvio de Emergência em Hakalaoa Falls
O Projeto de Túnel de Desvio de Emergência de Hakalaoa Falls, finalista do Prêmio Destaque
em Empreendedorismo de Engenharia Civil 2004, foi projetado e concluído com sucesso
pela equipe de projeto e construção da Jas. W. Glover Ltda. e URS Corporation em abril de
2002. Seu sucesso é notável pela complexidade da implementação e pelas exigências para
satisfazer as necessidades de diferentes grupos de pessoas com metas específicas.
Para formular uma solução, primeiramente a equipe teve de avaliar extensivamente o
local do projeto e informar-se sobre a história do sistema de abastecimento de água Lower
Hamakua Ditch. O projeto foi realizado no Vale de Waipio, no Havaí, na costa de barlavento
da ilha do Havaí e lugar das históricas cachoeiras gêmeas: Hakalaoa e Hiilawe. Os fazendei-
ros do Vale de Waipio dependem da água dos córregos naturais da área, capturada pelo sis-
tema de água Lower Hamakua Ditch. Esse sistema de abastecimento de água, com cerca de
38 quilômetros de comprimento, foi construído em 1910 pela Hamakua Sugar Company.
A água era usada para transportar e processar cana-de-açúcar. O Lower Hamakua Ditch,
conseqüentemente, tornou-se um sistema de irrigação para os fazendeiros do Vale de Wai-
pio, desviando água de quatro córregos da região.
Os fazendeiros do Vale de Waipio tiveram o abastecimento de água interrompido em
1989, quando um deslizamento de terras, na parte principal de Hakalaoa Fals, destruiu
um trecho de aproximadamente 9 metros do sistema hídrico. Uma calha de madeira foi
construída para recuperar o fluxo de água do sistema. No entanto, esse reparo temporário
não foi resistente o suficiente para domar a grande força da água de Hakalaoa, e assim
o fluxo foi desviado para sua cachoeira gêmea, a Hiilawe. Os principais efeitos negativos
desse desvio foram: os fazendeiros do vale perderam 11 milhões de dólares e sua fonte de
água; o ecossistema local sofreu danos quando as duas cachoeiras foram convertidas em
uma única. Com isso, a beleza das históricas cachoeiras gêmeas deixou de existir para os
moradores e turistas que as apreciavam.
A equipe do projeto trabalhou com muitos desafios. Eles tiveram um orçamento li-
mitado e um prazo curto para cumprir a necessidade imediata de restauração do abas-
tecimento de água. O local do projeto se localizava mais ou menos na metade da parte
principal de Hakalaoa, que tem mais de 600 metros de altura. A equipe projetou um túnel
de desvio de 90 metros de comprimento com uma estrutura linear plana de forma que
pudesse resistir à força da água quando Hakalaoa fosse restabelecida. Nessa localização,
a equipe não poderia usar maquinário, como, por exemplo, máquinas de construção de
túneis ou robôs de perfuração. Assim, o novo túnel de 90 metros de comprimento e dois
metros de diâmetro foi escavado manualmente. A equipe precisou retirar e levar mais de
1.300 toneladas de material de construção e rochas escavadas de/para o local diariamente,
em viagens de apenas meia tonelada cada, em uma velocidade de pouco mais de três qui-
lômetros por hora, percorrendo mais de três quilômetros por viagem.
Apesar desses desafios, a equipe terminou o projeto com uma boa margem de segu-
rança, dentro do orçamento e do prazo. O resultado trouxe benefícios para várias pessoas.
A solução do projeto custou ao governo 17 milhões de dólares a menos que uma outra
solução proposta, de construir um sistema de túnel totalmente novo. Além disso, o sistema
de irrigação para os fazendeiros do Vale de Waipio foi finalmente restaurado 14 anos de-
pois do deslizamento. Por fim, os ecologistas tiveram o prazer de verificar que as cachoeiras
gêmeas foram recuperadas depois que a água desviada foi encaminhada de volta para seu
curso original, impedindo assim futuros danos ao ecossistema do Vale de Waipio.
Emergency Bypass Water Tunnel. Waipio Valley, Hilo, Hawaii, URS Corporation, www.asce.org/ocea/#zakim.
Hakalaoa Falls Emergency Bypass Tunneling Project Named Finalist for Outsanding Civil Engineering Achievement Award.
http://www.asce.org/pressroom/news/display_press.cfm?uid=1629.
Outra atividade que deve ser realizada durante a fase de conclusão é a certificação de
que todos os pagamentos foram efetuados pelo cliente. Muitos contratos incluem uma
cláusula de pagamento de progresso, que determina que o cliente faça o pagamento final
na conclusão do projeto. Em alguns casos, o pagamento final é uma porcentagem alta (por
exemplo, 25%) do preço total do projeto. Igualmente, deve-se verificar se todos os paga-
mentos foram efetuados a todos os subcontratados ou consultores e para cada compra de
materiais ou itens. Em caso afirmativo, pode-se fechar os “livros” do projeto, ou registros de
contabilidade e fazer uma análise financeira do projeto, na qual os custos reais são compa-
rados ao orçamento do projeto.
Durante a fase de conclusão do projeto, o gestor de projeto deve preparar uma avaliação
de desempenho por escrito para cada membro da equipe e descrever como cada um deles
ampliou seus conhecimentos, em conseqüência da participação no projeto, e também que
áreas eles precisam desenvolver mais. Se um membro da equipe não se reporta diretamente
ao gestor de projeto na estrutura organizacional da empresa, este deve providenciar uma
cópia da avaliação de desempenho para o supervisor imediato desse membro.
Finalmente, nenhum projeto de sucesso deve terminar sem algum tipo de comemoração,
que pode ser desde um happy hour para comer uma pizza até um evento mais formal, com
oradores da organização do cliente e prêmios ou certificados de reconhecimento para os
participantes do projeto.
Outra atividade importante na fase de conclusão é organizar reuniões de avaliação pós-
projeto. Estas devem ser conduzidas internamente, na organização que realizou o projeto, e
também com o cliente. O propósito dessas reuniões é avaliar o desempenho do projeto,
determinar se os benefícios esperados foram realmente alcançados e identificar o que pode
ser feito para melhorar o desempenho de projetos futuros.
Avaliação Interna Pós-Projeto

Internamente, deve haver dois tipos de reuniões: individuais com os membros da equipe e
uma reunião de grupo com a equipe do projeto. Sua realização deve ser feita logo depois
da conclusão do projeto e ser anunciada antecipadamente, para que as pessoas possam
estar preparadas.
O gestor do projeto deve fazer uma reunião individual com cada membro da equipe. Es-
sas reuniões permitem que os participantes dêem suas impressões pessoais sobre o desem-
penho do projeto e apontem o que pode ser melhorado nos projetos futuros. As reuniões
individuais permitem que as pessoas falem abertamente, sem o constrangimento causado
por uma reunião de grupo.
Por exemplo, eles podem mencionar qualquer problema de relacionamento de trabalho
com outros membros da equipe. É evidente que o gestor do projeto deve assegurá-los de
que essas revelações serão confidenciais. Terminadas as reuniões individuais com os mem-
bros da equipe, o gestor do projeto pode identificar problemas comuns levantados nessas
reuniões. Com essas informações, o gestor do projeto pode desenvolver uma pauta para
a reunião de grupo com toda a equipe do projeto.
Na reunião de grupo com a equipe do projeto, o gestor de projeto deve discutir o que
ocorreu durante o desenvolvimento do projeto e identificar as recomendações específicas para
aperfeiçoamento. Um exemplo de pauta para uma reunião de equipe de avaliação pós-pro-
jeto é mostrado na Figura 4.5.

10. Quais são os dois tipos de reunião
de avaliação pós-projeto interna que o
gestor deve realizar?
FIGURA 4.5 Pauta de Reunião de Equipe de Avaliação Pós-Projeto
AVALIAÇÃO PÓS-PROJETO
Reunião de Equipe
Agenda = Pauta
1. Desempenho Técnico
Escopo de trabalho
Qualidade
Gestão de mudanças
2. Desempenho de Custos
3. Desempenho de Cronograma
4. Controle e planejamento do projeto
5. Relacionamento com o cliente
6. Relacionamento entre membros da equipe
7. Comunicações
8. Identificação e resolução de problemas
9. Recomendações para projetos futuros
A seguir, estão alguns temas que podem ser discutidos dentro de cada item da pauta:
1. Desempenho técnico. Como ficou o escopo final do trabalho comparado ao escopo
do trabalho no início do projeto? Houve muitas mudanças no escopo do trabalho?
As mudanças foram conduzidas de maneira apropriada em termos de aprovações e
documentação? Que impacto as mudanças tiveram nos custos e no cronograma do
projeto? O escopo do trabalho foi totalmente cumprido? O trabalho e deliverables
do projeto foram concluídos com qualidade e atenderam às expectativas do cliente?
2. Desempenho de custos. Quais foram os custos finais do projeto, comparando-se o or-
çamento original com o orçamento final, o qual incluiu todas as mudanças relevantes
no escopo do projeto? Se houve um contrato de preço global, ele foi lucrativo ou a
organização do projeto perdeu dinheiro? Se houve um contrato por administração, o
projeto foi concluído dentro do orçamento do cliente? Houve algum pacote de tra-
balho em particular que ficou acima ou abaixo de seu orçamento em mais de 10%?
Em caso afirmativo, por quê? Quais foram as causas dos excedentes de custos? As
estimativas de custos foram realistas?
3. Desempenho de cronograma. Como foi o cronograma real do projeto comparado ao
cronograma original? Se o projeto atrasou, quais foram as causas? Como foi o desem-
penho do cronograma associado a cada pacote de trabalho? As estimativas de dura-
ção das atividades foram realistas?
4. Planejamento e controle de projeto. O projeto foi planejado com um nível suficiente
de detalhe? Os planos para incorporar mudanças foram atualizados a tempo? O de-
sempenho real foi comparado ao desempenho planejado regularmente? Os dados do
desempenho real foram precisos e coletados a tempo? O sistema de planejamento
e controle foi usado regularmente pela equipe do projeto? Ele foi utilizado para a
tomada de decisões?
5. Relacionamento com o cliente. Foram feitos todos os esforços para fazer do cliente
um participante do sucesso do projeto? Foi lhe perguntado regularmente seu ní-
vel de satisfação com relação ao progresso do projeto? Houve, com regularidade,
reuniões pessoais agendadas com o cliente? Ele foi informado dos problemas em
potencial a tempo e lhe foi perguntado seu interesse em participar do processo de
resolução do problema?
6. Relacionamento entre membros da equipe. Houve um sentimento de “equipe” e um

compromisso com o sucesso do projeto? Ocorreu alguma situação que impediu o
trabalho de equipe?
7. Comunicações. A equipe manteve-se constantemente informada sobre o status do
projeto e de seus problemas em potencial? O ambiente do projeto foi favorável a co-
municações convenientes, honestas e abertas? As reuniões foram produtivas? As comu-
nicações por escrito dentro da equipe e com o cliente foram suficientes, insuficientes
ou demasiadas?
8. Resolução e identificação de problemas. Quais mecanismos foram usados antecipa-
damente pelos membros da equipe para identificar os problemas em potencial? A
resolução do problema foi feita de maneira racional e completa?
9. Recomendações. Com base na discussão e na avaliação da equipe sobre os itens an-
teriores, quais recomendações específicas podem ser feitas para ajudar a melhorar o
desempenho em projetos futuros?
Após reunião de avaliação, o gestor de projeto deve elaborar por escrito um breve rela-
tório de gestão com um resumo do desempenho e recomendações do projeto.
Feedback do Cliente
Tão importante quanto a reunião interna é a reunião de avaliação pós-projeto com o cliente.
Seus objetivos devem ser: determinar se o projeto proporcionou ao cliente os benefícios es-
perados, avaliar o nível de satisfação do cliente e obter qualquer feedback que possa ser útil
no relacionamento futuro com esse ou outros clientes. Os participantes da reunião devem
incluir o gestor do projeto, membros-chave da equipe de projeto e representantes-chave
da organização do cliente que estiveram envolvidos no projeto. O gestor deve programar a
reunião para quando o cliente estiver realmente em condições de dizer se o projeto aten-
deu às suas expectativas e trouxe os benefícios previstos. No caso de um projeto para o
desenvolvimento de um folheto colorido de oito páginas para um cliente, pode-se realizar
a reunião pouco tempo após o livreto impresso ser entregue ao cliente, pois este saberá
imediatamente se o folheto atendeu às expectativas.
Contudo, no caso do projeto de uma máquina especial de montagem automatizada, pla-
nejada para reduzir o nível de defeitos em produtos de 10% para 2%, podem ser necessários
vários meses após sua instalação para que o cliente seja capaz de verificar se o nível de
defeitos foi reduzido. Esse tempo pode ser necessário para que os operadores aprendam a
manejar o equipamento adequadamente ou para que a empresa verifique uma redução na
devolução de mercadorias. É ideal que o fornecedor converse diretamente com o cliente e
faça perguntas abertas. Isso dá aos clientes uma oportunidade não apenas de expressar seu
grau de satisfação, como também de fazer comentários detalhados sobre as partes do proje-
to com as quais ficaram satisfeitos ou insatisfeitos. Esses comentários não serão surpresa se
o gestor de projetos estiver monitorando continuamente o nível de satisfação do cliente ao
longo do projeto. Se o cliente estiver satisfeito, o fornecedor ou a organização que realizou
o projeto terá várias novas oportunidades.
Primeiro, o fornecedor deve perguntar ao cliente sobre quaisquer outros projetos que ele
poderia realizar – talvez sem passar por um processo de concorrência. Se o cliente estiver
satisfeito com um folheto, por exemplo, o fornecedor deve perguntar se quaisquer outros
folhetos, relatórios anuais ou materiais de marketing são necessários.
Da mesma forma, se o cliente estiver satisfeito com uma máquina de montagem automa-
tizada, o fornecedor deve perguntar se outras peças do processo de fabricação precisam ser
estudadas para melhorias de produtividade adicionais. Segundo, o fornecedor deve pedir
permissão para usar o cliente como referência de contato para consulta de clientes em po-
tencial. É possível que o fornecedor queira mencionar o cliente em um folheto, talvez com
uma foto e uma frase dizendo quão satisfeito ele ficou com o desempenho do fornecedor.
Outro modo de fazer publicidade é escrever um artigo sobre o projeto em colaboração

com o cliente e publicá-lo na forma de press release para jornais e outros meios adequados.

11. Relacione três motivos para a
realização de uma reunião de avaliação
pós-projeto com o cliente.
Outra forma de se obter feedback do cliente em relação a sua satisfação com os resulta-
dos do projeto é promover uma pesquisa de avaliação pós-projeto com o cliente, conforme
apresentado na Figura 4.6. O gestor de projeto entrega esse formulário de pesquisa para o
cliente e, possivelmente, a outras partes interessadas no projeto, para que ele seja preenchi-
do e devolvido. Para grandes projetos, diversas pessoas na organização do cliente podem
contribuir com respostas.
Quando existem múltiplos clientes ou usuários finais dos resultados de um projeto, pode
ser complicado obter feedback deles. Por exemplo, depois que um grupo de voluntários
organiza um festival municipal de uma semana, como obter feedback das pessoas que estive-
ram presentes e saber seu nível de satisfação e suas sugestões para melhorar o evento para o
próximo ano? Ou então pense em um projeto no qual um novo software foi desenvolvido.
O cliente imediato é o gerente de produtos da empresa, mas os verdadeiros clientes são
as pessoas que irão comprar o software. O gerente de produtos pode estar satisfeito com
o produto produzido, mas como a equipe de projeto determina se os usuários finais estão
satisfeitos? Nos dois casos – o festival municipal e o novo software –, a equipe de projeto
pode usar algum tipo de pesquisa ou grupo focal para obter feedback dos usuários finais.
Encerramento Precoce do Projeto

Pode haver casos em que o projeto precisa ser encerrado antes da conclusão. Por exemplo,
imagine que uma empresa esteja trabalhando em um projeto de pesquisa e desenvolvimento
de material avançado com determinadas propriedades em temperaturas extremamente bai-
xas. Após um pouco de trabalho de desenvolvimento e testes, determina-se que continuar
desenvolvendo o material poderia custar muito mais e levar muito mais tempo do que origi-
nalmente previsto. Se a empresa decidir que a probabilidade de gastos maiores vai gerar um
resultado satisfatório baixo, o projeto será interrompido, ainda que a empresa tenha inves-
tido vários milhões de dólares nele. Outra circunstância que pode causar o encerramento
precoce de um projeto é a mudança na situação financeira da empresa – por exemplo, se
as vendas estiverem baixando ou se a empresa for vendida para outro grupo.
O cliente também pode interromper projetos por insatisfação. Por exemplo, se os com-
pradores de uma casa não estiverem satisfeitos com o trabalho do fornecedor ou se senti-
rem frustrados com atrasos no cronograma, eles podem rescindir o contrato com o fornece-
dor e contratar outro para terminar o projeto. De forma semelhante, se estiver financiando
a concepção e produção de uma nova aeronave militar e os custos do projeto começam a
ultrapassar significativamente o orçamento, o governo pode cancelar o contrato.

12. Para um fornecedor, quais são
duas possíveis conseqüências do
encerramento precoce de um projeto em
função de insatisfação do cliente?
FIGURA 4.6 Pesquisa Pós-Projeto de Avaliação do Cliente
Pesquisa Pós-Projeto de Avaliação do Cliente
Favor preencher esta breve pesquisa para nos ajudar a avaliar e melhorar nosso processo de
gestão de projetos. Caso seja necessário mais espaço para as respostas, favor anexar folhas
adicionais.
Título do Projeto
Nível de Satisfação
Baixo Alto
1. Completude do Escopo do Projeto 1 2 3 4 5 6 7 8 9 10
Comentários
2. Qualidade do Trabalho 1 2 3 4 5 6 7 8 9 10
Comentários
3. Cumprimento do Cronograma 1 2 3 4 5 6 7 8 9 10
Comentários
4. Cumprimento do Orçamento 1 2 3 4 5 6 7 8 9 10
Comentários
5. Comunicações 1 2 3 4 5 6 7 8 9 10
Comentários
6. Relacionamento com o Cliente 1 2 3 4 5 6 7 8 9 10

Comentários
7. Desempenho Geral 1 2 3 4 5 6 7 8 9 10
Comentários
Quais benefícios você de fato percebeu ou prevê como resultado desse

projeto?
A. Benefícios Quantitativos
B. Benefícios Qualitativos
Sugestões sobre como podemos melhorar nosso desempenho em projetos futuros
Nome Data
• É importante desenvolver um plano antes do início do projeto. Despender tempo

para desenvolver um plano bem concebido é fundamental para o cumprimento
bem-sucedido do projeto.
• A participação gera comprometimento. As pessoas que serão envolvidas na realiza-
ção do projeto devem participar do planejamento do trabalho.
• Programe reuniões pessoais regulares com o cliente.
• Pergunte regularmente ao cliente qual seu nível de satisfação com o progresso
do projeto.
• Mantenha o cliente e a equipe de projeto informados sobre o status do projeto e
possíveis problemas de forma oportuna.
• O segredo para o controle eficaz de projetos é medir o progresso real e compará-lo
ao progresso planejado de forma oportuna e regular, adotando ações corretivas
• Após a conclusão, deve-se avaliar seu desempenho para se aprender o que poderia
ser melhorado caso um projeto semelhante fosse realizado no futuro. Deve-se ob-
ter feedback do cliente e da equipe de projeto.
Ter um projeto interrompido por insatisfação do cliente pode ser muito prejudicial para
a imagem do fornecedor. Ele pode ter um prejuízo financeiro em função da interrupção e
precisar demitir alguns dos funcionários que estavam trabalhando no projeto. Mais impor-
tante, a reputação do fornecedor pode ficar manchada. O cliente insatisfeito provavelmente
não voltará a fazer negócios com ele, e uma reputação manchada pode dificultar os negó-
cios do fornecedor com outros clientes. Uma forma de se evitar o encerramento precoce de
um projeto em função de insatisfação do cliente é monitorar seu grau de satisfação conti-
nuamente no decorrer do projeto e tomar ações corretivas ao menor sinal de insatisfação.
RESUMO
Executar, ou realizar o projeto – implementar a solução proposta – é a terceira fase do
ciclo de vida do projeto. Essa fase começa depois que um acordo ou contrato é estabele-
cido entre o cliente e o fornecedor ou equipe de projeto e termina quando seu objetivo é
alcançado. Como resultado, o cliente fica satisfeito com a qualidade do trabalho concluído,
realizado dentro do prazo e do orçamento.
Essa terceira fase tem duas partes: fazer o planejamento detalhado para o projeto e im-
plementar o plano para atingir o objetivo do projeto. É necessário desenvolver um plano
que mostre como as tarefas do projeto serão executadas dentro do orçamento e do crono-
grama. O planejamento determina o que precisa ser feito, quem irá fazê-lo, quanto tempo
vai levar e quanto vai custar. O resultado do esforço de planejamento é um plano-base para
a realização do projeto. É importante que as pessoas envolvidas na execução do projeto
também participem do planejamento do trabalho. A participação gera comprometimento.
Após o estabelecimento de um plano, a equipe de projeto, liderada pelo gestor de projeto,
implementa o plano.
O gerenciamento de riscos envolve identificação, avaliação e resposta aos riscos do
projeto, a fim de minimizar a probabilidade e o impacto das conseqüências de eventos
adversos sobre o cumprimento de seu objetivo. A identificação de riscos inclui a determi-
nação de quais riscos podem afetar o projeto de forma adversa e quais podem ser as con-
seqüências de cada risco, caso ocorram. Sua avaliação individual envolve a determinação
da probabilidade da ocorrência do evento de risco e o grau de impacto que o evento terá
sobre o objetivo do projeto.
O planejamento de resposta a riscos envolve o desenvolvimento de um plano de ação
para reduzir o impacto ou a probabilidade de cada risco, o estabelecimento de um ponto
desencadeador de quando implementar as ações para enfrentar cada risco e a atribuição de
responsabilidade a pessoas específicas para a implementação de cada plano de resposta.
Durante o projeto, é importante avaliar todos os riscos e, conseqüentemente, determinar se
existem quaisquer mudanças na probabilidade de ocorrência ou no impacto potencial de
qualquer um deles; da mesma forma, novos riscos, não considerados no início do projeto,
podem ser identificados.
Enquanto a execução do projeto está sendo realizada pela equipe, é necessário moni-
torar o progresso para garantir que tudo esteja saindo conforme planejado. O processo de
controle de projeto envolve a coleta regular de dados sobre seu desempenho, a compara-
ção do desempenho real com o planejado e a tomada de ações corretivas se o desempenho
real estiver aquém do planejado. A gestão de projetos é uma abordagem proativa para o con-
trole de um projeto, de forma a garantir que seu objetivo seja atingido mesmo quando as
coisas não saem conforme o planejado.
A quarta e última fase do ciclo de vida do projeto é a conclusão, que começa depois que
o trabalho do projeto termina. O objetivo dessa fase é aprender com a experiência adquiri-
da, a fim de melhorar o desempenho em projetos futuros. As atividades de avaliação pós-
projeto incluem tanto reuniões individuais com os membros da equipe como reuniões de
grupo com a equipe de projeto. Também é importante reunir-se com o cliente para avaliar
seu nível de satisfação e determinar se o projeto trouxe os benefícios esperados para ele.
Os projetos podem ser interrompidos antes da conclusão por vários motivos. Podem, por
exemplo, ser encerrados por insatisfação do cliente, o que pode resultar em prejuízo finan-
ceiro e manchar a reputação do fornecedor ou organização que estiver realizando o projeto.
Uma forma de se evitar o encerramento precoce do projeto em função de insatisfação do
cliente é monitorar continuamente o nível de satisfação do cliente no decorrer do projeto e
adotar ações corretivas ao menor sinal de insatisfação.
PERGUNTAS
1. Qual fase do ciclo de vida envolve o planejamento do projeto? Quando essa fase pode
ser iniciada?
2. Descreva por que o planejamento é tão importante e relacione as etapas envolvidas no
planejamento detalhado.
3. Pense em um projeto no qual você esteja trabalhando atualmente ou tenha trabalhado
nos últimos tempos. Descreva o planejamento feito por você antes de iniciar o trabalho.
4. Descreva o que pode estar envolvido na execução real de um projeto. Relacione as
atividades que devem ser executadas para um projeto no qual esteja trabalhando atual-
mente.
5. Por que é importante controlar um projeto depois que é iniciado? Como isso é feito?
O que pode ser feito se o progresso real de um projeto não corresponder ao progresso
esperado?
6. Descreva o processo de controle de projeto. Discuta como pode ser aplicado para um
projeto no qual esteja trabalhando atualmente ou em um projeto no qual tenha traba-
lhado recentemente.
7. Por que um projeto deve ter um período de emissão de relatórios bem definido? Duran-
te cada período de relatório, que tipos de dados precisam ser coletados?
8. Descreva o que precisa ser feito para se gerenciar os riscos de um projeto. Quando isso
deve ser feito? Como a matriz de avaliação de riscos pode ajudar nesse processo?
9. Discuta o que precisa ser feito como parte da conclusão de um projeto. Por que essas
atividades são importantes?
10. Discuta o processo interno de avaliação pós-projeto e os dois tipos de reunião envolvidos.
11. Cite algumas formas de se obter feedback do cliente após a conclusão de um projeto.
Como você usaria essas informações?
12. Por que alguns projetos são interrompidos antes de sua conclusão? Quando é aconse-
lhável fazer isso?
~clements.
1. Procure na Internet um projeto que tenha sido concluído com sucesso. Escreva um
resumo de três páginas sobre esse projeto, incluindo os fatores essenciais que fize-
ram dele um sucesso. Em seguida, busque na Internet um projeto que não tenha sido
completado com sucesso. Escreva um resumo de três páginas sobre ele, incluindo as
razões pelas quais você acha que fracassou.
2. Procure organizações de gestão de projetos na Internet. Descreva brevemente cinco
organizações diferentes, seus objetivos e características únicas.
3. Procure softwares de gerenciamento de riscos na Internet. Faça o download de uma
versão de avaliação, se encontrar. Escreva um resumo de duas páginas sobre as fun-
ções disponíveis no software.
4. Procure padrões de gestão de projetos na Internet. Forneça uma lista dos padrões
encontrados. Descreva os três que considerar mais importantes.
5. Procure publicações sobre gestão de projetos na Internet e em sua biblioteca. Faça
uma lista dessas publicações e alguns de seus artigos mais recentes. Se possível,
peça uma amostra grátis de uma ou mais dessas publicações.
ESTUDO DE CASO Nº 1 Uma Empresa de Fabricação de Eletrônicos

A Delta Inc. fabrica equipamentos de testes eletrônicos. Seus produtos são conhecidos por
sua qualidade, e a empresa pratica preços premium no mercado, em função de sua reputação.
Hannah Elkton é vice-presidente de marketing, Jim Anderson é gerente de vendas e
Cathy Perez é gerente de desenvolvimento de produto. Tanto Jim como Cathy trabalham
para Hannah. Cathy chegou à empresa há dois anos, após trabalhar em uma firma concor-
rente e ser preterida em uma promoção. Na Delta, ela iniciou um projeto para desenvolver
um dispositivo de testes de baixo custo que iria concorrer com produtos na outra ponta do
mercado, como aqueles fabricados por seu antigo empregador. Após quase 12 meses de tra-
balho de desenvolvimento, o produto correspondeu às expectativas de Cathy. A fabricação
do novo produto começou logo depois, e ele chegou ao mercado há cerca de três meses.
Jim, funcionário da Delta há 25 anos, sentiu-se menosprezado quando Cathy iniciou o
projeto de desenvolvimento sem perguntar sua opinião. Ele acredita que tem conhecimen-
to do mercado e sabe o que irá e o que não irá vender.
Certo dia, Jim marca uma reunião com Hannah e Cathy. Ele começa a reunião anun-
ciando:
– Solicitei esta reunião para dizer a vocês que temos um sério problema. Meus represen-
tantes de vendas dizem que alguns dos clientes que adquiriram o novo dispositivo de testes
de baixo custo da Cathy estão muito insatisfeitos.
– Qual é o problema, especificamente?, pergunta Cathy.
– Não sei exatamente, mas meus representantes de vendas me disseram que não estão
interessados em tentar vendê-los se não funcionam direito, responde Jim.
– Como você vem a uma reunião dessas e faz acusações sem saber os fatos? Que tipos
de problemas e em que quantidade?, pergunta Cathy.
– Talvez seus representantes de vendas não queiram vender o produto porque você está
lhes dando uma comissão baixa.
Jim rapidamente responde: – Talvez, se tivesse tentado descobrir o que nossos clientes
querem e precisam, em vez de imaginar o que eles queriam, o produto teria tido mais
sucesso. Até onde sei, você desperdiçou muito dinheiro para desenvolver essa porcaria –
dinheiro que afetou os lucros da empresa e reduziu as bonificações deste ano para mim e
para meus representantes de vendas.
Hannah intervém: – Precisamos de alguns dados concretos sobre quais são exatamente
os problemas, a fim de corrigir a situação. Não podemos deixar um problema como esse
manchar a nossa reputação e prejudicar as vendas de nossos outros produtos.
Cathy e Jim respondem simultaneamente: – Vou fazer isso.
PERGUNTAS
1. Por que há um problema na Delta Inc.?

2. O que Hannah deve fazer? Como deve proceder?
3. Como o problema poderia ter sido evitado?
4. Quais lições podem ser aprendidas para projetos futuros?
ATIVIDADE EM GRUPO
Forme equipes com três alunos cada. Peça que cada membro da equipe assuma o papel de
uma das pessoas do estudo de caso; dê tempo para que cada grupo debata as causas e as
soluções para esse problema.
Em seguida, peça que cada grupo reflita sobre as perguntas acima, escrevendo um breve
relatório ou fazendo uma rápida apresentação de suas respostas para a turma.
ESTUDO DE CASO Nº 2 Projeto de Expansão de Fábrica

Jacob Clemson é proprietário da Digitsig Inc., uma empresa de eletrônicos em fase de cres-
cimento. As vendas estão expandindo rapidamente. Atualmente, sua fábrica está funcionan-
do em três turnos e no máximo de sua capacidade. Ele teve de arrendar mais espaço em um
edifício a vários quilômetros de distância. Sabe que deve expandir sua fábrica para atender
à demanda crescente, aumentar a eficiência e reduzir os custos associados ao transporte de
materiais e produtos entre sua fábrica e o edifício arrendado. O custo do arrendamento foi
bastante alto, pois não havia muitos espaços bons disponíveis na região. Por isso, Jacob es-
tava desesperado para conseguir mais espaço imediatamente ou não seria capaz de atender
à demanda, e seus clientes poderiam procurar os concorrentes.
Jacob conheceu Andy Gibson, um dos proprietários da AG Contractors, em um evento
da Câmara de Comércio. Ele contou a Andy sobre suas necessidades de expansão. Andy
disse: – Podemos fazer isso por você, senhor Clemson. Já fizemos muitos projetos seme-
lhantes. Como deve saber, os negócios estão a todo o vapor na região, e conseguir um
fornecedor não será fácil. Mas o fato de termos nos encontrado pode ser um sinal de sorte,
porque estamos concluindo outro projeto e poderíamos começar a trabalhar no seu, se che-
garmos logo a um acordo. Tenho outras quatro propostas pendentes; se entrarem, nós não
conseguiremos cuidar de mais nenhum projeto. E, como disse, imagino que todos os outros
fornecedores estejam tão ocupados quanto nós. Parece-me que você realmente precisa dar
início a esse projeto de expansão imediatamente. Acho que podemos ajudá-lo.
Jacob não queria perder mais tempo; como ficou com receio de não conseguir outro
fornecedor, assinou um contrato com a AG Contractors, por um preço que achou razoável.
O novo espaço seria usado principalmente para armazenar materiais recebidos e produtos
acabados. Ele concordou com uma cláusula do contrato para pagar uma bonificação de 10%
se o projeto de expansão fosse concluído em 12 meses, em vez dos 15 que Andy lhe disse
que seria o prazo normal.
Estamos agora 14 meses depois. Andy Gibson e Gerri Penk, um gestor de projetos
recém-contratado pela AG Contractors, foram até o escritório de Jacob Clemson. A recep-
cionista perguntou: – Pois não?
Andy perguntou: – Jacob está?
– Sim, está. Você marcou hora?, interrogou a recepcionista.
Andy foi entrando e dizendo à recepcionista: – Não precisa. Vai ser bem rápido.
Gerri, surpreso, o acompanhou. Ele bateu na porta de Jacob uma vez, abriu-a e entrou
sem esperar resposta.
Atônito, Jacob Clemson olhou para ele e disse: – Estou no meio de uma importante...
Andy interrompeu: – Só vou levar um minuto. Só gostaria de dizer que concluímos o
projeto de expansão de sua fábrica dentro do prazo e de acordo com o orçamento. Termi-
namos em 12 meses, exatamente como eu sabia, quer dizer, esperava que iríamos terminar.
Precisei ser severo com alguns de nossos subcontratados, mas é assim que funciona no
mundo dos negócios. Às vezes, precisamos jogar duro para que o trabalho seja feito. Tenho
certeza de que você também pensa assim, Jacob, ou não estaria onde está.
Jacob Clemson se manifestou: – Bem, tivemos alguns problemas...
Andy o interrompe novamente: – Em um projeto grande como esse, sempre há proble-
mas, e algumas pessoas acabam perdendo a paciência. Mas isso sempre acontece. Não se
preocupe. No fim, deu tudo certo. Pensei que talvez pudéssemos sair para almoçar e come-
morar, mas temos outra reunião do outro lado da cidade. Ligue-me um dia desses; talvez a
gente possa se encontrar e discutir se existem outros projetos nos quais eu possa ajudá-lo.
Andy então se virou e saiu rapidamente do escritório de Jacob, passando por Gerri, que
correu para o alcançar.
Depois que eles saíram, Jacob estava um tanto surpreso e furioso. Ele pensou consigo
mesmo: – Outro projeto? Só sobre o meu cadáver. Jogar duro? Que tipo de pessoa ele pensa
que sou? Concluir o projeto no prazo e de acordo com o orçamento – ele acha que é só
isso o que importa? Esse projeto foi um pesadelo. Acabou custando 50% mais que o preço
original da AG em função de todas as mudanças estipuladas por eles. Nunca perguntavam,
nunca ouviam, nunca me disseram o que estava acontecendo e nunca retornavam as mi-
nhas ligações. Que bando de idiotas! Nunca mais vou fazer negócios com eles.
Andy, ao entrar no carro com Gerri, disse: – Aí está, outro cliente satisfeito da AG.
E bastante ingênuo também, divertia-se Andy. – Sabia que poderíamos terminar o projeto
em 12 meses. Mas vi que ele estava desesperado e disse que levaria 15 meses. Fiz que ele
concordasse em pagar uma bonificação se concluíssemos o projeto em 12 meses.
Gerri perguntou: – Andy, isso não é falta de ética?
– Ei, os negócios estão a todo o vapor para a Digitsig; eles têm muito dinheiro. Além
do mais, a culpa foi dele, que esperou tanto tempo até se decidir pela expansão. Ele teve
sorte de contar com a nossa ajuda. Mas tenho de lhe dizer, Gerri, fiquei me perguntando
por que ele estava construindo todo aquele depósito quando a maioria das outras empresas
está trabalhando com pronta entrega. Mas eu nunca iria contar isso a ele. O simples fato
de ter uma empresa já é surpreendente. Bem, você vai descobrir que há um mundo cruel
lá fora, Gerri.
Gerri respondeu: – Andy, fiquei com a impressão de que o senhor Clemson não ficou
totalmente satisfeito. Quer dizer, ele não chegou a dizer que estava satisfeito.
– Mas também não disse que não estava, Andy retrucou. Além do mais, ele nunca me
pareceu interessado no projeto, nunca pediu para fazermos reuniões e, quando eu tentei
marcar uma, estava ocupado demais. E os pagamentos foram sempre atrasados – como
se estivesse nos fazendo um favor. Acredite, ele está empolgado com o trabalho da AG.
Ele estava desesperado para realizar o projeto; nós o realizamos para ele – no prazo e de
acordo com o orçamento. E ganhamos muito dinheiro com o projeto. Portanto, nós dois
saímos ganhando.
– Pensando bem, usarei nosso amigo Jacob como referência para o novo cliente com
quem nos reuniremos agora à tarde para analisar sua CP. Os clientes sempre pedem referên-
cias de projetos anteriores, mas, francamente, eles quase nunca ligam para essas pessoas.
– Ei, Gerri, você vai aprender que é preciso se concentrar no próximo cliente e não se
preocupar com os antigos. Funciona, acredite, ou eu não seria dono desse Porsche. Talvez
eles não tenham lhe ensinado isso no curso de MBA, mas eu aprendi na escola da vida
quando herdei esse negócio de meu pai. Ele era adorado na comunidade, e eu estou apenas
seguindo seus passos.
PERGUNTAS
1. Que outra atitude Andy Gibson deveria ter tomado durante seu encontro com Jacob
Clemson em seu escritório?
2. Quais são algumas das coisas que Andy Gibson deveria ter feito de outra forma em seu
contato inicial com Jacob e durante o projeto?
3. Quais são algumas das coisas que Jacob deveria ter feito de outra forma quando conhe-
ceu Andy e durante o projeto?
4. O que Gerri deveria fazer?
ATIVIDADE EM GRUPO
Divida os alunos em grupos de três ou quatro para elaborar respostas às perguntas rela-
cionadas ao estudo de caso. Cada grupo deve eleger um porta-voz para apresentar suas
respostas ao restante da turma.
Parte 2
PLANEJAMENTO E CONTROLE DO PROJETO
CAPÍTULOS
5 Planejamento 6 Cronograma 7 Controle do 8 Considerações 9 Planejamento e
Cronograma sobre Recursos Desempenho
de Custos
Trata da Produz a estimativa Discute o monitora- Expõe a incorpora- Inclui a estimativa
determinação de das durações de to- mento do progres- ção de requisitos dos custos do
quais atividades das as atividades e o so do projeto e o e limitações de projeto, o desen-
precisam ser desenvolvimento de replanejamento recursos no plano volvimento do orça-
conduzidas, quem um cronograma e atualização do e no cronograma mento do projeto, a
será responsável de projeto detalha- cronograma do do projeto. análise do desem-
por elas e em qual do que especifica projeto, quando penho de custos do
seqüência serão quando cada ativi- necessário. projeto e a previsão
realizadas. dade deve começar dos custos totais
e terminar. na conclusão do
projeto.
Os capítulos da Parte 2 abordam as técnicas para o planejamento e controle de um projeto,

a fim de se atingir seu objetivo com sucesso. O planejamento determina o que precisa ser
feito, quem vai fazê-lo, quanto tempo vai levar e quanto vai custar. Despender um pouco
de tempo para desenvolver um plano bem concebido é fundamental para a realização
bem-sucedida do objetivo do projeto. O desenvolvimento de um plano detalhado inclui:
(1) a definição das atividades específicas necessárias para realizar o projeto e a atribuição
de responsabilidades para cada uma dessas atividades; (2) a determinação da seqüência
na qual essas atividades devem ser conduzidas; (3) a estimativa do tempo e dos recursos
necessários para cada atividade, e (4) a elaboração de um cronograma e de um orçamento
para o projeto. Muitos projetos ultrapassaram seus orçamentos, extrapolaram a data de con-
clusão ou cumpriram exigências apenas parcialmente porque não havia um plano básico
viável antes de serem iniciados. Para se evitar isso, é necessário planejar o trabalho e depois
executar o plano.
Uma vez que tenha sido estabelecido, o plano deve ser implementado. Isso significa a
realização do trabalho de acordo com o plano e o controle do trabalho de forma que o es-
copo do trabalho seja alcançado dentro do orçamento e do prazo. Após o início do projeto,
é necessário monitorar seu progresso, a fim de garantir que tudo está saindo conforme pla-
nejado. Isso envolve a mensuração do progresso real e sua comparação com o progresso
planejado. Se, a qualquer momento, o projeto não estiver saindo conforme o planejado,
devem ser tomadas ações corretivas, e o projeto deve ser replanejado. O segredo para um
controle eficaz do projeto é comparar o progresso real com o progresso planejado de forma
regular e pontual, e tomar uma ação corretiva imediatamente, se necessário.
97
Capítulo PLANEJAMENTO
5 Objetivo do Projeto
Estrutura Analítica do Projeto
Matriz de Responsabilidades
Software de Gestão de Projetos
Resumo
Perguntas
Definindo Atividades Exercícios na Internet
Desenvolvendo o Planejamento Estudo de Caso no 1 Um Centro
de Redes de Atividades de Pesquisa Médica Sem Fins
Princípios de Redes de Atividades Lucrativos
Atividades Fictícias Perguntas
Preparando o Diagrama de Rede Atividade em Grupo
Planejamento para Estudo de Caso no 2 O Casamento
Desenvolvimento de Sistemas de Perguntas
Informação Atividade em Grupo
Exemplo de SI: Desenvolvimento Apêndice Microsoft Project
de Aplicativos de Internet para
a ABC Office Designs
98
Ca pítulo Cinc o
As Olimpíadas
Cem dias antes do início das Olimpíadas de 2004 em Atenas, na Grécia, parecia que mui-
tas atividades do projeto estavam ocorrendo dentro de um cronograma muito apertado.
Elas começaram muito tarde: embora Atenas tenha sido escolhida como sede em 1997, o
projeto não foi iniciado antes do ano 2000, quando houve a notificação do Comitê Olímpico
Internacional. Desde o início do projeto, prazos adicionais de construção e o aumento das
exigências de segurança resultaram em um acréscimo de US$ 1,19 bilhão ao custo do projeto.
Quando restavam menos de cem dias no cronograma, notou-se que a maioria dos projetos de
construção não seria concluída até poucos dias antes do início dos jogos.
O Complexo Esportivo Olímpico de Atenas – que sediou a abertura e a cerimônia de
encerramento das Olimpíadas, bem como as pistas e os campos, partidas de tênis, finais
de basquete, ginástica olímpica, natação e ciclismo – estava com a cobertura inacabada.
Além disso, as obras na pista de atletismo ainda não tinham começado. A finalização do ve-
lódromo, para o ciclismo, estava com novo prazo: ficaria pronto apenas 40 dias antes do
início dos jogos. A construção de estruturas para outros eventos olímpicos ainda estava
em andamento. Conseqüentemente, os atrasos nos projetos de construção principais pro-
vocavam atrasos em outros elementos críticos do projeto. Um deles era a infra-estrutura
de telecomunicações, que incluía a infra-estrutura para telefonia, celulares, serviços e rede
de tecnologia de rádio digital terrestre, sistema de TV a cabo, rede de TI para os Jogos
Olímpicos, serviços de IP, comunicações marítimas, comunicações por satélite e centrais de
atendimento de chamadas. A instalação do sistema de segurança revelou-se outra parte
crítica do projeto, pois seria adiada. A associação de empresas que proporcionou a esse
sistema os US$ 312 milhões culpou, como se pode imaginar, as atividades de construção de
apoio pelo atraso na instalação. O sistema era constituído de milhares de câmeras de alta
resolução, rádio, comunicações e rede de computadores.
A equipe de projeto das Olimpíadas estava trabalhando com prazos muito apertados,
pouca ou nenhuma folga, para que muitas atividades interdependentes fossem concluídas.
Esse exemplo ilustra a importância do uso de técnicas de planejamento de rede de ativida-
des para definir claramente as relações prévias entre as atividades do projeto. O gestor de
projetos pode compartilhar essas informações e a dependência de uma tarefa em relação à
outra, para ajudar a controlar o projeto. Essas informações favorecem o entendimento dos
membros da equipe quanto à realização dos objetivos em curto prazo, necessários para se
alcançar objetivos maiores e melhorar as chances de concluir o projeto dentro do prazo
estipulado.
Argitis, T. Athens Working to Finish Olympic Stadium 100 Days Before Games. Bloomberg, 2004.
Orkin, L. Crews Scramble to Finish Olympic Complex. Associated Press, 2004.
Quinn, P. Company Works to Prepare Olympics Telecom. Associated Press, 2004.
Varouhakis, M. Olympics Security Set for Games. Associated Press, 2004.
99
100 Parte 2 Planejamento e Controle do Projeto
Este capítulo descreve as técnicas usadas para planejar os elementos de trabalho e as

atividades necessárias para a realização de um projeto. Você vai conhecer melhor:
• o desenvolvimento de uma estrutura analítica do projeto;
• o desenvolvimento de um diagrama de rede;
• a utilização de uma metodologia de gestão de projetos chamada de ciclo de vida
de desenvolvimento de sistemas para projetos de desenvolvimento de sistemas de
informação.
Planejamento é a organização sistemática de tarefas para se atingir um objetivo. Estipula
o que precisa ser realizado e como será realizado. Este se torna uma referência contra a
qual o progresso real pode ser comparado; então, quando ocorrem desvios, devem ser
tomadas ações corretivas.
É importante que as pessoas envolvidas na realização do trabalho também se interessem
por seu planejamento. Elas costumam ter mais conhecimento sobre quais atividades de-
talhadas precisam ser conduzidas e quanto tempo cada tarefa deve levar. Ao participar
do planejamento do trabalho, ficarão comprometidas com sua realização de acordo com
o plano e dentro do prazo e do orçamento. A participação gera comprometimento. De
maneira geral, no caso de projetos de vários anos e que incluem centenas ou milhares de
pessoas, não é possível envolver todas no planejamento inicial. À medida que o projeto
se desenvolve, contudo, pode ser possível envolver várias dessas pessoas no desenvol-
vimento de planos mais detalhados.
OBJETIVO DO PROJETO
A primeira etapa no processo de planejamento é definir o objetivo do projeto – o resultado
ou produto final esperado. O objetivo deve ser claramente definido e acordado entre o
cliente e a organização ou fornecedor que vai conduzir o projeto. Ele deve ser claro, atin-
gível, específico e mensurável. O cumprimento do objetivo do projeto deve ser facilmente
reconhecível tanto pelo cliente quanto pelo fornecedor. O objetivo é o alvo – o produto
final tangível que a equipe de projeto deve fornecer.
Para um projeto, o objetivo costuma ser definido em termos de escopo, cronograma e
custo – ele exige a conclusão do trabalho dentro do orçamento e em determinado período
de tempo. Por exemplo, o objetivo do projeto pode ser “lançar no mercado, dentro de dez
meses e com um orçamento de US$ 2 milhões, um novo eletrodoméstico para cozinhar,
que atenda a certas especificações de desempenho predefinidas”. Outro exemplo é “pro-
duzir um catálogo publicitário de quatro cores e 16 páginas com artigos de volta às aulas e
enviá-lo até o dia 31 de julho para todos os clientes-alvo identificados na região, com um
orçamento de US$ 40 mil”.

1. Para um projeto, o objetivo costuma
ser definido em termos de __________,
__________ e __________.
Um objetivo de projeto como “terminar a casa” é muito ambíguo, pois o cliente e o for-
necedor podem ter opiniões diferentes sobre o que significa “terminar”. Um objetivo mais
bem definido seria “terminar a casa até o dia 31 de maio, de acordo com as plantas e as
especificações estipuladas em 15 de outubro e dentro de um orçamento de US$ 150 mil”.
As especificações e as plantas fornecem os detalhes em relação ao escopo do trabalho que
o fornecedor concordou em executar. Portanto, não deve haver discussões sobre a inclusão
Capítulo 5 Planejamento 101
ou não de paisagismo ou sobre a colocação de carpete, nem sobre o tamanho da porta de

entrada, a cor da pintura nos quartos ou o estilo dos acessórios de iluminação. Todos esses
detalhes seriam estipulados nas especificações.

2. Descreva o objetivo de um projeto
no qual você esteja trabalhando
atualmente (ou tenha trabalhado
recentemente).
É ideal que o objetivo do projeto seja claro e conciso desde o início. Contudo, às ve-
zes este precisa ser modificado à medida que o projeto caminha. O gestor de projetos e o
cliente devem chegar a um acordo sobre todas as mudanças em relação ao objetivo inicial
do projeto. Quaisquer mudanças podem afetar o escopo do trabalho, a data de conclusão
e o custo final.
ESTRUTURA ANALÍTICA DO PROJETO

Uma vez definido o objetivo do projeto, o próximo passo é determinar quais elementos
de trabalho, ou atividades, precisam ser conduzidos para seu cumprimento. Isso requer a
elaboração de uma lista com todas as atividades. Existem duas formas de se preparar essa
relação. Uma é pedir que a equipe de projeto faça um brainstorm sobre qual seria a lista
de atividades. Esse método é adequado para projetos pequenos; contudo, para os maiores
e mais complexos, é difícil desenvolver uma lista abrangente de atividades sem se esquecer
de alguns itens. Para esses projetos, a criação de uma estrutura analítica de projeto (EAP) é
uma abordagem melhor.

3. O que é uma estrutura analítica de
projeto?
A EAP desmembra um projeto em porções, ou itens, gerenciáveis, garantindo que to-

dos os elementos de trabalho necessários à conclusão do escopo de trabalho do projeto
sejam identificados. Trata-se de uma árvore hierárquica de itens finais que serão atingidos
ou produzidos pela equipe durante a execução do projeto. Atingir ou produzir todos esses
itens constitui a conclusão do escopo do projeto. Um exemplo de uma EAP para um festival
municipal é apresentado na Figura 5.1.

4. O item de trabalho no nível mais baixo
de qualquer ramificação da estrutura
analítica de projeto é chamado de
______________________________.
A estrutura gráfica subdivide o projeto em porções menores, chamadas itens de tra-

balho. Nem todas as ramificações da EAP precisam ser desmembradas no mesmo nível.
FIGURA 5.1 Estrutura Analítica de Projeto para Festival
Level 0
Festival
Lynn
Level 1
1 2 3 4
Promoção Lista de Jogos Brinquedos

Voluntários
Lynn Beth Steve Pat
Level 2
1.1 1.2 1.3 3.1 3.2 3.3 4.1 4.2

Anúncios Fornecedor
Cartazes Ingressos Quiosques Jogos Prêmios de Autorizações
de Jornal Divertimentos
Lynn Keith Andrea Jim Steve Jeff Pat Neil
Level 3
O item no nível mais baixo de qualquer ramificação é chamado pacote de trabalho. A maio-
ria dos pacotes de trabalho exibidos na Figura 5.1 está no segundo nível, mas quatro itens
de trabalho são ainda divididos em um terceiro nível, mais detalhado; um item de trabalho
(Lista de Voluntários) não é desmembrado além do primeiro nível. Normalmente, a EAP
indica a organização ou a pessoa responsável de cada item de trabalho.
5 6 7
Entretenimento Alimentação Serviços
Jeff Bill Jack
5.1 5.2 6.1 6.2 7.1 7.2 7.3 7.4

Arquibancada Alimentação Instalações Estacionamento Limpeza Instalações
Artistas Segurança
Principal de Sanitários
Jeff Jim Bill Chris Steve Tyler Jack Rose
5.2.1 5.2.2 5.2.3 7.2.1 7.2.2 7.3.1 7.3.2

Posto de
Som e Contêineres Sanitários Primeiros
Palco Assentos Fornecedor
Iluminação Socorros
Jim Joe Jim Tyler Damian Jack Beth
6.2.1 6.2.2 6.2.3

Quiosques de Equipamento Áreas de
Alimentação de Cozinha Alimentação
Chris Bill Jim
Os critérios para se decidir o grau de detalhamento e quantos níveis devem ser colo-
cados na EAP são: (1) o nível no qual uma pessoa ou organização pode ser considerada
responsável pela realização do item de trabalho e (2) o nível no qual você deseja controlar
o orçamento e monitorar, bem como coletar dados de custos durante o projeto. Não há
uma EAP específica correta para qualquer projeto. Por exemplo, duas equipes de projeto
distintas podem desenvolver EAPs bastante diferentes para o mesmo projeto.
MATRIZ DE RESPONSABILIDADES
A matriz de responsabilidades é um método utilizado para exibir, na forma de tabelas,
as pessoas responsáveis pela realização dos itens de trabalho na EAP. É uma ferramenta útil,
já que enfatiza quem é responsável em cada item de trabalho e mostra o papel de cada
pessoa na realização do projeto global. A Figura 5.2 demonstra a matriz de responsabilida-
des associada à EAP na Figura 5.1 para o projeto do festival.

5. Uma matriz de responsabilidades
mostra qual pessoa é responsável por
realizar cada ________ na estrutura
analítica do projeto.
Algumas matrizes de responsabilidades usam um X para mostrar quem é responsável

pelos itens de trabalho; outras utilizam um P para designar responsabilidade principal e um S
para indicar responsabilidade de suporte para um item de trabalho específico. Por exemplo,
a Figura 5.2 indica que Jim tem a responsabilidade principal pelos quiosques de jogos,
enquanto Chris e Joe oferecem suporte a esse trabalho. É uma boa idéia designar apenas
uma pessoa como líder ou uma pessoa com a responsabilidade principal para cada item
de trabalho. A designação de duas pessoas como líderes conjuntas aumenta o risco de que
determinado trabalho fique “órfão”, já que cada uma assume que a outra irá fazê-lo.
DEFININDO ATIVIDADES
Conforme observado anteriormente, uma lista de atividades específicas e detalhadas para a
realização do projeto global pode ser gerada por meio de brainstorming da equipe, prin-
cipalmente no caso de projetos pequenos. Contudo, para projetos nos quais não se utiliza
uma estrutura analítica de projeto, atividades individuais podem ser definidas pela pessoa
ou equipe responsável de cada pacote de trabalho. Atividade é uma porção definida de tra-
balho que consome tempo, mas que não necessariamente exige o esforço de pessoas – por
exemplo, esperar que o concreto endureça pode levar vários dias, porém não exige ne-
nhum trabalho humano.
Para o pacote de trabalho 3.1 na Figura 5.1, quiosques de jogos, as oito atividades deta-
lhadas a seguir podem ser identificadas:
• Projetar quiosques;
• Especificar materiais;
• Comprar materiais;
• Construir quiosques;
• Pintar quiosques;
• Desmontar quiosques;
• Mover quiosques para o local do festival e remontá-los;
• Desmontar quiosques e transportar para depósito.
Quando todas as atividades detalhadas forem identificadas para cada um dos pacotes
de trabalho, a próxima etapa é exibi-las graficamente em um diagrama de rede que mostre
a seqüência apropriada e as inter-relações necessárias para se realizar todo o escopo do
projeto.
FIGURA 5.2 Matriz de Responsabilidades para Projeto de Festival
Damian
Andrea
Steve
Item da
Keith
Chris
Lynn
Tyler
Rose
Beth
Jack
Neil
Jeff
Jim
Joe
Pat
Bill
EAP Item de Trabalho
Festival S S S S P S S
1 Promoção S S P
1.1 Anúncios de jornal P
1.2 Cartazes P
1.3 Ingressos P S S
2 Lista de Voluntários P S S
3 Jogos S S P
3.1 Quiosques S P S
3.2 Jogos S P
3.3 Prêmios P S
4 Passeios S P
4.1 Fornec. de divertimentos P
4.2 Autorizações P S
5 Entretenimento P S S
5.1 Artistas S P
5.2 Arquibancada principal P S
5.2.1 Palco P S
5.2.2 Som e iluminação P
5.2.3 Assentos S P
6 Alimentação P S
6.1 Alimentação P S
6.2 Instalações S P S
6.2.1 Quiosques de alimentação P S S
6.2.2 Equipamento de cozinha P
6.2.3 Áreas de alimentação P S
7 Serviços P S S S
7.1 Estacionamento P
7.2 Limpeza S P
7.2.1 Contêineres P
7.2.2 Fornecedor P
7.3 Instalações p/ sanitários S P
7.3.1 Sanitários P
7.3.2 Primeiros socorros P
7.4 Segurança S S P
Legenda: P = Responsabilidade Principal; S = Responsabilidade de Suporte.
Companhia Aérea Alemã
A companhia aérea alemã Lufthansa foi a primeira a oferecer serviço de Internet de alta ve-
locidade durante os vôos. Como pioneira na implementação dessa nova tecnologia, a em-
presa desenvolveu um plano para testar o novo sistema. A FlyNet foi testada pela primeira
vez no dia 15 de janeiro de 2003, em um vôo sem escalas de Frankfurt, na Alemanha, para
Washington, nos Estados Unidos. Esse foi o início de um período de testes de três meses.
O novo serviço de Internet de banda larga permitirá que executivos leiam seus e-mails,
acessem a Intranet de suas empresas e procurem informações na Web enquanto viajam.
O sistema de acesso on-line móvel de alta velocidade para o “escritório voador” foi
construído pela Connexion, subsidiária da Boeing. A Lufthansa decidiu oferecer esse servi-
ço em resposta à necessidade dos clientes apontadas em pesquisas com usuários. A poltro-
na é equipada com uma saída para laptop. Antenas de rede sem fio ficam ocultas no painel
acima da poltrona e são usadas para transmitir e receber sinais de satélites disponíveis em
toda a extensão dos Estados Unidos e na região do Atlântico Norte. O sistema atinge veloci-
dades de transmissão de dados semelhantes às obtidas pela tecnologia RDSI. O sistema de
banda larga não beneficiará apenas os clientes, mas também os pilotos da Lufthansa, que
poderão utilizá-lo para obter previsões do tempo mais precisas. Além disso, eles podem se
informar melhor para evitar turbulências ou congestionamento no espaço aéreo.
A Lufthansa está fazendo um grande investimento nessa nova tecnologia. Os custos
de desenvolvimento, instalação e manutenção estão na casa de dezenas de milhões de dó-
lares. Somente os custos de instalação são de cerca de US$ 400 mil por avião com predis-
posição para a Internet. Testar o sistema é essencial. A Lufthansa convidou empresas como
Siemens, BASF, Software AG e Boehringer Ingelheim para participar de suas demonstra-
ções. A companhia aérea testou o acesso à Intranet de cada empresa e aos servidores de
e-mail por meio de uma Rede Privada Virtual, disponibilizada pelo sistema de banda larga
sem fio da Connexion. Os assistentes da FlyNet ficaram disponíveis a bordo para oferecer
atendimento aos clientes.
Aparentemente, a fase de testes teve bons resultados. A Lufthansa revelou recente-
mente seus planos de modificar toda a sua frota de longa distância para que ofereça servi-
ço de Internet em alta velocidade. A instalação foi programada para começar em janeiro de
2004. O programa FlyNet deve estar disponível nos vôos transatlânticos programados pela
Lufthansa até a primavera de 2004.
Hess, A. Truly Wireless: Lufthansa Launched Broadband Internet on Board, www.ppcw.net, 20 de janeiro de 2003.
Merritt, R. Boieng Preps Jets for Broadband. CMP Media, 14 de fevereiro de 2003.
DESENVOLVENDO O PLANEJAMENTO DE REDES DE ATIVIDADES

O planejamento de redes é uma técnica útil no planejamento, na programação e no controle
de projetos compostos de várias atividades inter-relacionadas.
Duas técnicas de planejamento de redes, a técnica de avaliação e análise de progra-
mas (PERT) e o método do caminho crítico (CPM), foram desenvolvidas na década de
1950. Desde então, foram aperfeiçoadas outras formas de planejamento de redes, como o
método de diagrama de precedência (PDM) e a técnica de avaliação e análise gráfica
(GERT). Todas se encaixam na mesma categoria geral de técnicas de planejamento de re-
des, já que utilizam um diagrama de rede para mostrar o fluxo seqüencial e as inter-relações
entre as atividades.
Antigamente, havia diferenças metodológicas distinguíveis entre PERT e CPM. Hoje em
dia, contudo, quando a maioria das pessoas se refere a um diagrama CPM ou um gráfico
PERT, querem dizer genericamente que se trata de um diagrama de rede. Veja nas Figuras
5.8 e 5.9 (discutidas mais à frente neste capítulo) exemplos de diagramas de rede de um
projeto para a condução de estudo de mercado consumidor. A Figura 5.14 é um exemplo

de projeto para o desenvolvimento de um sistema de relatórios pela Internet.
Técnicas de planejamento de rede costumam ser comparadas a uma ferramenta um pou-
co mais familiar conhecida como gráfico de Gantt (às vezes, chamado de gráfico de bar-
ras). Trata-se de uma ferramenta mais antiga de planejamento e programação, desenvolvida
no início da década de 1990; contudo, continua sendo bastante popular, principalmente em
função de sua simplicidade.
O gráfico de Gantt combina as duas funções, de planejamento e de programação. A
Figura 5.3 mostra um gráfico de Gantt para um estudo de mercado consumidor. As ativida-
des são relacionadas à esquerda e uma escala de tempo é exibida em toda a parte inferior.
A duração estimada para cada atividade é indicada por uma linha ou barra que se estende
pelo período no qual se espera que seja concluída. As colunas que indicam quem é respon-
sável pelas tarefas podem ser adicionadas ao gráfico.
Com gráficos de Gantt, a programação das atividades ocorre simultaneamente com seu
planejamento. A pessoa que for desenhar as linhas ou barras de atividades deve estar ciente
das inter-relações entre elas – isto é, quais atividades devem ser concluídas antes que ou-
tras sejam iniciadas, e quais atividades podem ser conduzidas simultaneamente. Uma das
maiores desvantagens do tradicional gráfico de Gantt é que não exibe graficamente as inter-
relações entre as atividades. Portanto, não fica evidente quais delas serão afetadas quando
determinada atividade se atrasa. Contudo, a maioria dos pacotes de softwares de gestão de
projetos é capaz de produzir gráficos de Gantt que exibem as interdependências entre as
tarefas usando setas de conexão.
Como o planejamento e a programação são feitos de forma simultânea em um gráfico de
Gantt tradicional, é trabalhoso realizar mudanças ao plano manualmente. Isso vale princi-
palmente se uma atividade, no início do projeto, se atrasar e, conseqüentemente, várias das
linhas ou barras restantes precisarem ser redesenhadas. As técnicas de rede, de outro lado,
FIGURA 5.3 Gráfico de Gantt para Projeto de Estudo de Mercado Consumidor

Atividade Responsável 0 10 20 30 40 50 60 70 80 90 100 110 120 130 140
Identificar Consumidores-Alvo Susan
Esboçar Questionário Susan
Questionário Teste Piloto Susan
Concluir Questionário Susan
Imprimir Questionário Steve

Preparar Etiquetas
Steve
para Mala Direta
Enviar Questionário
Steve
Coletar Respostas
Desenvolver Software Andy
de Análise de Dados
Desenvolver Dados para Susan
Teste de Software
Testar Software Andy
Inserir Dados de Resposta Jim
Analisar Resultados Jim
Preparar Relatório Jim
0 10 20 30 40 50 60 70 80 90 100 110 120 130 140

Dias
separam as funções de planejamento e programação. Um diagrama de rede é o resultado,

ou produto, da função de planejamento, e não é desenhado em uma escala de tempo.
A partir desse diagrama, desenvolve-se um cronograma (esse tópico será estudado em
detalhes no próximo capítulo). A separação das duas funções facilita muito a revisão de um
plano e o cálculo de um cronograma atualizado.
Princípios de Redes de Atividades

Existem alguns princípios básicos que devem ser compreendidos e seguidos na prepara-
ção de um diagrama de rede. Também existem diferentes formatos que podem ser usados
no desenho do diagrama. Um deles é o diagrama de atividades (DA), também conhecido
como diagrama de nós (DN). O outro é o diagrama de setas (DS).

6. Identifique dois formatos para a
elaboração de um diagrama de rede.
DIAGRAMA DE ATIVIDADES (DA)

No formato DA, cada atividade é representada por uma caixa da rede e sua descrição é
escrita dentro da caixa da seguinte forma:
Conseguir
Voluntários
As atividades consomem tempo, e sua descrição normalmente começa com um verbo.

Cada atividade é representada por uma, e apenas uma caixa. Além disso, cada caixa recebe
um número de atividade exclusivo. No exemplo acima, a atividade “Conseguir Voluntários”
recebeu o número de atividade 7.

7. As atividades são relacionadas em
uma ordem de __________, para mostrar
quais atividades devem ser ___________
antes que outras possam ___________.
As atividades têm uma relação de precedência – isto é, estão relacionadas em uma

ordem de precedência para mostrar quais atividades devem ser concluídas antes que outras
possam começar. As setas que ligam as caixas de atividades mostram a direção da prece-
dência. Uma atividade não pode começar antes que todas as atividades precedentes ligadas
a ela por setas tenham sido concluídas.
Certas atividades precisam ser realizadas em ordem seqüencial. Por exemplo, conforme
apresentado a seguir, somente depois que “Lavar Carro” for concluída, “Secar Carro” pode
começar.
Lavar Secar
Carro Carro
3 4
Algumas atividades podem ser conduzidas simultaneamente. Por exemplo, conforme

mostrado a seguir, “Conseguir Voluntários” e “Comprar Materiais” podem ser feitas simul-
taneamente. Ou quando as duas tiverem sido concluídas, “Construir Quiosque” pode co-
meçar. De forma semelhante, quando “Pintar Quiosque” for concluída, tanto “Desmontar
Quiosque” quanto “Limpar” podem começar a ser executadas simultaneamente.
Conseguir Desmontar
Voluntários Quiosque
7 11
Construir Pintar
Quiosque Quiosque
9 10
Comprar Limpar
Materiais
8 12
DIAGRAMA DE SETAS (DS)

No formato DS, uma atividade é representada por uma seta da rede, e sua descrição é es-
crita acima da seta, da seguinte forma:
Coletar Dados
Cada atividade é representada por uma, e apenas uma, seta. A parte final da seta designa o
começo da atividade e sua ponta representa a conclusão da atividade. O comprimento e a
curvatura da seta não indicam, de forma alguma, a duração da atividade ou sua importância
(ao contrário do que ocorre no gráfico de Gantt, no qual o comprimento da linha ou barra
indica a duração da atividade).

8. No formato de diagrama de setas
para a elaboração de um diagrama
de rede, as atividades são ligadas por
círculos chamados _____________.
No formato DS, as atividades são ligadas por círculos chamados eventos. Um evento
representa a conclusão das atividades que entram nele e o início das atividades que saem
dele. No formato DS, cada evento – e não cada atividade – recebe um número exclusivo.
Por exemplo, as atividades mostradas a seguir, “Lavar Carro” e “Secar Carro”, têm uma re-
lação seqüencial e são ligadas pelo evento 2. O evento 2 representa a conclusão de “Lavar
Carro” e o início de “Secar Carro”.
Lavar Carro Secar Carro

1 2 3
O evento no começo (parte final da seta) da atividade é conhecido como evento ante-
cessor, e o evento no final (ponta da seta) da atividade é conhecido como evento suces-
sor. Para a atividade “Lavar Carro”, o evento antecessor é 1, e o evento sucessor é 2; para
a atividade “Secar Carro”, o evento antecessor é 2, e o evento sucessor é 3.
Todas as atividades indo em direção a um evento (círculo) devem ser concluídas antes
que quaisquer atividades partindo daquele evento possam ser iniciadas. Por exemplo, con-
forme apresentado a seguir, as atividades “Conseguir Voluntários” e “Comprar Materiais”
podem ser realizadas simultaneamente, mas só quando as duas estiverem concluídas é que
a atividade “Construir Quiosque” pode começar. Da mesma forma, quando “Pintar Quios-
que” estiver concluída, tanto “Desmontar Quiosque” quanto “Limpar” podem ser iniciadas
e realizadas simultaneamente.
Conseguir Desmontar
Voluntários Quiosque
6 Construir Pintar 11
Quiosque Quiosque
8 9 10
7 12
Comprar Limpar
Materiais
ATIVIDADES FICTÍCIAS
No formato de diagrama de setas, há um tipo especial de atividade, conhecido como ativi-
dade fictícia (ou atividade fantasma), que tem duração nula e é representada por uma
seta pontilhada no diagrama de rede. As atividades fictícias, usadas somente no formato do
diagrama de setas, são necessárias por duas razões: para ajudar na identificação única de ati-
vidades e mostrar certas relações de precedência que, do contrário, não seriam mostradas.
Ao desenhar-se um diagrama de rede no formato de setas, existem duas regras básicas
referentes à identificação única de atividades:
1. Cada evento (círculo) no diagrama de rede deve ter um número de evento exclusivo,
isto é, dois eventos nunca podem ter o mesmo número no diagrama de rede.
2. Cada atividade deve ter uma combinação exclusiva de números de eventos anteces-
sores e sucessores.
As atividades A e B a seguir têm a combinação de número de evento antecessor-sucessor
1-2. Isso não é permitido em um diagrama de setas, porque, se alguém se referisse à ativi-
dade 1-2, não seria possível saber se estava se referindo à atividade A ou à atividade B.
1 2
B
Quando o utilizamos para calcular um cronograma de projeto com base no diagrama de

setas, um software provavelmente exigirá que cada atividade seja identificada por uma
combinação única de números de eventos antecessores-sucessores.
A inserção de uma atividade fictícia, conforme mostrado a seguir, permite que as ativi-
dades A e B tenham uma combinação única de números de eventos antecessores-sucesso-
res. Em (a), a atividade A é chamada 1-3, e a atividade B, 1-2. Da mesma forma, em (b), a
atividade A é chamada 1-2, e a atividade B é 1-3. As duas formas são aceitáveis para essa
situação.
A A
1 3 1 2 3
B B
2
(a) (b)
Consideremos o exemplo de um caso no qual uma atividade fictícia deve ser usada para
mostrar uma relação de precedência que, do contrário, não seria mostrada. A situação é a
seguinte:
• As atividades A e B podem ser realizadas simultaneamente.
• Quando a atividade A é concluída, a atividade C pode começar.
• Quando tanto a atividade A quanto a atividade B estiverem concluídas, a atividade D
pode começar.
Para ilustrar esse exemplo, devemos usar uma atividade fictícia, conforme mostrado a
seguir.
A C
1 3 5
B D
2 4 6
A atividade fictícia 3-4, de certa forma, estende a atividade A para mostrar que, além de
ser necessária para começar a atividade C, seu término também é necessário (juntamente
com o término da atividade B), a fim de iniciar a atividade D.

9. Atividades fictícias são usadas apenas
quando o formato de _________ é usado
na elaboração de um diagrama de rede.
Atividades fictícias são mostradas por
meio de uma ___________.
O formato mostrado a seguir é incorreto, já que indica que as atividades A e B devem

ser concluídas para que as atividades C e D possam começar, quando, na verdade, apenas
a atividade A (e não A e B) deve ser concluída para que a atividade C possa ter início.
A C
1 4
3
B D
2 5
Uma vantagem do formato de diagrama de atividades é que a lógica pode ser ilustrada
sem o uso de atividades fictícias. Por exemplo, a seguir, temos o formato de diagrama de
atividades para a relação apresentada acima; nenhuma atividade fictícia é necessária.
A C
1 3
B D
2 4
LOOPS
A seguir, nos formatos de diagrama de atividades e de setas, temos uma relação ilógica
entre atividades conhecida como loop. Ao prepararmos um diagrama de rede, o desenho
das atividades em loop não é permitido, pois isso ilustraria um caminho de atividades que
se repetiria indefinidamente.
B A
A 1 2
1 2
C C B
3
3
LADDERING
Alguns projetos têm um conjunto de atividades que se repetem várias vezes. Por exemplo,
considere um projeto envolvendo a pintura de três quartos. A pintura de cada quarto exige:
(1) a preparação do quarto para receber a pintura; (2) a pintura das paredes e do teto, e (3) a
pintura do rodapé. Suponha que três profissionais estarão disponíveis – um para preparar o
cômodo, um outro para pintar as paredes e o teto e um terceiro para fazer o rodapé.
Pode parecer lógico desenhar um diagrama de rede para o projeto, conforme mostrado
na Figura 5.4 ou 5.5. Contudo, a Figura 5.4 indica que todas as atividades devem ser con-
duzidas em ordem seqüencial, o que significa que, em determinado momento, apenas uma
pessoa estará trabalhando, enquanto as outras duas estão esperando. Por outro lado, a Fi-
gura 5.5 indica que os três quartos podem ser feitos simultaneamente, o que não é possível,
já que só existe um profissional disponível para cada tipo de atividade.
A Figura 5.6 mostra uma técnica conhecida como laddering, que pode ser usada para
fazer o diagrama desse projeto. Ela indica que depois de terminar um quarto, cada profis-
sional pode começar a trabalhar no próximo. Essa abordagem permitirá que o projeto seja
concluído no menor tempo possível, além de os profissionais tirarem o máximo de proveito
dos recursos disponíveis.
FIGURA 5.4 Atividades Realizadas em Série
Preparar Pintar Pintar Preparar Pintar Pintar Preparar Pintar Pintar

Quarto 1 Quarto 1 Quarto 1 Quarto 2 Quarto 2 Quarto 2 Quarto 3 Quarto 3 Quarto 3
1 2 3 4 5 6 7 8 9
(a) Formato de Diagramas de Atividades
Preparar Pintar Pintar Preparar Pintar Pintar Preparar Pintar Pintar

Quarto 1 Quarto 1 Quarto 1 Quarto 2 Quarto 2 Quarto 2 Quarto 3 Quarto 3 Quarto 3
1 2 3 4 5 6 7 8 9 10
(b) Formato de Diagramas de Setas
FIGURA 5.5 Atividades Realizadas Simultaneamente
Preparar Pintar Pintar

Quarto 1 Quarto 1 Rodapé 1
1 4 7
Iniciar Preparar Pintar Pintar

Quarto 2 Quarto 2 Concluir
Rodapé 2 o Projeto
Projeto
2 5 8

3 6 9
(a) Formato de Diagrama de Atividade

2 5

1 3 6 8

4 7
(b) Formato de Diagrama de Setas
FIGURA 5.6 Laddering

1 2 4

3 5 7

6 8 9
(a) Formato de Diagrama de Atividades

1 2 3

4 5 6 7
Pintar
Preparar Pintar Rodapé 3
Quarto 3 Quarto 3
8 9 10
(b) Formato de Diagrama de Setas
Preparando o Diagrama de Rede

Tendo em mão uma lista de atividades e conhecimento sobre os princípios de redes de
atividades, é possível preparar um diagrama de rede. Primeiro, selecione o formato a ser
usado – diagrama de atividades ou diagrama de setas. Em seguida, comece a desenhar as
atividades em sua ordem de precedência lógica, já que o projeto deve progredir do início
até o fim. Após decidir em qual seqüência as atividades devem ser desenhadas para mostrar
sua inter-relação de precedência lógica, você deve refletir sobre as três perguntas a seguir,
em relação a cada atividade individual:
1. Quais atividades devem ser concluídas imediatamente antes de a atividade ser

iniciada?
2. Quais atividades podem ser feitas simultaneamente a essa atividade?
3. Quais atividades não podem ser iniciadas até que essa atividade seja concluída?
Respondendo às perguntas para cada atividade, você conseguirá desenhar um diagrama

de rede que ilustre as inter-relações e a seqüência de atividades necessárias à realização de
todo o escopo de trabalho do projeto.
Todo o diagrama de rede deve fluir da esquerda para a direita, embora algumas setas
venham da direita para a esquerda, para evitar que o diagrama global fique demasiadamente
extenso. Diferentemente do gráfico de Gantt, o diagrama de rede não é desenhado sobre
uma escala de tempo. É mais fácil visualizar o projeto inteiro se o diagrama de rede puder
ser desenhado para caber inteiro em uma folha grande de papel. Contudo, se a rede for
muito grande, talvez sejam necessárias várias páginas. Nesses casos, pode ser necessário
criar um sistema de referência ou um conjunto de símbolos que mostre as relações entre as
atividades nas diferentes páginas.
Ao começar a desenhar o diagrama de rede para um projeto, não se preocupe demais
com a aparência dele no início. É melhor fazer um esboço mais grosseiro do diagrama com
a certeza de que as relações lógicas entre as atividades estão corretas. Depois, pegue o dia-
grama novamente e desenhe-o com uma aparência mais arrumada (ou gere o diagrama no
computador, caso esteja usando o software de gestão de projetos).
As diretrizes a seguir devem ser levadas em consideração ao se decidir o nível de deta-
lhamento (em termos de número de atividades) do diagrama de rede para determinado
projeto:
1. Se uma estrutura analítica de projeto foi preparada para ele, as atividades devem ser
identificadas para cada pacote de trabalho. Por exemplo, a Figura 5.7 mostra uma
EAP para um projeto que envolve um estudo de mercado consumidor e as atividades
que foram identificadas para cada pacote de trabalho.
2. Pode ser preferível desenhar um diagrama de rede em nível resumido e depois
expandi-lo em uma rede mais detalhada. Uma rede resumida contém um pequeno
número de atividades de nível mais elevado, em vez de um grande número de ativi-
dades detalhadas. Em alguns casos, uma rede resumida pode ser suficiente para ser
usada durante todo o projeto.
3. O nível de detalhamento pode ser determinado por certas interfaces ou pontos de
transferências óbvios:
• Se houver mudança de responsabilidade – isto é, se uma pessoa ou organização
diferente assumir a responsabilidade pela continuação do trabalho –, deve-se de-
finir o final de uma atividade e o início das demais. Por exemplo, se uma pessoa
é responsável por fabricar um produto e outra é responsável por embalá-lo, estas
devem ser duas atividades separadas.
• Se houver um produto tangível como resultado de uma atividade, deve-se definir
o final de uma atividade e o início das outras atividades. Alguns exemplos de pro-
FIGURA 5.7 Estrutura Analítica para Projeto de Estudo de Mercado Consumidor
Estudo de
Mercado
Consumidor
Jim
1.0 2.0
Questionário Relatório
Susan Jim
1.1 1.2 2.1 2.2

Concepção Respostas Software Relatório
Susan Steve Andy Jim
• Identificar • Imprimir • Desenvolver • Inserir dados

Consumidores-Alvo Questionário Software de Respostas
• Esboçar • Preparar Etiquetas • Testar • Analisar Resultados
Questionário para Mala Direta
Software • Preparar
• Questionário • Enviar Questionário Relatório
Teste Piloto e Receber Respostas
• Concluir
Questionário
• Desenvolver
Dados para Teste
dutos tangíveis incluem relatórios, desenhos, o despacho de um equipamento e a

concepção de um software. No caso de um folheto, a produção do esboço deve
ser definida como o final de uma atividade; outra atividade como, talvez, “Aprovar
Esboço de Folheto”, viria em seguida.
4. As atividades não devem ter uma duração estimada superior aos intervalos de tempo
nos quais o progresso real do projeto será analisado e comparado ao progresso pla-
nejado. Por exemplo, se for um projeto de três anos e a equipe de projeto planejar
analisar seu progresso mensalmente, a rede não deve conter nenhuma atividade com
duração estimada superior a 30 dias. Se houver aquelas com duração estimada maior,
devem ser desmembradas em atividades mais detalhadas, com duração de 30 dias ou
menos.
Qualquer que seja o nível de detalhamento usado no diagrama de rede inicial, algumas
atividades podem ser mais desmembradas à medida que o projeto caminha. É sempre mais fá-
cil identificar atividades que precisam ser realizadas no curto prazo (nas próximas semanas
ou meses) que identificar as que deverão ocorrer daqui a um ano. Não é raro se adicionar
mais detalhes a um diagrama de rede à medida que o projeto progride.
Em alguns casos, uma organização pode fazer projetos semelhantes para diferentes
clientes e determinadas partes deles podem incluir os mesmos tipos de atividades nas mes-
mas relações de precedência lógicas. Se esse for o caso, pode valer a pena desenvolver
sub-redes padrão para essas partes de projetos. Estas podem economizar esforço e tempo
quando um diagrama de rede é desenvolvido para um projeto global. Sub-redes padrão
FIGURA 5.8 Diagrama de Rede para Projeto de Estudo de Mercado Consumidor

(Formato de diagrama de atividades)
Preparar
Etiquetas para
Mala direta
5 Steve
Identificar Esboçar Questionário Revisar Comentários Imprimir

Consumidores- Questionário Teste Piloto Concluir Questionário Questionário
Alvo
1 Susan 2 Susan 3 Susan 4 Susan 6 Steve
Desenvolver
Software
de
Análise de Dados
7 Andy
Desenvolver
Dados para
Teste de Software
8 Susan
devem ser desenvolvidas para as partes de projetos nas quais as relações lógicas entre as
atividades foram bem estabelecidas pela prática. Elas podem ser, obviamente, modificadas
conforme a necessidade de um projeto específico.

10. Consulte a Figura 5.8.
a. Quando “Preparar Etiquetas para
Mala Direta” e “Imprimir Questionário”
forem concluídas, qual atividade pode
ser iniciada?
b. Para começar “Inserir Dados de
Respostas”, quais atividades devem ser
concluídas imediatamente antes?
Por fim, depois que todo o diagrama de rede tiver sido desenhado, é necessário atribuir
um número exclusivo de atividade para cada atividade (caixa), se estiver usando o formato
de diagrama de atividades, ou para cada evento (círculo), se estiver usando o formato de
diagrama de setas.
Enviar Questionário Inserir Dados Analisar Preparar

e de Respostas Resultados Relatório
Receber Respostas
9 Steve 11 Jim 12 Jim 13 Jim
Testar
Software
10 Andy
Legenda
Descrição
da
Atividade
Número
da
Atividade
Responsável

a. Para começar “Testar Software”,
quais atividades devem ser concluídas
imediatamente antes?
b. Verdadeiro ou falso: depois que
“Imprimir Questionário” estiver
concluída, “Enviar Questionário e
Receber Respostas” pode começar
imediatamente.
As Figuras 5.8 e 5.9 mostram diagramas de rede completos para o projeto de estudo de
mercado consumidor nos formatos de diagrama de atividades ou de setas, respectivamente.
Observe a adição da pessoa responsável nesses diagramas.
Escolher entre o formato de diagrama de atividades ou de setas é uma questão de prefe-
rência pessoal. Os dois formatos utilizam uma rede baseada em relações de precedência. A
rede é uma espécie de mapa que mostra todas as atividades inter-relacionadas para a exe-
cução do escopo do projeto. Também é uma ferramenta de comunicação para a equipe de
projeto, já que indica quem é responsável pelas atividades e como o trabalho dessa pessoa
se encaixa no projeto global.
FIGURA 5.9 Diagrama de Rede para Projeto de Estudo de Mercado Consumidor

(Formato de diagrama de setas)
Preparar
Etiquetas para
Mala Direta
Steve
Revisar
Identificar Comentários
Esboçar Questionário Concluir
Consumidores- Questionário Teste Piloto Imprimir
Alvo Questionário Questionário
1 2 3 4 5
Susan Susan Susan Susan Steve
Desenvolver Software
Andy
Desenvolver
Dados para Teste
de Software
Susan
PLANEJAMENTO PARA DESENVOLVIMENTO DE

SISTEMAS DE INFORMAÇÃO
Em função do número rapidamente crescente de projetos relacionados à tecnologia de
informação, pareceu-nos uma boa idéia incluirmos uma seção em cada um dos próximos
capítulos para práticas de gestão de projetos no desenvolvimento de sistemas de informa-
ção. Um sistema de informação (SI) é um sistema informatizado que aceita a inserção de
dados, processa-os e gera informações úteis para os usuários. Estes incluem sistemas com-
putadorizados de registro de pedidos, sistemas de comércio eletrônico, caixas eletrônicos
e sistemas de faturamento, folha de pagamento e estoque. O desenvolvimento de um SI é
um processo desafiador que exige bastante planejamento e controle a fim de garantir que
o sistema atenda às necessidades do usuário e seja concluído dentro do prazo e de acordo
com o orçamento.
Uma ferramenta, ou metodologia, de planejamento de gestão de projetos, chamada
de ciclo de vida de desenvolvimento de sistemas (CVDS), normalmente é usada para
ajudar a planejar, executar e controlar projetos de desenvolvimento de SI. O CVDS é com-
posto de um conjunto de fases ou etapas que precisam ser concluídas no decorrer de um
Enviar Questionário
e Inserir Dados Analisar Preparar
Receber Respostas de Respostas Resultados Relatório
7 10 11 12 13
40
Steve Jim Jim Jim
Testar
Software
9
Andy
Legenda
Descrição
da
Atividade
Responsável
8 Número da
Atividade
Número da
Atividade
projeto de desenvolvimento. Muitas pessoas consideram o CVDS como um método clássico

para a resolução de problemas. Ele consiste nas seguintes etapas:
1. Definição do problema. Dados são coletados e analisados enquanto os problemas e
as oportunidades são claramente definidos. Fatores técnicos, econômicos, operacio-
nais e outros são definidos e estudados para determinar, pelo menos inicialmente, se
o SI pode ser desenvolvido e usado com sucesso.
2. Análise do sistema. A equipe de desenvolvimento define o escopo do sistema a ser
desenvolvido, entrevista usuários em potencial, estuda o sistema existente (que pode
ser manual) e define os requisitos de usuário.
3. Concepção do sistema. Vários projetos conceituais alternativos são produzidos, des-
crevendo entrada (input), processamento, saída (output), hardware, software e a base
de dados em um nível mais alto. Cada uma dessas alternativas é avaliada; a melhor é
selecionada para ser concebida e desenvolvida em mais detalhes.
4. Desenvolvimento do sistema. O sistema real é criado. Compra-se o hardware enquanto o
software é comprado, customizado ou desenvolvido. Bases de dados, telas de entra-
da, relatórios de sistema, redes de telecomunicações, controles de segurança e outros
recursos também são desenvolvidos.
FIGURA 5.10 Estrutura Analítica de Projeto para Projeto de Sistema de Relatórios pela Internet
Nível 0 Sistema de Relatórios

pela Internet
Beth
Nível 1 1 2 3
Deﬁnição Concepção
do Análise do do
Problema Sistema Problema
Beth Jim Tyler
Nível 2
1.1 1.2 1.3 3.1 3.2 3.3 3.4
Estudar Preparar Entrada e Processamento Preparar
Reunir e Base Avaliação
Dados Possibilidade Relatório Saída Relatório
de Dados
Beth Jack Rose Tyler Joe Cathy Sharon
2.1 2.2 2.3 2.4

Entrevista dos Estudar Deﬁnir
Sistema Solicitações Preparar
Usuários Relatório
Existente de Usuários
Jim Steve Jeff Jim
Nível 3
3.1.1 3.1.2 3.1.3 3.1.4
Tela para Perguntas
Menus Entrada Relatórios
Periódicos Ad Hoc
de Dados
Tyler Tyler Steve Jeff
5. Testes do sistema. Depois que módulos individuais internos ao sistema forem desen-
volvidos, os testes podem começar. Estes envolvem a procura de erros lógicos, erros
em bases de dados, erros de omissão, erros de segurança e outros problemas que
podem impedir que o sistema seja bem-sucedido. Depois que os módulos individuais
são testados e os problemas corrigidos, todo o sistema é testado. Uma vez que os
usuários e desenvolvedores estejam convencidos de que está livre de erros, o sistema
será implementado.
6. Implementação do sistema. O sistema existente é substituído pelo novo, aprimorado,
e os usuários são treinados. Existem várias metodologias para a conversão do sistema
vigente em um novo sistema com o mínimo de interrupção para os usuários.
O CVDS termina com a implementação do sistema. O ciclo de vida do sistema em si
continua com uma revisão formal do processo de desenvolvimento depois que estiver im-
plementado e operando e, em seguida, com a manutenção, as modificações e as melhorias
do sistema.

Office Designs
Uma empresa denominada ABC Office Designs tem um grande número de representantes
de vendas que comercializam móveis de escritório para grandes empresas. Cada representante
4 5 6
Desenvolvimento Testes Implementação
do Sistema
Hannah Maggie Beth
5.1 5.2 5.3 5.4
Hardware Preparar
Software Rede Relatório
Maggie Gene Greg Rose
4.1 4.2 4.3 4.4 6.1 6.2 6.3

Preparar Conversão Preparar
Software Hardware Rede
Relatório Treinamento do Sistema Relatório
Hannah Joe Gerri Jack Jim Beth Jack
4.1.1 4.1.2
Pacote de Software
Software Personalizado
Hannah Maggie
de vendas fica responsável por um Estado específico e cada Estado faz parte de uma das qua-
tro regiões do país. Para permitir que os gerentes consigam monitorar o número e a quantidade
de vendas para cada representante, Estado e região, a ABC decidiu desenvolver um sistema de
informação baseado na Internet que rastreia preços, estoques e concorrentes.
O Departamento de SI da empresa nomeou Beth Smith como gestora de projeto para
o desenvolvimento do Sistema de Relatório pela Internet. Com a ajuda de sua equipe, ela
identificou as principais tarefas a ser realizadas e desenvolveu a estrutura analítica de pro-
jeto mostrada na Figura 5.10. Observe que a EAP segue o CVDS. No nível 1, as principais
tarefas são definição do problema, análise, concepção, desenvolvimento, testes e imple-
mentação. Cada uma dessas tarefas é posteriormente desmembrada em tarefas de nível 2,
enquanto algumas são desmembradas em tarefas de nível 3.
Depois que a equipe de projeto criou a EAP, a matriz de responsabilidades mostrada na
Figura 5.11 foi desenvolvida. Observe que essa tabela reflete todas as atividades mostradas
na EAP. Além disso, ela demonstra quem tem a responsabilidade principal e a responsabi-
lidade secundária por cada tarefa.
Após atribuir a responsabilidade de cada tarefa a membros da equipe, o gestor do pro-
jeto elabora um gráfico de Gantt com as principais tarefas a ser realizadas. O gráfico de
Gantt é mostrado na Figura 5.12. Observe que ele proporciona uma visualização clara das
atividades a ser conduzidas e do prazo no qual cada uma será realizada. O gestor do pro-
jeto reservou cinco dias para a definição do problema, dez dias para a análise do sistema,
FIGURA 5.11 Matriz de Responsabilidades para Projeto de Sistema de Relatórios pela

Internet
Hannah
Maggie
Sharon
Item
Cathy
Steve
Gene
Tyler
Gerri
Greg
Rose
Beth
da
Jack
Jeff
Joe
Jim
EAP Item de Trabalho
Sistema de Relatório pela Internet P S S S S
1 Definição do Problema P S S
1.1 Reunir Dados P S S
1.2 Estudar Viabilidade P S S S S
1.3 Preparar Relatório S P
2 Análise do Sistema P S S
2.1 Entrevistar Usuários P S S S
2.2 Estudar Sistema Existente P
2.3 Definir Solicitações dos Usuários P
2.4 Preparar Relatório P
3 Concepção do Sistema P S S S
3.1 Entrada e Saída S S P
3.1.1 Menus S P
3.1.2 Entrada de Dados S P
3.1.3 Relatórios Periódicos P S S
3.1.4 Perguntas Ad Hoc S P S
3.2 Processamento da Base de Dados P S S
3.3 Avaliação S S S P
3.4 Preparar Relatório P S
4 Desenvolvimento do Sistema S P S S
4.1 Software P S S S
4.1.1 Empacotamento P S S S
4.1.2 Personalizar Software S S P
4.2 Hardware S P
4.3 Rede P
4.4 Preparar Relatório P
5 Testes S P S S
5.1 Software S S P
5.2 Hardware S S P
5.3 Rede S S P
5.4 Preparar Relatório P S S S
6 Implementação P S S
6.1 Treinamento P S S
6.2 Conversão do Sistema P S S
6.3 Preparar Relatório S S P
LEGENDA: P = Responsabilidade Primária; S = Responsabilidade de Suporte.
FIGURA 5.12 Gráfico de Gantt para Projeto de Sistema de Relatório pela Internet
Atividade Responsável 0 5 10 15 20 25 30 35 40 45 50
Definição do Problema Beth
Análise do Sistema Jim
Concepção do Sistema Tyler
Desenvolvimento do Sistema Hannah
Testes Maggie
Implementação Beth
0 5 10 15 20 25 30 35 40 45 50
Semanas
FIGURA 5.13 Lista de Atividades e Antecessores Imediatos
Projeto de Sistema de Relatório pela Internet
Antecessores
Atividade Imediatos
1. Reunir Dados —
2. Estudar Possibilidade —
3. Preparar Relatório de Definição do Problema 1, 2
4. Entrevistar Usuários 3
5. Estudar Sistema Existente 3
6. Definir Solicitações dos Usuários 4
7. Preparar Relatório de Análise do Sistema 5, 6
8. Entrada e Saída 7
9. Processamento e Base de Dados 7
10. Avaliação 8, 9
11. Preparar Relatório de Concepção do Sistema 10
12. Desenvolvimento do Software 11
13. Desenvolvimento do Hardware 11
14. Desenvolvimento
v da Rede 11
15. Prep. Relatório de Desenvolv. do Sistema 12, 13, 14
16. Teste do Software 15
17. Teste do Hardware 15
18. Teste da Rede 15
19. Preparar Relatório de Testes 16, 17, 18
20. Treinamento 19
21. Conversão do Sistema 19
22. Preparar Relatório de Implementação 20, 21
FIGURA 5.14 Diagrama de Rede para Projeto de Sistema de Relatório pela Internet
(Formato de Diagrama de Atividades)
Projeto
começa
em 0
Reunir Entrevistar Definir Solicitações

Dados Usuários dos Usuários
1 Beth 4 Jim 6 Jeff

Preparar Relatório
de Definição Entrada
do Problema e
Saída
3 Rose
8 Tyler
Preparar Relatório
Estudar Estudar Sistema de Análise Avaliação
Viabilidade Existente do Sistema
2 Jack 5 Steve 7 Jim 10 Cathy

Processamento
e
Base de Dados
9 Joe
dez dias para a concepção do sistema, 15 dias para o desenvolvimento do sistema, oito
dias para testes do sistema e cinco dias para a implementação do sistema. Do modo que foi
apresentado, o projeto precisa ser concluído em 50 dias.
Após concluir o gráfico de Gantt, o gestor do projeto sentiu que era importante desen-
volver um diagrama de rede para mostrar as interdependências que existem entre as tarefas.
Contudo, antes de fazer isso, Beth e a equipe de projeto criaram uma lista com todas as
tarefas a ser feitas, com o antecessor imediato de cada uma relacionado à direita da tarefa,
conforme apresentado na Figura 5.13. Observe que, antes de começar “Preparar Relatório
de Definição do Problema”, tanto “Coletar Dados” quanto “Estudar Viabilidade” devem ser
concluídos. De forma semelhante, antes do início de “Preparar Relatório de Análise do Siste-
ma”, tanto “Estudar Sistema Existente” quanto “Determinar Exigências dos Usuários” devem
ser concluídas.
Com essa lista, Beth preparou o diagrama de rede usando o formato de diagrama de
atividades, conforme mostrado na Figura 5.14.
SOFTWARE DE GESTÃO DE PROJETOS

Há uma grande variedade de pacotes de software de gestão de projetos comercializados a
preços acessíveis. Esses softwares permitem ao gestor do projeto e à equipe de projeto pla-
nejarem e controlarem projetos de modo totalmente interativo. Veja o Apêndice A ao final
do livro para uma abordagem mais aprofundada dos softwares de gestão de projetos.
Os recursos comuns dos softwares de gestão de projetos permitem ao usuário:
• criar listas de tarefas com suas durações estimadas;
• estabelecer interdependências entre as tarefas;
• trabalhar com várias escalas de tempo, incluindo horas, dias, semanas, meses e
anos;
• lidar com certas limitações – por exemplo, uma tarefa não pode começar antes de
determinada data, uma tarefa deve ser iniciada até determinada data, sindicatos tra-
balhistas não permitem que mais de duas pessoas trabalhem nos fins de semana;
Desenvolvimento Teste
de do Software
Software
12 Hannah 16 Maggie
Treinamento
20 Jim
Preparar Relatório Desenvolvimento Preparar Relatório Preparar Preparar
Teste Relatório de
de Concepção do de Desenvolvimento Relatório
do Hardware Implementação
do Sistema Hardware do Sistema de Testes
11 Sharon 13 Joe 15 Jac k 17 Gene 19 Rose 22 Jack
Conversão
do Sistema
Desenvolvimento Teste 21 Beth

da Rede da Rede
14 Gerri 18 Greg
Legenda:
Descrição da
Atividade
Número da
Atividade
Responsável
• rastrear membros da equipe, incluindo valores de pagamento, horas trabalhadas até

aquele ponto do projeto e data das próximas férias;
• incorporar feriados, fins de semana e férias dos membros da equipe aos sistemas de
geração de calendários;
• gerenciar os turnos dos profissionais (dia, tarde, noite);
• monitorar e prever orçamentos;
• procurar conflitos – por exemplo, recursos superalocados e conflitos de tempo;
• gerar uma grande variedade de relatórios;
• fazer a interface com outros softwares, como processadores de planilhas e bases de
dados;
• classificar informações de várias formas – por exemplo, por projeto, membro da
equipe ou pacote de trabalho;
• gerenciar múltiplos projetos;
• trabalhar on-line e reagir rapidamente no caso de mudanças de cronograma, orça-
mento ou pessoal;
• comparar custos reais com custos orçados;
• exibir dados de várias formas, incluindo tanto gráficos de Gantt como diagramas de
rede.
Observação: Conforme mencionado anteriormente, a maioria dos softwares de gestão de
projetos é capaz de elaborar gráficos de Gantt que exibem as interdependências entre as
tarefas, conectando essas atividades e suas antecessoras por meio de setas. Os diagramas de
rede usados com mais freqüência pelos softwares de gestão de projetos têm o formato de
diagrama de atividades. O usuário pode alternar entre os gráficos de Gantt e os diagramas
de rede com um clique no mouse.
• É importante desenvolver um plano antes do início do projeto. Despender um de-

terminado tempo para desenvolver um plano bem concebido é fundamental para
a realização bem-sucedida do objetivo de qualquer projeto.
• A participação gera comprometimento. Ao participar do planejamento do trabalho,
as pessoas ficarão comprometidas com a sua realização de acordo com o plano.
• O objetivo do projeto precisa ser claro, atingível, específico e mensurável, devendo
ser acordado entre o cliente e a organização que irá realizá-lo.
RESUMO
Planejamento é a organização sistemática de tarefas para se atingir um objetivo. O plano
estipula o que precisa ser realizado e como será realizado. O plano torna-se uma referência
contra a qual o progresso real pode ser comparado; portanto, quando ocorrem desvios,
devem ser adotadas ações corretivas.
A primeira etapa no processo de planejamento é definir o objetivo do projeto – o resul-
tado ou produto final esperado. O objetivo do projeto costuma ser definido em termos de
escopo, cronograma e custo. Este deve ser claramente definido e acordado entre o cliente
e a organização ou fornecedor que vai conduzi-lo.
Uma vez definido o objetivo do projeto, o próximo passo é determinar quais elementos
de trabalho, ou atividades, precisam ser conduzidos para seu cumprimento. Isso requer a
elaboração de uma lista com todas as atividades.
A estrutura analítica de projeto (EAP) desmembra um projeto em porções, ou itens
gerenciáveis, para ajudar a garantir que todos os elementos de trabalho necessários à con-
clusão do escopo de trabalho do projeto sejam identificados. Trata-se de uma árvore hie-
rárquica de itens finais que serão atingidos ou produzidos pela equipe durante a execução
do projeto. Geralmente se indica a organização ou a pessoa responsável pelos itens de
trabalho.
Normalmente, uma matriz de responsabilidades é desenvolvida para exibir, na forma de
tabelas, as pessoas responsáveis pela realização dos itens de trabalho da EAP. É uma ferra-
menta útil, já que enfatiza quem é responsável em cada item de trabalho e mostra o papel
de cada pessoa na realização do projeto global.
Finalmente, o planejamento de redes é uma técnica útil no planejamento, na progra-
mação e no controle de projetos compostos de várias atividades inter-relacionadas. Além
disso, também é útil para a comunicação de informações sobre os projetos. Existem vários
formatos de diagrama de rede diferentes que podem ser usados; os dois mais populares são
o diagrama de atividades (DA) e o diagrama de setas (DS).
No formato de diagrama de atividades, cada uma delas é representada por uma caixa da
rede, e sua descrição é escrita dentro da caixa. No formato de diagrama de setas, cada ativi-
dade é representada por uma seta da rede, e sua descrição é escrita acima da seta.
Após a criação de uma lista de atividades, pode-se elaborar um diagrama de rede. Ao
decidir a seqüência na qual as atividades devem ser desenhadas, a fim de mostrar sua rela-
ção de precedência lógica umas com as outras, você deve determinar: (1) quais atividades
devem ser concluídas imediatamente antes que determinada atividade possa ser iniciada;
(2) quais atividades podem ser realizadas simultaneamente e (3) quais atividades não po-
dem ser iniciadas antes que as anteriores tenham sido concluídas.
O planejamento do projeto é uma atividade essencial no desenvolvimento de um sistema
de informação (SI). Uma ferramenta, ou metodologia, de planejamento de gestão de pro-
jetos, chamada de ciclo de vida de desenvolvimento de sistemas (CVDS), normalmente é

usada para ajudar a planejar, executar e controlar projetos de desenvolvimento de SI. O
CVDS é composto de um conjunto de fases ou etapas: definição do problema, análise do
sistema, concepção do sistema, desenvolvimento do sistema, teste do sistema e implemen-
tação do sistema. Todas essas etapas precisam ser concluídas no decorrer de um projeto de
desenvolvimento.
Existem vários pacotes de software de gestão de projetos para ajudar os gestores de
projetos a planejar, rastrear e controlar projetos de forma totalmente interativa.
PERGUNTAS
1. O que quer dizer planejar um projeto? O que isso envolve? Quem deve estar envolvido
no planejamento do trabalho?
2. O que significa o termo objetivo do projeto? O que pode acontecer se o objetivo de um
projeto não é claramente especificado? Dê três exemplos de objetivos de projeto clara-
mente especificados.
3. O que é uma estrutura analítica de projeto? O que é matriz de responsabilidades? Como
elas se relacionam?
4. O que é uma atividade? As atividades sempre exigem esforço humano? Consulte a Figu-
ra 5.1. Forneça uma lista detalhada de atividades necessárias para cumprir o pacote de
trabalho 3.3. Faça o mesmo para o pacote 4.2.
5. O que significam os termos evento antecessor e evento sucessor?
6. Consulte a Figura 5.9. Quais atividades devem ser concluídas antes do início de “Inserir
Dados de Respostas”? Quais atividades podem começar depois que “Revisar Comen-
tários e Concluir Questionário” é concluída? Relacione duas atividades que podem ser
feitas simultaneamente.
7. Em que casos devemos usar um diagrama de rede do tipo laddering? Dê um exemplo,
diferente do usado neste capítulo, e desenhe o diagrama de rede correspondente tan-
to no formato de diagrama de atividades como no diagrama de setas.
8. Por que recomendariam um software de gestão de projetos a alguém envolvido em
gestão de projetos? Que recursos e benefícios esse tipo de software oferece?
9. Desenhe um diagrama de rede representando a seguinte lógica: à medida que o pro-
jeto começa, as atividades A e B podem ser realizadas simultaneamente. Quando a
atividade A é concluída, as atividades C e D podem começar. Quando a atividade B é
concluída, as atividades E e F podem começar. Quando as atividades D e E são concluí-
das, a atividade G pode começar. O projeto é concluído quando as atividades C, F e G
são concluídas. Use tanto o formato de diagrama de atividades quanto o de diagrama
de setas.
10. Desenhe um diagrama de rede representando as seguintes informações: o projeto co-
meça com três atividades: A, B e C, que podem ser realizadas simultaneamente. Quando
A é concluída, D pode começar; quando B é concluída, F pode começar; quando B e D
são concluídas, E pode começar. O projeto é finalizado quando C, E e F são concluídas.
Use tanto o formato de diagrama de atividades quanto o de setas.
11. Desenhe um diagrama de rede que represente a lista de tarefas do projeto de desenvolvi-
mento de SI a seguir. Use tanto o formato de diagrama de atividades quanto o de setas.
Atividade Antecessora Imediata

1. Definição do Problema —
2. Estudo do Sistema Atual 1
3. Definição de Exigências dos Usuários 1
4. Concepção do Sistema Lógico 3
5. Concepção do Sistema Físico 2
6. Desenvolvimento do Sistema 4,5
7. Testes do Sistema 6
8. Converter Base de Dados 4,5
9. Conversão do Sistema 7,8
12. Encontre o máximo de erros possível no diagrama de rede a seguir:
A B R N
2 7 3
E K
1 4 7
F J L
G
3 8 6
~clements.
1. Procure por ferramentas para planejamento de projeto na Internet e descreva pelo
menos três sites encontrados.
2. Visite o link da International Project Management Association em http://ipma.kings
quare.nl/. Explore o site para saber como se associar e conhecer suas publicações.
3. O International Journal of Project Management é uma publicação da IPMA. Visite
a homepage da revista usando o link fornecido no site da IPMA ou entre em Else-
vier Science Direct pelo site www.sciencedirect.com. Encontre na edição de cortesia
(sample issue online, disponível gratuitamente) um artigo de seu interesse. Que áreas
de aplicação e tópicos são tratados nessa revista?
ESTUDO DE CASO Nº 1 Um Centro de Pesquisa Médica sem Fins

Lucrativos
Você é Alexis, diretor de relações externas de um centro de pesquisa médica sem fins lucra-
tivos, responsável pela pesquisa de doenças relacionadas ao envelhecimento. O trabalho do
centro depende de fundos provenientes de várias fontes – como população e bens privados
– e de doações concedidas por corporações, fundações e o governo federal.
Seu departamento elabora um relatório anual para o conselho de diretores sobre as
conquistas do centro e sua condição financeira. É composto principalmente de textos,
incluindo alguns gráficos e tabelas, todos em preto-e-branco, e uma capa simples. Seu vo-
lume é grande, e sua leitura direta. Produzi-lo é um processo barato, porém o esforço na
organização do conteúdo exige tempo para solicitar informações e enviá-las para os outros
departamentos do centro.
Na última reunião do conselho, seus membros sugeriram que se “refinasse” o relatório
para conferir ao documento funções de promoção e marketing. Querem que você envie
o próximo relatório anual para os vários depositários do centro, doadores antigos e futuros
doadores com grande potencial. O conselho acredita que esse documento é necessário
para “associar” o centro a outras organizações sem fins lucrativos, com as quais ele parece
disputar doações e capital. Os membros do conselho consideram que o relatório anual
poderia ser usado para informar esses depositários sobre os avanços do centro na área de
pesquisa e sua forte administração fiscal, para que o capital e as doações recebidas sejam
usados com eficiência.
Você precisará produzir um relatório anual menor, mais simples e de fácil leitura, que
mostre os benefícios da pesquisa, bem como seu impacto na vida das pessoas. Deverá in-
cluir fotos de vários hospitais, clínicas e instituições de caridade permanentes que utilizam
os resultados da pesquisa realizada pelo centro. Também incluirá depoimentos de pacientes
e famílias que se beneficiaram com a pesquisa. O relatório deve “chamar a atenção”. Precisa
ser colorido, conter muitas fotos e gráficos de fácil compreensão, além de permitir uma
leitura acessível ao doador potencial comum.
Trata-se de uma incumbência importante para seu departamento, que contém outros três
membros da equipe. Você terá de contratar atividades de terceiros e, possivelmente, visitar
várias instalações médicas espalhadas pelo país, para tirar fotos e recolher depoimentos.
Também deverá propor o design, a impressão e a distribuição a vários fornecedores para
que estes possam lhe enviar propostas e preços. Estima-se que cerca de cinco milhões de
cópias precisarão ser impressas e enviadas.
É dia 1o de abril. O conselho solicita sua presença para a próxima reunião, agendada
para 15 de maio, em que você apresentará um plano detalhado, o cronograma e o orça-
mento relativos à forma como concluirá o projeto. O conselho quer o relatório anual “nos
Correios” por volta de 15 de novembro, para que potenciais doadores o recebam perto do
feriado (próximo ao Dia de Ação de Graças), quando o “espírito de generosidade” poderá
estar fortalecido. O ano fiscal do centro termina dia 30 de setembro, e sua demonstração
financeira deve estar disponível por volta do dia 15 de outubro. No entanto, informações
para o relatório não relacionadas às finanças podem começar a ser reunidas logo após a
reunião de conselho, em 15 de maio.
Por sorte, você está fazendo um curso sobre gestão de projetos no período noturno em
uma universidade local e acredita que essa seja uma oportunidade para colocar em prática o
que tem aprendido. Você sabe que se trata de um grande projeto e que as expectativas dos
membros do conselho são altas; quer ter certeza de que atenderá a essas expectativas e de
que o orçamento necessário para esse projeto será aprovado por eles. Entretanto, isso só vai
acontecer se confiarem que possui um plano detalhado para a realização do projeto. Você
e sua equipe têm seis semanas para elaborar esse plano, que será apresentado na reunião
de conselho do dia 15 de maio. Caso seja aprovado, vocês terão um prazo de seis semanas
– de 15 de maio a 15 de novembro – para implementar o plano e concluir o projeto.
Os membros de sua equipe são: Grace, especialista em marketing; Levi, escritor/editor,
e Lakysha, assistente, cujo hobby é fotografar (ela faz faculdade de jornalismo fotográfico à
noite e já ganhou vários concursos de fotografia).
PERGUNTAS
Você e sua equipe precisam elaborar um plano para ser apresentado ao conselho, que
inclua:
1. O objetivo do projeto e uma lista de hipóteses sobre ele.

2. Uma estrutura analítica e uma matriz de responsabilidades.
3. Uma lista de atividades necessárias para alcançar o objetivo do projeto.
4. Um diagrama de rede de atividades (usando o sistema de caixas) que mostre as relações
entre todas as atividades.
O estudo desse caso continua no próximo capítulo, no qual será solicitado que sua equi-
pe elabore estimativas de duração para cada atividade, um cronograma e um orçamento
para o projeto.
ATIVIDADE EM GRUPO
Divida os integrantes do curso em grupos de quatro pessoas, que deverão representar
Alexis, Grace, Levi e Lakysha. Então, desenvolva os quatro itens acima enumerados.
Observação: O estudo desse caso continuará nos Capítulos 6 ao 9; portanto, guarde os
resultados de seu trabalho.
ESTUDO DE CASO Nº 2 O Casamento

Tonny e Peggy Sue formaram-se em maio na Universidade do Texas. Ela se formou em pe-
dagogia, e ele em culinária. Ambos trabalham na região de Dallas. Peggy Sue é professora,
e Tony chefe de cozinha em um restaurante de hotel.
É Natal quando Tony pede Peggy Sue em casamento. Ela aceita com muita alegria. O dia
do casamento fica escolhido para 30 de junho.
Tony é de Nova York. É filho único do “Grande Tony” e de Carmella, e conhecido na
família como “Pequeno Tony”. Tem três irmãs mais novas, ainda solteiras. A família é pro-
prietária de um restaurante chamado Grande Tony, claro, e os quatro filhos trabalham nele
desde pequenos. Há muitos parentes nessa grande família, dos quais a maioria mora na
cidade de Nova York. O casal também possui muitos amigos no bairro.
Peggy Sue é de Cornfield, Nebraska. É a mais jovem de quatro irmãs, que, quando pe-
quenas, trabalhavam na fazenda da família. Seu pai faleceu há muitos anos. Sua mãe, Mil-
dred, hoje vive sozinha na fazenda, cujas terras são arrendadas para um fazendeiro vizinho.
Todas as irmãs de Peggy Sue casaram-se com rapazes da região e moram em Cornfield. As
cerimônias de casamento foram modestas (cerca de 50 pessoas), simples e praticamente
iguais. O planejamento segue um padrão estabelecido por Mildred – às 9 da manhã, acon-
tece a cerimônia na pequena igreja e, em seguida, um buffet brunch é servido. Isso é tudo.
Elas não dispõem de dinheiro para organizar casamentos mais requintados, pois a renda
com a fazenda é muito pequena. As irmãs de Peggy Sue não fizeram faculdade e ela preci-
sou fazer empréstimos para pagar suas despesas com os estudos.
Tony e Peggy decidem ligar para casa e comunicar as boas-novas: o noivado e o futuro
casamento.
Tony telefona para contar a novidade à mãe, Carmella, que responde: “Que ótimo, que-
rido! Estava esperando por esse dia. Não acredito que o meu bebê vai se casar. Estou tão
feliz. Vai ser o maior e melhor casamento de todos os tempos. Parentes e amigos virão para
comemorar, sendo cerca de 300 pessoas. E, claro, a recepção será em nosso restaurante;
acho que o salão tem espaço suficiente. Direi a seu primo Vinnie que você quer que ele seja
o padrinho. Afinal, vocês cresceram juntos, ainda que não tenham se visto com freqüência
desde que você foi estudar no Texas. Vou telefonar para a tia Lucy assim que desligar e
dizer-lhe que Maria e Teresa estão convidadas para levar as flores, e o Nicky para carregar o
sino. Ah, ia me esquecendo do mais importante: suas irmãs serão as damas de honra. Já sei
até a cor do vestido delas – rosa forte; vão estar deslumbrantes. E, querido, ainda não per-
guntei a seu pai, mas sei que ele vai concordar comigo: segunda-feira, vou telefonar para
minha amiga Francine, uma agente de viagens, e conseguir duas passagens para sua lua-
de-mel de duas semanas na Itália. Como nunca esteve lá, você deveria ir. Será um presente
meu e do seu pai. E dê meus parabéns a Peggy Lee ou Peggy Susie, ou quem quer que seja.
Estamos felizes por vocês dois. O casamento é seu, por isso não quero me intrometer. Só
estou aqui para ajudar. Sabe do que estou falando. Portanto, é só falar se precisar que eu
faça alguma coisa, meu pequeno Tony. Mais uma coisa: domingo, depois da missa, vou ver
o padre Frank e pedir que ele marque no calendário o casamento para o dia 30 de junho,
às 14 horas. Tchau, meu grande garoto. Vou contar para seu pai que você ligou. Estou louca
para falar para todo mundo se preparar para a festa do dia 30 de junho”.
Peggy Sue também telefona para a mãe e conta sobre o casamento que está por vir.
Mildred responde: “Que maravilha, querida! Estou feliz por seu casamento. Esperou tanto
tempo fazendo faculdade e tudo mais. Vou dar início aos preparativos. Já sei como fazê-lo
de olhos fechados. Vou falar com o reverendo Johnson depois do culto de domingo. Suas
irmãs devem esperar que serão as damas de honra, mantendo assim a tradição familiar.
Acho que Holley será a madrinha; é a vez dela. A propósito, ela provavelmente estará grá-
vida do terceiro filho na mesma época do casamento, mas acho que isso não importa. Bem,
possivelmente vão ter seus filhos logo, logo, assim como suas irmãs. Estou feliz por ver que
finalmente você está sossegando. De verdade, deveria considerar a hipótese de voltar para
casa, agora que terminou a faculdade. Vi sua professora da segunda série, Emma Miller, no
mercadinho outro dia. Disse que está se aposentando. Falei para ela que você ficaria feliz
com a notícia e que provavelmente iria querer se candidatar à vaga”.
“Ela acha que não vai haver ninguém querendo essa vaga, o que aumenta suas chances.
Você pode vir morar comigo. A casa é tão grande e vazia. Há bastante espaço, e eu posso
ajudá-la a cuidar dos bebês. Seu namorado, Tony – ele é cozinheiro ou algo do tipo, não é?
– tenho certeza de que pode conseguir um emprego na pousada da cidade. Ai, querida, es-
tou tão feliz! Tenho rezado para que volte desde que você partiu. Vou comunicar a notícia
às suas irmãs quando vierem jantar hoje à noite. Logo estaremos todas juntas novamente.
Tchau, querida. Muito cuidado aí nessa cidade grande.”
Tony e Peggy Sue começam a discutir sobre o casamento. Decidem fazer uma cerimônia
religiosa grandiosa – com familiares e amigos, entre os quais os da época de faculdade.
Querem que a cerimônia e recepção sejam ao ar livre, com muita comida, música e dança
até anoitecer. No entanto, não têm certeza de quanto tudo vai custar e percebem que a mãe
de Peggy Sue não poderá pagar pelo casamento, o que eles mesmos terão de fazer. Tanto
Tony quanto Peggy têm empréstimos educativos a liquidar, mas esperam que o dinheiro
recebido como presente dos convidados seja suficiente para as despesas do casamento e
que talvez ainda sobre um pouco para a lua-de-mel.
Já é Ano-Novo; Tony e Peggy Sue decidem iniciar o planejamento detalhado de todas as
coisas que precisam fazer para estarem preparados para o casamento.
PERGUNTAS
1. Elabore uma lista de hipóteses que serão utilizadas como base para planejar o casamento.
2. Elabore uma lista de atividades que precisam ser realizadas do momento atual até o dia
do casamento.
3. Para cada atividade, identifique uma pessoa (Tony, Peggy Sue etc.) responsável pela
verificação de seu cumprimento.
4. Baseando-se na lista de atividades, elabore um diagrama de rede (usando o modelo de

diagrama de atividades) que mostre as relações entre todas as atividades.
ATIVIDADE EM GRUPO
Divida os integrantes do curso em grupos de três ou quatro e responda às perguntas ante-
riores.
Observação: O estudo deste caso continua no Capítulo 6, no qual será solicitado que sua
equipe elabore estimativas de duração para cada atividade, um cronograma e um orçamen-
to para o projeto; portanto, guarde os resultados de seu trabalho.
Não, não vale opinar que Tony e Peggy Sue vão simplesmente fugir, mesmo que essa
seja uma idéia muito tentadora!
Observação: O estudo desse caso continuará dos Capítulos 6 ao 9; portanto, guarde os
APÊNDICE Microsoft Project

O Microsoft Project é o software de gestão de projetos mais usado no mundo dos negócios
atualmente. Ele é potente, fácil de usar e tem um preço bastante acessível. Uma versão de
teste grátis foi incluída neste livro. Neste apêndice, iremos discutir brevemente como o
Microsoft Project pode ser usado para dar suporte às técnicas discutidas neste capítulo, com
base no estudo de mercado consumidor.
Familiarizando-se com o ambiente do Microsoft Project 2003. Abra o Microsoft Project
2003. Observe que Gantt Chart View é a área de trabalho principal. Se não estiver com
essa visualização, vá até o menu View e clique em Gantt Chart. Acima da área de trabalho
principal, estão a barra de ferramentas padrão (Tools), a barra de ferramentas de formata-
ção (Format) e a barra de ferramentas do projeto (Project). Caso uma delas esteja oculta, vá
para o menu View, aponte para Toolbars e selecione as barras de ferramentas a partir da
lista. À esquerda da área de trabalho principal, você irá encontrar, em um espaço estreito, o
Task Pane, que começa com o Getting Started Pane e contém links para o Microsoft Office
Online, uma lista dos arquivos Microsoft abertos anteriormente e a opção para iniciar um
novo projeto (New Project). Se o gerenciador de tarefas (Task Pane) estiver oculto, vá para
o menu View, aponte para Toolbars e selecione Task Pane a partir da lista. Você pode mo-
ver esse painel para que ele fique à direita ou à esquerda da área de trabalho principal.
Visite o Microsoft Office Online para obter tutoriais on-line e muito mais. Caso ainda
não tenha feito isso, reserve um tempo para navegar pelo Microsoft Office Online. Lá você
encontrará tutoriais, dicas, modelos, novidades e outras informações importantes sobre o
Microsoft Project 2003. O link para o Microsoft Office Online pode ser encontrado no painel
Getting Started Task Pane.
Começando a construir o Projeto de Estudo de Mercado Consumidor. No menu File,
clique em New para iniciar um novo projeto. Em seguida, a partir do painel de tarefas à
esquerda, selecione Blank Project.
Sobre o Project Guide. Você pode optar por usar o Project Guide, que será exibido no
painel de tarefas. O Project Guide vai fornecer as etapas básicas de que precisa nas quatro
áreas de seu projeto:
Área 1 – Tarefas (Tasks);
Área 2 – Recursos (Resources);
Área 3 – Rastreamento (Track);
Área 4 – Relatório (Report).
Essas áreas são relacionadas na barra de ferramentas Project Guide, na parte superior.
Clique em cada área da barra de ferramentas Project Guide para visualizar a guia correspon-
dente no painel de tarefas. Caso não encontre essa barra de ferramentas, vá para o menu
View, aponte para Toolbar e clique em Project Guide. Esta é uma ferramenta útil para cons-
truir seu primeiro projeto. Contudo, nem todas as etapas desses exercícios no MS Project
estão incluídas no Project Guide; por isso, as instruções fornecidas neste livro irão assumir
que você não está usando o Project Guide.
Primeiro, configure algumas propriedades para descrever o arquivo de projeto. No
menu File, clique em Properties para inserir “Estudo de Mercado Consumidor” como o
título do projeto (Project Title), conforme mostrado na Figura 5A.1. Você pode inserir
outras informações, como assunto (Subject), autor (Author), gestor (Manager), empresa
(Company) e outros comentários relacionados. Clique em OK para salvar e feche a janela
Project Properties.
Você também precisa, primeiro, inserir informações relacionadas a prazos para que o
software possa automaticamente gerar cronogramas de projeto e calcular custos.
No menu Project, clique em Project Information para visualizar a janela Project Informa-
tion e insira a data inicial (Start date): Mon 1/16/06, conforme Figura 5A.2. Clique em OK
para fechar a janela Project Information.
Em seguida, no menu Tools, clique em Change Working Time. Selecione ou insira os
seguintes dados:
1. Para: Padrão (Standard, em Project Calendar) na caixa de seleção.

2. Encontre o calendário de janeiro de 2006, clique no dia 16 e selecione o botão
“Nonworking time” para marcar a data como feriado.
FIGURA 5A.1 Propriedades do Projeto
FIGURA 5A.2 Informações do Projeto
3. Todos os demais dias do calendário devem ser configurados como “Use default” para
horários de trabalho-padrão: de segunda a sexta, das 8 da manhã às 5 da tarde, com
uma hora de almoço.
4. Clique em Options para configurar os seguintes horários de trabalho-padrão:
_______ Horas por dia (Hours per Day) = 8
_______ Horas por semana (Hours per Week) = 40
_______ Dias por mês (Days per Month) = 20
_______ Clique em OK para fechar a janela Options.
5. Clique em OK para fechar a ferramenta Change Working Time.
Agora, você deve ver Gantt Chart View com a tabela de entrada de dados (Entry Table)
na tela. Aqui você vai inserir nomes na coluna Task Name. Consulte a Figura 5A.3 para ver
os nomes de tarefas a serem inseridos. Após preencher um nome de tarefa, observe que a
duração-padrão (1 dia) é automaticamente inserida, com as datas de início e término. Deixe
esses valores como padrão, por enquanto. É possível criar subconjuntos de tarefas com faci-
lidade. Na barra de ferramentas de formatação (Format), verá duas setas verdes. Você pode
usá-las para criar subtarefas e trazer uma tarefa para um nível mais alto da organização.
Tente fazer isso, embora, para este exercício, não precise criar subtarefas.
Para cada subtarefa inserida, você pode adicionar outros detalhes, com a adição de Task
Notes. Clique com o botão direito em um nome de tarefa para selecionar Task Notes no
Menu. Essa tela lhe permite que insira informações adicionais sobre cada tarefa.
Em seguida, insira os dados antecessores na coluna Predecessor para mostrar as depen-
dências entre as tarefas, conforme mostrado na Figura 5A.4. Consulte a Figura 5A.3 para
esses dados. Por exemplo, a Task 1 (Tarefa 1) é a antecessora da Task 2 ou, em outras
palavras, a Task 2 depende da conclusão da Task 1.
FIGURA 5A.3 Tarefas – Nomes, Duração, Datas de Início e Término das Tarefas
FIGURA 5A.4 Tarefas – Adicionando Dados Antecessores
FIGURA 5A.5 Recursos
As equipes para o projeto de Estudo de Mercado Consumidor são compostas de Susan,

Steve, Andy e Jim. Insira esses nomes na planilha de recursos (Resource Sheet), na qual
todos os membros da equipe são relacionados, com seus correspondentes valores de pa-
gamento, conforme mostrado na Figura 5A.5. No menu View, clique em Resource Sheet.
Preencha essa planilha com os nomes dos membros da equipe (Susan, Steve, Andy e Jim).
Você pode inserir informações como iniciais a serem usadas, valor de pagamento por hora
e valor para hora extra.
Em seguida, você pode mostrar quem vai realizar cada tarefa que acabou de relacionar.
No menu View, clique em Gantt Chart para cada tarefa, atribua uma pessoa para esta na
coluna Resource Names. Os nomes da Resource Sheet podem ser selecionados a partir da
lista suspensa na coluna Resource Names. Consulte a Figura 5A.4 para atribuições nome-
tarefa neste exercício. Observe que o gráfico de Gantt é gerado automaticamente no lado
direito da tela.
Para cada tarefa, você pode visualizar todas as informações detalhadas relacionadas
àquela tarefa clicando com o botão direito sobre o nome da tarefa e, em seguida, clicando
em Task Information no menu.
Para visualizar o diagrama TAAP mostrado na Figura 5A.6, no menu View, clique em Ne-
twork Diagram. Esse diagrama de rede é equivalente ao formato de diagrama de atividades
discutido neste capítulo. Você também pode criar um diagrama PERT menos detalhado por
meio do menu View; clique em More Views e, em seguida, em Relationship Diagram. Para
voltar à visualização-padrão, clique em Gantt Chart.
Para salvar as informações de seu projeto, no menu File, clique em Save As. É altamen-
te recomendável salvar um projeto com um plano-base antes de seu início, para que seja
possível comparar o progresso real com o planejado depois que o projeto tiver começado.
FIGURA 5A.6 O Diagrama de Rede
Capítulo CRONOGRAMA
6 Estimativas de Duração das

Atividades
Datas de Início e de Conclusão do
Projeto
Estudo de Caso no 1 Um Centro
de Pesquisa Médica Sem Fins
Lucrativos
Perguntas
Cálculo do Cronograma Atividade em Grupo
Início e Término Mais Cedo Estudo de Caso no 2 O Casamento
Início e Término Mais Tarde Perguntas
Folga Total Atividade em Grupo
Caminho Crítico Apêndice no 1 Considerações
Folga Livre sobre Probabilidades
Cronograma para Estimativas de Duração das
Desenvolvimento de Sistemas de Atividades
Informação Distribuição Beta de
Exemplo de SI: Desenvolvimento Probabilidades
de Aplicativos de Internet para Fundamentos de Probabilidade
a ABC Office Designs Cálculo de Probabilidades
Software de Gestão de Projetos Resumo
Resumo Perguntas
Perguntas Apêndice no 2 Microsoft Project
138
Ca pítulo S e is
Projeto Censo 2000 nos Estados Unidos
A cada dez anos, todas as residências norte-americanas são estimuladas a responder um
questionário do Censo norte-americano. Os dados coletados são usados para a contagem
dos membros da população, exigida pela Constituição do país. Utilizam-se essas informa-
ções para alocar a representação no Congresso. Os recursos para os membros do Congres-
so de diferentes distritos, legisladores de Estado e funcionários eleitos são distribuídos de
acordo com os dados do Censo que, aliás, é útil por muitos outros motivos. Ele representa
uma oportunidade para o governo coletar informações que o ajudam a elaborar políticas
em áreas como saúde, educação, transportes, serviços à comunidade, habitação e plane-
jamento econômico. Para os que não estão envolvidos no processo de coleta de dados,
participar do Censo dura apenas alguns minutos, tempo necessário para responder ao
questionário. Para os funcionários, porém, trata-se de um projeto de vários anos. O Censo 2000
foi um projeto que durou 13 anos, com início em 1991 e término em 2003. O custo do ciclo
de vida total do Censo de 2000 foi de US$ 65 bilhões (correspondentes ao valor do dólar
em 2000).
No Censo 2000, exigiu-se um planejamento cauteloso para a coleta de dados. Nos
Estados Unidos inteiros, estabeleceram-se 520 escritórios regionais para o Censo, a fim de
verificar e coletar o maior número possível de endereços no Arquivo de Endereços Princi-
pal. Para aumentar a quantidade de residências com as quais o departamento poderia en-
trar em contato, foram usados processos de coleta de dados especiais em algumas regiões.
As categorias descrevem o método de coleta de dados e são divididas por tipos de endere-
ço. O procedimento Atualizar/Deixar foi empregado em zonas rurais que usam endereços
do tipo “quilômetro tal da rodovia” ou simples caixas de entrega de correspondência. Fun-
cionários do Censo entregavam pessoalmente os questionários e verificavam os endereços
que não estavam presentes no Arquivo de Endereços Principal do departamento. Nesse
caso, solicitava-se de todas as residências a devolução dos questionários por correio. Esse
processo Entregar/Reenviar foi utilizado para endereços-padrão em logradouros de zonas
urbanas, cidades pequenas e médias e zonas rurais. Os questionários eram entregues às
residências por correio e tinham de ser reenviados também por correio. O procedimento
Listar/Enumerar foi o mais trabalhoso. Os funcionários do Censo visitaram zonas rurais e
afastadas onde a população migra conforme as estações. Empregou-se tal procedimento
em regiões afastadas do Alasca. Os responsáveis pela contagem encontravam-se pessoal-
mente com os residentes de vilas de pescadores, para coletar dados no inverno, antes da
época de degelo. Na primavera, a população diminui, pois as pessoas passam a maior parte
do tempo longe das vilas, pescando e caçando. Os funcionários do Censo costumavam ir às
residências, completando o questionário durante a própria visita.
O objetivo do projeto era chegar a um índice de 70% de questionários respondidos,
para o Censo 2000. O departamento implementou um plano para divulgar a realização do
Censo vindouro e a importância da pesquisa. Parcerias com o Congresso, líderes locais,
líderes de comunidades e educadores foram essenciais para informar a população de seus
respectivos distritos sobre o evento, em encontros municipais e em outros eventos das co-
munidades. A divulgação por meio de propagandas pagas começou em 1999, cerca de um
ano antes do Censo. Fizeram-se propagandas na televisão, no rádio, em revistas, em outdoors
e em transportes públicos. Além disso, um “acompanhamento da ausência de respostas”
também foi planejado. O departamento estimou que os funcionários do Censo visitariam
46 milhões de residências, a fim de conversar com aqueles que não tinham completado e
enviado os questionários para um dos quatro centros de coleta dos Estados Unidos.
Para assegurar que o projeto fosse concluído na data prevista, o sistema usado para
a coleta de dados passou por longos testes. Lockheed Martin e TRW associaram-se ao
139
departamento para desenvolver esse sistema. Os questionários de cada residência foram

identificados por um código de barras exclusivo. Em seguida, foram escaneados optica-
mente; os softwares de reconhecimento óptico de caracteres (OCR) leram as respostas que
foram assinaladas e as anotações feitas à mão. Os funcionários do Censo foram responsá-
veis por completar a entrada de dados para itens que não foram reconhecidos pelo softwa-
re OCR. O sistema também procurou por dados duplicados, fato bem possível devido às
diferentes formas para envio de dados: Internet, correio, telefonema e pessoalmente.
A contagem do Censo 2000 foi considerada a mais precisa da história norte-americana.
Pela primeira vez, os dados do Censo foram disponibilizados na Internet. Os números indi-
caram uma população de 281.421.906 em 2000, mostrando um aumento de 32,7 milhões
em relação a 1990. Trata-se do maior aumento na história do Censo norte-americano, que
teve início em 1790.
Discurso Elaborado por Kenneth Prewitt, Diretor do Departamento do Censo Norte-Americano, perante o Subcomitê acerca
da Reforma Governamental por meio do Comitê do Censo, Câmara dos Deputados, 8 de fevereiro de 2000.
Relatório Oficial de Contabilidade Geral Norte-Americana aos Solicitantes Congressionais, Custos Completos dos Progra-
mas de Avaliação de Cobertura, Censo 2000.
O Capítulo 5 abordou a determinação de quais atividades precisam ser realizadas e em

qual seqüência, a fim de se atingir o objetivo de um projeto. O resultado foi um plano na
forma de diagrama de rede que ilustra graficamente as atividades na seqüência de inter-
dependência apropriada para a realização do escopo de trabalho do projeto. Quando se
utilizam técnicas de planejamento de rede, a função de estabelecimento de cronograma
depende da função de planejamento. Um cronograma é um calendário de realização para
um plano e, portanto, não pode ser estabelecido antes que este tenha sido desenvolvido.
Neste capítulo, vamos estabelecer um cronograma para o plano. Você aprenderá a:
• estimar a duração de cada atividade;
• estabelecer a data de início estimada e a data de conclusão exigida para todo o projeto;
• calcular a data mais cedo na qual cada atividade pode começar e terminar, com base
na data de início estimada do projeto;
• calcular a data mais tarde na qual cada atividade deve começar e terminar para se
concluir o projeto antes da data de conclusão exigida;
• determinar quanto existe de folga positiva ou negativa entre a data em que cada ati-
vidade pode começar ou terminar e a data na qual ela deve começar ou terminar;
• identificar o caminho crítico (mais longo) para as atividades.
ESTIMATIVAS DE DURAÇÃO DAS ATIVIDADES

A primeira etapa no estabelecimento de um cronograma de projeto é estimar quanto
tempo vai durar cada atividade do momento em que começou até o momento em que é
concluída. Essa estimativa de duração para cada atividade deve ser o tempo total decorrido
– o tempo para que o trabalho seja feito somado a qualquer tempo de espera associado.
Na Figura 6.1, por exemplo, a estimativa de duração para a atividade 1, “Envernizar Pisos”,
é de cinco dias, o que inclui tanto o tempo de envernizar os pisos quanto o de espera para
que o verniz seque.

1. Verdadeiro ou falso: a estimativa de
duração para uma atividade deve incluir o
tempo exigido para se realizar o trabalho
mais qualquer tempo de espera associado.
Capítulo 6 Cronograma 141
FIGURA 6.1 Estimativa de Duração de Atividades (Diagrama de Atividades)
Envernizar Colocar
Pisos Móveis no Lugar
1 5 2 1
LEGENDA
Descrição da
Atividade
Número da Estimativa
Atividade de Duração
FIGURA 6.2 Estimativa de Duração de Atividades (Diagrama de Setas)
Envernizar Pisos Colocar Móveis no Lugar

1 2 3
5 1
LEGENDA
Descrição
da Atividade
Estimativa de Duração
Número Número
do Evento do Evento
A estimativa de duração da atividade costuma ser apresentada no canto direito inferior

da caixa, no formato de diagrama de atividades dos diagramas de rede, abaixo da seta no
formato de diagrama de setas (veja Figura 6.2).
É interessante que a pessoa responsável por executar uma atividade em particular faça a
estimativa de duração para essa atividade. Isso gera um compromisso por parte do respon-
sável e evita qualquer viés que possa ser introduzido caso uma mesma pessoa faça as esti-
mativas de duração para todas as atividades. No entanto, em alguns casos – como grandes
projetos que envolvem centenas de pessoas realizando várias atividades no decorrer de vá-
rios anos –, pode não ser viável pedir que cada pessoa forneça estimativas de duração das
atividades no início do projeto. Em vez disso, cada organização ou subcontratado responsá-
vel por um grupo ou tipo de atividades pode designar uma pessoa experiente para fazer as
estimativas de duração de todas as atividades pelas quais é responsável. Caso a organização
ou subcontratado tenha realizado projetos semelhantes no passado e mantenha registros de
quanto tempo as atividades específicas de fato levaram, esses dados históricos podem ser
usados como guia para a estimativa de duração de atividades em projetos futuros.
A estimativa de duração de uma atividade deve ser baseada na quantidade de recursos
que se espera utilizar para desenvolver essa atividade. A estimativa deve ser agressiva,
porém, realista. Ela não deve incluir tempo para os imprevistos. Também não deve ser
demasiadamente otimista e curta. Normalmente é melhor ser um pouco agressivo e estimar
uma duração de cinco dias para uma atividade, e depois concluí-la de fato em seis dias, do
que ser excessivamente conservador e estimar uma duração de dez dias, e depois levar de
fato dez dias. As pessoas, às vezes, agem conforme a expectativa – se uma atividade está
estimada para levar dez dias, sua dedicação será dimensionada para preencher igualmente
todos os dez dias, mesmo que a atividade pudesse ser realizada em menos tempo.
Tentar inflar as estimativas de duração prevendo que o gestor do projeto poderá depois
negociar durações mais curtas não é uma boa idéia, tampouco “rechear” as estimativas, a
fim de se tornar um herói quando as atividades forem concluídas em menos tempo que
o estimado.
No decorrer do projeto, algumas atividades tomarão mais tempo que sua duração esti-
mada, algumas serão feitas em menos tempo que sua duração estimada, enquanto outras
podem levar exatamente o tempo estimado. No decorrer de um projeto que envolva mui-
tas atividades, esse atrasos e antecipações tendem a anular uns aos outros. Por exemplo,
uma atividade pode levar duas semanas mais que originalmente estimado, mas esse atraso
pode ser compensado por outras duas atividades que são concluídas uma semana antes
do previsto.
As Figuras 6.3 e 6.4 mostram diagramas de rede para um estudo de mercado consu-
midor nos formatos DA e DS, respectivamente, com as estimativas de duração para cada
atividade. Uma base de tempo consistente, com horas, dias ou semanas deve ser usada
para todas as estimativas de duração de atividades em um diagrama de rede. Observe que,
no formato DS, não é necessário fazer uma estimativa de duração para atividades fictícias,
porque, por definição, sua duração é nula (igual a zero).
Para projetos nos quais há um elevado grau de incerteza em relação às estimativas de
duração das atividades, é possível usar três estimativas de duração: uma otimista, uma pes-
simista e uma mais provável. Para uma discussão sobre essa técnica, veja o apêndice ao
final deste capítulo.
FIGURA 6.3 Diagrama de Rede para Projeto de Estudo de Mercado Consumidor,

Indicando Estimativas de Duração (Diagrama de Atividades)
Preparar Etiquetas
para Mala Direta
5 Ste ve 2
Identificar Revisar Comentários

Esboçar Questionário Imprimir
Consumidores e
Questionário Teste Piloto Questionário
-Alvo Concluir Questionário
1 Susan 3 2 Susan 10 3 Susan 20 4 Susan 5 6 Steve 10
Desenvolver
Software de
Análise de Dados
7 Andy 12
Desenvolver Dados
para
Teste de Software
8 Susan 2
DATAS DE INÍCIO E DE CONCLUSÃO DO PROJETO

A fim de se estabelecer uma base a partir da qual seja possível calcular um cronograma
usando as estimativas de duração para as atividades, é necessário selecionar uma data de
início estimada e uma data de conclusão exigida para o projeto global. Esses dois itens
(ou datas) definem o intervalo total de tempo no qual um projeto deve ser concluído.

2. O intervalo global de tempo no qual
um projeto deve ser concluído é definido
por sua data _______________________
e sua data _______________________.
A data de conclusão exigida do projeto costuma ser parte do objetivo do projeto e nor-
malmente consta do contrato. Em alguns casos, tanto a data de início estimada quanto a
data de conclusão exigida são especificadas, como, por exemplo, “o projeto não terá início
antes de 1º de junho e deve ser concluído até o dia 30 de setembro”. Em outros casos, o
cliente especifica apenas a data na qual o projeto deve ser concluído.
Contudo, o fornecedor pode não se comprometer a concluir o projeto até uma data
específica antes que o cliente tenha aprovado o contrato. Nesses casos, o contrato pode
Enviar
Questionário e Inserir Dados Analisar Preparar
Receber Respostas de Respostas Resultados Relatório
9 Steve 65 11 Jim 7 12 Jim 8 13 Jim 10
Testar
Software
10 Andy 5
LEGENDA
Descrição da
Atividade
Atividade Duração
Responsável

Indicando Estimativas de Duração (Diagrama de Setas)
Preparar
Etiquetas para
Mala Direta
Steve
2
Revisar
Comentários
Identificar Questionário e Concluir
Esboço Imprimir
Consumidores- Teste Piloto Questionário
Questionário Questionário
Alvo
1 2 3 4 5
3 10 20 5 10
Desenvolver
Software de
Análise de Dados
Andy
12
Desenvolver
Dados para Teste
de Software
Susan
2
especificar que “o projeto será concluído dentro de 90 dias após a assinatura do contra-
to”. Aqui, o tempo total para o projeto é declarado em termos de um período de tempo
(90 dias), e não de datas específicas.
Suponha que o projeto de estudo de mercado consumidor mostrado nas Figuras 6.3 e
6.4 deva ser concluído em 130 dias úteis. Se definirmos a data de início do projeto como 0,
sua data de conclusão exigida é o dia 130.
CÁLCULO DO CRONOGRAMA
Após ter uma duração estimada para cada atividade da rede e um intervalo global de tem-
po no qual o projeto deve ser concluído, é preciso determinar (com base em durações e
seqüência de precedências) se as atividades podem ser realizadas até a data de conclusão
exigida. Para fazer isso, você pode calcular um cronograma de projeto que forneça as datas
importantes para cada atividade e estabeleça:
1. A data mais cedo na qual uma atividade pode ser iniciada e terminada, com base na
data de início estimada para o projeto.
Enviar
Questionário e
Receber Inserir Dados Analisar Preparar
Respostas de Respostas Resultados Relatório
7 10 11 12 13
40
Steve Jim Jim Jim
65 7 8 10
Testar
Software
9
Andy
5
LEGENDA
Descrição da
Atividade
Responsável
8 Número da
Número da
Atividade Atividade
2. A data mais tardia na qual uma atividade pode ser iniciada e terminada, a fim de se
concluir o projeto até a data de conclusão exigida.
Início e Término Mais Cedo

Dada uma duração estimada para cada atividade da rede, e usando a data de início estimada
para o projeto como referência, é possível calcular as duas datas a seguir para cada atividade:
1. A data de início mais cedo (IC) é a data mais cedo na qual determinada atividade
pode começar, calculada com base na data de início estimada para o projeto e nas
estimativas de duração para as atividades anteriores.

3. Qual é a equação para o cálculo da
data de término mais cedo de uma
atividade?
2. A data de término mais cedo (TC) é a data mais cedo na qual uma atividade em
particular pode ser concluída, calculada a partir da adição da estimativa de duração
da atividade à data de início mais cedo da atividade:
TC = IC + Estimativa de Duração
As datas IC e TC são determinadas calculando-se de forma progressiva – isto é, per-
correndo-se o diagrama de rede do início ao fim do projeto. Há uma regra que deve ser
seguida ao se fazer esses cálculos progressivos.

4. As datas de início e término mais
cedo para atividades são determinadas
calculando-se de forma ______________
no diagrama de rede.
Regra 1: A data de início mais cedo para uma atividade em particular deve ser a mesma ou
posterior a ela, isto é, a data mais tardia de todas as datas de término mais cedo comparan-
do-se todas as atividades que apontam diretamente para essa atividade em particular.
FIGURA 6.5 Datas de Início Mais cedo
0 5
Ensaiar Ato
Cômico
1 5
LEGENDA
0 10 10 12 Início Término
mais Cedo mais Cedo
Fazer Ensaio
Descrição da
Figurinos Geral Atividade
2 10 4 2 Atividade de Duração
0 4
Finalizar
Cenários
3 4
(a) Diagrama de Atividades
Ensaiar Ato
0 Cômico
1
5 LEGENDA
5 Ensaio Descrição da
Atividade
Fazer Início Término
0 Figurinos 10 10 Geral 12 mais Cedo mais Cedo
2 4 5
10 2
Finalizar 4 Número da Número da
0 Cenários Atividade Atividade
3
4
(b) Diagrama de Setas
A Figura 6.5 mostra três atividades que apontam diretamente para “Ensaio Geral”. “Ensaiar
Ato Cômico” tem uma TC no dia 5, “Fazer Figurinos” tem uma TC no dia 10 e “Finalizar Ce-
nário” tem uma TC no dia 4. “Ensaio Geral” não pode começar antes que as três atividades te-
nham sido concluídas, então, a data mais tardia às três TCs determina a IC para “Ensaio Geral”.
A data mais tardia para as três atividades é o dia 10 – a data de término mais cedo para “Fazer
Figurinos”. Portanto, “Ensaio Geral” não pode começar antes do dia 10. Isto é, sua IC deve ser
no dia 10 ou depois. Embora “Ensaiar Ato Cômico” e “Finalizar Cenário” possam terminar antes
de “Fazer Figurinos”, “Ensaio Geral” não pode começar porque a lógica de rede indica que as
três atividades devem ser concluídas antes que “Ensaio Geral” possa começar.

5. Consulte as Figuras 6.6 e 6.7. Quais
são as datas de início e término mais
cedo para “Questionário Teste Piloto”?
As Figuras 6.6 e 6.7 mostram os cálculos progressivos para o projeto de estudo de mer-
cado consumidor. A data de início estimada do projeto é 0. Portanto, a data mais cedo em
que “Identificar Consumidores-Alvo” pode começar é 0, e a data mais cedo em que pode
terminar é 3 dias depois (porque a sua duração estimada é de 3 dias). Quando “Identificar
Consumidores-Alvo” é concluída no dia 3, “Elaborar Esboço de Questionário” pode come-
çar. Essa atividade tem uma duração de 10 dias; portanto, sua IC é o dia 13. Os cálculos
de IC e TC para as atividades subseqüentes são feitos de forma semelhante, avançando de
forma progressiva no diagrama de rede.
Observe por um momento “Testar Software”. Sua IC é dia 50, porque, de acordo com a
Regra 1, essa atividade não pode começar antes que as duas atividades que apontam direta-
mente em direção a ela sejam concluídas. “Desenvolver Software de Análise de Dados” não
termina antes do dia 50 e “Desenvolver Dados para Teste de Software” não termina antes
do dia 40. Como “Testar Software” não pode começar antes que essas duas atividades sejam
concluídas, “Testar Software” não pode começar antes do dia 50.
Para ilustrar melhor a Regra 1, consulte mais uma vez as Figuras 6.6 e 6.7. Para começar
“Enviar Questionário e Receber Respostas”, as duas atividades imediatamente antecessoras,
“Preparar Etiquetas para Mala Direta” e “Imprimir Questionário” devem ser concluídas. A TC
de “Preparar Etiquetas para Mala Direta” é dia 40, e a TC de “Imprimir Questionário” é dia
48. Segundo a Regra 1, é a mais tardia das duas TCs, ou o dia 48, que determina a IC de
“Enviar Questionário e Receber Respostas”.
Se continuar calculando a IC e a TC para cada atividade restante do diagrama de rede
das Figuras 6.6 e 6.7, verá que a última atividade, “Preparar Relatório Final”, tem sua TC no
dia 138. Isso significa 8 dias além do tempo de conclusão exigido para o projeto, de 130 dias.
Nesse ponto, sabemos que há um problema.

6. O que determina a data de início mais
cedo de uma atividade?
Deve-se observar que, embora a IC e TC para cada atividade sejam apresentadas nos dia-
gramas de rede nas Figuras 6.6 e 6.7, isso não costuma ser o caso. Em vez disso, as datas
de IC e TC (e as datas de IT e TT, explicadas na seção a seguir) são relacionadas em uma
tabela de cronograma separada, como aquela na Figura 6.8. Separar a tabela de cronograma
do diagrama lógico de rede facilita a geração de cronogramas revisados e atualizados

Indicando Datas de Início e Término mais Cedo (Diagrama de Atividades)
38 40
Preparar
Etiquetas para
Mala Direta
Projeto 5 Steve 2
Começa
em 0
0 3 3 13 13 33 33 38 38 48
Identificar Esboçar Revisar Comentários
Questionário Imprimir
Consumidores- Questionário e
Teste Piloto Concluir Questionário Questionário
Alvo
38 50
Desenvolver
Software de
Análise de Dados
7 Andy 12
38 40
Desenvolver Dados
para Teste de
Software
8 Susan 2
(eventualmente usando o software de gestão de projetos), sem que seja necessário fazer
mudanças contínuas às datas de IC, TC, IT e TT no diagrama de rede em si.
Início e Término Mais Tarde

Dada uma duração estimada para cada atividade da rede, e usando a data de conclusão exigida
para o projeto como referência, é possível calcular as duas datas a seguir para cada atividade:
1. A data de término mais tarde (TT) é a data mais tardia na qual uma atividade em
particular deve ser concluída a fim de que todo o projeto seja finalizado até a data de
conclusão exigida, calculada com base na data de conclusão exigida para o projeto
e nas estimativas de duração para as atividades sucessoras.
2. A data de início mais tarde (IT) é a data mais tardia na qual uma atividade em par-
ticular deve ser iniciada a fim de que todo o projeto seja concluído até a data exigida,
calculada por meio da subtração da estimativa de duração da atividade da data de
término mais tarde:
IT = TT – Estimativa de Duração

7. Qual é a equação para o cálculo
de data de início mais tarde de uma
atividade?
48 113 113 120 120 128 128 138

e Receber Respostas de Respostas Resultados Relatório
9 Steve 65 11 Jim 7 12 Jim 8 13 Jim 10
Conclusão Solicitada = 130 Dias

50 55
Testar
Software
10 Andy 5
Início Término
mais Cedo mais cedo
LEGENDA
Descrição da
Atividade
Número Estimativa
da Atividade de Duração
Responsável
As datas de TT e IT são determinadas calculando-se de forma regressiva – isto é, percor-

rendo-se o diagrama de rede a partir do fim até o início do projeto. Há uma regra que deve
ser seguida ao se fazer esses cálculos regressivos.
Regra 2: A data de término mais tarde para uma atividade em particular deve ser a mesma
data ou anterior a ela, isto é, a data mais cedo de todas as datas de início mais tarde compa-
rando-se todas as atividades que partem diretamente daquela atividade em particular.

8. As datas de início e término mais tarde
são determinadas calculando-se de forma
_________________ no diagrama de rede.
A Figura 6.9 mostra duas atividades que partem diretamente de “Imprimir Cartazes e
Panfletos”. Esse projeto precisa ser concluído até o dia 30. Portanto, “Distribuir Cartazes”
deve ser iniciada até o dia 20, porque tem uma duração de 10 dias e “Enviar Panfletos por
Mala Direta” deve ser iniciada até o dia 25, porque apresenta uma duração de 5 dias. A
data mais cedo dentre essas duas datas ITs é dia 20. Portanto, o mais tarde que “Imprimir
Cartazes e Panfletos” pode terminar é dia 20, para que “Distribuir Cartazes” possa começar
até o dia 20. Embora “Enviar Panfletos por Mala Direta” não tenha de começar até o dia 25,
“Imprimir Cartazes e Panfletos” deve terminar até o dia 20, ou, então, todo o projeto terá

Indicando Datas de Início e Término mais Cedo (Diagrama de Setas)
Preparar Etiquetas
para Mala Direta
Steve
Projeto 2
Começa
38
em 0
Revisar
Consumidores- Esboçar Questionário e Concluir Imprimir
Alvo Questionário Teste Piloto Questionário Questionário
0 3 3 13 13 33 33 38 38
1 2 3 4 5
3 10 20 5 10
Desenvolver Software
38
Andy
12
38
Desenvolver
Dados para Teste
de Software
Susan
2
atraso. Se “Imprimir Cartazes e Panfletos” não terminar até o dia 25, “Distribuir Cartazes” não
poderá começar até o dia 25. Como “Distribuir Cartazes” tem uma duração estimada de 10
dias, essa atividade não terminará antes do dia 35, o que significa 5 dias além da data de
conclusão exigida para o projeto.

são as datas de início e término mais
tarde para “Inserir Dados de Respostas”?
As Figuras 6.10 e 6.11 mostram os cálculos regressivos para o projeto de estudo de mer-
cado consumidor. A data de conclusão exigida para o projeto é de 130 dias úteis. Portanto, o
prazo máximo para que “Preparar Relatório”, a última atividade, seja concluído é no dia 130, e
a data mais tarde em que pode começar é no dia 120, porque tem uma duração estimada de
10 dias. Para que “Preparar Relatório” possa começar no dia 120, o mais tarde que “Analisar
Resultados” pode terminar é no dia 120. Se a TT para “Analisar Resultados” for no dia 120,
40
6
40
Enviar
Questionário e Inserir
Receber Dados de Analisar Preparar
40 Respostas Respostas Resultados Relatório
48 48 113 113 120 120 128 128 138

7 10 11 12 13
40
Steve Jim Jim Jim
65 7 8 10
Testar
Software
50 50
9
Andy
40
5
LEGENDA
Descrição da Atividade
Início Término
mais Cedo mais Cedo
40
40 Responsável
8 Número Estimativa de Duração Número
do Evento do Evento
então, sua IT é dia 112, já que sua duração estimada é de 8 dias. Os cálculos das TTs e ITs
para atividades anteriores são feitos de forma semelhante, percorrendo o diagrama de rede de
forma regressiva.
Observe “Revisar Comentários e Concluir Questionário”. Para que as quatro atividades que
partem dessa atividade possam começar até suas datas IT (para que o projeto possa terminar até
a data de conclusão exigida de 130 dias), “Revisar Comentários e Concluir Questionário” deve
ser terminada até a IT mais cedo das quatro atividades, segundo a Regra 2. A data mais cedo das
quatro ITs é dia 30, a data mais tardia na qual “Imprimir Questionário” deve começar. Portanto,
o mais tarde que “Revisar Comentários e Concluir Questionário” pode terminar é dia 30.

10. O que determina a data de término
de uma atividade em particular?
Se continuar calculando a TT e a IT para cada atividade do diagrama de rede, verá que a

primeira atividade, “Identificar Consumidores-Alvo”, tem uma IT de -8 dias (data negativa)!
FIGURA 6.8 Cronograma para Projeto de Estudo de Mercado Consumidor, Indicando

Datas de Início e Término mais Cedo
Mais Cedo
Est.
Dur.
Atividade Resp. Início Término
1 Identificar Consumidores-Alvo Susan 3 0 3
2 Esboço de Questionário Susan 10 3 13
3 Questionário Teste Piloto Susan 20 13 33
4 Revisar Comentários e Concluir Questionário Susan 5 33 38
5 Preparar Etiquetas para Mala Direta Steve 2 38 40
6 Imprimir Questionário Steve 10 38 48
7 Desenvolver Software de Análise de Dados Andy 12 38 50
8 Desenvolver Dados para Teste de Software Susan 2 38 40
9 Enviar Questionário e Receber Respostas Steve 65 48 113
10 Enviar Questionário e Receber Respostas Andy 5 50 55
11 Inserir Dados de Respostas Jim 7 113 120
12 Analisar Resultados Jim 8 120 128
13 Preparar Relatório Jim 10 128 138
Isso significa que, a fim de concluir todo o projeto até a data de conclusão exigida de 130
dias, o projeto deve começar 8 dias mais cedo do que a previsão inicial. Observe que essa
diferença é igual à que obtivemos quando fizemos os cálculos progressivos no diagrama de
rede para obtermos as datas de IC e TC. Na essência, descobrimos que esse projeto pode
levar 138 dias para terminar, embora seu tempo de conclusão exigido seja de 130 dias.
Assim como as datas de início e término mais cedo, as datas de início e término mais
tarde não costumam ser mostradas no diagrama de rede em si, mas sim em uma tabela de
cronograma separada (veja a Figura 6.12).
Folga Total
No projeto de estudo de mercado consumidor, há uma diferença de oito dias entre a data
de término mais cedo calculada da última atividade (“Preparar Relatório”) e a data de con-
clusão exigida para o projeto. Essa diferença é a folga total (FT), às vezes chamada de
flutuação. Quando for um número negativo, como nesse exemplo, a folga total indica uma
falta de folga ao longo de todo o projeto.
Se a folga total for positiva, representa a quantidade máxima de tempo que pode atrasar
as atividades de determinado caminho sem pôr em risco a conclusão do projeto até a data
exigida. De outro lado, se a folga total for negativa, representa a quantidade de tempo para
acelerar as atividades de um caminho em particular, de modo que o projeto seja concluído
até a data exigida. Se a folga total for zero, as atividades do caminho não precisam ser ace-
leradas, mas também não podem ser atrasadas.
FIGURA 6.9 Datas de Término Mais Tarde
Distribuir
Cartazes
Imprimir 2 10 LEGENDA
Cartazes 20 30 Descrição da
e Panfletos Atividade
Número Estimativa
1 8 Enviar da Atividade de Duração
12 20 Panfletos por Início Término
mais Tarde mais Tarde
Mala Direta
3 5
25 30
(a) Diagrama de Atividades
Distribuir
Cartazes
3
Imprimir 10 30
Cartazes LEGENDA Descrição
20
e Panfletos da Atividade
1 2
12 8 20 Início Término
Enviar mais Tarde
25 Número mais Tarde Número
Panfletos por do Evento Estimativa de Duração do Evento
Mala Direta
4
5 30
(b) Diagrama de Setas

11. Quando um projeto tem uma folga
total positiva, algumas atividades
podem ser _____________________ sem
comprometer a conclusão do projeto
até a data exigida. Quando um projeto
tem uma folga total negativa, algumas
atividades precisam ser ______________
para que o projeto seja concluído até a
data exigida.
A folga total para um caminho de atividades em particular é comum e compartilhada

entre todas as atividades daquele caminho. Considere o projeto diagramado a seguir:
Remover Colocar
Papel de Preparar Papel de
Parede Parede Parede
Antigo Novo
1 7 2 5 3 3

Indicando Datas de Início e Término Mais Tarde (Diagrama de Atividades)
38 40
Preparar
Etiquetas para
Mala Direta
Projeto
Começa 5 Steve 2
em 0
38 40
0 3 3 13 13 33 33 38 38 48
Identificar Revisar
Esboçar Questionário Comentários Imprimir
Consumidores- e Concluir
Questionário Teste Piloto Questionário
Alvo Questionário
–8 –5 –5 5 5 25 25 30 30 40
38 50
Desenvolver
Software de
Análise de Dados
7 Andy 12
88 100
38 40
Desenvolver Dados
para Teste de
Software
8 Susan 2
98 100
O mais cedo que o projeto pode terminar é dia 15 (a soma das durações das três ativida-
des, 7 + 5 + 3). Contudo, a data de conclusão exigida para o projeto é 20 dias. As três ativi-
dades desse caminho podem, portanto, ser atrasadas em até 5 dias sem pôr em risco a con-
clusão do projeto no prazo exigido. Isso não significa que cada atividade do caminho possa
ser atrasada em 5 dias (já que isso iria criar um atraso total de 15 dias); em vez disso, todas
as atividades que compõem o caminho podem ter um atraso total de 5 dias no conjunto.
Por exemplo, se “Remover Papel de Parede Antigo” de fato levar 10 dias (3 a mais do
que os 7 dias estimados), essa atividade usará 3 dos 5 dias de folga total e somente restarão
2 dias da folga total.

12. Folga total é a diferença entre as
datas __________ e as __________.
A folga total é calculada subtraindo-se a data de término (ou início) mais cedo da
atividade de sua data de término (ou início) mais tarde. Isto é, a folga é igual à data de
término mais tarde (TT) menos a data de término mais cedo (IT) para a atividade ou a data
de começo mais tarde (IT) menos a data de começo mais cedo (IC) para aquela atividade.
Os dois cálculos são equivalentes.
Folga Total = TT – TC ou Folga Total = IT – IC
48 113 113 120 120 128 128 138

9 Steve 65 11 Jim 7 12 Jim 8 13 Jim 10
40 105 105 112 112 120 120 130

50 55
Testar
Software
10 Andy 5 LEGENDA
Início Término
100 105 mais Cedo mais Cedo
Descrição
da Atividade
Número Estimativa
Início Término
Responsável
Caminho Crítico
Nem todas as redes são tão simples como a usada para ilustrar a folga total. Em gran-
des diagramas de rede, pode haver vários caminhos de atividades do início até a conclusão
do projeto, assim como há muitas estradas que podem ser usadas para viajar de uma cidade
a outra. Se 20 amigos fossem sair de uma mesma cidade em um mesmo horário para uma
festa em outra cidade, cada um seguindo por uma estrada diferente, eles só poderiam atin-
gir o objetivo depois que a última pessoa chegasse – a que usou a estrada mais longa (ou
mais demorada). De forma semelhante, um projeto não pode ser concluído até que o ca-
minho mais longo (mais demorado) de atividades seja finalizado. Esse caminho mais longo
no diagrama de rede geral é chamado caminho crítico.
Uma forma de se determinar quais atividades compõem o caminho crítico é descobrir
quais têm a menor folga. Subtraia a data de término mais cedo da data de término mais tarde
para cada atividade (ou subtraia a data de início mais cedo da data de início mais tarde – os
dois cálculos fornecerão o mesmo resultado) e depois procure todas as atividades com o
valor mais baixo (o menos positivo ou o mais negativo). Estas estão no caminho crítico de
atividades.
Os valores de folga total para o projeto de estudo de mercado consumidor são apresen-
tados na Figura 6.13. O valor mais baixo é –8 dias. As atividades com esse mesmo valor de
folga total compõem o caminho 1 – 2 – 3 – 4 – 6 – 9 – 11 – 12 – 13. Essas nove atividades
compõem o caminho crítico, ou mais demorado. Sua duração estimada nesse caminho
soma 138 dias (3 + 10 + 20 + 5 + 10 + 65 + 7 + 8 + 10). Entre elas, essas atividades precisam

Mostrando Datas de Início e Término Mais Tarde (Diagrama de Setas)
Preparar
Etiquetas para
Mala Direta
Steve
Projeto 2
Começa
38 38
em 0
Revisar
Esboçar Questionário e Concluir
Consumidores- Questionário Teste Piloto Questionário Imprimir
Alvo
Questionário
0 3 3 13 13 33 33 38 38
1 2 3 4 5
–8 –5 –5 5 5 25 25 30 30 Steve
Susan Susan Susan Susan 10
3 10 20 5
Desenvolver
Software de
Análise de Dados
38
88
Andy
12
98 38
Desenvolver Dados
para Teste de
Software
Susan
2
ser aceleradas em 8 dias para que o projeto seja concluído no tempo exigido de 130 dias.
As Figuras 6.14 e 6.15 ressaltam as atividades que compõem o caminho crítico.

13. O caminho mais longo de atividades
do início ao fim de um projeto é
chamado caminho _____________.
Para eliminar os –8 dias de folga, é preciso que a duração estimada de uma ou mais
atividades nesse caminho crítico seja reduzida. Vamos imaginar uma redução em “Enviar
Questionário e Receber Respostas” de 65 para 55 dias, reduzindo o prazo para os entrevis-
tados devolverem o questionário. Como a duração estimada de uma atividade no caminho
crítico está sendo reduzida em 10 dias, a folga total muda de –8 dias para +2 dias. A estima-
tiva de duração revisada de 55 dias pode ser usada para preparar um cronograma de projeto
revisado, conforme mostrado na Figura 6.16. Esse cronograma mostra que o caminho crítico
agora tem uma folga total de +2 dias; e o projeto está previsto para acabar em 128 dias, dois
dias antes do prazo de conclusão estimado de 130 dias.
40
6
40
40 40

40 40 e Receber Respostas Relatório
de Respostas Resultados
48 48 113 113 120 120 128 128 138

7 10 11 12 13
40 40 40 105 105 112 112 120 120 130
Steve Jim Jim Jim
65 7 8 10
55
Testar
Software
50 50
9
100 100
Andy
5
40 100
LEGENDA
Descrição
da Atividade
Início Término
40 100 mais Cedo mais Cedo
40 Início Término
8 Número
Responsável
Número
da Atividade da Atividade
100 Estimativa de Duração
Como dissemos anteriormente, um diagrama de rede grande pode ter muitos caminhos
ou rotas do início até o fim. Alguns dos caminhos podem ter valores positivos de folga
total; outros podem ter valores negativos de folga total. Os caminhos com valores positivos
de folga total às vezes são chamados caminhos não críticos, enquanto os caminhos com
valor zero ou valores negativos de folga total são chamados de caminhos críticos. Nesse
caso, o caminho mais longo costuma ser chamado de caminho mais crítico.
Folga Livre
Outro tipo de folga que, às vezes, é calculado é a folga livre (FL). É a quantidade de tempo
pelo qual uma atividade em particular pode ser adiada sem atrasar a data de início mais
cedo das atividades imediatamente sucessoras a ela. É a diferença relativa entre as quan-
tidades de folga total para atividades que caminham em direção a uma mesma atividade.
A folga livre é calculada a partir do mais baixo dos valores de folga total para todas as
atividades que caminham em direção a uma atividade em particular e depois subtraindo-o
dos valores de folga total para as outras atividades que também caminham em direção a
essa mesma atividade. Como a folga livre é a diferença relativa entre os valores de folga
total para as atividades que caminham em direção à mesma atividade, ela só existirá quan-
do duas ou mais atividades rumam em direção a uma mesma atividade. Da mesma forma,

Datas de Início e Término mais Tarde
Mais Cedo Mais Tarde

Est.
Dur.
Atividade Resp. Início Fim Início Fim
1 Identificar Consumidores-Alvo Susan 3 0 3 –8 –5
2 Esboçar de Questionário Susan 10 3 13 –5 5
3 Questionário Teste Piloto Susan 20 13 33 5 25
4 Revisar Comentários e Concluir Questionário Susan 5 33 38 25 30
5 Preparar Etiquetas para Mada Direta Steve 2 38 40 38 40
6 Imprimir Questionário Steve 10 38 48 30 40
7 Desenvolver Software de Análise de Dados Andy 12 38 50 88 100
8 Desenvolver Dados para Teste de Software Susan 2 38 40 98 100
9 Enviar Questionário e Receber Respostas Steve 65 48 113 40 105
10 Testar Software Andy 5 50 55 100 105
11 Inserir Dados de Respostas Jim 7 113 120 105 112
12 Analisar Resultados Jim 8 120 128 112 120
13 Preparar Relatório Jim 10 128 138 120 130
como a folga livre é uma diferença relativa entre os valores de folga total, ela é sempre um
valor positivo.
Para uma ilustração de folga livre, veja as Figuras 6.13 e 6.14. No diagrama de rede
(Figura 6.14), existem três casos em que uma atividade em particular possui mais de uma
atividade caminhando em direção a ela:
• A Atividade 9, “Enviar Questionário e Receber Respostas”, tem as atividades 5 e 6 cami-
nhando em direção a ela.
• A Atividade 10, “Testar Software”, tem as atividades 7 e 8 caminhando em direção a ela.
• A Atividade 11, “Inserir Dados de Respostas”, tem as atividades 9 e 10 caminhando em
direção a ela.

14. Consulte as Figuras 6.13 e 6.14.
Das duas atividades que caminham em
direção à atividade 11, “Inserir Dados
de Respostas”, qual atividade tem folga
livre? Qual é seu valor?
No cronograma (Figura 6.13), os valores de folga total para as atividades 5 e 6 são 0 e

-8 dias, respectivamente. O menor desses valores é -8 dias para a atividade 6. A folga livre
para a atividade 5 é a diferença relativa entre sua folga total, 0 e –8. Essa diferença relativa
é de 8 dias: 0 – (–8) = 8 dias. Isso significa que a atividade 5, “Preparar Etiquetas para Mala

Valores de Folga Total
Est. Folga
Dur. Total
1 Identificar Consumidores-Alvo Susan 3 0 3 –8 –5 –8
2 Esboçar Questionário Susan 10 3 13 –5 5 –8
3 Questionário Teste Piloto Susan 20 13 33 5 25 –8
4 Revisar Comentários e Concluir Questionário Susan 5 33 38 25 30 –8
5 Preparar Etiquetas para Mala Direta Steve 2 38 40 38 40 0
6 Imprimir Questionário Steve 10 38 48 30 40 Ð8
7 Desenvolver Software de Análise de Dados Andy 12 38 50 88 100 50
8 Desenvolver Dados para Teste de Software Susan 2 38 40 98 100 60
9 Enviar Questionário e Receber Respostas Steve 65 48 113 40 105 –8
Direta”, tem uma folga livre de 8 dias e pode usar até essa quantidade sem atrasar a data de
início mais cedo da atividade 9, “Enviar Questionário e Receber Respostas”.
De forma semelhante, os valores de folga total para as atividades 7 e 8 são 50 e 60 dias,
respectivamente. O menor desses dois valores é 50 dias. Portanto, a atividade 8, “Desenvol-
ver Software de Análise de Dados”, tem uma folga livre de 10 dias (60 – 50 = 10) e pode
usar até essa quantidade sem atrasar a data de início mais cedo da atividade 10, “Testar
Software”.
CRONOGRAMA PARA DESENVOLVIMENTO DE SISTEMAS DE

INFORMAÇÃO
O Capítulo 5 definiu o sistema de informação (SI) como um sistema baseado em computador
que aceita a entrada de dados, processa esses dados e produz as informações solicitadas pelo
usuário. A elaboração do cronograma para o desenvolvimento de um sistema de informação
é um processo desafiador. Infelizmente, isso costuma ser feito de forma aleatória; assim, uma
grande porcentagem de projetos de SI é concluída muito mais tarde que originalmente pro-
metido ou nem chega a ser finalizada. Um dos fatores mais importantes na elaboração eficaz
de um cronograma é estabelecer estimativas de duração para as atividades o mais realista
possível. Essa não é uma tarefa fácil; contudo, fica mais fácil com a experiência.
Entre os problemas comuns que costumam levar os projetos de desenvolvimento de SI
a serem concluídos após a data de conclusão exigida estão:
• falha por não se identificarem todos os requisitos dos usuários;
• falha por não se identificarem os requisitos dos usuários de forma adequada;
• ampliação contínua do escopo do projeto;

Indicando o Caminho Crítico (Diagrama de Atividades)
Preparar
Etiquetas para
Mala Direta
5 Steve 2
Projeto
Começa
em 0
Identificar Revisar
Esboçar Questionário Comentários Imprimir
Consumidores- Questionário e Concluir
Teste Piloto Questionário
Alvo Questionário
Desenvolver
Software de
Análise de Dados
7 Andy 12
Desenvolver Dados
para Teste de
Software
8 Susan 2
• subestimação das curvas de aprendizado para novos pacotes de software;

• incompatibilidade de hardware;
• falhas na concepção lógica do software;
• seleção inadequada de software;
• incapacidade de selecionar a melhor estratégia de concepção;
• problemas de incompatibilidade de dados;
• não-realização de todas as fases do CVDS.
Exemplo de SI: Desenvolvimento de Aplicativos de Internet

para a ABC Office Designs (cont.)
Recordamos, do Capítulo 5, que a ABC Office Designs tem um grande número de repre-
sentantes de vendas que comercializam móveis de escritório para grandes empresas. Cada
representante de vendas fica responsável por um estado específico, e cada estado faz parte
de uma das quatro regiões do país. Para permitir que os gerentes monitorem o número e a
quantidade de vendas para cada representante, Estado e região, a ABC decidiu desenvolver
um sistema de informação baseado na Internet. Além disso, o SI deve ser capaz de rastrear
preços, estoques e concorrentes.
O Departamento de SI da empresa nomeou Beth Smith como gestora de projeto para
o desenvolvimento do sistema de relatório pela Internet. Primeiramente, Beth identificou
todas as principais tarefas que precisavam ser realizadas e desenvolveu a estrutura analítica
do projeto, a matriz de responsabilidades e o diagrama de rede. Seu próximo passo foi fazer
as estimativas de duração para as atividades. Após várias consultas à equipe de projeto, ela
chegou às estimativas apresentadas na Figura 6.17.

9 Steve 65 11 Jim 7 12 Jim 8 13 Jim 10
Testar
Software
10 Andy 5
LEGENDA
Descrição
da Atividade
Número Estimativa
Responsável
Recordamos, do Capítulo 5, que foram destinados 50 dias a esse projeto, o qual precisa
começar o mais breve possível. Com base na estimativa de duração de cada atividade e nas
datas de início e conclusão exigidas para o projeto, Beth estava pronta para fazer os cálcu-
los das datas de início mais cedo (IC) e término mais cedo (TC) para cada atividade. Esses
valores são apresentados acima de cada atividade na Figura 6.18.
Beth calculou as datas de IC e TC avançando no diagrama de rede. As primeiras tarefas,
“Reunir Dados” e “Estudar Viabilidade”, têm datas de IC igual a 0. Como se espera que “Reu-
nir Dados” leve 3 dias, sua TC é 0 + 3 = 3 dias. Como se espera que “Estudar Viabilidade”
leve 4 dias, sua TC é 0 + 4 = 4 dias. Ela continuou esse processo, avançando pelo diagrama
de rede até que todas as atividades tivessem recebido datas de IC e TC.
Após o cálculo dessas datas, Beth concentrou-se nas datas de IT e TT. O ponto de par-
tida nesse caso foi o tempo no qual o projeto deve ser concluído: 50 dias. As datas de IT e
TT são apresentadas a seguir de cada atividade na Figura 6.19.
Beth calculou as datas de TT e IT movendo-se de forma regressiva no diagrama de
rede. A última tarefa, “Preparar Relatório de Implementação”, tem uma data de TT de 50
– data na qual o projeto precisa ser concluído. Como se espera que “Preparar Relatório
de Implementação” leve um dia, sua IT é 50 – 1 = 49 dias. Isso significa que “Preparar Re-
latório de Implementação” deve ser iniciada até no máximo dia 49, ou o projeto não será
finalizado na data exigida. Ela continuou esse processo, movendo-se de forma regressiva
pelo diagrama de rede até que todas as atividades tivessem recebido datas de TT e IT.
Após os cálculos das datas de IC, TC, IT e TT, Beth calculou a folga total. Esses valores
são apresentados na Figura 6.20. Lembre-se de que a folga total é calculada subtraindo-se a
IC da IT ou subtraindo-se a TC da TT de cada atividade.

Indicando o Caminho Crítico (Diagrama de Setas)
Preparar
Etiquetas para
Mala Direta
Steve
2
Projeto
Começa
em 0
Revisar
Identificar Esboçar Questionário Comentários
e Concluir Imprimir
Consumidores- Questionário Teste Piloto Questionário
Alvo Questionário
1 2 3 4 5
Steve
Susan Susan Susan Susan
10
3 10 20 5
Desenvolver
Software de
Análise de Dados
Andy
12
Desenvolver Dados
para Teste de
Software
Susan
2
Após calcular a folga total para cada atividade, Beth teve de identificar o caminho crítico.
Para o projeto de desenvolvimento de sistema de relatório baseado na Internet, qualquer
atividade com uma folga de –9 está no caminho crítico. A Figura 6.21 mostra o caminho
crítico para esse projeto de desenvolvimento. Nesse ponto, Beth e sua equipe devem de-
terminar uma forma de reduzir o tempo de desenvolvimento em 9 dias ou solicitar que a
data de conclusão do projeto seja estendida de 50 para 59 dias ou chegar a algum outro
tipo de acordo.

Quase todos os pacotes de software de gestão de projetos permitem a realização das fun-
ções de elaboração de cronograma identificadas neste capítulo. Especificamente, a duração
das atividades pode ser estimada em horas, dias, semanas, meses ou anos e, com um cli-
que no mouse, escalas de tempo podem ser facilmente convertidas de dias para semanas,
semanas para dias e assim por diante. As estimativas de duração podem ser facilmente

7 10 11 12 13
40
Steve Jim Jim Jim
65 7 8 10
Testar
Software
9
Andy
5
LEGENDA
Descrição
da Atividade
Responsável
8 Número
Número
da Atividade da Atividade
atualizadas e revisadas. Além disso, sistemas de calendários oferecem ao gestor do projeto

a capacidade de manejar fins de semana, feriados e férias.
As datas de início e término do projeto podem ser inseridas como ocasiões de calendário
específicas (por exemplo, 1º de junho de 2003 ou 31 de dezembro de 2004), ou na forma
de um número global de dias (ou semanas ou meses), sem datas de calendário específicas
atribuídas (por exemplo, o projeto precisa ser concluído até a semana 50). Com a data de
conclusão exigida e a lista de atividades com sua duração estimada, o software calculará
a data até a qual o projeto precisa começar. De forma semelhante, ele calculará a data de
conclusão mais cedo do projeto, com base na data de início real e a lista de atividades com
suas durações estimadas.
O software também calculará datas de IC, TC, IT e TT, a folga total e a folga livre, e
o caminho crítico, tudo com um clique no mouse. É importante, contudo, que o gestor
de projeto entenda o que são esses termos e o que os cálculos significam. Veja o Apên-
dice A ao final do livro para uma discussão mais abrangente sobre softwares de gestão
de projetos.
Projetos de Alto Risco da NASA
Todos os gestores de projetos precisam estar preparados para o inesperado. Isso vale espe-
cialmente para os projetos de alto risco da Nasa. Por exemplo, a espaçonave Gênesis retor-
nou à Terra no dia 8 de setembro de 2004, como já se esperava. No entanto, a aterrissagem
não ocorreu conforme planejado.
Esperava-se que seu mecanismo de pára-quedas funcionasse, para que uma tripu-
lação, em um helicóptero, interceptasse a espaçonave no ar. Mas isso não aconteceu, e a
espaçonave de US$ 264 milhões espatifou-se no solo com uma velocidade estimada de 310
quilômetros por hora.
A horrível aterrissagem comprometeu uma nova pesquisa que estava para começar,
quatro anos depois de a Gênesis ter sido lançada (em agosto de 2001). A espaçonave co-
letou partículas transportadas pelo vento solar no espaço. Essas partículas, que seriam es-
tudadas de perto pela primeira vez, representam as formas de matéria mais primitivas, do
período em que o sistema solar foi formado. As minúsculas amostras de poeira espacial
contêm bilhões de partículas, na forma de átomos, prontas para serem estudadas. Com
esse projeto de pesquisa, planejado para ocorrer durante o ano de 2008, espera-se revelar
informações sobre o sistema solar, relativas à época em que não passava de uma nuvem de
poeira e gás interestelar, 4,5 bilhões de anos antes da formação do Sol e dos planetas.
Assistir à espaçonave Gênesis, de 190 quilos, atingir o solo levou os cientistas a teme-
rem o pior: perder todo seu árduo trabalho e suas novas grandes descobertas sobre o es-
paço. Entretanto, a equipe foi capaz de implementar seu plano de contingência – desenvol-
vido há muito tempo, caso o pára-quedas não funcionasse. O plano de contingência teve
de incluir precauções de segurança. O funcionamento do pára-quedas deveria ocorrer com
o uso de dispositivos explosivos, que, no entanto, acabaram não explodindo. Os responsá-
veis pela recuperação da espaçonave precisaram assegurar que nenhum dos dispositivos
explodisse durante o manejo. A equipe extraiu cuidadosamente amostras dos coletores na
cápsula danificada. Por sorte, o solo desértico tinha sido amaciado por chuvas recentes,
permitindo que a maior parte da espaçonave se mantivesse intacta. Portanto, o conteúdo
da Gênesis pôde ser recuperado, porém é possível que tenha havido contaminação das
amostras, segundo os cientistas.
Sem dúvida, a equipe empregará as lições aprendidas com o projeto da Gênesis ao
próximo projeto: a Stardust. As duas espaçonaves possuem as mesmas estruturas e os mes-
mos mecanismos. Estima-se que a Stardust retorne à Terra em janeiro de 2006, também
por pára-quedas; a espaçonave deverá trazer amostras de partículas do cometa Wild 2, um
corpo gelado do espaço distante. A elaboração antecipada de um plano de contingência
tem ajudado no controle desse projeto – bem como no dos próximos – no que se refere ao
tratamento e à administração de seus riscos.
Britt, R. Lots of Science Intact in Smashed-Up Genesis Capsule. Associated Press, 10 de setembro de 2004.
David, L. Space Probe Fails do Deploy Chute, Slams into Earth. Associated Press, 8 de setembro de 2004.
Malik, T. After the Fall: Genesis Samples to Shed Light on Our Origins. Associated Press, 7 de setembro de 2004.
FIGURA 6.16 Cronograma Revisado para Projeto de Estudo de Mercado Consumidor

Est. Folga
Dur. Total
1 Identificar Consumidores-Alvo Susan 3 0 3 2 5 2
2 Esboçar Questionário Susan 10 3 13 5 15 2
3 Questionário Teste Piloto Susan 20 13 33 15 35 2
4 Revisar Comentários e Concluir Questionário Susan 5 33 38 35 40 2
6 Imprimir Questionário Steve 10 38 48 40 50 2
9 Enviar Questionário e Receber Respostas Steve 55 48 103 50 105 2
11 Inserir Dados de Respostas Jim 7 103 110 105 112 2
12 Analisar Resultados Jim 8 110 118 112 120 2
13 Preparar Relatório Jim 10 118 128 120 130 2
• O responsável por executar cada atividade deve fazer a estimativa de duração para
aquela atividade. Isso gera comprometimento por parte dessa pessoa.
• A estimativa de duração de uma atividade deve se basear na quantidade de recur-
sos que se espera que sejam usados na atividade.
• As estimativas de duração das atividades devem ser agressivas, porém realistas.
• As atividades não devem ter duração maior que os intervalos de tempo nos quais o
progresso real será revisado e comparado ao progresso planejado.
RESUMO
Após o desenvolvimento de um plano para o projeto, o próximo passo é pôr em prática
um cronograma do projeto. A primeira etapa nesse processo é estimar quanto tempo cada
atividade levará, a partir do momento em que é iniciada, até sua conclusão. Normalmente,
é uma boa idéia que a pessoa responsável por uma atividade estime sua duração; contudo,
isso não costuma ser possível no caso de grandes projetos.
A estimativa de duração de uma atividade deve ser baseada na quantidade de recursos
que se espera utilizar para desenvolver essa atividade. A estimativa deve ser agressiva,
porém realista. Uma base de tempo consistente, com horas, dias ou semanas, deve ser usa-
da para todas as estimativas de duração de atividades.
FIGURA 6.17 Lista de Atividades, Antecessores Imediatos e Estimativas de Duração
Antecessores Estimativa de
Atividade
Imediatos Duração (dias)
1. Reunir Dados — 3
2. Estudar Viabilidade — 4
3. Preparar Relatório da Definição de Problema 1, 2 1
4. Entrevistar Usuários 3 5
5. Estudar Sistema Existente 3 8
6. Definir Solicitações de Usuários 4 5
7. Preparar Relatório de Análise do Sistema 5, 6 1
8. Entrada e Saída 7 8
9. Processamento e Base de Dados 7 10
10. Avaliação 8, 9 2
11. Preparar Relatório de Concepção do Sistema 10 2
12. Desenvolvimento do Software 11 15
13. Desenvolvimento do Hardware 11 10
14. Desenvolvimento da Rede 11 6
15. Preparar Relatório de Desenvolvimento do Sistema 12, 13, 14 2
16. Teste do Software 15 6
17. Teste do Hardware 15 4
18. Teste da Rede 15 4
19. Preparar Relatório de Testes 16, 17, 18 1
20. Treinamento 19 4
21. Conversão do Sistema 19 2
22. Preparar Relatório de Implementação 20, 21 1
As datas de início e término mais cedo (IC e TC), e as datas de início e término mais
tarde (IT e TT) podem ser calculadas para cada atividade. As datas IC e TC são calculadas
avançando-se pelo diagrama de rede. A data de início mais cedo para uma atividade é
calculada com base na data de início estimada para o projeto e nas estimativas de duração
para as atividades antecessoras. A data de término mais cedo para uma atividade é calculada
adicionando-se a estimativa de duração da atividade à data de início mais cedo da atividade.
A data de início mais cedo para uma atividade em particular deve ser a mesma data ou pos-
terior à última ocasião de início mais cedo de todas as atividades que apontam diretamente
em direção àquela atividade em particular.
As datas de IT e TT são calculadas de forma regressiva no diagrama de rede. A data de
término mais tarde para uma atividade é calculada com base na data de conclusão exigida
para o projeto e nas estimativas de duração de atividades sucessoras. A data de término
mais tarde é calculada subtraindo-se a estimativa de duração da atividade da data de térmi-
no mais tarde da atividade. A data de término mais tarde para uma atividade em particular
deve ser a mesma data ou anterior a ela, isto é, a data mais cedo de todas as datas de início
mais tarde comprando-se todas as atividades que partem diretamente daquela atividade
em particular.
A folga total para determinado caminho da rede é comum a todas as atividades do ca-
minho e compartilhada por todas elas. Se for positiva, representa a quantidade máxima de
tempo pelo qual as atividades de determinado caminho podem se atrasar sem arriscar a
conclusão do projeto até a data exigida. Se a folga total for negativa, ela representa a quan-
tidade de tempo para acelerar as atividades de um caminho em particular, de modo que o
projeto seja concluído na data exigida. Se for zero, as atividades daquele caminho não pre-
cisam ser aceleradas, mas não podem ser atrasadas. O caminho crítico é o trajeto mais longo
(e mais demorado) de atividades no diagrama de rede e representa uma série de atividades
que não podem ser adiadas sem que o projeto todo seja atrasado.
Elaborar um cronograma para o desenvolvimento de um sistema de informação é um pro-
cesso desafiador. Infelizmente, isso costuma ser feito de forma aleatória, e, assim, uma grande
porcentagem de projetos de SI é concluída muito mais tarde do que originalmente prometi-
do. Um dos fatores mais importantes na elaboração eficaz de um cronograma é estabelecer
estimativas de duração de atividades o mais realista possível. O gestor de projeto deve estar
ciente dos problemas comuns que costumam protelar projetos de desenvolvimento de SI
para além da data de conclusão exigida.
Pacotes de software de gestão de projetos podem ajudar no processo de elaboração de
cronogramas.
PERGUNTAS
1. Por que a função de elaboração de cronogramas depende da função de planejamento?

Qual deve ser feita primeiro? Por quê?
2. Descreva o que é uma estimativa de duração de atividade. Como é determinada? Uma
atividade pode ter uma estimação de duração igual a zero? Justifique sua resposta.
3. Por que um fornecedor pode preferir especificar o tempo de conclusão de um projeto
em termos de número de dias após o início do projeto a usar uma data específica? Dê
alguns exemplos de casos em que isso seria apropriado.
4. Consulte as Figuras 6.6 e 6.7. Por que a data de início mais cedo de “Revisar Comentários
e Concluir Questionário” é o dia 33? Por que a data de término mais cedo é o dia 38?
5. Consulte as Figuras 6.10 e 6.11. Por que a data de início mais tarde para “Enviar Questioná-
rio e Receber Respostas” é o dia 40? Por que a data de término mais tarde é o dia 105?
6. O que significa o termo folga quando aplicado a uma atividade em particular? Qual é a
diferença entre folga positiva e folga negativa? Como ela é calculada?
7. O que significa o termo folga total quando aplicado a um caminho? Quando um cami-
nho é considerado crítico?
8. Por que é importante determinar o caminho crítico de um projeto? O que ocorre se as
atividades desse caminho são atrasadas? O que acontece se as atividades nesse caminho
forem aceleradas?
9. Por que a elaboração de cronograma para projetos de SI é tão desafiadora? Quais são
alguns dos problemas comuns que levam projetos de SI a atrasarem além de suas datas
de conclusão previstas?
10. Calcule as datas de IC, TC, IT e TT e a folga para cada atividade na figura a seguir e iden-
tifique o caminho crítico para o projeto. O projeto pode ser concluído em 40 semanas?
3
B E
10 7
A D G H
1 2 5 6 7
2 15 12 5
C F
8 20
4
FIGURA 6.18 Diagrama de Rede para Projeto de Sistema de Relatório pela Internet,
Mostrando Datas de Início e Término mais Cedo (Diagrama de Atividades)
Projeto
Começa
em 0
0 3 5 10 10 15
Definir
Reunir Entrevistar Solicitações de
Dados Usuários Usuários
1 Beth 3 4 5 4 Jim 5 6 Jeff 5 16 24

Preparar
Relatório da
Definição de Entrada
Problema e Saída
0 4 3 Rose 1 5 13 15 16 26 28
8 Tyler 8
Estudar Estudar Sistema Preparar Relatório
Viabilidade Existente de Análise Avaliação
do Sistema
2 Jack 4 5 Steve 8 7 Jim 1 16 26 10 Cathy 2
Processamento e
Base de Dados
9 Joe 10
Desenvolver
Telas de
Entrada
Projetar 5 8
Entradas
e Saídas
Definição 3 3 Desenvolver
Análise do Testar Implementar
do Relatórios Sistema
Sistema Sistema
Problema de Saída
1 2 2 5 Projetar 6 10 8 6 9 5
Desenvolver
Base de Base
Dados de Dados
4 15 7 2
30 45 47 53
Desenvolvimento Teste do
do Software Software
54 58
12 Hannah 15 16 Maggie 6
Treinamento
28 30 30 40 45 47 47 51 53 54 58 59
20 Jim 4
Preparar Relatório Preparar Relatório Preparar
Desenvolvimento de Teste do Preparar Relatório
de Concepção Desenvolvimento Relatório de
do Hardware Hardware de Implementação
do Sistema do Sistema Testes
11 Sharon 2 13 Joe 10 15 Jack 2 17 Gene 4 19 Rose 1 54 56 22 Jack 1
Conversão do
30 36 47 51 Sistema
Desenvolvimento 21 Beth 2
Teste da Rede
da Rede
14 Gerr i 6 18 Greg 4 Conclusão Solicitada = 50 Dias
LEGENDA Início Término

mais Cedo mais Cedo
Descrição da
Atividade
t
Responsável
C
A 2 6 H
18
3 2 J
1 7 8
G 8 5
B I
5 E 9
3 5
10
D F
7 5
4
Mostrando Datas de Início e Término mais Tarde (Diagrama de Atividades)
Projeto
Começa
em 0
0 3 5 10 10 15
Definir
Reunir Entrevistar Solicitações de
Dados Usuários Usuários
1 Beth 3 4 5 4 Jim 5 6 Jeff 5 16 24

Preparar
–8 –5 Relatório da –4 1 1 6
Problema e Saída
0 4 3 Rose 1 5 13 15 16 26 28
8 Tyler 8
–5 –4
Estudar Estudar Sistema Preparar Relatório
de Análise 9 17
Viabilidade Existente Avaliação
do Sistema
2 Jac k 4 5 Ste ve 8 7 Jim 1 16 26 10 Cathy 2

–9 –5 –2 6 6 7 17 19
Processamento e
Base de Dados
9 Joe 10
7 17
~clements.
1. Procure na Internet ferramentas de programação de projetos e descreva pelo menos

três sites encontrados.
2. Para as questões de 2 a 5, visite Software Program Managers Network (SPMN) em
http://www.spmn.com. Qual é a função da SPMN? Quem administra a SPMN atual-
mente? Explore o site da organização.
3. Clique no link “16 Critical Software Practices” (16 Práticas Críticas de Software). Des-
creva brevemente esses 16 fatores.
4. Clique na seção “Lessons Learned” (Lições Aprendidas) e explore vários links. Explore
o link relacionado a cronogramas. Descreva o que descobriu.
5. Clique no botão “Web Links” do site. Explore e descreva pelo menos três deles.
ESTUDO DE CASO nº 1 Um Centro de Pesquisa Médica sem Fins

Lucrativos
Este estudo de caso é a continuação do caso presente no Capítulo 5.
30 45 47 53
54 58
Treinamento
21 36 38 44
28 30 30 40 45 47 47 51 53 54 58 59
20 Jim 4
Preparar Relatório Preparar Relatório Teste do Preparar
de Concepção Desenvolvimento de Relatório de 45 49 Preparar Relatório
da Rede Desenvolvimento Hardware de Implementação
11 Sharon 2 13 Joe 10 15 Jac k 2 17 Gene 4 19 Rose 1 54 56 22 Jac k 1

19 21 26 36 36 38 40 44 44 45 49 50
Conversão do
30 36 47 51 Sistema
Teste da Rede
do Hardware
47 49
14 Gerr i 6 18 Greg 4
30 36 40 44
mais Cedo mais Cedo
Descrição da
Atividade
Início Término
t
Responsável
PERGUNTAS
1. Elabore uma estimativa de duração para cada atividade.

2. Baseando-se em uma data de início 0 (15 de maio) para um projeto que exige 180 dias
de duração (15 de novembro), calcule as datas de IC, TC, IT e TT, bem como a folga
total de cada atividade. (Observação: se seus cálculos resultarem em cronograma de
projeto com folga total negativa, não faça nenhuma revisão das estimativas de duração
das atividades ou outras alterações na rede. Tais procedimentos serão realizados no
Capítulo 7.)
3. Determine o caminho crítico e identifique as atividades que o compõem.
4. Elabore a estimativa de custos de cada atividade e determine o orçamento total do
projeto.
ATIVIDADE EM GRUPO
Divida os integrantes do curso nos mesmos grupos de três ou quatro pessoas que trabalha-
ram juntas no capítulo anterior e responda às perguntas relacionadas acima.
Observação: O estudo desse caso continuará do Capítulo 7 ao 9; portanto, guarde os
FIGURA 6.20 Cronograma para Projeto de Sistema de Relatório pela Internet


Est. Folga
Dur. Total
Atividade Resp. Início Término Início Término
1 Reunir Dados Beth 3 0 3 –8 –5 –8
2 Estudar Viabilidade Jack 4 0 4 –9 –5 –9
3 Preparar Relatório da Definição de Problema Rose 1 4 5 –5 –4 –9
4 Entrevistar Usuários Jim 5 5 10 –4 1 –9
5 Estudar Sistema Existente Steve 8 5 13 –2 6 –7
6 Definir Solicitações de Usuários Jeff 5 10 15 1 6 –9
7 Preparar Relatório de Análise do Sistema Jim 1 15 16 6 7 –9
8 Entrada e Saída Tyler 8 16 24 9 17 –7
9 Processamento e Base de Dados Joe 10 16 26 7 17 –9
10 Avaliação Cathy 2 26 28 17 19 –9
11 Preparar Relatório de Concepção do Sistema Sharon 2 28 30 19 21 –9
12 Desenvolvimento do Software Hannah 15 30 45 21 36 –9
13 Desenvolvimento do Hardware Joe 10 30 40 26 36 –4
14 Desenvolvimento da Rede Gerri 6 30 36 30 36 0
15 Preparar Relatório de Desenvolvimento do Sistema Jack 2 45 47 36 38 –9
16 Teste do Software Maggie 6 47 53 38 44 –9
17 Teste do Hardware Gene 4 47 51 40 44 –7
18 Teste da Rede Greg 4 47 51 40 44 –7
19 Preparar Relatório de Testes Rose 1 53 54 44 45 –9
20 Treinamento Jim 4 54 58 45 49 –9
21 Conversão do Sistema Beth 2 54 56 47 49 –7
22 Preparar Relatório de Implementação Jack 1 58 59 49 50 –9

Este estudo de caso é a continuação do caso presente no Capítulo 5.
PERGUNTAS
1. Elabore uma estimativa de duração para cada atividade.

2. Baseando-se em uma data de início 0 (1 de janeiro) para um projeto que exige 180 dias
de duração (30 de junho), calcule as datas de IC, TC, IT e TT, bem como a folga total de
cada atividade. (Observação: se seus cálculos resultarem em cronograma de projeto com
folga total negativa, não faça nenhuma revisão das estimativas de duração das atividades
ou outras alterações na rede. Tais procedimentos serão realizados no Capítulo 7.)
3. Determine o caminho crítico e identifique as atividades que o compõem.

4. Elabore a estimativa de custos de cada atividade e determine o orçamento total do
casamento.
ATIVIDADE EM GRUPO
ram juntas no capítulo anterior e responda às perguntas enumeradas anteriormente.
Observação: O estudo desse caso continuará do Capítulo 7 ao 9; portanto, guarde os
APÊNDICE Nº 1 Considerações sobre Probabilidades

ESTIMATIVAS DE DURAÇÃO DAS ATIVIDADES
Lembre-se de que a estimativa de duração para cada atividade é o tempo total decorrido
desde seu início até sua finalização. Em projetos para os quais há alto grau de incerteza
em relação às estimativas de duração das atividades, é possível usar três estimativas para
cada atividade:
1. Tempo otimista (to ) é o tempo no qual uma atividade em particular pode ser con-
cluída se tudo sair perfeitamente bem e não houver complicações. Uma regra prática
é que deve haver apenas uma chance em dez de se concluir a atividade em menos
tempo do que a estimativa otimista.
2. Tempo mais provável (tm ) é o tempo pelo qual uma atividade em particular pode
geralmente ser completada sob condições normais. Se uma atividade foi repetida
muitas vezes, a duração real que ocorre com mais freqüência pode ser usada como
a estimativa de tempo mais provável.
3. Tempo pessimista (tp ) é o tempo no qual uma atividade em particular pode ser con-
cluída sob condições adversas, como na presença de complicações incomuns ou
imprevistas. Uma regra prática é que há apenas uma chance em dez de se concluir a
atividade em mais tempo do que a estimativa de tempo pessimista.
O estabelecimento de três estimativas de tempo possibilita levar a incerteza em consi-
deração ao se estimar quanto tempo cada atividade levará. O tempo mais provável deve
ser maior ou igual ao tempo otimista e o tempo pessimista deve ser maior ou igual ao
tempo mais provável.
Não é necessário que três estimativas de tempo sejam feitas para cada atividade. Se al-
guém tiver vasta experiência ou dados de quanto tempo demorou a execução de atividades
bastante semelhantes em projetos já concluídos, pode ser preferível fazer apenas uma es-
timativa de quanto tempo se espera de uma atividade (conforme discutido neste capítulo).
Contudo, usar três estimativas de tempo (to, tm e tp ) pode ser útil quando houver alto grau
de incerteza sobre quanto tempo uma atividade pode levar.
DISTRIBUIÇÃO BETA DE PROBABILIDADES

No planejamento de rede, quando três estimativas de tempo são usadas para cada ativida-
de, assume-se que as três estimativas seguem uma distribuição beta de probabilidades.
Com base nessa suposição, é possível calcular uma duração esperada (também chamada
de média), te , para cada atividade, a partir das três estimativas de tempo. A duração espera-
da é calculada usando-se a fórmula a seguir:
to + 4(tm ) + t p
te =
6
Mostrando o Caminho Crítico (Diagrama de Atividades)
Projeto
Começa
em 0
0 3 5 10 10 15
Definir
Reunir Entrevistar
Solicitações de
Dados Usuários
Usuários
1 Beth 3 4 5 4 Jim 5 6 Jeff 5 16 24

Preparar
–8 –5 Relatório da –4 1 1 6
Problemat
e Saída
0 4 3 Rose 1 5 13 15 16 26 28
8 Tyler 8
–5 –4 Preparar Relatório
Estudar Estudar Sistema 9 17
Existente de Análise Avaliação
Viabilidade do Sistema
2 Jac k 4 5 Steve 8 7 Jim 1 16 26 10 Cathy 2

–9 –5 –2 6 6 7 17 19
Processamento e
Base de Dados
9 Joe 10
7 17
Suponha que o tempo otimista para uma atividade seja de uma semana, o tempo mais
provável seja de 5 semanas e o tempo pessimista seja de 15 semanas. A distribuição beta de
probabilidades é mostrada na Figura 6.22. A duração esperada para essa atividade é:
1 + 4(5) + 15
te = = 6 semanas
6
Suponha que o tempo otimista para outra atividade seja de 10 semanas, o tempo mais
provável seja de 15 semanas e o tempo pessimista seja de 20 semanas. A distribuição beta
de probabilidades é mostrada na Figura 6.23. A duração esperada para essa atividade é:
10 + 4(15) + 20
te = = 15 semanas
6
Coincidentemente, isso equivale à estimativa de tempo mais provável.

15. Calcule a duração esperada para
uma atividade que tenha as seguintes
estimativas de tempo: t0 = 8, tm = 12
e tp = 22
Os picos das curvas nas Figuras 6.22 e 6.23 representam os tempos mais prováveis para
suas respectivas atividades. A duração esperada, te, divide a área total sob a curva beta de
probabilidades em duas partes iguais. Em outras palavras, 50% da área sob qualquer cur-
va beta de probabilidades ficarão à esquerda de te e 50% ficarão à direita. Por exemplo, a
Figura 6.22 mostra que 50% da área sob a curva ficam à esquerda de 6 semanas e 50% da
30 45 47 53
54 58
Treinamento
21 36 38 44
28 30 30 40 45 47 47 51 53 54 58 59
20 Jim 4
Preparar Relatório Preparar Relatório Preparar
Desenvolvimento de Teste do 45 49 Preparar Relatório
de Concepção Desenvolvimento Relatório de de Implementação
do Hardware Hardware
11 Sharon 2 13 Joe 10 15 Jack 2 17 Gene 4 19 Rose 1 54 56 22 Jack 1

19 21 26 36 36 38 40 44 44 45 49 50
Conversão do
30 36 47 51 Sistema
da Rede Teste da Rede
47 49
14 Gerr i 6 18 Greg 4
30 36 40 44
mais Cedo mais Cedo
Descrição da
Atividade
Início Término
t
Responsável
área ficam à direita de 6 semanas. Então, há uma probabilidade de 50% de que uma atividade
de fato leve mais ou menos tempo que sua duração esperada. Dito de outra forma, há uma
probabilidade de 0,5 de que uma atividade leve mais tempo que te , e uma probabilidade de
0,5 de que uma atividade leve menos tempo que te = 8, tm = 12 e tp = 22. Na Figura 6.22, exis-
te 50% de probabilidade de que uma atividade levará de fato mais que 6 semanas e existe 50%
de probabilidade de que ela levará de fato menos que 6 semanas.
FIGURA 6.22 Distribuição Beta de Probabilidades

Probabilidade
1 5 6 15
to tm te tp
Tempo Estimado
FIGURA 6.23 Distribuição Beta de Probabilidades
Probabilidade
10 15 20
to tm tp
te
Tempo Estimado
Assume-se que, à medida que um projeto avança, algumas atividades levarão menos
tempo que sua duração esperada e algumas atividades levarão mais tempo que sua duração
esperada. Também se assume que, quando todo o projeto estiver concluído, a diferença
líquida total entre todas as durações esperadas e as reais será mínima.
FUNDAMENTOS DE PROBABILIDADE
O planejamento de rede no qual três estimativas de tempo são usadas para cada atividade
pode ser considerado uma técnica estocástica, ou probabilística, que permite a incorpora-
ção de incerteza na duração da atividade por meio de três estimativas que se supõe sejam
distribuídas segundo a distribuição beta de probabilidades. Qualquer técnica que utilize
apenas uma estimativa de tempo é considerada uma técnica determinística. Como assumi-
mos por hipótese que as três estimativas de tempo para cada atividade seguem uma distri-
buição beta de probabilidades, é possível calcular a probabilidade de que o projeto seja de
fato concluído antes da data exigida. Se apenas uma estimativa de tempo for utilizada para
cada atividade, não podem ser feitos cálculos de probabilidade.
Quando três estimativas de tempo são usadas, todas as atividades no caminho crítico do
diagrama de rede podem ser adicionadas para se obter uma distribuição de probabilidade
total. O teorema do limite central da teoria das probabilidades afirma que essa distribuição
de probabilidade total não é uma distribuição beta de probabilidades, e sim uma distri-
buição normal de probabilidades, que tem forma de sino e é simétrica em relação ao
seu valor médio. Além disso, essa distribuição de probabilidades total tem uma duração
esperada que é igual à soma das durações esperadas de todas as atividades que formam a
distribuição total. Também tem uma variância que é igual à soma das variâncias de todas
as atividades que compõem a distribuição total.
A variância para a distribuição de probabilidade beta de uma atividade é encontrada
usando-se a fórmula a seguir:
⎛t p = to ⎞⎟2
Variância = σ = ⎜⎜⎜
2
⎟
⎜⎝ 6 ⎠⎟⎟
Observe que a variância da distribuição normal é a soma das variâncias da distribui-

ção beta.

16. Calcule a duração esperada te e a
variância σ2 para a distribuição beta de
probabilidades a seguir.
5 8 23
to tm tp
Enquanto a duração esperada – que divide a área sob a distribuição de probabilidade

em duas partes iguais – é uma medida da tendência central de uma distribuição, a va-
riância é uma medida da dispersão de uma distribuição em relação a seu valor esperado.
O desvio padrão, σ , é outra medida da dispersão de uma distribuição e é igual à raiz
quadrada da variância. O desvio padrão proporciona uma representação visual melhor
da dispersão de uma distribuição em relação ao valor médio, ou esperado, que a variância.
Para uma distribuição normal (veja a Figura 6.24), a área dentro de um desvio-padrão
da média (para os dois lados) inclui aproximadamente 68% da área total sob a curva,
a área dentro de dois desvios padrão inclui aproximadamente 95% da área total sob a
curva e a área dentro de três desvios padrão inclui aproximadamente 99% da área total
sob a curva.

17. Qual porcentagem da área sob essa
curva normal está sombreada?
Mean +1σ
FIGURA 6.24 Distribuição Normal de Probabilidades
–3σ –2σ –1σ Média +1σ +2σ +3σ

68%
95%
99%
Conforme observado anteriormente, o desvio padrão é uma medida da dispersão de

uma distribuição. A Figura 6.25 mostra duas distribuições normais. A distribuição em (a) da
Figura 6.25 é mais dispersa e, conseqüentemente, tem um desvio padrão maior que em (b).
Contudo, para as duas distribuições, 68% da área sob a curva estão incluídas dentro de um
desvio padrão da média.
A distribuição de probabilidade total de todas as atividades no caminho crítico de um
diagrama de rede é uma distribuição normal, com média igual à soma das durações es-
peradas de atividades individuais e variância igual à soma das variâncias das atividades
individuais. Considere a rede simples da Figura 6.26. Assuma que o projeto pode começar
no tempo 0 e deve ser concluído até o dia 42. As distribuições de probabilidade para as
atividades da Figura 6.26 são apresentadas na Figura 6.27.
A duração esperada para cada atividade é a seguinte:
2 + 4(4) + 6
Atividade A te = = 4 dias
6
5 + 4(13) + 15
Atividade B te = = 12 dias
6
13 + 4(18) + 35
Atividade C te = = 20 dias
6
Total = 36 dias

18. Se 95% da área sob a curva normal
a seguir estiver entre os dois pontos
indicados, qual é o desvio padrão?
Qual é a variância?
12 Média 32
95%
Se somarmos as três distribuições, iremos obter uma média total ou te total:

Atividade to tm tp
A 2 4 6
B 5 13 15
C 13 18 35
Total 20 35 36
20 + 4(35) + 56
Total = t e = = 36 dias
6
Esse resultado é o mesmo que a soma das três durações esperadas individuais calculadas
anteriormente: 4 + 12 + 20 = 36 dias. A distribuição total de probabilidades é mostrada em
(d) da Figura 6.27. A duração esperada total para o caminho 1-2-3-4 é de 36 dias. Assim, o
projeto tem um tempo de conclusão esperado mais cedo no dia 36. Conforme observado an-
teriormente, a data de conclusão exigida para o projeto é o dia 42.
A distribuição total tem um tempo decorrido médio igual à soma das três médias indivi-
duais, ou durações esperadas. Existe uma probabilidade de 0,5 de que o projeto será con-
cluído antes do dia 36, e uma probabilidade de 0,5 de que será concluído após o dia 36.
FIGURA 6.25 Distribuições Normais de Probabilidades
–1σ +1σ –1σ +1σ
(a) (b)
FIGURA 6.26 Projeto Exemplo
A B C
1 2 3 4
2–4–6 5–13–15 13–18–35
4 12 20
FIGURA 6.27 Distribuições de Probabilidades
Atividade A Atividade B
Probabilidade
2 4 6 5 12 13 15
to tm tp to te tm tp
te
(a) (b)
Atividade C Total
13 18 20 35 36
to tm te tp te
(c) (d)
Para o exemplo simples da Figura 6.26, as variâncias para as distribuições beta das três
atividades são as seguintes:
⎛ 6 − 2 ⎞⎟2
σ = ⎜⎜
2
= 0, 444
⎜⎝ 6 ⎠⎟⎟
Atividade A
⎛ 15 − 5 ⎞⎟2
σ = ⎜⎜
2
= 2, 778
⎜⎝ 6 ⎠⎟⎟
Atividade B
⎛ 35 − 13 ⎞⎟2
σ = ⎜⎜
2
Atividade C ⎟ = 13, 444
⎜⎝ 6 ⎠⎟
Total = 16, 666
A variância para a distribuição total, que é uma distribuição de probabilidade normal, é a

soma das três variâncias individuais ou 16,666. O desvio padrão, σ, da distribuição total é:
2
Desvio padrão = σ = σ = 16, 666 = 4, 08 dias
A Figura 6.28, assim como (d) da Figura 6.27, mostra a curva de probabilidade total com
a adição dos desvios padrão.
A Figura 6.28 é uma curva normal, então, 68% de sua área total estão contidas dentro de
±1σ (desvio padrão) de te ou entre 31,92 dias e 40,08 dias; 95% de sua área estão entre 27,84
dias e 44,16 dias; e 99% de sua área estão entre 23,76 dias e 48,24 dias. Essa distribuição de
probabilidade pode ser interpretada da seguinte forma:
• Existe uma chance de 99% (probabilidade de 0,99) de que o projeto seja concluído
de 23,76 a 48,24 dias.
de 27,84 a 44,16 dias.
• Existe uma chance de 47,5% (probabilidade de 0,475) de que o projeto seja concluído
de 27,84 a 36 dias.
de 36 a 44,16 dias.
de 31,92 a 40,08 dias.
de 31,92 a 36 dias.
de 36 a 40,08 dias.
FIGURA 6.28 Distribuição de Probabilidade Normal para Projeto Amostra
1σ 1σ
2σ 2σ
3σ 3σ
23.76 31.92 36 40.08 48.24

27.84 44.16
de 27,84 a 31,92 dias.
de 40,08 a 44,16 dias.
antes de 23,76 dias.
após 48,24 dias.
Assim, pode-se afirmar que o quociente entre o valor da área sob certas partes da curva
normal pela área total sob a curva está relacionado à probabilidade.
CÁLCULO DE PROBABILIDADES
A data de término mais cedo esperada para um projeto é determinada pelo caminho crítico
do diagrama de rede. É igual à data inicial programada para o projeto mais a soma das du-
rações esperadas das atividades do caminho crítico do início ao fim do projeto. Conforme
afirmado anteriormente, a probabilidade de que o projeto seja de fato concluído antes da
data de término mais cedo esperada é de 0,5, porque metade da área sob a curva de dis-
tribuição normal fica à esquerda dessa data esperada; a probabilidade de que o projeto
seja de fato concluído após data de término mais cedo esperada também é de 0,5, porque
metade da área sob a curva normal fica à direita dessa data esperada. Conhecer a data de
conclusão exigida para um projeto possibilita o cálculo da probabilidade de que o projeto
seja de fato concluído antes dessa data.
A fim de encontrar a probabilidade de que o projeto seja de fato concluído antes de sua
data de conclusão exigida, usa-se a seguinte fórmula:
TT − TC
Z =
σt
Os elementos são os seguintes:
• TT é a data de conclusão exigida (término mais tarde) para o projeto.
• TC é a data de término mais cedo esperada para o projeto (média da distribuição
normal).
• σt é o desvio padrão da distribuição total das atividades no caminho mais longo (de
maior duração de tempo), que leva à conclusão do projeto.
Na equação anterior, Z mede o número de desvios padrão entre TC e TT na curva de
probabilidade normal. Esse valor deve ser convertido em um número que indique a propor-
ção da área sob a curva normal que fica entre TC e TT. Como a área total sob uma curva
normal é igual a 1,0, a probabilidade de finalizar o projeto antes da data de conclusão exi-
gida é igual à proporção da área sob a curva localizada à esquerda da TT.
A data de término mais cedo (TC) esperada para a rede simples de três atividades na
Figura 6.26 foi calculada como 36 dias. Lembre-se de que a data de conclusão exigida (TT)
para o projeto é 42 dias ou 6 dias mais tarde que a TC. A Figura 6.29 mostra a curva normal
para o projeto, com TC = 36 dias e TT = 42 dias.
A proporção da área sob a curva à esquerda de TT é igual à probabilidade de que o pro-
jeto seja concluído antes de 42 dias. A TC divide a área sob a curva em duas partes iguais,
cada uma contendo metade da área; portanto, sabemos que a proporção da área à esquerda
de TC é de 0,5. Devemos agora encontrar a proporção da área entre TC e TT e adicionar
esse valor a 0,5, para obter a proporção da área total à esquerda de TT. Usando a equação
anterior para encontrar a proporção da área entre TC e TT, podemos calcular Z:
TT − TC 42 − 36 6
Z = = = = 1, 47
σt 4, 08 4, 08
FIGURA 6.29 Distribuição Normal de Probabilidades para Exemplo de Projeto
36 42
TC TT
O valor de 1,47 para Z indica que existe 1,47 de desvio padrão (1 desvio padrão de 4,08
dias) entre TC e TT. Contudo, o valor de Z não fornece diretamente a proporção da área sob
a curva entre TC e TT. A fim de encontrarmos essa área, devemos converter o valor de Z
em um número que forneça a área diretamente, usando uma tabela de conversão-padrão,
como a Tabela 6.1.
A primeira coluna e a linha superior da tabela são usadas para encontrar o valor de Z de-
sejado com uma significância de 0,01. Para encontrar a área para um valor de Z de 1,47, pri-
meiro desça na coluna da extrema esquerda até 1,4; em seguida, siga horizontalmente nessa
linha até a coluna 0,07. O número é 0,42922. Isso significa que, para um valor de Z de
1,47, a proporção da área sob a curva normal é de 0,42922. Esse valor revela que a proba-
bilidade de que o projeto seja de fato concluído entre TC e TT, ou entre 36 e 42 dias, é de
0,42922; assim, existe uma probabilidade de 42,922%. Contudo, como estamos interessados
em descobrir a probabilidade de que o projeto seja de fato concluído a qualquer momento
antes de 42 dias, devemos somar a ele a probabilidade de conclusão antes de 36 dias. A
probabilidade de que o projeto seja concluído a qualquer momento antes de 42 dias é igual
à probabilidade de que ele seja concluído antes de 36 dias mais a probabilidade de que seja
concluído entre 36 e 42 dias:
0,50000 + 0,42922 = 0,92922
A probabilidade de que o projeto seja de fato concluído antes de sua data de conclusão exigida
de 42 dias é de 0,92922, ou seja, há uma chance de 92,922%.
RESUMO
Se cada atividade do diagrama de rede para um projeto tiver três estimativas de tempo (oti-
mista, mais provável e pessimista), é possível calcular a probabilidade de que o projeto seja
de fato concluído antes da data de conclusão exigida usando os métodos discutidos neste
apêndice. Contudo, devemos ter cuidado ao interpretarmos essa probabilidade, principal-
mente quando existem vários caminhos que são quase tão longos quanto o caminho crítico.
Se os desvios-padrão desses caminhos alternativos são consideravelmente diferentes daquele do
caminho crítico, a probabilidade de que o projeto seja de fato concluído antes de sua data
de conclusão exigida pode ser mais baixa quando esses caminhos são usados nos cálculos de
probabilidade do que quando se usa o caminho crítico. Essa discrepância normalmente sur-
ge quando dois ou mais caminhos que são iguais ou quase iguais em comprimento levam à
conclusão do projeto.
TABELA 6.1 Tabela de Áreas da Curva Normal entre a Ordenada Máxima e os

Valores de Z
Z 0,00 0,01 0,02 0,03 0,04 0,05 0,06 0,07 0,08 0,09
0.0 0,00000 0,00399 0,00798 0,01197 0,01595 0,01994 0,02392 0,02790 0,03188 0,03586
0.1 0,03983 0,04380 0,04776 0,05172 0,05567 0,05962 0,06356 0,06749 0,07142 0,07535
0.2 0,07926 0,08317 0,08706 0,09095 0,09483 0,09871 0,10257 0,10642 0,11026 0,11409
0.3 0,11791 0,12172 0,12552 0,12930 0,13307 0,13683 0,14058 0,14431 0,14803 0,15173
0.4 0,15542 0,15910 0,16276 0,16640 0,17003 0,17364 0,17724 0,18082 0,18439 0,18793
0.5 0,19146 0,19497 0,19847 0,20194 0,20540 0,20884 0,21226 0,21566 0,21904 0,22240
0.6 0,22575 0,22907 0,23237 0,23565 0,23891 0,24215 0,24537 0,24857 0,25175 0,25490
0.7 0,25804 0,26115 0,26424 0,26730 0,27035 0,27337 0,27637 0,27935 0,28230 0,28524
0.8 0,28814 0,29103 0,29389 0,29673 0,29955 0,30234 0,30511 0,30785 0,31057 0,31327
0.9 0,31594 0,31859 0,32121 0,32381 0,32639 0,32894 0,33147 0,33398 0,33646 0,33891
1.0 0,34134 0,34375 0,34614 0,34850 0,35083 0,35314 0,35543 0,35769 0,35993 0,36214
1.1 0,36433 0,36650 0,36864 0,37076 0,37286 0,37493 0,37698 0,37900 0,38100 0,38298
1.2 0,38493 0,38686 0,38877 0,39065 0,39251 0,39435 0,39617 0,39796 0,39973 0,40147
1.3 0,40320 0,40490 0,40658 0,40824 0,40988 0,41149 0,41309 0,41466 0,41621 0,41774
1.4 0,41924 0,42073 0,42220 0,42364 0,42507 0,42647 0,42786 0,42922 0,43056 0,43189
1.5 0,44319 0,43448 0,43574 0,43699 0,43822 0,43943 0,44062 0,44179 0,44295 0,44408
1.6 0,44520 0,44630 0,44738 0,44845 0,44950 0,45053 0,45154 0,45254 0,45352 0,45449
1.7 0,45543 0,45637 0,45728 0,45818 0,45907 0,45994 0,46080 0,46164 0,46246 0,46327
1.8 0,46407 0,46485 0,46562 0,46638 0,46712 0,46784 0,46856 0,46926 0,46995 0,47062
1.9 0,47128 0,47193 0,47257 0,47320 0,47381 0,47441 0,47500 0,47558 0,47615 0,47670
2.0 0,47725 0,47778 0,47831 0,47882 0,47932 0,47982 0,48030 0,48077 0,48124 0,48169
2.1 0,48214 0,48257 0,48300 0,48341 0,48382 0,48422 0,48461 0,48500 0,48537 0,48574
2.2 0,48610 0,48645 0,48679 0,48713 0,48745 0,48778 0,48809 0,48840 0,48870 0,48899
2.3 0,48928 0,48956 0,48983 0,49010 0,49036 0,49061 0,49086 0,49111 0,49134 0,49158
2.4 0,49180 0,49202 0,49224 0,49245 0,49266 0,49286 0,49305 0,49324 0,49343 0,49361
2.5 0,49377 0,49396 0,49413 0,49430 0,49446 0,49461 0,49477 0,49492 0,49506 0,49520
2.6 0,49534 0,49547 0,49560 0,49573 0,49585 0,49598 0,49609 0,49621 0,49632 0,49643
2.7 0,49653 0,49664 0,49674 0,49683 0,49693 0,49702 0,49711 0,49720 0,49728 0,49736
2.8 0,49744 0,49752 0,49760 0,49767 0,49774 0,49781 0,49788 0,49795 0,49801 0,49807
2.9 0,49813 0,49819 0,49825 0,49831 0,49836 0,49841 0,49846 0,49851 0,49856 0,49861
3.0 0,49865 0,49869 0,49874 0,49878 0,49882 0,49886 0,49889 0,49893 0,49897 0,49900
3.1 0,49903 0,49906 0,49910 0,49913 0,49916 0,49918 0,49921 0,49924 0,49926 0,49929
3.2 0,49931 0,49934 0,49936 0,49938 0,49940 0,49942 0,49944 0,49946 0,49948 0,49950
3.3 0,49952 0,49953 0,49955 0,49957 0,49958 0,49960 0,49961 0,49962 0,49964 0,49965
3.4 0,49966 0,49968 0,49969 0,49970 0,49971 0,49972 0,49973 0,49974 0,49975 0,49976
3.5 0,49977 0,49978 0,49978 0,49979 0,49980 0,49981 0,49981 0,49982 0,49983 0,49983
3.6 0,49984 0,49985 0,49985 0,49986 0,49986 0,49987 0,49987 0,49988 0,49988 0,49989
3.7 0,49989 0,49990 0,49990 0,49990 0,49991 0,49991 0,49992 0,49992 0,49992 0,49992
3.8 0,49993 0,49993 0,49993 0,49994 0,49994 0,49994 0,49994 0,49995 0,49995 0,49995
3.9 0,49995 0,49995 0,49996 0,49996 0,49996 0,49996 0,49996 0,49996 0,49997 0,49997
4.0 0,49997 0,49997 0,49997 0,49997 0,49997 0,49997 0,49998 0,49998 0,49998 0,49998
PERGUNTAS
1. Verdadeiro ou falso: a fim de calcularmos a probabilidade de que um projeto seja

concluído antes da data de conclusão exigida, é necessário termos três estimativas de
tempo para cada atividade e a data de conclusão exigida para o projeto.
2. Quais são a duração esperada, a variância e o desvio padrão para uma atividade cujas
estimativas de três tempos sejam t0 = 2, tm = 14 e tp = 14?
3. Qual dos seguintes não é uma medida de dispersão de uma distribuição: variância,
média ou desvio padrão?
4. A data de término mais cedo esperada para um projeto é de 138 dias e sua data de
conclusão exigida é de 130 dias. Qual é a probabilidade de que o projeto seja conclu-
ído antes da data exigida se σt (o desvio padrão da distribuição total das atividades no
caminho mais longo) for 6?
APÊNDICE Nº 2 Microsoft Project

Neste apêndice, discutiremos como o Microsoft Project pode ser utilizado para apoiar as
técnicas discutidas neste capítulo, utilizando o exemplo do estudo de mercado consumidor.
Para recuperar informações de seu projeto, no menu File, clique em Open e encontre o
arquivo sobre estudo de mercado consumidor. Agora estamos prontos para introduzir as
durações estimadas para cada tarefa, conforme discutido neste capítulo.
FIGURA 6A.1 Acrescentar Data de Duração e Mostrar o Caminho Crítico
Introduza os dados diretamente na coluna Duration. Veja a Figura 6A.1 para dados de
duração. Repare que, ao introduzir a duração de cada tarefa, a unidade de tempo-padrão é
“d” para dias. Você pode incluir “m” depois do número para representar minutos; “h” para
horas; “d” para dias; “w” para semanas ou “mon” para meses. Por exemplo, uma entrada
“2w” corresponde a uma estimativa de duração para duas semanas. Ao modificar as es-
timativas de duração, o sistema automaticamente atualiza as datas de início e término de
cada tarefa.
Atente para o gráfico de Gantt atualizado da Figura 6A.1. As dependências entre as ta-
refas são indicadas por setas. Você pode realçar o caminho crítico em vermelho. Para isso,
no menu Format, selecione o assistente Gráfico de Gantt e utilize o realce vermelho para
exibir o caminho crítico dessa forma.
Para criar a Visualização de Calendário da Figura 6A.2, selecione “Calendar” no menu
View. Desse modo, você poderá visualizar cada semana e, ao mesmo tempo, as tarefas do
cronograma.
No capítulo anterior, você aprendeu como criar dois gráficos PERT diferentes; um Dia-
grama de Relações simples e um Diagrama de Rede padrão. Você também pode produzir
um diagrama de rede mais detalhado. No menu View, selecione More Views, mostrado na
Figura 6A.3, e selecione Descriptive Network Diagram na lista. O mesmo diagrama da Figu-
ra 6A.4 deverá ser mostrado.
Repare que o caminho crítico no diagrama PERT também é exibido em vermelho.
FIGURA 6A.2 Visualização de Calendário
FIGURA 6A.3 Visualizações Adicionais do Menu de Visualização
O Microsoft Project 2003 calculou as datas de início e término mais cedo e mais tarde
para cada tarefa. Para saber esses valores, você precisa ver a Schedule Table (Tabela de Cro-
nograma) na visualização do Gráfico de Gantt. Comece com a visualização do Gráfico de
Gantt. No menu View, clique em Gantt Chart. Em seguida, também no menu View, aponte
para Table e clique em Schedule. A tabela da Figura 6A.5 deverá aparecer.
Você pode solicitar um relatório de todas as tarefas críticas do projeto de Estudo de
Mercado Consumidor. No menu View, clique em Reports. Essa janela deverá aparecer, con-
tendo um menu para os tipos de relatório, como na Figura 6A.6. Escolha Overview, clique
em “Select” e selecione Critical Tasks. O Relatório de Tarefas Críticas deverá aparecer, como
na Figura 6A.7.
FIGURA 6A.4 Diagrama de Rede Descritivo
FIGURA 6A.5 Visualização de Gráfico de Gantt/ Tabela de Cronograma
FIGURA 6A.6 Pré-Visualização de um Relatório a Ser Impresso
FIGURA 6A.7 Relatório de Tarefas Críticas
Capítulo CONTROLE DO CRONOGRAMA
7 Processo de Controle de Projetos

Efeitos do Desempenho do
Cronograma Real
Incorporando Mudanças do
Perguntas
de Pesquisa Médica sem Fins
Projeto ao Cronograma Lucrativos
Atualizando o Cronograma do Perguntas
Projeto Atividade em Grupo
Abordagens para Controle do Estudo de Caso no 2 O Casamento
Cronograma
Perguntas
Controle de Cronograma para
Atividade em Grupo
Desenvolvimento de Sistemas de
Informação Apêndice no 1 Compensação de
Tempo-Custo
Exemplo de SI: Desenvolvimento
de Aplicativos de Internet para Resumo
a ABC Office Designs (cont.) Perguntas
Software de Gestão de Projetos Apêndice no 2 Microsoft Project
Resumo
190
Ca pítulo S e te
Receita Federal Norte-Americana (IRS)
A Receita Federal Norte-Americana (Internal Revenue Service – IRS) tem atualizado sua in-
fra-estrutura de TI e aplicativos de negócios por meio de seu programa de Modernização
de Sistemas de Negócios (BSM). Esse projeto de US$ 8 bilhões inclui o novo Customer Ac-
count Data Engine (CADE), que armazenará as informações de todos os contribuintes nor-
te-americanos. O CADE será uma nova base de dados centralizada que substituirá a atual
base de dados Master File, criada em 1962. O IRS espera que o CADE proporcione mais agi-
lidade no processamento das declarações e restituições a cerca de 30% dos contribuintes.
Todo o programa de modernização deve ajudar o IRS a conduzir auditorias em tempo hábil,
a proporcionar um serviço de qualidade ao cliente e a diminuir os custos das operações.
A conquista dessas metas tem sido lenta e cara. Em cinco anos de projeto, o CADE já
está com o cronograma atrasado em quase três anos e 40% acima do orçamento. Uma das
razões principais para o atraso do cronograma e para o orçamento ultrapassado é a falta
de comunicação entre o IRS e a empresa contratada para desenvolver o novo sistema. Nas
primeiras etapas do projeto, o IRS não atribuiu adequadamente as responsabilidades para
esse projeto dentro da organização. Além disso, gerentes de nível médio e usuários do
sistema não foram consultados.
Na verdade, o fornecedor recebeu pouca orientação por parte do IRS e, portanto, não
compreendeu direito os processos de negócios do IRS nem definiu adequadamente os re-
quisitos do sistema. O fornecedor também foi incapaz de fazer as devidas estimativas de
custo e cronograma para o projeto e, desse modo, não avaliou completamente os riscos
do projeto. O que também contribuiu para o resultado insatisfatório foi o fato de que, ao
abandonar os próprios protocolos de desenvolvimento de projeto, o IRS aprovou os com-
ponentes do sistema sem os testes adequados de requisitos. Como resultado, requisitos
importantes de concepção do sistema não foram atendidos. Os gerentes de nível médio
solicitaram muitas mudanças personalizadas que não se ajustavam aos padrões estabele-
cidos para o novo sistema.
O IRS tomou as seguintes providências para solucionar os problemas: a unidade de
negócios do IRS agora é responsável pelo programa BSM; os funcionários ficaram respon-
sáveis pelos projetos específicos e os usuários finais agora gastam mais tempo fornecendo
feedback sobre o sistema. Ao organizar melhor as práticas de gestão de projetos, o IRS es-
pera que o projeto de atualização do sistema possa ser concluído o mais breve possível.
Johsonston, D. At I.R.S., a Systems Update Gone Awry. New York Times, 11 de dezembro de 2003, p. C1.
Varon, E. For the IRS There’s No EZ Fix. CIO, 1o de abril de 2004.
191
Os Capítulos 5 e 6 estabeleceram um plano-base e um cronograma, respectivamente,

para o projeto de estudo de mercado consumidor. A partir do momento em que um pro-
jeto realmente se inicia, é necessário monitorar seu progresso para assegurar que tudo
está de acordo com o cronograma. Isso envolve a medição do progresso real e sua com-
paração com o cronograma. Se, a qualquer momento durante o projeto, determina-se
que está atrasado, devem ser tomadas ações corretivas para normalizar o cronograma.
Se o projeto ficar muito atrasado, pode ser difícil colocá-lo de novo nos trilhos.
O segredo para um controle de projetos eficaz é medir o progresso real e compará-lo
com o progresso planejado de forma regular e oportuna e tomar uma ação corretiva ime-
diatamente, se necessário. Um gestor de projeto não deve simplesmente esperar que um
problema desapareça sem a intervenção corretiva – porque isso não acontecerá. Basean-
do-se no progresso real e considerando que outras mudanças podem ocorrer, é possível
atualizar com regularidade o cronograma do projeto e prever se este terminará antes ou
depois do tempo de conclusão exigido.
Este capítulo abordará os detalhes de processo de controle de um projeto e enfocará
principalmente o papel fundamental do controle de cronograma para assegurar que o
trabalho seja feito a tempo. Ao dominar os conceitos discutidos neste capítulo, você de-
verá estar bem preparado para ajudar a controlar seus projetos. Você aprenderá a:
• executar as etapas do processo de controle de projetos;
• determinar os efeitos do desempenho do cronograma real do projeto;
• incorporar mudanças de projeto no cronograma;
• atualizar o cronograma do projeto;
• controlar o cronograma do projeto.
PROCESSO DE CONTROLE DE PROJETOS

O processo de controle de um projeto envolve a coleta de dados regular sobre o desem-
penho do projeto, a comparação do desempenho real com o planejado e a aplicação de
ações corretivas se o desempenho real estiver abaixo do planejado. Esse processo deve
ocorrer com regularidade durante todo o projeto.
A Figura 7.1 ilustra as etapas do processo de controle de projetos. Tem início com o
estabelecimento de um plano-base que mostra como o escopo do projeto (tarefas) será
cumprido a tempo (cronograma) e dentro do orçamento (recursos, custos). Uma vez que
o cliente e o fornecedor ou a equipe estão de acordo com esse plano-base, pode-se iniciar
o projeto.
Um período regular de relatório deve ser estabelecido para a comparação do progresso
real com o progresso planejado. O relatório pode ser diário, semanal, quinzenal ou mensal,
dependendo da complexidade ou da duração total do projeto. Se for esperado que um pro-
jeto tenha a duração total de um mês, o período de relatório pode ser de um dia apenas.
De outro lado, se é esperado que um projeto dure cinco anos, o período de relatório pode
ser de um mês.
Em cada período de relatório, dois tipos de dados ou informações precisam ser coletados:
1. Dados de desempenho real. Isso inclui:
• o momento real em que as atividades são iniciadas e finalizadas;
• os custos reais gastos e comprometidos.

1. Quais são os dois tipos de dados ou
informações que precisam ser coletados
durante cada período de relatório?
Capítulo 7 Controle do Cronograma 193
FIGURA 7.1 Processo de Controle de Projeto
Estabelecer
plano-base
Iniciar o projeto
Esperar até
o próximo
período
de relatório Durante cada
período
de relatório
Coletar dados do Incorporar mudanças

desempenho real no plano do projeto
(escopo, cronograma,
(cronograma, custos) orçamento)
Atualizar cronogramas,
orçamentos e previsões
para o projeto
Analisar o status atual

comparado com o plano
Não São necessárias

ações corretivas?
Sim
Identificar ações corretivas

e incorporar
mudanças associadas
2. Informações sobre qualquer mudança no orçamento, no cronograma e no escopo do

projeto. Essas mudanças podem ser iniciadas pelo cliente ou pela equipe do projeto
ou podem ser o resultado de uma ocorrência imprevista, como um desastre natural,
uma greve de trabalhadores ou a demissão de um membro importante da equipe
do projeto.
Deve-se observar que, uma vez que as mudanças são incorporadas ao plano e acordadas
com o cliente, um novo plano-base precisa ser estabelecido. O escopo, o cronograma e o
orçamento do novo plano-base podem ser diferentes daqueles do plano-base original.
É crucial que os dados e informações discutidos anteriormente sejam coletados de ma-
neira oportuna e usados para atualizar o cronograma e o orçamento do projeto. Por exem-
plo, se o relatório de projeto é feito mensalmente, dados e informações devem ser obtidos
o mais tarde possível naquele período mensal, pois, quando o cronograma e o orçamento
atualizados forem calculados, estes serão baseados nas informações o mais recente possível.
Em outras palavras, um gestor de projeto não deve coletar dados no início do mês e depois
esperar até o final do mês para usá-los visando atualizar o cronograma e o orçamento do
projeto, já que os dados ficarão obsoletos e poderiam levar à tomada de decisões incorretas
sobre o status do projeto e as ações corretivas.
Após a atualização do orçamento e do cronograma, ambos precisam ser comparados
com o cronograma e orçamento básicos e analisados para se verificar quaisquer variações
e determinar se o projeto está avançado ou atrasado em relação ao cronograma e dentro
ou fora do orçamento. Se o status do projeto estiver correto, não é preciso adotar nenhuma
ação corretiva e o status será analisado novamente para o próximo relatório.

2. Verdadeiro ou falso: em geral,
é melhor que o período de relatório
seja curto durante um projeto.
No entanto, se é determinado que são necessárias ações corretivas, devem-se tomar de-
cisões a respeito de como revisar o cronograma ou o orçamento. Essas decisões geralmente
significam uma compensação que envolve tempo, custo e escopo. Por exemplo, a redução
da duração de uma atividade pode exigir o aumento de custos para pagar mais recursos ou
a redução do escopo da tarefa (e, possivelmente, o não-cumprimento dos requisitos téc-
nicos do cliente). Da mesma forma, a redução dos custos do projeto pode exigir o uso de
materiais de qualidade inferior do que originalmente planejado. Uma vez tomada a decisão
sobre quais ações corretivas aplicar, elas devem ser incorporadas ao cronograma e ao orça-
mento. É necessário elaborar um cronograma e um orçamento revisados para determinar se
as medidas corretivas planejadas resultam em um cronograma e orçamento aceitáveis. Caso
contrário, serão necessárias revisões posteriores.
O processo de controle de projetos continua por todo o projeto. Em geral, quanto me-
nor é o período de relatório, maiores são as chances de se identificar antecipadamente os
problemas e de se adotar efetivas ações corretivas. Se um projeto ficar muito fora de con-
trole, pode ser difícil alcançar seu objetivo sem o sacrifício do escopo, do orçamento, do
cronograma ou da qualidade. Pode haver situações nas quais é recomendável aumentar a
freqüência de relatórios até que o projeto volte a caminhar nos trilhos. Por exemplo, se um
projeto de cinco anos com relatório mensal estiver comprometido por um erro no cronogra-
ma ou por um aumento no excedente do orçamento, seria prudente reduzir o período de
relatório para uma semana, a fim de monitorar mais rigorosamente o projeto e o impacto
das ações corretivas.

3. Além de estabelecer um plano-base
sólido, também é necessário __________
o projeto de forma proativa depois que
ele for iniciado, a fim de se garantir que
o objetivo do projeto seja alcançado.
O processo de controle de projetos é uma parte importante e necessária da gestão do

projeto. Apenas estabelecer um bom plano-base não é suficiente, visto que até mesmo
os planos mais bem concebidos nem sempre funcionam. A gestão de projetos é uma abor-
dagem proativa para o controle de um projeto, para assegurar que o objetivo do projeto será
alcançado até mesmo quando as coisas não acontecem de acordo com o plano.
EFEITOS DO DESEMPENHO DO CRONOGRAMA REAL

Durante um projeto, algumas atividades serão concluídas a tempo, algumas serão termina-
das antes do cronograma e outras depois. O progresso real – ou mais rápido, ou mais lento
do que o planejado – terá um efeito sobre o cronograma das atividades não concluídas e
remanescentes do projeto. Especificamente, os tempos reais de término (TRs) de ativi-
dades concluídas determinarão as datas de início e término mais cedo para as atividades
remanescentes do diagrama de rede, como também a folga total.

4. Quais os três tipos de valores serão
afetados pelas datas de término real de
atividades concluídas?
A parte (a) da Figura 7.2 é um diagrama de atividades (DA) para um projeto simples. Ela
mostra que a data mais cedo em que o projeto pode terminar é de 15 dias (a soma das du-
rações das três atividades, 7 + 5 + 3). Visto que o tempo de conclusão exigido é de 20 dias,
o projeto tem uma folga total de +5 dias.
Suponha que a atividade 1, “Remover Papel de Parede Antigo”, seja de fato concluída
no dia 10, em vez de no dia 7, como planejado, por ter se tornado mais difícil do que o
previsto (veja a parte (b) da Figura 7.2.). Isso significa que a data de início e término mais
cedo para as atividades 2 e 3 será de três dias mais tarde do que o previsto pelo cronograma
original. Como “Remover Papel de Parede Antigo” é de fato concluída no dia 10, o IC (início
mais cedo) para “Remendar Parede” será no dia 10 e seu TC (término mais cedo) será no
dia 15. Avançando nos cálculos, verificamos que “Colocar Papel de Parede Novo” terá um
IC no dia 15 e um TC no dia 18. Comparando esse novo TC da última atividade com a data
de conclusão exigida do dia 20, verificamos uma diferença de dois dias. A folga total ficou
pior – foi alterada em sentido negativo, de +5 dias para +2 dias. Esse exemplo ilustra como
os tempos de término reais das atividades têm um efeito propagador, alterando as datas de
início e término mais cedo e a folga total das atividades remanescentes.
É útil indicar no diagrama de rede, de algum modo, quais atividades foram concluí-
das. Um método é pintar ou riscar a caixa da atividade, como foi feito na parte (b) da
Figura 7.2.
FIGURA 7.2 Efeito de Tempo Real de Término
Remover Colocar
Papel de Remendar
0 Parede Papel de
Parede Conclusão Exigida = 20 Dias
Antigo Parede Novo
1 7 2 5 3 3
(a)
Remover Colocar
Papel de Remendar
AF = 10 Parede Papel de
Parede Conclusão Exigida = 20 Dias
Antigo Parede Novo
1 7 2 5 3 3
(b)
INCORPORANDO MUDANÇAS DO PROJETO AO CRONOGRAMA

Por todo o projeto, podem ocorrer mudanças que tenham um impacto sobre o cronograma.
Como foi observado anteriormente, estas podem ser de iniciativa do cliente ou da equipe
do projeto ou o resultado de um acontecimento imprevisto.
A seguir, estão dois exemplos de mudanças solicitadas pelo cliente:
• Um comprador diz à construtora que a sala de estar da casa deveria ser maior e as
janelas do quarto deveriam ser recolocadas.
• Um cliente diz à equipe de projeto do desenvolvimento de um sistema de informação
que o sistema deve ter a capacidade de produzir um conjunto de relatórios e gráficos
não mencionado anteriormente.
Esses tipos de mudanças representam alterações do escopo original do projeto e terão

um impacto no cronograma e no custo. No entanto, o grau de impacto pode depender
de quando as mudanças são solicitadas. Se são solicitadas no início do projeto, podem ter
um impacto menor sobre o custo e o cronograma do que se forem solicitadas ao final do
projeto. Por exemplo, seria relativamente mais fácil mudar o tamanho da sala de estar e
recolocar as janelas do quarto se a casa ainda estivesse sendo desenhada e as plantas sendo
preparadas. No entanto, se as mudanças forem solicitadas depois que a disposição da sala
estiver construída e as janelas instaladas, o impacto sobre os custos e o cronograma será
muito maior.
Quando o cliente solicita uma mudança, o fornecedor ou a equipe do projeto devem
estimar o impacto sobre o cronograma e o orçamento do projeto e, em seguida, receber
uma aprovação do cliente antes de proceder à mudança. Se o cliente aprova as alterações
propostas no orçamento e cronograma do projeto, algumas tarefas adicionais, mudanças
nas estimativas de duração e custos de mão-de-obra e material devem ser incorporados.
Um exemplo de mudança que parte de iniciativa da equipe de projeto que está pla-
nejando uma feira é a decisão de eliminar todas as atrações para adultos por causa das
limitações de espaço e do custo de seguro. O plano do projeto teria, portanto, de ser
revisado para cancelar ou alterar todas as atividades que envolvem atrações para adultos.
Um exemplo de mudança iniciada pelo gestor do projeto seria o caso de um fornecedor
encarregado de desenvolver um sistema de cobrança automática para um cliente sugerir
que, em vez de incorporar um software customizado, o sistema use um software padrão a
fim de reduzir os custos e acelerar o cronograma.
Algumas mudanças envolvem o acréscimo de atividades omitidas quando o plano ori-
ginal foi desenvolvido. Por exemplo, a equipe de projeto pode ter se esquecido de incluir
atividades associadas ao desenvolvimento de materiais de treinamento e à realização de
treinamento para um novo sistema de informação. Ou ainda, o cliente ou o fornecedor
podem ter deixado de incluir a instalação de valetas e calhas no escopo do trabalho da
construção de um restaurante.
Outras mudanças se tornam necessárias em razão de acontecimentos imprevistos, como
uma tempestade que atrapalha o andamento da construção de um edifício, a reprova-
ção de um novo produto no controle de qualidade, ou o falecimento ou o pedido de de-
missão prematuro de um membro-chave de uma equipe de projeto. Esses incidentes teriam
um impacto sobre o cronograma e/ou orçamento e exigiriam que o plano do projeto fosse
alterado.

5. Quais três elementos podem ser
afetados por mudanças em projetos?
Não obstante, outras mudanças podem ser causadas ao adicionar mais detalhes no dia-
grama de rede, conforme o projeto avança. Qualquer que seja o nível de detalhe usado no
diagrama de rede inicial, haverá algumas atividades que podem ser desmembradas mais
adiante, conforme o projeto avança.
Qualquer tipo de mudança – solicitada pelo cliente, pelo fornecedor, pelo gestor de
projeto, por um membro da equipe ou por um acontecimento imprevisto – exigirá uma
modificação no plano em termos de escopo, orçamento e/ou cronograma. Quando essas
mudanças são acordadas, um novo plano-base é estabelecido e utilizado como uma refe-
rência contra a qual o desempenho real do projeto será comparado.
Com relação ao cronograma do projeto, as mudanças podem ser causadas pelo acrésci-
mo ou cancelamento de atividades, por uma nova seqüência de atividades, pela alteração
das estimativas de duração das atividades ou por uma nova data de conclusão exigida para
o projeto.
Veja os Capítulos 10 e 12 para mais discussões sobre gestão e controle de mudanças.
ATUALIZANDO O CRONOGRAMA DO PROJETO

O planejamento e programação de projetos por meio de redes de atividades permitem que
os cronogramas de projeto sejam dinâmicos. Como o plano da rede (diagrama) e o cronogra-
ma (tabulação de datas e prazos) são separados, eles são muito mais fáceis de atualizar ma-
nualmente do que um gráfico de Gantt tradicional. No entanto, existem diversos pacotes de
softwares de gestão de projetos que auxiliam na geração automatizada de cronogramas,
diagramas de rede, orçamentos e até mesmo conversões de gráficos de Gantt em redes.
Uma vez que tenham sido coletados os dados dos tempos reais de término das ativida-
des concluídas e dos efeitos de qualquer mudança do projeto, pode-se atualizar o cronogra-
ma do projeto. Os cálculos são baseados na metodologia explicada no Capítulo 6:
• As datas de início e término mais cedo para as atividades não concluídas e rema-
nescentes são calculadas avançando-se pelo diagrama, mas se baseiam nos tempos
reais de término das atividades concluídas e nas durações estimadas das atividades
não concluídas.
• As datas de início e término mais tarde para as atividades não concluídas são calcu-
ladas movendo-se para trás no diagrama.
Como ilustração do cálculo de um cronograma atualizado, vamos considerar o diagrama

de rede da Figura 7.3 para projeto de estudo de mercado consumidor. Suponha o seguinte:
1. Atividades concluídas:
a. Atividade 1, “Identificar Consumidores-Alvo”, concluída de fato no dia 2.
b. Atividade 2, “Elaborar Esboço de Questionário”, concluída de fato no dia 11.
c. Atividade 3, “Questionário Teste Piloto”, concluída de fato no dia 30.
2. Mudanças do projeto:
a. Descobriu-se que a base de dados que seria utilizada para preparar as etiquetas
para mala direta não estava atualizada. Uma nova base de dados precisa ser ad-
quirida para que as etiquetas para mala direta possam ser preparadas. Essa nova
base de dados foi encomendada no dia 23, a qual será entregue pelo fornecedor
em 21 dias.
b. Uma análise preliminar das respostas do questionário piloto indica que é necessá-
ria uma revisão profunda do questionário. Portanto, a estimativa de duração para
a atividade 4 precisa ser aumentada de 5 para 15 dias.
O diagrama de rede da Figura 7.3 incorpora as informações anteriores. A Figura 7.4

mostra o cronograma atualizado. Observe que a folga total para o caminho crítico agora é
de –5 dias, em vez de +2 dias no cronograma-base da Figura 6.16 do Capítulo 6. O tempo

Incorporando Progresso Real e Mudanças
Preparar Etiquetas Preparar Etiquetas

para Mala Direta para Mala Direta
Iniciada no Dia 23
14 Steve 21 5 Steve 2
Identificar Revisar Comentários Imprimir

Esboçar Questionário
Consumidores- 2 Questionário 11 30 e Questionário
Alvo Teste Piloto Concluir Questionário
Desenvolver
Software de
Análise de Dados
7 Andy 12
Desenvolver Dados
para
Teste de Software
8 Susan 2
de conclusão previsto do projeto agora é dia 135, que está além do tempo de conclusão
exigido de 130 dias.
ABORDAGENS PARA CONTROLE DO CRONOGRAMA

O controle do cronograma envolve quatro etapas:
1. Análise do cronograma para determinar quais áreas podem precisar de ação corretiva.
2. Decisão de quais ações corretivas específicas devem ser tomadas.
3. Revisão do plano para incorporar as ações corretivas escolhidas.
4. Recálculo do cronograma para avaliar os efeitos das ações corretivas planejadas.
Se as ações corretivas planejadas não resultarem em um cronograma satisfatório, essas eta-

pas precisam ser repetidas.

6. Ao analisar o cronograma de um
projeto, é importante identificar todos
os caminhos de atividades que têm uma
folga ______________.

e de Respostas Resultados Relatório
Receber Respostas
9 Steve 55 11 Jim 7 12 Jim 8 13 Jim 10
Conclusão Exigida = 130 Dias de Trabalho
Testar
Software
10 Andy 5
LEGENDA
Descrição da
Atividade
Número da Estimativa de
Atividade Duração
Responsável
As caixas riscadas indicam atividades concluídas
Durante um projeto, cada vez que um cronograma é recalculado – seja depois que os
dados reais ou as mudanças do projeto são incorporados ou depois que as ações corretivas
são planejadas –, é necessário analisar o cronograma recém-calculado para determinar se
é preciso trabalhar nele mais a fundo. A análise do cronograma deve incluir a identificação
do caminho crítico e de qualquer caminho de atividades que tenha uma folga negativa, as-
sim como os caminhos nos quais tenham ocorrido “escorregões” (a folga ficou pior) com-
parado com o cronograma anteriormente calculado.
Um esforço concentrado para acelerar o progresso do projeto deve ser aplicado aos ca-
minhos com folga negativa. O total de folga deve determinar a prioridade com a qual esses
esforços concentrados são aplicados. Ou seja, deve ser dada maior prioridade ao caminho
com a folga mais negativa.
As ações corretivas que eliminarão a folga negativa do cronograma do projeto devem
ser identificadas. Estas devem reduzir as estimativas de duração para as atividades nos
caminhos de folga negativa. Lembre-se de que a folga para um caminho de atividades é
dividida entre todas as atividades desse caminho. Portanto, uma mudança na estimativa
de duração de qualquer atividade desse caminho causará uma modificação correspondente
na folga para esse caminho.
Ao analisar um caminho de atividades com uma folga negativa, você deve se concentrar
em dois tipos de atividades:
1. Atividades que estão próximas (ou seja, estão em andamento ou prestes a ser inicia-
das). É muito mais inteligente tomar uma ação corretiva agressiva para reduzir as du-
FIGURA 7.4 Estrutura Analítica Atualizada para Projeto de Estudo de Mercado Consumidor

Estim. Folga Término
Dur. Total Real
Atividade Resp. Início Término Início Término
1 Identificar Consumidores-Alvo Susan 2
2 Esboçar Questionário Susan 11
3 Questionário Teste Piloto Susan 30
4 Revisar Comentários e Concluir Questionário Susan 15 30 45 25 40 –5
6 Imprimir Questionário Steve 10 45 55 40 50 –5
9 Enviar Questionário e Receber Respostas Steve 55 55 110 50 105 –5
14 Providenciar Nova Base de Dados para Etiquetas Steve 21 23 44 27 48 4
rações de atividades que serão feitas no curto prazo do que planejar reduzir as durações
das atividades programadas para o futuro. Se você adiar para tomar uma ação corre-
tiva que reduzirá as durações das atividades até o futuro distante, pode descobrir que
a folga negativa piorou ainda mais. À medida que o projeto avança, sempre sobra
menos tempo para que seja tomada uma ação corretiva.
Ao observar a Figura 7.4, podemos ver que seria melhor tentar reduzir as durações
das atividades que estão próximas do caminho crítico, como, por exemplo “Revisar
Comentários e Concluir Questionário” ou “Imprimir Questionário”, do que transferir
a ação corretiva para a última atividade, “Preparar Relatório”.

7. Ao analisar um caminho de atividades
que tenha uma folga negativa, quais os
dois tipos de atividades que devem ser
observados com cuidado?
2. Atividades com estimativas de longa duração. Adotar medidas corretivas que reduzirão
uma atividade de 20 dias em 20% (ou seja, em quatro dias) tem um impacto maior que
eliminar totalmente uma atividade de um dia. Geralmente, atividades de maior duração
apresentam a oportunidade para maiores reduções.
Rebotes da Nike
Como uma empresa se recupera de um fracasso na implementação de projeto de TI?
A Nike diria a você que isso é possível. Veja o projeto de sua cadeia de fornecedores. Em
2000, a empresa implementou pela primeira vez seu novo sistema de cadeia de fornecedo-
res com planejamento de demanda, chamado “i2”. Inicialmente não funcionou como plane-
jado. Por causa de um defeito do software, a empresa perdeu US$ 100 milhões em vendas.
A Nike estava no processo de desenvolvimento de um novo sistema de Planejamento
de Recursos Empresariais (ERP). Além do ERP, também quis utilizar um sistema menor, o i2,
para ajudar a centralizar a cadeia de fornecedores. Como a empresa cresceu e se tornou
uma operação global, sua cadeia de fornecedores ficou fragmentada. Ela tinha 27 sistemas
diferentes de gestão de pedidos em todo o mundo. Os processos de planejamento da Nike
já estavam centralizados em sua matriz em Beaverton, Oregon, e ela queria fazer o mesmo
para sua cadeia de fornecedores. A Nike, equivocadamente, pensou que, como o sistema i2
era relativamente pequeno, se comparado ao seu sistema de ERP planejado, a implemen-
tação seria fácil. No entanto, aprendeu do jeito mais difícil que o i2 era, na verdade, um
sistema muito complexo de se integrar e usar.
O i2 foi desenvolvido com pressa e vinculado diretamente aos pedidos da fábrica,
usando algoritmos que processam grande quantidade de dados de números históricos de
vendas e determinam uma demanda futura dos produtos da empresa. O resultado inicial
da primeira implementação do i2 foi um excesso de pedidos para alguns produtos especí-
ficos e poucos pedidos para outros produtos que, na verdade, tinham alta demanda.
Os projetos de TI que fracassam são recuperáveis quando toda a equipe valoriza a
tecnologia e entende o que é necessário ser feito para os negócios da empresa. A empresa
praticou a paciência e aprendeu com o próprio erro ao usar o i2. Os executivos da Nike
constataram que os problemas do i2 eram solucionáveis. Eles concluíram que o sistema
era lento demais, não estava bem integrado ao modelo de negócios, tinha falhas de software
e que os funcionários, antes da implementação oficial, não tinham recebido treinamen-
to suficiente sobre como usar o sistema. Então, eles se empenharam mais em resolver
os problemas no software i2, implementaram um sólido plano de teste e garantiram que
os funcionários da Nike recebessem um treinamento completo antes de utilizar o sistema.
Depois dessa má experiência com o pequeno sistema i2, a Nike aprendeu a não apressar
a implementação de seu novo (e maior) sistema de ERP. A empresa estabeleceu uma meta
de negócios bem definida: diminuir em três meses o ciclo de fabricação de calçados espor-
tivos. Também reconheceu que o sistema i2 não estava bem equipado para fazer isso para
a empresa, pois não se ajustava ao modelo de negócios de venda de calçados, no qual a
Nike dependia de um controle bastante rígido de sua cadeia de fornecedores. Dessa forma,
a empresa continuou utilizando o i2 para a linha de roupas, mas trocou seu planejamento
de calçados esportivos para seu sistema de ERP maior.
O resultado do projeto reelaborado foi um sistema realmente centralizado, algo que
muitas outras grandes empresas que usam sistemas de ERP não têm no momento. A Nike
levou certo tempo para desenvolver seu novo sistema de cadeia de fornecedores e hoje a
empresa conta com maior visibilidade financeira, melhor gestão de fluxo de caixa, maior
previsão de receita e capacidade para executar tranqüilamente suas finanças globais em
diferentes moedas – tudo em uma única base de dados.
Koch, C. Nike Rebounds: How Nike Survived a $ 100 Million Supply Chain Disaster and a Seven-Year, $ 500 Million ERP Im-
plementation. CIO, 15 de junho de 2004.
Observe novamente a Figura 7.4. Pode haver mais oportunidade para reduzir a
estimativa de duração de 55 dias para “Enviar Questionário e Receber Respostas” em
cinco dias (9%) do que reduzir as estimativas de duração mais curtas de outras ativi-
dades do caminho crítico.
Existem diversas abordagens para se reduzir as estimativas de duração das atividades.

Uma maneira óbvia é aplicar mais recursos para acelerá-las. Isso pode ser feito designan-
do-se mais pessoas para trabalhar na atividade ou pedindo-lhes que trabalham nela para
acrescentar mais horas por dia ou mais dias por semana. Recursos adicionais apropriados
podem ser transferidos de atividades concomitantes que tenham folga positiva. No entanto,
às vezes, acrescentar pessoal para uma atividade pode fazer com que a atividade fique mais
lenta, visto que as pessoas já designadas para a atividade são desviadas do trabalho a fim de
ajudar as novas pessoas a entrar no ritmo para acelerar. Outra abordagem é designar uma
pessoa com maior habilidade ou mais experiência para conduzir ou ajudar na atividade, de
modo que a realize em menor tempo do que seria possível com as pessoas menos expe-
rientes originalmente designadas.
Reduzir o escopo ou os requisitos para uma atividade é outro modo de reduzir sua esti-
mativa de duração. Por exemplo, pode ser satisfatório passar somente uma camada de tinta
em uma sala do que duas camadas, como originalmente planejado. Em um caso extremo,
pode-se tomar a decisão de eliminar totalmente algumas atividades, cancelando essas ativi-
dades e sua duração no cronograma.

8. Relacione quatro abordagens para
reduzir as durações estimadas de
atividades.
Aumentar a produtividade por meio de métodos ou de tecnologia mais eficazes é tam-

bém outra abordagem para reduzir as durações das atividades. Por exemplo, em vez de
se designar pessoas para digitarem dados de um levantamento do cliente em uma base
de dados informatizada, pode-se utilizar equipamento de leitura óptica.
Uma vez decididas as ações corretivas específicas para reduzir a folga negativa, deve-se
revisar no plano de rede as estimativas de duração para as atividades apropriadas. Em
seguida, um cronograma revisado precisa ser calculado para avaliar se as ações corretivas
planejadas reduzem a folga negativa como previsto.
Na maioria dos casos, eliminar uma folga negativa por meio da redução das durações
das atividades envolverá uma compensação na forma de aumento de custos ou uma redu-
ção no escopo (para uma discussão mais completa sobre esse assunto, ver o apêndice de
compensação tempo-custo ao final deste capítulo). Se o projeto estiver com o cronograma
atrasado (tem folga negativa substancial), pode-se exigir um aumento substancial de cus-
tos e/ou redução do escopo do trabalho ou da qualidade para ajustar o cronograma. Isso
poderia colocar em risco elementos do objetivo de todo o projeto: escopo, orçamento, cro-
nograma e/ou qualidade. Em alguns casos, o cliente e o fornecedor ou a equipe do projeto
podem ter de reconhecer que um ou mais desses elementos não podem ser alcançados.
Desse modo, por exemplo, o cliente pode ter de estender o tempo de conclusão exigido
para o projeto inteiro ou é possível haver uma discussão sobre quem deve pagar qualquer
custo acrescentado para acelerar o cronograma – o fornecedor ou o cliente.
Alguns contratos incluem uma cláusula de bonificação, por meio da qual o cliente
pagará ao fornecedor um bônus se o projeto for concluído antes do cronograma. No
entanto, alguns fornecedores inserem uma cláusula de multa, por meio da qual o cliente
pode reduzir o pagamento final ao fornecedor se o projeto não for concluído a tempo.
Algumas dessas multas podem ser substanciais. Nas duas situações, um controle efetivo do
cronograma é crucial.
O segredo para um controle efetivo do cronograma é abordar de forma agressiva, logo
que identificados ou piorar, todos os caminhos que tenham valores de folga negativos em
vez de esperar que as coisas melhorem conforme o projeto avança. Tratar dos problemas
de cronograma logo no início minimiza o impacto negativo no custo e no escopo. Se
um projeto fica muito para trás, torna-se mais difícil ajustá-lo ao cronograma, e isso não
ocorre de graça, pois exige que mais dinheiro seja gasto ou que se reduza o escopo ou a
qualidade.
Em projetos que não têm folga negativa, é importante não deixar que a folga aumente,
aceitando-se atrasos e escorregões. Se um projeto estiver adiantado, um esforço concentra-
do deve ser feito para mantê-lo adiantado.
As reuniões de projeto são um bom foro para discutir as questões de controle de cro-
nograma. Veja a discussão sobre reuniões de projeto no Capítulo 12 e sobre a discussão de
resolução de problemas no Capítulo 11.
CONTROLE DE CRONOGRAMA PARA DESENVOLVIMENTO DE

SISTEMAS DE INFORMAÇÃO
Controlar o cronograma para o desenvolvimento de um sistema de informação é um desa-
fio. Inúmeras circunstâncias inesperadas podem surgir e estender a data originalmente pre-
vista para a conclusão do projeto de desenvolvimento de SI. No entanto, como em qualquer
outro tipo de projeto, o segredo para seu controle eficiente é medir – de forma contínua – o
progresso real, compará-lo com o progresso que foi planejado e adotar medidas corretivas
imediatamente.
O controle de cronograma para projetos de desenvolvimento de SI – assim como outras
formas de controle – é realizado de acordo com as etapas anteriormente discutidas neste
capítulo. Um processo para controle de projetos como o ilustrado na Figura 7.1 deve ser
utilizado para comparar o desempenho real com o cronograma. Assim que o cliente e a
equipe do projeto concordarem com as mudanças, estas deverão ser registradas e o crono-
grama deverá ser revisado.
As mudanças normalmente necessárias durante os projetos de desenvolvimento de SI
incluem:
• Mudanças na interface – como campos adicionais, ícones diferentes, cores diferen-

tes, botões ou estruturas de menu diferentes, telas completamente novas.
• Mudanças nos relatórios – como campos adicionais, totais e subtotais diferentes, clas-
sificações diferentes, critérios de seleção diferentes, ordem dos campos diferente ou
relatórios completamente novos.
• Mudanças nas consultas on-line – como diferentes capacidades ad hoc, acesso a
diferentes campos e bases de dados, diferentes estruturas das consultas ou consultas
adicionais.
• Mudanças na estrutura da base de dados – como campos adicionais, diferentes no-
mes dos campos de dados, diferentes capacidades de espaço para armazenamento de
dados, diferentes relações entre os dados ou bases de dados completamente diferentes.
• Mudanças nas rotinas de processamento do software – como algoritmos, interfaces
diferentes com outras sub-rotinas, lógica interna diferente ou novos procedimentos.
• Mudanças nas velocidades de processamento – como taxas de transmissão de dados
(throughput) ou tempos de resposta.
• Mudanças na capacidade de armazenamento – como um aumento no número má-
ximo de registros de dados.
• Mudanças nos processos de negócios – como mudanças no trabalho ou fluxo de da-

dos, adição de novos clientes que devem ter acesso ou processos completamente
novos que devem ser apoiados.
• Mudanças no software resultantes de atualizações de hardware ou, ao contrário, atua-
lizações de hardware resultantes da disponibilidade de softwares mais potentes.

Office Designs (cont.)
Recordamos dos Capítulos 5 e 6 que a ABC Office Designs nomeou Beth Smith como ges-
tora do projeto para o desenvolvimento do sistema de relatório pela Internet. Ela identificou
todas as principais tarefas que precisavam ser realizadas e desenvolveu a estrutura analítica
do projeto, a matriz de responsabilidades e o diagrama de rede. Quando calculou as da-
tas de início mais cedo e mais tarde para cada atividade, descobriu que o projeto levaria
59 dias para ser concluído – nove dias a mais que os 50 dias originais exigidos. Contudo,
após longas discussões com a gerência superior, nas quais ela destacou a importância de
se desenvolver o sistema corretamente da primeira vez, sem ter de correr durante algumas
fases críticas do CVDS, Beth convenceu seus superiores a estender a data de conclusão do
projeto para 60 dias.
Beth e sua equipe avançaram com o projeto e concluíram as atividades 1 a 6:
A Atividade 1, “Reunir Dados”, terminou, de fato, no dia 4.

A Atividade 2, “Estudar Viabilidade”, terminou, de fato, no dia 4.
Incorporando Progresso Real e Mudanças
Reunir Entrevistar Definir Solicitações

Dados Usuários dos Usuários
1 Beth 4 Jim 6 Jeff

Preparar Relatório
de Definição Entrada
do Problema e
Saída
3 Rose
8 Tyler 8
Preparar Relatório
Estudar Estudar Sistema de Análise Avaliação
Viabilidade Existente do Sistema
2 Jack 5 Steve 7 Jim 1 10 Cathy 2

Processamento
e
Base de Dados
9 Joe 8
A Atividade 3, “Preparar Relatório da Definição de Problema”, terminou, de fato, no dia 5.

A Atividade 4, “Entrevistar Usuários”, terminou, de fato, no dia 10.
A Atividade 5, “Estudar Sistema Existente”, terminou, de fato, no dia 15.
A Atividade 6, “Definir Solicitações de Usuários”, terminou, de fato, no dia 18.
Eles, então, descobriram que, se utilizassem algum software existente para a base de da-
dos, seria possível reduzir a duração estimada da atividade 9, “Processamento e Base
de Dados”, de dez para oito dias.
As Figuras 7.5 e 7.6 mostram o diagrama de rede e o cronograma do projeto, respecti-
vamente, anteriores após a incorporação dessas mudanças. Observe que, em função das
ocorrências anteriores, o caminho crítico tem uma folga total igual a zero.

Quase todos os pacotes de software de gestão de projetos permitem que você realize as
funções de controle identificadas neste capítulo. Especificamente, enquanto uma ativida-
de está em andamento ou depois que esta é concluída, as informações atuais podem ser
inseridas no sistema, e o software revisará automaticamente o cronograma do projeto. Da
mesma forma, se as durações estimadas para quaisquer atividades futuras forem alteradas,
essas alterações podem ser inseridas no sistema, e o software atualizará automaticamente
o cronograma. Todos os diagramas de rede, tabelas e relatórios produzidos pelo software
serão atualizados para refletir as informações mais recentes. Veja o Apêndice A ao final do
livro para uma discussão mais abrangente sobre softwares de gestão de projetos.
Desenvolvimento Teste
de do Software
Software
Treinamento
20 Jim 4
Preparar Relatório Desenvolvimento Preparar Relatório Preparar Preparar
Teste Relatório de
de Concepção do de Desenvolvimento Relatório
do Hardware Implementação
do Sistema Hardware do Sistema de Testes
11 Sharon 2 13 Joe 10 15 Jac k 2 17 Gene 4 19 Rose 1 22 Jack 1
Conversão
do Sistema
Desenvolvimento Teste 21 Beth 2

da Rede da Rede
14 Gerri 6 18 Greg 4
Legenda
Descrição da
Atividade
Responsável
• Gestão de projetos envolve uma abordagem proativa no controle do projeto, a fim

de se garantir que seu objetivo seja alcançado, mesmo quando as coisas não saem
conforme planejado.
• A partir do momento em que o projeto se inicia, é importante monitorar o progres-
so, a fim de se garantir que tudo saia conforme planejado.
• O segredo para um controle de projetos eficaz é medir o progresso real e compará-
lo ao progresso planejado de forma contínua, e adotar ações corretivas imediata-
mente, se necessário.
• O segredo para um controle de cronograma eficaz é abordar quaisquer caminhos
com valores de folga negativos ou em declínio de forma agressiva assim que forem
identificados. Um esforço concentrado para acelerar o progresso do projeto deve
ser aplicado a esses caminhos. A quantidade de folga negativa deve determinar a
prioridade de aplicação desses esforços concentrados.
• Ao tentar-se reduzir a duração de um caminho de atividades que tenha uma folga
negativa, concentre-se nas atividades que estejam próximas ou em atividades que
tenham estimativas de duração longas.
• O tratamento precoce de problemas de cronograma irá minimizar o impacto negati-
vo sobre custo e escopo. Se um projeto ficar muito atrasado, fica mais difícil colocá-lo
novamente dentro do cronograma. Isso normalmente exige que mais dinheiro seja
gasto ou que se reduza o escopo ou a qualidade.
• Se ações corretivas forem necessárias, deve-se tomar decisões referentes à com-
pensação de tempo, custo e escopo.
• Use a metodologia de compensação tempo-custo para reduzir a duração do projeto
incrementalmente para o menor aumento associado em custo incremental.
• Um período de relatório regular deve ser estabelecido para se comparar o progresso
real com o progresso planejado.
• Quanto menor for o período de relatório, maiores são as chances de se identificar
problemas de forma precoce e adotar as ações corretivas.
• Durante cada período de relatório, dados sobre desempenho real e informações sobre
mudanças no escopo, cronograma e orçamento do projeto precisam ser coletados re-
gularmente e utilizados para elaborar um cronograma e orçamento atualizados.
RESUMO
Depois que um projeto começa de fato, é necessário monitorar seu progresso a fim de se
garantir que tudo está saindo conforme o cronograma. Isso envolve medir o progresso real
e compará-lo ao cronograma. Se, a qualquer momento durante o projeto, for determinado
que ele está atrasado em relação ao cronograma, deve-se tomar ações corretivas para que
ele volte ao cronograma normal. O segredo para um controle eficaz é medir o progresso
real, compará-lo ao progresso planejado de forma regular e tomar ações corretivas imedia-
tamente. Com base no progresso real e levando-se em consideração outras mudanças que
podem ocorrer, é possível atualizar regularmente o cronograma do projeto e prever se este
será concluído antes ou depois da data de conclusão exigida.
Deve-se estabelecer um período regular de relatório para se comparar o progresso real
ao planejado. Essa análise pode ser diária, semanal, quinzenal ou mensal, dependendo da
FIGURA 7.6 Estrutura Analítica Atualizada para Projeto de Sistema de Relatório pela
Internet

Estim. Folga Término
Dur. Início Término Início Término Total Real
Atividade Resp.
1 Reunir Dados Beth 4
2 Estudar Viabilidade Jack 4
3 Preparar Relatório da Definição de Problema Rose 5
4 Entrevistar Usuários Jim 10
5 Estudar Sistema Existente Steve 15
6 Definir Solicitações de Usuários Jeff 18
7 Preparar Relatório de Análise do Sistema Jim 1 18 19 18 19 0
8 Entrada e Saída Tyler 8 19 27 19 27 0
9 Processamento e Base de Dados Joe 8 19 27 19 27 0
10 Avaliação Cathy 2 27 29 27 29 0
11 Preparar Relatório de Concepção do Sistema Sharon 2 29 31 29 31 0
12 Desenvolvimento do Software Hannah 15 31 46 31 46 0
13 Desenvolvimento de Hardware Joe 10 31 41 36 46 5
14 Desenvolvimento de Rede Gerri 6 31 37 40 46 9
15 Preparar Relatório de Desenvolv. do Sistema Jack 2 46 48 46 48 0
16 Teste do Software Maggie 6 48 54 48 54 0
17 Teste do Hardware Gene 4 48 52 50 54 2
18 Teste da Rede Greg 4 48 52 50 54 2
19 Preparar Relatório de Testes Rose 1 54 55 54 55 0
20 Treinamento Jim 4 55 59 55 59 0
21 Conversão do Sistema Beth 2 55 57 57 59 2
22 Preparar Relatório de Implementação Jack 1 59 60 59 60 0
complexidade ou da duração global do projeto. Em cada período de relatório, dois tipos de

dados ou informações precisam ser coletados: dados sobre o desempenho real e informa-
ções sobre quaisquer mudanças no escopo, cronograma ou orçamento do projeto.
O processo de controle continuará com o decorrer do projeto. Em geral, quanto mais
curto for o período de relatório, maiores são as chances de se identificar problemas de forma
precoce e adotar ações corretivas. Se um projeto fica muito fora de controle, pode ser difícil
atingir seu objetivo sem se sacrificar o escopo, o orçamento, o cronograma ou a qualidade.
Ao longo de um projeto, algumas atividades serão concluídas a tempo, outras serão
concluídas antes do tempo e outras ainda terminarão depois do cronograma. O progresso
real – seja mais lento, seja mais rápido que o planejado – terá efeito sobre o cronograma
de atividades remanescentes, não concluídas, do projeto. Especificamente, o tempo real de

término (TR) das atividades concluídas irá determinar as datas de início e término mais cedo
para as atividades remanescentes do diagrama de rede, assim como a folga total.
Durante um projeto, podem ocorrer mudanças que terão impacto sobre o cronograma.
Sua iniciativa pode ser do cliente ou da equipe do projeto ou, então, as mudanças podem ser
resultado de uma ocorrência imprevista. Qualquer tipo de mudança – de iniciativa do cliente,
do fornecedor, do gestor do projeto, de um membro da equipe ou um evento imprevisto
– exigirá uma modificação do plano em termos de escopo, orçamento e/ou cronograma.
Quando essas mudanças são acordadas, um novo plano-base é estabelecido e usado como
referência contra a qual o desempenho real do projeto será comparado.
Após a coleta de dados sobre as datas de término real das atividades concluídas e so-
bre os efeitos de quaisquer mudanças no projeto, pode-se atualizar o cronograma do projeto.
Os cálculos necessários baseiam-se na metodologia explicada no Capítulo 6.
O controle do cronograma envolve quatro etapas: análise do cronograma para se deter-
minar quais áreas podem precisar de ações corretivas, decisão sobre quais ações corretivas
específicas devem ser tomadas, revisão do plano para incorporação das ações corretivas es-
colhidas e recálculo do cronograma para avaliar os efeitos das ações corretivas planejadas.
Ações corretivas que irão eliminar a folga negativa do cronograma do projeto devem ser
identificadas. Estas devem reduzir as estimativas de duração para atividades que estejam
nos caminhos com folgas negativas. Ao analisar-se um caminho de atividades que tenha
uma folga negativa, você deve se concentrar em dois tipos de atividades: atividades que
estejam próximas e atividades que tenham estimativas de longa duração.
Existem vários métodos para se reduzir as estimativas de duração das atividades. Isso
inclui a aplicação de mais recursos para se acelerar uma atividade, a atribuição de pessoas
com maior conhecimento ou mais experiência para trabalhar na atividade, a redução do
escopo ou das exigências para atividade e o aumento de produtividade com o uso de me-
lhores métodos ou tecnologias.
PERGUNTAS
1. Explique por que é importante monitorar o progresso de um projeto de forma contínua.
2. Descreva com as próprias palavras o que significa processo de controle de projetos. Dê
um exemplo de uso.
3. Por que um projeto deveria ter um período regular de relatório? Todos os projetos
devem ter o mesmo período de relatório? Justifique sua resposta. Que tipos de dados
devem ser coletados durante cada período de relatório?
4. Se o cronograma de um projeto precisar ser ajustado, quais compensações podem ocor-
rer?
5. Quem pode ter a iniciativa de fazer uma mudança em um cronograma de projeto? Por
que fazer isso? Quando fazer isso? Dê exemplos.
6. Como o diagrama de rede e o cronograma são atualizados depois que um projeto é
iniciado e há solicitação de mudanças?
7. Descreva o método de quatro etapas para controle de cronograma. Dê exemplos de uso.
8. Quando um cronograma precisa ser acelerado, quais atividades são prováveis candida-
tas a ajustes? Por quê?
9. Por que o uso de alguma folga por uma atividade pode afetar outras atividades de um
projeto?
10. Consulte a pergunta 10 ao final do Capítulo 6. Suponha que a tarefa A de fato terminou
em três semanas, que a tarefa B de fato terminou em 12 semanas e que a tarefa C de fato
terminou em 13 semanas. Recalcule a data de conclusão esperada para o projeto. Em quais
atividades você se concentraria a fim de reconduzir o projeto ao cronograma normal?
11. Consulte a pergunta 11 ao final do Capítulo 6. Suponha que “Análise do Sistema” de

fato terminou em oito semanas, “Projetar Entrada e Saída” de fato terminou em 15 se-
manas e “Projetar Base de Dados” de fato terminou em 19 semanas. Recalcule a data
de conclusão esperada para o projeto. Em quais atividades você se concentraria a fim
de reconduzir o projeto ao cronograma normal?
12. Consulte a pergunta 12 ao final do Capítulo 6. Suponha que a tarefa A de fato terminou
em cinco semanas e que a tarefa B de fato terminou em cinco semanas. Recalcule a
data de conclusão esperada para o projeto. Em quais atividades você se concentraria
a fim de reconduzir o projeto ao cronograma normal?
Caso tenha dificuldade para acessar algum dos sites relacionados a seguir, você pode encontrar
os exercícios (com endereços atualizados) em nosso site: www.towson.edu/~clements.
1. Procure por técnicas de controle de projetos na Internet e descreva pelo menos três
sites encontrados.
2. Para as questões de 2 a 5, visite e explore o site http://www.4pm.com. Cada sessão
contém links de artigos relacionados. Leia um artigo que seja de seu interesse.
3. Explore os temas na PM Library. Leia um artigo que lhe interesse.
4. Clique no link “PMTalk Newsletter”. Faça assinatura gratuita da newsletter e baixe a
ferramenta de área de trabalho em seu computador. Resuma, pelo menos, uma das
reportagens da newsletter.
5. Procure pelos termos fracasso de projeto e sucesso de projeto no site. Releia um dos
artigos.

Lucrativos
Este caso é continuação do estudo de caso dos Capítulos 5 e 6.
PERGUNTAS
1. Caso o cronograma que calculou no Capítulo 6 tenha folga negativa, você precisa revi-
sar seu plano e atualizar o cronograma para eliminar todas as folgas negativas. Realize
também qualquer mudança associada à estimativa de custos para as atividades e calcule
um orçamento total atualizado para o projeto.
Caso o cronograma calculado no Capítulo 6 não tenha folga negativa, passe para o
item 2.
2. Suponha que seja dia 15 de agosto. Providencie uma lista de atividades que devem ser
concluídas a partir dessa data, junto com as datas reais de término (TRs) e custos reais
gastos para cada uma dessas atividades concluídas.
3. Crie um cenário de problemas que tenham surgido e que causarão atraso de pelo me-
nos duas atividades programadas para serem concluídas entre 15 de setembro e 15 de
novembro.
4. Baseando-se nos tempos reais de término e nos problemas de atraso de cronograma
identificados no item 2, atualize o cronograma e, em seguida, faça as atualizações ne-
cessárias para o plano (incluindo qualquer estimativa de custo e duração). Continue
fazendo dessa forma até que todas as folgas negativas sejam eliminadas.
ATIVIDADE DE GRUPO
Divida os integrantes do curso nos mesmos grupos de três ou quatro da atividade de grupo
do capítulo anterior e responda às perguntas anteriores.
Observação: O estudo deste caso continua nos Capítulos 8 e 9; portanto, guarde os re-
sultados de seu trabalho.

Este caso é continuação do estudo de caso dos Capítulos 5 e 6.
PERGUNTAS
1. Caso o cronograma que calculou no Capítulo 6 tenha folga negativa, você precisa re-
visar seu plano e atualizar o cronograma para eliminar todas as folgas negativas. Faça
também qualquer mudança associada à estimativa de custos para as atividades e calcule
um orçamento total atualizado para o projeto.
Caso o cronograma que você calculou no Capítulo 6 não tenha folga negativa, passe
para o item 2.
2. Suponha que seja dia 31 de março. Providencie uma lista de atividades que devem ser
concluídas a partir dessa data, com as datas reais de término (TRs) e os custos reais
gastos para cada uma das atividades concluídas.
3. Crie um cenário de problemas que tenham surgido e que causarão atraso de pelo menos
duas atividades programadas para serem concluídas entre 1o de maio e 30 de junho.
4. Baseando-se nos tempos reais de término e nos problemas de atraso de cronograma
identificados no item 2, atualize o cronograma e, em seguida, faça as atualizações ne-
cessárias para o plano (incluindo qualquer estimativa de custo e duração). Continue
fazendo dessa forma, até que todas as folgas negativas sejam eliminadas.
ATIVIDADE DE GRUPO
Observação: O estudo deste caso continua nos Capítulos 8 e 9; portanto, guarde os re-
sultados de seu trabalho.
APÊNDICE Nº 1 Compensação Tempo-Custo

A metodologia de compensação tempo-custo é utilizada para reduzir a duração do projeto
incrementalmente, com o menor aumento associado de custo incremental. Esta segue as
seguintes premissas:
1. Cada atividade tem dois pares de estimativas de custo e duração: normal e de pro-
cessamento mínimo. O tempo normal é a duração estimada de tempo exigida para
realizar a atividade sob condições normais, de acordo com o plano. O custo normal
é aquele estimado para concluir a atividade no tempo normal. O tempo de proces-
samento mínimo é a menor duração de tempo estimada em que se pode concluir a
atividade. O custo de processamento mínimo é o custo estimado para concluir
a atividade no tempo de processamento mínimo. Na Figura 7.7, cada uma das qua-
tro atividades tem um par de estimativas de custo e tempo normais e um par de esti-
mativas de custo e tempo de processamento mínimo. O tempo normal estimado para
realizar a atividade A é de sete semanas e seu custo normal estimado é US$ 50.000.
O tempo de processamento mínimo para essa atividade é cinco semanas e o custo

para concluir a atividade nessa duração é US$ 62.000.

9. Quais são os tempos normais e
de processamento mínimo para as
atividades B, C e D na Figura 7.7?
2. Uma duração da atividade pode ser incrementalmente acelerada de seu tempo normal
para seu tempo de processamento mínimo ao se aplicar mais recursos – nomeando
mais pessoas, trabalhando horas extras, usando mais equipamentos e assim por dian-
te. O aumento de custos estará associado ao adiantamento da atividade.
3. Uma atividade não pode ser concluída em menor tempo do que o de processamento
mínimo, seja qual for a quantidade de recursos adicionais aplicados. Por exemplo,
a atividade A não pode ser concluída em menos de cinco semanas, seja qual for a
quantidade de recursos utilizados ou de dinheiro gasto.
4. Os recursos necessários para reduzir a duração estimada de uma atividade do tempo
normal para o tempo de processamento mínimo estarão disponíveis no momento certo.
5. Dentro da variação entre tempos de processamento mínimo e normais da atividade,
a relação entre o tempo e o custo é linear. Cada atividade tem a própria taxa de
custo por período de tempo para se comprimir a atividade, reduzindo-se a duração
de tempo normal para o tempo de processamento mínimo. Essa taxa de custo de
compressão por período de tempo é calculada da seguinte forma:
Custo de processamento mínimo – Custo normal

Tempo normal – Tempo de processamento mínimo

10. Quais são os custos semanais para
se acelerar as atividades B, C e D na
Figura 7.7?
FIGURA 7.7 Rede com Tempos e Custos de Processamento Normais e Mínimos e Seus
Custos
A B
N = 7, US$ 50.000 N = 9, US$ 80.000
C = 5, US$ 62.000 C = 6, US$ 110.000
Início Término
C D
N = 10, US$ 40.000 N = 8, US$ 30.000 Legenda
C = 9, US$ 45.000 C = 6, US$ 42.000 N = Estimativas normais
C = Estimativas de tempo
de processamento mínimo
Por exemplo, na Figura 7.7, o custo semanal para se comprimir a atividade A do

tempo normal para o tempo de processamento mínimo é:
US$ 62.000 – US$ 50.000 = US$ 12.000

7 semanas – 5 semanas 2 semanas = US$ 6.000 por semana
O diagrama de rede da Figura 7.7 tem dois caminhos do início para o término: A-B e
C-D. Se consideramos somente as estimativas de duração normal, o caminho A-B levará
16 semanas para ser concluído, enquanto o caminho C-D levará 18 semanas. Portanto, o
menor tempo em que o projeto pode ser concluído baseado nessas estimativas de tempo é
18 semanas – a extensão de seu caminho crítico, formada pelas atividades C e D. O custo
total do projeto, baseado no custo associado à realização de cada atividade em seu tempo
normal, é
US$ 50.000 + US$ 80.000 + US$ 40.000 + US$ 30.000 = US$ 200.000
Se todas as atividades foram realizadas em seus respectivos tempos de processamento

mínimo, o caminho A-B levaria 11 semanas, e o caminho C-D levaria 15 semanas. O menor
tempo em que o projeto pode ser concluído, baseado nas estimativas de tempo de proces-
samento mínimo, é 15 semanas, ou seja, três semanas antes do que se as atividades fossem
realizadas nos tempos normais.

11. Se todas as atividades da Figura 7.7
fossem realizadas em seu tempo de
processamento mínimo, qual seria o
custo total do projeto?
Geralmente não é necessário, ou mesmo construtivo, comprimir todas as atividades. Por

exemplo, na Figura 7.7, queremos comprimir somente uma quantidade necessária das ativi-
dades adequadas para acelerar a conclusão de 18 para 15 semanas. Qualquer compressão
adicional de atividades apenas aumentará o custo total do projeto e não reduzirá em nada
mais a duração total do projeto, porque isso está determinado pela extensão do caminho
crítico. Em outras palavras, apressar atividades que não estejam no caminho crítico não re-
duzirá o tempo de conclusão do projeto, mas sim aumentará o custo total.
O objetivo do método de compensação tempo-custo é determinar o menor tempo de con-
clusão do projeto, baseando-se na compressão das atividades que resultam no menor au-
mento do custo total do projeto. Para efetuar isso, é necessário encurtar a duração total do
projeto, um período de tempo por vez, comprimindo somente as atividades que estão no(s)
caminho(s) crítico(s) e que tenham o mais baixo custo de aceleração por período de tem-
po. Da Figura 7.7, determinamos anteriormente que, baseando-se em estimativas de custo
e tempo normais, o menor tempo que o projeto poderia ser concluído é 18 semanas (como
determinado pelo caminho crítico C-D), com um custo total de projeto de US$ 200.000.
O custo semanal de aceleração de cada uma das atividades é:
Atividade A US$ 6.000 por semana
Atividade B US$ 10.000 por semana
Atividade C US$ 5.000 por semana
Atividade D US$ 6.000 por semana
Para reduzir a duração total do projeto de 18 para 17 semanas, exige-se primeiramente
a identificação do caminho crítico, que é C-D, e a determinação de quais atividades do
caminho crítico podem ser aceleradas com o mais baixo custo por semana. A aceleração da
atividade C custa US$ 5.000 por semana, e da atividade D, US$ 6.000 por semana. Portanto,
é menos caro apressar a atividade C. Se a atividade C é comprimida 1 semana (de 10 sema-
nas para 9 semanas), a duração total do projeto é encurtada de 18 para 17 semanas, mas o
custo total do projeto aumenta US$5.000, passando para US$ 205.000.
Para encurtar a duração total do projeto em mais um período de tempo, de 17 para 16 se-
manas, devemos identificar novamente o caminho crítico. As durações dos dois caminhos são
de 16 semanas para A-B e de 17 semanas para C-D. Portanto, o caminho crítico ainda é C-D
e deve ser reduzido novamente. Observando o caminho C-D, vemos que, embora a atividade
C tenha um custo de aceleração mais baixo por semana do que a atividade D, não podemos
acelerar a atividade C, porque alcançamos seu tempo de processamento mínimo de 9 semanas
quando o projeto foi reduzido de 18 para 17 semanas. Portanto, a única opção é acelerar a
atividade D em 1 semana, de 8 para 7 semanas. Isso reduz a duração do caminho crítico C-D
para 16 semanas, mas o custo total do projeto aumenta em US$ 6.000 (o custo por semana para
aceleração da atividade D), de US$ 205.000 para US$ 211.000.
Mais uma vez, vamos reduzir a duração do projeto em mais uma semana, de 16 para 15
semanas. Se observarmos os dois caminhos, vemos que ambos estão agora com a mesma
duração, 16 semanas, então, temos agora dois caminhos críticos. Para reduzir a duração to-
tal do projeto de 16 para 15 semanas, é necessário reduzir cada caminho em 1 semana. Ao
observarmos o caminho C-D, vemos que a única atividade com algum tempo remanescente
para ser comprimido é a atividade D. Ela pode ter sua duração reduzida em mais 1 semana,
de 7 para 6 semanas, com um custo adicional de US$ 6.000. Para acelerar o caminho A-B
em uma semana, temos a opção de comprimir a atividade A ou a atividade B. A atividade
A tem um custo de aceleração de US$ 6.000 por semana, comparado à taxa de US$ 10.000
por semana da atividade B. Portanto, para reduzir a duração total do projeto de 16 para
15 semanas, precisamos comprimir as atividades D e A em 1 semana cada. Isso aumenta
o custo total do projeto em US$ 12.000 (US$ 6.000 + US$ 6.000), passando de US$ 211.000
para US$ 223.000.
Vamos tentar novamente encurtar a duração total do projeto em 1 semana, de 15 para 14
semanas. Mais uma vez, temos dois caminhos críticos com a mesma duração, 15 semanas.
Portanto, os dois devem ser reduzidos de 1 semana. No entanto, ao observar o caminho
C-D, vemos que ambas as atividades já estão no tempo de processamento mínimo – 9
semanas e 6 semanas, respectivamente – e, portanto, não podem ser apressadas em nada
mais. Acelerar o caminho A-B não teria nenhum valor, pois isso aumentaria o custo total do
projeto, mas não reduziria sua duração total. Nossa capacidade para reduzir a duração total
do projeto é limitada pelo fato de o caminho C-D não poder ser mais reduzido.
A Tabela 7.1 mostra a aceleração incremental da conclusão total do projeto e o aumento
incremental associado do custo total do projeto. Ela indica que, ao reduzirmos a duração total
do projeto de 1 semana, o custo total do projeto aumentaria em US$ 5.000. Para reduzi-lo a 2
semanas, custaria US$ 11.000, e, para reduzi-lo a 3 semanas, o custo seria de US$ 23.000.
Se todas as quatro atividades fossem comprimidas, o custo total do projeto seria de
US$ 259.000, mas ainda não seria concluído em menos de 15 semanas. Usando o método
TABELA 7.1 Compensação Tempo-Custo
Duração
do Projeto Caminho(s)
(semanas) Crítico(s) Custo Total do Projeto
18 C-D $ 200.000
17 C-D $ 200.000 + $ 5.000 = $ 205.000
16 C-D $ 205.000 + $ 6.000 = $ 211.000
15 C-D, A-B $ 211.000 + $ 6.000 + $ 6.000 = $ 223.000
de compensação tempo-custo, reduzimos a duração do projeto de 18 para 15 semanas com

um custo adicional de US$ 23.000, ao comprimir seletivamente as atividades críticas com o
mais baixo custo de aceleração por período de tempo. Comprimir todas as atividades teria
resultado em um desperdício de US$ 36.000, visto que não se poderia alcançar nenhuma
redução na duração total do projeto superior a 15 semanas.
RESUMO
A metodologia de compensação tempo-custo é utilizada para reduzir a duração do projeto
incrementalmente com o menor aumento associado no custo incremental. Está baseada nas
suposições de que cada atividade tenha uma estimativa de custo e uma duração de proces-
samento mínimo e normais, que a duração de uma atividade pode ser incrementalmente
reduzida ao se aplicarem mais recursos e que a relação entre tempo e custo é linear. O tem-
po normal é a duração estimada de tempo exigida para realizar a atividade sob condições
normais. O custo normal é o custo estimado para concluir a atividade no tempo normal. O
tempo de processamento mínimo é a menor duração estimada do período em que a ativida-
de pode ser concluída. O custo de processamento mínimo é o custo estimado para concluir
a atividade no tempo de processamento mínimo.
PERGUNTAS
1. O que é a metodologia de compensação tempo-custo? Quando é utilizada?

2. Por que são necessários os custos e tempos de processamento mínimo e normais para
esse procedimento?
3. Suponha que uma atividade tenha um tempo normal de 20 semanas, um custo normal
de US$ 72.000, um tempo de processamento mínimo de 16 semanas e um custo de pro-
cessamento mínimo de US$ 100.000. Em quantas semanas, no máximo, pode-se reduzir
a duração dessa atividade? Qual é o custo semanal para acelerar essa atividade?
4. Por que não é apropriado comprimir todas as atividades de um projeto para alcançar o
cronograma mais curto?
APÊNDICE Nº 2 Microsoft Project

Discutiremos neste apêndice como o Microsoft Project pode ser utilizado para sustentar as
técnicas discutidas neste capítulo com base no exemplo de Estudo de Mercado Consumi-
dor. Como foi mostrado no Capítulo 5, se quiser comparar o progresso real com o progres-
so planejado, você deve salvar seu projeto com um plano-base antes do início.
Para salvar os dados do projeto-base, no menu Tools, aponte para Tracking e depois
em Save Baseline, como mostra 7A.1. Você também pode usar essa ferramenta para limpar
uma base.
Como foi discutido no Capítulo 6, para atualizar informações sobre qualquer tarefa, cli-
que diretamente no nome dela para selecionar Task Information no menu. A Tabela Geral
(General Tab) está selecionada como padrão. Nela, você pode selecionar a porcentagem de
trabalho concluído para essa tarefa. Além disso, pode atualizar outras informações, como
o tempo de duração e os recursos exigidos. A Figura 7A.2. mostra a tela de entrada dentro
da Tabela Geral. Depois que as informações da tarefa tenham sido alteradas, os gráficos
PERT e de Gantt serão automaticamente atualizados.
Para conseguir informações sobre as atividades atuais, no menu View, clique em Reports,
para abrir a janela de menu Reports. Clique em Current Activities e depois em Select. Você
deverá ver o menu Current Activity Reports listar seis relatórios disponíveis diferentes, como
mostra a Figura 7A.3.
FIGURA 7A.1 Salvando um Plano-Base
Para obter informações sobre variâncias em seu projeto, no menu View, clique em Gantt
Chart. Em seguida, você precisa selecionar a tabela que exibirá os valores de variância.
No menu View, clique em Table e depois em Variance. Você deve ver a tabela exibida na
Figura 7A.4. Essa tabela mostra os tempos reais de início e término comparados com os
tempos-base de início e término de cada atividade e suas variâncias. Observe que nesse
ponto ainda supomos que o projeto não tenha sido iniciado, de forma que a soma de todas
as variâncias é igual a zero. Isso pode mudar conforme o projeto avança.
Dados de rastreamento importantes podem ser exibidos na Tracking Table. Para isso, na
visualização de Gantt Chart, no menu View, clique em Table e depois em Tracking. Essa
tabela, na Figura 7A.5, mostra os tempos reais de início e de término, a porcentagem de
conclusão, a duração real, a duração remanescente, os custos reais e o tempo de trabalho
real de cada atividade.
Para obter uma representação visual do progresso real versus o progresso planejado, no
menu View, clique em More Views e depois em Tracking Gantt. O gráfico Tracking Gantt,
Figura 7A.6, exibe duas barras para cada tarefa. A barra inferior mostra as datas-base de
início e de término e a barra posterior mostra as datas atuais de início e de término. Desse
modo, você pode ver a diferença entre o plano-base e o cronograma atual.
FIGURA 7A.2 Informações sobre Tarefas
FIGURA 7A.3 Relatórios sobre Atividades Atuais
FIGURA 7A.4 Tabela de Variância
FIGURA 7A.5 Tabela de Rastreamento
FIGURA 7A.6 Rastreando o Gráfico de Gantt
Capítulo CONSIDERAÇÕES SOBRE RECURSOS
8 Planejamento Limitado por

Recursos
Utilização Planejada de Recursos
Nivelamento de Recursos
de Pesquisa Médica sem Fins
Lucrativos
Perguntas
Programação com Limitação de Atividade em Grupo
Recursos Estudo de Caso no 2 O Casamento
Software de Gestão de Projetos Perguntas
Resumo Atividade em Grupo
Perguntas Apêndice Microsoft Project
220
Ca pítulo Oito
Projeto do Genoma Humano
Como gestor de projetos, você precisa certificar-se de que sua equipe tem as ferramentas
necessárias para executar o projeto. Essa vantagem pode ser vista nesse exemplo real de
projeto.
Em uma conferência realizada na estação de esqui de Utah, em 1984, cientistas de
várias partes do mundo reuniram-se para discutir métodos de identificação de mutações
genéticas em humanos, especificamente nos sobreviventes da bomba atômica da Segun-
da Guerra Mundial, em Hiroshima e Nagasaki, no Japão. Alguns anos depois, o Departa-
mento Norte-Americano de Energia seguiu a recomendação para estudar e definir todo o
genoma humano, ou seja, todo o conjunto organizado do DNA humano. O governo norte-
americano passou a financiar o recrutamento de cientistas nos Estados Unidos para formar
o Projeto Genoma Humano. Centenas de cientistas de 20 centros de seqüenciamento de
genes da China, da França, da Alemanha, da Grã-Bretanha, do Japão e dos Estados Unidos
colaboraram nesse projeto. Esse esforço internacional foi iniciado formalmente em outu-
bro de 1990 e terminou oficialmente em 14 de abril de 2003. Equipes de cientistas traba-
lharam por 13 anos para mapear o genoma humano completo. Parece muito tempo, mas,
na verdade, esse grande e bem-sucedido projeto foi concluído antes do prazo e dentro do
orçamento, o que, no início, ninguém acreditava que fosse possível. Os cientistas norte-
americanos originalmente iniciaram o projeto com um orçamento de US$ 3 bilhões e uma
data de conclusão estabelecida para 2005. Os cientistas não acreditavam que poderiam
cumprir suas metas diante dessas limitações de tempo e de orçamento. Em 1990, sabiam
que a tecnologia existente para a análise de genes não era adequada em termos de preci-
são e eficiência. Desse modo, durante os primeiros anos do projeto, equipes concentraram
se na criação das ferramentas necessárias. Desenvolveram novos métodos para estudar os
genes e obtiveram avanços na biologia computacional e no armazenamento de informa-
ções. Uma vez criada uma tecnologia melhor, eles foram capazes de trabalhar mais rápido
e com mais eficiência. Em 1990, era de US$ 10 o custo para identificar uma única letra do
código de DNA, cada uma composta de um par de base. Um técnico treinado precisava de
um dia inteiro para processar 10.000 desses pares de base. Depois do desenvolvimento das
novas tecnologias, o custo caiu para US$ 0,05 por par de base, e o tempo para processar
10.000 pares de base caiu drasticamente para apenas um segundo.
Com a tecnologia certa, esse projeto terminou dois anos antes do programado e
US$ 400 milhões abaixo do orçado. Com a colaboração internacional, os cientistas foram
capazes de identificar 99% das porções de genes do genoma humano. Para identificar as
porções desconhecidas restantes, os cientistas precisam de tecnologia ainda mais avan-
çada. Outros grandes resultados desse projeto são: o banco de dados público criado para
reunir todos os dados do projeto, o qual permite que as informações do genoma humano
sejam acessíveis a todos os cientistas do mundo sem nenhuma restrição de uso ou redis-
tribuição; novas ferramentas de análise desenvolvidas para o projeto, as quais continuam
sendo úteis para trabalhar com os dados no banco de dados público; e a identificação de
mais de 1.400 genes de doenças humanas – anteriormente ao projeto somente 100 genes
de doenças humanas haviam sido identificados.
International Consortium Completes Human Genome Project, http://ornl.gov/sci/techresources/Human_Genome/project/

50yr/press4_2003.shtml.
Weiss, R. Genome Project Complete; Findings May Alter Humanity’s Sense of Itself, Experts Predict. Washington Post, 15 de
abril de 2003, p. A06.
221
Nos capítulos anteriores, estabelecemos cronogramas baseados no elemento tempo. Ad-

mitimos que os recursos exigidos para realizar as atividades individuais estariam dispo-
níveis quando fossem necessários. Esses podem ser pessoas, equipamentos, máquinas,
ferramentas, instalações e espaço. As pessoas podem ser de diferentes especializações
profissionais, como pintores, designers, cozinheiros, programadores de computador e
montadores.
A consideração de recursos acrescenta outra dimensão para o planejamento e a pro-
gramação de projetos. Em muitos projetos, há limites para as quantidades disponíveis dos
diversos tipos de recursos necessários à realização das atividades do projeto. Várias delas
podem requerer os mesmos recursos ao mesmo tempo e, assim, pode não haver recursos
disponíveis para satisfazer toda a demanda. De certo modo, essas atividades competem
com o uso dos mesmos recursos. Se não há recursos suficientes disponíveis, algumas
atividades podem ter de ser adiadas para quando os recursos estejam disponíveis para
elas. Portanto, os recursos podem limitar o cronograma do projeto. Eles podem também
ser um obstáculo para a conclusão do projeto dentro do orçamento quando se determina
a necessidade de recursos adicionais para concluir o projeto a tempo.
Este capítulo tratará de diversas abordagens de incorporação das considerações de
recursos no planejamento e na programação de projetos. Você aprenderá a:
• levar em consideração as limitações de recursos ao desenvolver um diagrama de rede;
• determinar a utilização planejada de recursos para um projeto;
• nivelar o uso de recursos dentro dos prazos exigidos para o projeto;
• elaborar o cronograma de projeto mais curto possível com as limitações de recursos
disponíveis.
PLANEJAMENTO LIMITADO POR RECURSOS

Um modo de determinar recursos é levá-los em consideração ao ilustrar as relações lógi-
cas entre as atividades no diagrama de rede. No mínimo, os diagramas de rede ilustram as
limitações técnicas entre as atividades. Essas atividades são projetadas em uma relação de
série, porque, do ponto de vista técnico, estas devem ser realizadas nessa seqüência. Por
exemplo, a Figura 8.1 mostra que as três atividades de construção de uma casa – construir
alicerce, levantar paredes e colocar telhado – devem ser feitas em série. Tecnicamente,
essas atividades devem ser realizadas nessa seqüência. O telhado não pode ser colocado
antes que as paredes sejam construídas!
Além de mostrar as limitações técnicas entre as atividades, a lógica de rede também
pode levar em consideração as limitações de recursos. A seqüência de atividades pode ser
ilustrada para refletir a disponibilidade de um número limitado de recursos. A parte (a) da
Figura 8.2 mostra que, tecnicamente, três atividades – pintar sala de estar, cozinha e pintar
dormitório – podem ser realizadas simultaneamente, isto é, não há uma razão técnica para
que o início de qualquer uma delas dependa da conclusão de outra. Suponha, no entanto, que
haja somente uma pessoa disponível para fazer toda a pintura. Essa limitação apresenta uma
restrição de recurso nas atividades de pintura, ou seja, embora tecnicamente as três possam
ser feitas simultaneamente, terão de ser realizadas em série porque há somente um pintor
disponível para as três. Para incorporar essa limitação de recursos, o diagrama terá que ser
FIGURA 8.1 Seqüência de Atividades com Limitações Técnicas
Construir Construir Colocar

Alicerce Paredes Telhado
Capítulo 8 Considerações sobre Recursos 223
FIGURA 8.2 Planejamento Limitado por Recursos
Pintar
Sala de Estar
Iniciar Pintar Finalizar

Projeto Cozinha Projeto
Pintar
Dormitório
(a) Seqüência de Atividades sem Limitações de Recursos
Iniciar Pintar Pintar Pintar Finalizar

Projeto Sala de Estar Cozinha Dormitório Projeto
(b) Seqüência de Atividades Baseada em Limitações de Recursos
projetado como mostra a parte (b) da Figura 8.2. A seqüência exata dessas três atividades
– qual sala é pintada primeiro, em segundo e em terceiro – é outra decisão que deve ser
tomada ao desenhar o diagrama de rede.

1. No mínimo, os diagramas de rede
ilustram as limitações _______________
entre as atividades. No entanto, quando
os recursos disponíveis são limitados,
o diagrama de rede pode ser elaborado
para refletir também as limitações de
________________.
Esse exemplo ilustra como as limitações podem ser consideradas ao se elaborar um

plano de rede. Essa abordagem de incorporar as limitações de recursos nas relações lógicas
entre as atividades do diagrama de rede é viável para projetos pequenos e de poucos re-
cursos. No entanto, torna-se complicada para projetos grandes e para aqueles em que são
necessários vários recursos diferentes para algumas das atividades.
UTILIZAÇÃO PLANEJADA DE RECURSOS

Se os recursos forem considerados no planejamento, é preciso indicar a quantidade e os
tipos de recursos necessários para realizar cada atividade. A Figura 8.3 é um diagrama de
rede para um projeto de pintura. Cada caixa de atividade mostra sua duração estimada (em
dias), assim como o número de pintores necessário para executar a atividade dentro da
duração estimada.
FIGURA 8.3 Projeto de Pintura com Recursos Necessários
Pintar
Escadas e Hall
4 Dias
Pintar Cômodos 1 Pintor
do Primeiro Andar
8 Dias
Pintar
2 Pintores
Banheiro
2 Dias
Pintar Cômodos 1 Pintor
Iniciar do Térreo Finalizar
Projeto 4 Dias Projeto
1 Pintor
Pintar
Dormitórios
6 Dias
1 Pintor
Com as informações da Figura 8.3, podemos elaborar um gráfico de utilização de recur-

sos, como mostra a Figura 8.4, que indica quantos pintores são necessários para cada dia,
baseando-se no tempo de início mais cedo e de término mais cedo para cada atividade.
O gráfico de utilização de recursos mostra que são necessários quatro pintores do dia 1 ao
dia 4, três pintores nos dias 5 e 6, dois pintores do dia 7 ao dia 10 e somente um pintor
nos dias 11 e 12. Ou seja, é necessário um total de 32 dias de pintura. O perfil de recursos
para pintores é ilustrado na Figura 8.5, que mostra uma utilização irregular de pintores. São
necessários um máximo de quatro pintores em uma fase do projeto e somente um pintor
em outra fase do projeto.
Recursos como pintores, por exemplo, geralmente não podem ser contratados como
diaristas para cumprir com os requisitos de flutuação. Se o mesmo número de pintores deve
ser empregado durante todo o projeto, será necessário pagar alguns pintores para trabalhar
horas extras durante os períodos de demanda máxima e pagar alguns outros pintores que
FIGURA 8.4 Utilização Planejada de Recursos
Pintores
Dias
Cômodos do Primeiro Andar (2 Pintores) 16
Escadas e Hall (1 Pintor) 4

Banheiro
(1 Pintor) 2
Cômodos do Térreo
(1 Pintor) 4
Dormitórios (1 Pintor) 6
Dia 1 2 3 4 5 6 7 8 9 10 11 12
Pintores 4 4 4 4 3 3 2 2 2 2 1 1 32
FIGURA 8.5 Perfil de Recursos para Pintores
Pintores
1 2 3 4 5 6 7 8 9 10 11 12
Dias
ficarão ociosos durante os períodos de baixa demanda. Desse modo, é preferível ter uma
aplicação de recursos mais uniforme, ou nivelada.
Deve-se notar que os gráficos de utilização de recursos mostrados nas Figuras 8.4 e 8.5
são baseados no tempo de início mais cedo de cada atividade. Esses gráficos de utilização
de recursos devem ser baseados em um cronograma “mais cedo possível” (MCP). Os
gráficos de utilização de recursos baseados no tempo de início mais tarde de cada atividade
devem ser baseados em um cronograma “mais tarde possível” (MTP).
NIVELAMENTO DE RECURSOS
O nivelamento de recursos é um método para desenvolver uma programação que pro-
cura minimizar as flutuações da demanda de recursos. Esse método nivela os recursos de
maneira que sejam aplicados o mais uniformemente possível sem estender o cronograma
do projeto além da data de conclusão exigida. É um método de tentativa e erro em que
atividades não críticas (aquelas que têm valores de folga positiva) são atrasadas para depois
do tempo de início mais cedo, a fim de manter um nível uniforme de recursos exigidos.
As atividades podem ser atrasadas somente até o ponto em que toda a folga positiva tenha
sido gasta, de modo que qualquer outro atraso estenderia seu projeto além da data de con-
clusão. O nivelamento de recursos procura estabelecer uma programação na qual o uso de
recursos é feito da forma mais nivelada possível sem estender o projeto além do tempo
de conclusão exigido.

2. O nivelamento de recursos procura
estabelecer uma programação na qual
o uso de recursos é feito do modo mais
nivelado possível sem estender o projeto
além do tempo de __________________.
Vamos analisar o projeto de pintura nas Figuras 8.3, 8.4 e 8.5, para determinar se a uti-
lização de recursos pode ser nivelada. As Figuras 8.3 e 8.4 mostram que o caminho crítico
para o projeto é formado por duas atividades e é de 12 dias (8 dias para pintar os cômo-
dos do primeiro andar e mais 4 dias para pintar as escadas e o hall). Portanto, essas duas
atividades não podem ser atrasadas sem que se estenda o tempo de conclusão do projeto
além de 12 dias. No entanto, observando a Figura 8.4, podemos ver que “Banheiro” po-
deria ser atrasado em até 2 dias, “Cômodos do Térreo” poderia ser atrasado em até 8 dias
e “Dormitórios” em até 6 dias – tudo sem estender o tempo de conclusão do projeto além
de 12 dias. Observando a Figura 8.4, podemos verificar que é possível tomar duas ações
alternativas para nivelar a demanda de recursos diários para pintores:
Alternativa 1. Atrasar a atividade com a folga mais positiva – “Cômodos do Térreo”
(folga de +8 dias) – em seis dias, ou seja, iniciá-la depois que “Dormitórios” tenha
terminado. Em vez de ter dois pintores diferentes para pintar os cômodos do térreo
e os dormitórios concomitantemente, a programação com nivelamento de recursos
utilizará o mesmo pintor para primeiro pintar os dormitórios e depois pintar os cô-
modos do térreo.
Alternativa 2. Atrasar “Dormitório”, de maneira a iniciá-lo no dia 4, depois que “Cô-
modos do Térreo” estiver concluída. Essa alternativa utilizará o mesmo pintor para
primeiro pintar os cômodos do térreo e depois pintar os dormitórios (o inverso da
alternativa 1, mas que alcança o mesmo resultado).
As Figuras 8.6 e 8.7 ilustram o perfil de recursos para a programação com nivelamento de
recursos (se escolhermos a alternativa 1). Comparando a Figura 8.6 com a Figura 8.4, obser-
vamos que o tempo de início mais cedo para “Cômodos do Térreo” foi atrasado de tempo 0
para o dia 6, e seu tempo de término mais cedo agora é dia 10, em vez de dia 4. A Figura 8.7
mostra uma utilização mais uniforme de pintores do que a Figura 8.5, exceto para os dias 11
e 12, que se mantêm iguais. Nos dois casos, são exigidos 32 pintores-dia, mas, na programa-
ção com nivelamento de recursos, eles são utilizados com menor flutuação.
Em projetos grandes e com muitos recursos diferentes, o nivelamento de recursos pode
se tornar bastante complicado. Existem vários pacotes de software de gestão de projetos
para auxiliar na elaboração de uma programação com nivelamento de recursos e de perfis
e gráficos de utilização de recursos.
CRONOGRAMA LIMITADO POR RECURSOS

O cronograma limitado por recursos é um método para desenvolver o cronograma mais
curto possível para uma quantidade fixa de recursos disponíveis. Esse método é apropriado
quando os recursos disponíveis para o projeto são limitados e esses limites não podem ser
excedidos. O método estende o tempo de conclusão do projeto, se necessário, a fim de
FIGURA 8.6 Utilização do Nivelamento de Recursos
Pintores
Dias

Banheiro
(1 Pintor) 2
Cômodos do Térreo (1 Pintor) 4
Dormitórios (1 Pintor) 6
Dia 1 2 3 4 5 6 7 8 9 10 11 12
Pintores 3 3 3 3 3 3 3 3 3 3 1 1 32
FIGURA 8.7 Perfil de Recursos para Pintores após Nivelamento
Pintores
1 2 3 4 5 6 7 8 9 10 11 12
Dias
manter o projeto dentro dos limites de recursos. É um método iterativo no qual os recursos
são alocados para atividades com base na menor folga. Quando diversas atividades preci-
sam do mesmo recurso limitado e na mesma hora, as de menor folga têm prioridade. Se
os recursos sobram, as atividades com a segunda menor folga têm prioridade, e assim por
diante. Se outras atividades precisam de um recurso que foi totalmente alocado para ativi-
dades de maior prioridade, as de menor prioridade ficam atrasadas e, como a folga torna-se
pior, conseqüentemente lhes é dada a prioridade. Esse atraso das atividades pode estender
o tempo de conclusão do projeto.

3. A programação com limitação de
recursos desenvolve o cronograma
_______________ quando a quantidade
de recursos disponíveis é fixa. Esse
método _________________ o tempo de
conclusão do projeto, se necessário, a fim
de manter o projeto dentro dos limites.
A Figura 8.8 ilustra o que poderia acontecer se somente um número limitado de pintores
(dois, por exemplo) estivesse disponível para realizar o projeto de pintura. Quando dimi-
nuímos o nível de recursos porque apenas dois pintores podem ser usados, nós aumenta-
mos o tempo de conclusão do projeto. Se somente dois pintores estão disponíveis todo o
tempo, o prazo de conclusão do projeto tem de ser estendido, pelo menos, do dia 12 ao
dia 16, a fim de cumprir com os 32 dias de pintura exigidos.
Vamos aplicar o cronograma limitado por recursos ao projeto de pintura da Figura 8.3.
A Figura 8.9, assim como a Figura 8.4, é nossa utilização de recursos original, que mostra
um tempo de conclusão de projeto de 12 dias. Vamos supor, porém, que estamos limitados
a somente dois pintores.
A Figura 8.9 mostra que, ao iniciar o projeto, três atividades (“Cômodos do Primeiro
Andar”, “Cômodos do Térreo” e “Dormitórios”) exigem um total de quatro pintores. Entre-
tanto, somente dois pintores estão disponíveis. Desse modo, eles serão alocados para as
atividades de acordo com a prioridade determinada pela folga.
A atividade “Cômodos do Primeiro Andar” tem folga 0, enquanto “Cômodos do Térreo”
tem folga de +8 dias, e “Dormitórios” tem folga de +6 dias. Portanto, os dois pintores serão
alocados para os cômodos do primeiro andar e continuarão designados para essa atividade
até ser concluída (nesse exemplo, supõe-se que, uma vez que se inicia uma atividade, con-
tinua-se com ela até que seja concluída, não sendo possível pará-la ou reiniciá-la). Pelo fato
FIGURA 8.8 Efeito da Viabilidade de Recursos Limitados
Limite
Pintores Reduzido
de Recursos
12 Dias
Tempo de
Conclusão
do Projeto
Estendido
de todos os recursos disponíveis estarem designados para “Cômodos do Primeiro Andar”

do tempo 0 até o dia 8, as outras duas atividades (“Cômodos do Térreo” e “Dormitórios”)
terão o início adiado para depois do dia 8. Essa primeira alocação de recursos é mostrada
na Figura 8.10.
O resultado desse primeiro passo na alocação dos pintores é a prorrogação da conclu-
são do projeto do dia 12 para o dia 14 por causa do atraso da atividade “Dormitórios”. Além
disso, ainda há um problema entre os dias 9 e 12 porque a demanda de recursos excede
o limite de dois pintores. Dessa forma, agora é necessário fazer uma segunda alocação de
pintores no dia 9. “Dormitórios” tem a menor folga (–2 dias); seu tempo de término mais
cedo esperado agora é de 14 dias, e o tempo exigido para a conclusão do projeto é de
12 dias. Como “Dormitórios” exige um pintor, um dos dois pintores disponíveis é alocado
para ela. Um pintor ainda pode ser alocado. Duas atividades, “Escadas e Hall” e “Cômodos
FIGURA 8.9 Utilização Original de Recursos
Folga

Banheiro
(1 Pintor) +2
Cômodos do Térreo
(1 Pintor) +8
Dormitórios (1 Pintor) +6
Dia 1 2 3 4 5 6 7 8 9 10 11 12
Pintores 4 4 4 4 3 3 2 2 2 2 1 1
Projeto de Construção da Rodovia de Indiana
Por causa dos atrasos imprevistos, os projetos de construção de rodovias em geral deixam
frustradas as pessoas que viajam diariamente. O Estado de Indiana evitou com sucesso
muitas frustrações ao utilizar uma abrangente campanha informativa para comunicar ao
público o fechamento da principal auto-estrada do Estado. O governo decidiu interditar
um trecho que abrangia a Interestadual 65 e a Interestadual 70 na cidade de Indianápolis. O
fechamento da rodovia permitiria que os operários trabalhassem dia e noite, a fim de con-
cluir o projeto em 85 dias. Sem a total paralisação da rodovia, o projeto precisaria de mais de
250 dias para ser concluído. No entanto, fechá-la incomodaria cerca dos 175.000 motoristas
que transitam por ela todos os dias.
Uma firma de relações públicas (RP) foi contratada para administrar e implementar
a campanha. A firma de RP colocou o próprio nome, Hyperfix, como marca de identidade
do projeto e criou um logo. A mensagem tinha de alcançar variados grupos de pessoas:
moradores da área, empresas da cidade, organizações de bairro, promotores de eventos,
turistas, motoristas de caminhão e o órgão governamental da cidade de Indianápolis.
Em 2002, os planos para a rodovia, com seu nome e logo, foram exibidos a todos. Eles
forneceram apresentações para os grupos de bairro, líderes da cidade, organizações em-
presariais de Indianápolis; além disso, também se reuniram com a associação de turismo,
de maneira que os viajantes fossem informados. Cartas, com mapas de rotas alternativas,
foram entregues às empresas de transporte. Nas áreas de descanso da rodovia, as pessoas
podiam ver cartazes com detalhes do projeto. O noticiário local deu destaque a Hyperfix
durante as notícias e colocou um link para Hyperfix em seu site.
O logo foi uma excelente ferramenta de comunicação. As pessoas podiam facilmente
falar sobre ele umas com as outras. Em alguns casos, os negócios beneficiaram-se do au-
mento das vendas ao integrar a palavra Hyperfix em seus comerciais.
O trabalho de relações públicas foi considerado um sucesso. A construção iniciou em
26 de maio de 2003, sem maiores problemas de trânsito. As pessoas foram informadas
dos planos com bastante antecedência e souberam utilizar rotas, estacionamentos e trans-
portes públicos alternativos. A American Consulting, uma firma de projeto de engenharia
contratada para a Hyperfix, acredita que a campanha informativa para avisar o público foi
“a chave para o funcionamento do projeto”.
Davis, A. Hype Helped Hyperfix. Indianapolis Business Journal, 9 de junho de 2003, p. 3.
do Térreo”, têm o próximo valor mais baixo de folga (0). Uma maneira de escolher entre
ambas é determinar qual delas tem sido crítica por mais tempo. Observando a Figura 8.9,
vemos que “Escadas e Hall” era mais crítica (folga 0) que “Cômodos do Térreo” (folga de
+8 dias). Portanto, o pintor restante deve ser alocado para “Escadas e Hall”. “Dormitórios”
iniciará depois do dia 8 e continuará até o dia 14. “Escadas e Hall” também iniciará depois
do dia 8 e continuará até o dia 12. Um pintor ficará disponível depois que “Escadas e Hall”
for concluída no dia 12. Assim, as duas atividades restantes, “Cômodos do Térreo” e “Ba-
nheiros”, terão o início adiado para depois do dia 12. Essa segunda alocação é mostrada
na Figura 8.11.
O resultado desse segundo passo na alocação dos pintores é outra prorrogação da con-
clusão do projeto, dessa vez, do dia 14 para o dia 16, por causa do adiamento da atividade
“Cômodos do Térreo”. Ainda há um problema nos dias 13 e 14, visto que a demanda de
recursos excede o limite de dois pintores. Dessa forma, agora é necessário fazer uma ter-
ceira alocação de pintores no dia 13, em que um pintor fica disponível após a conclusão de
“Escadas e Hall” (lembre-se de que o segundo pintor ainda está trabalhando em “Dormitó-
rios”). Duas atividades, “Banheiros” e “Cômodos do Térreo”, precisam de um pintor no dia
13. Como “Cômodos do Térreo” tem menos folga (–4 dias) que a outra atividade, o pintor
FIGURA 8.10 Primeira Alocação de Recursos
Folga

Banheiro
(1 Pintor) 2
Cômodos do Térreo (1 Pintor) 0
Dormitórios (1 Pintor) Ð2
Dia 1 2 3 4 5 6 7 8 9 10 11 12 13 14
Pintores 2 2 2 2 2 2 2 2 4 4 3 3 1 1
disponível será alocado para ela. “Cômodos do Térreo” iniciará depois do dia 12 e continua-
rá até o dia 16. Um pintor ficará disponível depois que “Dormitórios” for concluída no dia
14. Portanto, “Banheiro” terá o início adiado para depois do dia 14. Essa terceira alocação
de recursos é mostrada na Figura 8.12.
Como resultado desse terceiro passo na alocação dos pintores, o tempo de conclusão
do projeto é de quatro dias a mais que o tempo exigido para a conclusão do projeto, mas
todas as atividades foram programadas para iniciar e terminar com o propósito de ficarem
no limite de dois pintores. Nenhuma outra alocação é necessária.
A fim de acelerar o cronograma para concluir o projeto até o dia 12, seria necessário
implementar uma ou mais abordagens para controle de cronograma mencionadas no Capí-
tulo 7, como contratar mais pintores, fazer horas extras, reduzir o escopo de trabalho ou os
requisitos de algumas atividades, ou ainda aumentar a produtividade.
O cronograma limitado por recursos pode tornar-se muito complicado para um projeto
grande que exija muitos recursos diferentes, cada qual com um limite diferente de viabilidade.
FIGURA 8.11 Segunda Alocação de Recursos
Folga

Banheiro
(1 Pintor) –2
Cômodos do Térreo (1 Pintor) –4
Dormitórios (1 Pintor) –2
Dia 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Pintores 2 2 2 2 2 2 2 2 2 2 2 2 3 3 1 1
FIGURA 8.12 Terceira Alocação de Recursos
Folga

Banheiro
(1 Pintor) –4
Cômodos do Térreo (1 Pintor) –4
Dormitórios (1 Pintor) –2
Dia 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16
Pintores 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2 2
Existem vários softwares de gestão de projeto que executam a programação com limitação
de recursos.

O software de gestão de projeto fornece excelentes recursos para executar as considerações
sobre recursos em um projeto. A maioria dos pacotes de software permite que se crie e mante-
nha uma lista de recursos que podem ser utilizados por todas as tarefas de um projeto. A lista
normalmente permite armazenar o nome do recurso, o número máximo de unidades dispo-
níveis, os valores-padrão de horas e de horas extras e os custos. Além disso, visto que os
gastos com recursos podem ocorrer várias vezes durante um projeto, a maioria dos sistemas
de software permite que se crie um lançamento de débito para um recurso no início do uso,
Os recursos podem limitar o cronograma do projeto, visto que podem existir limites
para as quantidades disponíveis dos diversos tipos de recursos necessários à realização
das atividades do projeto.
• Se os recursos forem considerados no planejamento, é preciso estimar a quantida-
de e os tipos de recursos necessários para realizar cada atividade.
• Se não há recursos suficientes, algumas atividades podem ter de ser reprograma-
das para quando os recursos estiverem disponíveis para realizá-las.
• O nivelamento de recursos é um método para desenvolver uma programação que
procura minimizar as flutuações da demanda de recursos. Esse método nivela os re-
cursos de maneira que sejam aplicados o mais uniformemente possível, sem esten-
der o cronograma do projeto além da data de conclusão exigida.
• O cronograma limitado por recursos é um método para desenvolver o cronograma
mais curto quando o número de recursos disponíveis é fixo. Esse método estende
o tempo de conclusão do projeto, se necessário, a fim de manter o projeto dentro
dos limites de recursos.
nos intervalos fixos ou no final do projeto. A cada recurso, pode ser também atribuído um
calendário de disponibilidade.
O software normalmente informa o usuário se qualquer recurso tem conflitos de tempo
ou se qualquer recurso está superalocado em um projeto ou entre os projetos atuais. Geral-
mente são disponibilizados tabelas e gráficos de utilização de recursos.
Para resolver qualquer conflito ou nivelar os recursos, o software normalmente fornece
duas opções. A primeira é corrigir a situação manualmente. Com essa opção, o usuário
modifica os requisitos e as informações da tarefa ou a lista de recursos e depois observa se
a situação foi resolvida. A segunda opção é permitir que o software realize esse processo
automaticamente. Se o processo automático é selecionado, este normalmente pergunta ao
usuário se o prazo máximo pode ser estendido como a única maneira de resolver o conflito
ou nivelar os recursos.
Assim como ocorre com os outros recursos do software de gestão de projeto que te-
mos discutido, tudo isso pode ser feito com um simples clique. Veja o Apêndice A para uma
discussão completa sobre o software de gestão de projeto.
RESUMO
Os recursos podem ser pessoas, equipamentos, máquinas, ferramentas, instalações e espa-
ço. O pessoal pode ser de diferentes especializações profissionais, como pintores, desig-
ners, cozinheiros, programadores de computador e montadores.
A consideração de recursos acrescenta outra dimensão (além do elemento tempo) para o
planejamento e a programação de projetos. Em muitos projetos, existem limitações para as quan-
tidades disponíveis dos diversos tipos de recursos necessários à realização das atividades do
projeto. Várias delas podem requerer os mesmos recursos simultaneamente e, assim, pode
não haver recursos disponíveis para satisfazer toda a demanda. Se não há recursos sufi-
cientes disponíveis, algumas atividades podem ter de ser adiadas para quando os recursos
estejam disponíveis para elas.
Um modo de determinar os recursos é considerá-los ao ilustrar as relações lógicas entre
as atividades no diagrama de rede. Além disso, ao mostrar as limitações técnicas entre as
atividades, a lógica de rede também pode levar em consideração as limitações de recur-
sos. A seqüência de atividades pode ser ilustrada para refletir a disponibilidade de um
número limitado de recursos. Se forem considerados no planejamento, é preciso indicar a
quantidade e os tipos de recursos necessários para realizar cada atividade. Por essa razão,
geralmente se desenvolve um perfil de recursos.
O nivelamento de recursos é um método para desenvolver uma programação que pro-
cura minimizar as flutuações da demanda desta. Esse método nivela os recursos de maneira
que sejam aplicados o mais uniformemente possível sem estender o cronograma do projeto
além da data de conclusão exigida. No nivelamento de recursos, a data exigida para a con-
clusão do projeto é fixa e os recursos são alternados, a fim de eliminar a flutuação.
Elaborar uma programação com limitações de recursos é um método para desenvolver
o cronograma mais estreito possível para uma quantidade fixa de recursos disponíveis. Esse
método é apropriado quando os recursos disponíveis para o projeto são limitados e esses
limites não podem ser excedidos. O método estende a data de conclusão do projeto, se
necessário, a fim de se manter dentro dos limites de recursos. É um método iterativo no
qual eles são alocados para as atividades com base na folga mínima. As etapas são repetidas
até que todas as limitações de recursos tenham sido satisfeitas. Na programação com tais
limitações, os recursos são fixos e a data de conclusão do projeto é variada (estendida), a
fim de não exceder os limites de recursos.
A Figura 8.13 mostra as diferenças entre o nivelamento de recursos e a programação
com limitações de recursos.
Para um projeto maior que requeira muitos recursos diferentes, em que exista um limite
diferente de disponibilidade para cada um, a programação com limitações de recursos pode
FIGURA 8.13 Elementos Variáveis e Fixos para Nivelamento de Recursos e Programação

com Limitações de Recursos
Fixos Variáveis
Nivelamento Tempo de Conclusão Recursos

de Recursos Exigido para o Projeto
Programação com Tempo de Conclusão

Recursos
Limitações de Recursos Exigido para o Projeto
se tornar bastante complicada. Existem vários pacotes de software de gestão de projeto para
auxiliar nesse processo.
PERGUNTAS
1. Cite pelo menos dez exemplos de recursos.
2. Pense em um projeto que esteja atualmente executando ou tenha executado. Faça uma
lista dos recursos usados nesse projeto.
3. Por que os recursos precisam ser considerados ao se elaborar um cronograma?
4. Descreva como os recursos podem ser considerados ao desenhar um diagrama de rede.
5. O que são restrições técnicas? Dê alguns exemplos.
6. O que são restrições de recursos? Dê alguns exemplos.
7. Descreva o que significa nivelamento de recursos. Por que e quando é usado?
8. O nivelamento de recursos mantém um projeto em seu cronograma? Em caso afirmativo,
como isso ocorre?
9. Descreva o que significa programação com limitações de recursos. Por que é usada?
Quando é usada?
10. A programação com limitações de recursos mantém um projeto em seu cronograma? Em
caso afirmativo, como isso ocorre?
11. Usando a figura seguinte, faça um nivelamento de recursos. Suponha que cada tarefa
possa ser realizada independentemente das outras tarefas.
Tarefa 1 (2 trabalhadores)
Tarefa 2 (1 trabalhador)
Tarefa 5 (1 trabalhador)
Tarefa 6 ( 3 trabalhadores)
Dia 1 2 3 4 5 6 7 8 9 10
Trabalhadores 6 6 6 4 2 3 3 4 3 3
12. Usando a figura da questão 11, faça uma programação com limitações de recursos. Su-
ponha que tenha somente três trabalhadores disponíveis todo o tempo. Qual é a nova
data de conclusão para o projeto?
1. Procure por nivelamento de recursos na Internet e descreva o que descobriu.
2. Descubra e descreva como pelo menos um pacote de software de gestão de projeto
trata as considerações sobre recursos discutidas neste capítulo.
3. Para as questões de 3 a 5, visite a Associação para Gestão de Projetos (Association for
Project Management) no site http://www.apm.org.uk. Descreva as metas e os objetivos
dessa organização.
4. Explore os recursos oferecidos nesse site.
5. Explore as diferentes seções da organização. Entre nos links de outros sites do capítulo.
Explore pelo menos três dos links e descreva o que descobriu.

Lucrativos
Este estudo de caso é a continuação do caso apresentado nos Capítulos 5, 6 e 7.
PERGUNTAS
Utilizando o cronograma revisado que você calculou no item 1 do Capítulo 7 para elimi-
nar todas as folgas negativas (se não tinha nenhuma folga negativa para eliminar, utilize
o cronograma que calculou no item 2 do Capítulo 6) e a matriz de responsabilidades que
desenvolveu no Capítulo 5, agora elabore:
1. um gráfico da utilização planejada de recursos (semelhante ao da Figura 8.4);
2. um perfil de recursos (semelhante ao da Figura 8.5) para cada recurso, baseado no
cronograma “mais cedo possível” (MCP).
ATIVIDADE EM GRUPO
Observação: O estudo deste caso continuará no Capítulo 9; portanto, guarde os resulta-
dos de seu trabalho.

Este estudo de caso é a continuação do caso apresentado nos Capítulos 5, 6 e 7.
PERGUNTAS
Utilizando o cronograma revisado que você calculou no item 1 do Capítulo 7 para eliminar
todas as folgas negativas (se não tinha nenhuma folga negativa para eliminar, utilize o cro-
nograma que você calculou no item 2 do Capítulo 6) e a matriz de responsabilidades que
desenvolveu no Capítulo 5, agora elabore:
1. um gráfico da utilização planejada de recursos (semelhante ao da Figura 8.4);
2. um perfil de recursos (semelhante ao da Figura 8.5) para cada recurso, baseado no
cronograma “mais cedo possível” (MCP).
ATIVIDADE EM GRUPO
Observação: O estudo deste caso continuará no Capítulo 9; portanto, guarde os resulta-
dos de seu trabalho.

Neste apêndice, discutiremos como o Microsoft Project pode ser utilizado para apoiar as
técnicas discutidas neste capítulo, utilizando o exemplo do Estudo de Mercado Consumi-
dor.
A Figura 8A.1 mostra uma planilha de recursos para o estudo de mercado consumidor.
Para obter a planilha de recursos, clique em Resource Sheet no menu View. Como apren-
deu no Capítulo 5, essa tabela lhe permite inserir informações, como os valores de paga-
mento de horas extras e padrão e calendários de trabalhos específicos para cada um de seus
recursos. Observe que, para cada trabalhador do Estudo de Mercado Consumidor, foram
inseridos os valores de pagamento. Outros recursos, além dos recursos humanos, também
podem ser inseridos nessa tabela.
Podem-se inserir informações adicionais sobre cada recurso, clicando duas vezes sobre
um nome de recurso na coluna Resource Name. Você verá a janela Resource Information com
cinco guias: General, Working Time, Costs, Notes e Custom Fields, como na Figura 8A.2.
Para visualizar vários relatórios relacionados a seus recursos, clique em Reports no menu
View, selecione Assignments e clique em Select. Você verá quatro tipos diferentes de rela-
tórios de atribuições (Figura 8A.3).
No menu Assignment Reports, selecione Overallocated Resources e clique em Select.
FIGURA 8A.1 Planilha de Recursos
FIGURA 8A.2 Observações sobre Recursos
FIGURA 8A.3 Relatórios de Atribuição
FIGURA 8A.4 Relatório de Recursos Superalocados
Esse relatório (Figura 8A.4) fornece informações para todos os recursos que forem su-
peralocados. Nesse exemplo, observe que Steve foi designado para Preparar Etiquetas para
Mala Direta na sexta-feira, 10/3/2006, e na segunda-feira, 13/3/2006, oito horas por dia. Ele
também foi designado para Imprimir Questionário nos mesmos dias, pelo mesmo período
de tempo. Em outras palavras, esse relatório indica que Steve está designado para trabalhar
16 horas por dia na sexta-feira (dia 10 de março) e na segunda-feira (13 de março).
O relatório de Utilização de Recursos da Figura 8A.5 mostra as atribuições de tarefas e
recursos em um cronograma semanal. Para elaborá-lo, clique em Reports no menu View
para abrir a janela do menu Reports. No menu, clique em Workload e em seguida em Se-
lect. Você deverá ver um menu de dois tipos diferentes de Relatórios de Carga de Traba-
lho: Utilização de Tarefas e Utilização de Recursos. Selecione Resource Usage e clique em
Select.
Para executar a ferramenta de nivelamento de recursos criada pela Microsoft, clique em
Level Resources no menu Tools para abrir a janela da ferramenta de Nivelamento de Recursos
(Figura 8A.6). No Microsoft Project, basicamente a ferramenta de nivelamento de recursos ape-
nas examina os recursos superalocados e normalmente soluciona essas superalocações,
estendendo o prazo final do projeto. Feito esse nivelamento, o Microsoft Project não altera
as atribuições de recursos e as informações sobre tarefas. Ele apenas adia tarefas com
recursos superalocados. O nivelamento pode ser realizado, clicando no botão Level Now.
O nivelamento pode ser eliminado clicando no botão Clear Leveling.
Para obter uma análise de todos os recursos de seu projeto com o total de horas de
trabalho, o custo total e as taxas de utilização máxima, clique em Resource Sheet no menu
View. Em seguida, clique em Table e depois em Summary no menu View (Figura 8A.7).
FIGURA 8A.5 Relatório de Utilização de Recursos
FIGURA 8A.6 Nivelamento de Recursos
FIGURA 8A.7 Tabela de Recursos
Capítulo PLANEJAMENTO E DESEMPENHO DE CUSTOS
9 Estimativas de Custos do Projeto

Orçamento do Projeto
Alocando o Custo Orçado Total
Controle de Custos
Gerindo o Fluxo de Caixa
Desenvolvendo o Custo Orçado Resumo
Acumulado Perguntas
Determinando o Custo Real Exercícios na Internet
Custo Real Estudo de Caso no 1 Um Centro
Custo Comprometido de Pesquisa Médica sem Fins
Comparando o Custo Real com o Lucrativos
Custo Orçado Perguntas
Determinando o Valor do Trabalho Atividade em Grupo
Realizado Estudo de Caso no 2 O Casamento
Análise de Desempenho de Custo Perguntas
Índice de Desempenho de Custo Atividade em Grupo
Variação de Custos Apêndice – Microsoft Project
Estimativa de Custos
240
Ca pítulo Nov e
eBay
O controle de um projeto depende da capacidade de a equipe analisar os dados do projeto e
produzir indicadores de desempenho úteis. Na seção de Planejamento e Controle do Proje-
to, você aprenderá que os dados sobre os tempos real e esperado de término do projeto po-
dem ser utilizados para controlar o cronograma, assim como as informações sobre os gastos
reais e estimados. Embora esses sejam alguns dos indicadores básicos de desempenho, co-
muns a todos os projetos, diferentes setores industriais tipicamente desenvolvem o próprio
conjunto adicional de formas de mensuração que refletem os objetivos da organização.
“Se não for capaz de mensurá-lo, não poderá controlá-lo”, afirma Meg Whitman, presi-
dente e CEO do eBay. Ela entrou na empresa em 1998 e aplicou seus conhecimentos sobre
métrica de negócios para ajudar a fazer do eBay um website próspero e lucrativo de comér-
cio direto ao consumidor. A missão da empresa é oferecer uma plataforma para trocas que
possa ser usada por todos, o que tem sido feito com sucesso na Internet, melhorando-se
continuamente a experiência dos clientes no website. Decisões sobre mudanças baseiam-
se em fatores mensuráveis.
A empresa realiza algumas mensurações típicas da Internet; calcula, por exemplo, o
número de pessoas que visitam o site, o número de pessoas que se registram como usuá-
rios, o tempo que uma pessoa gasta ao visitá-lo e o tempo para carregar as páginas do
site. Como pioneira no mercado on-line, a empresa também descobriu indicadores novos e
úteis para analisar o desempenho de seus negócios: a relação entre suas receitas e o valor
das mercadorias trocadas no eBay; o dia mais movimentado da semana para as transações
no eBay; e um método de avaliação atribuída ao eBay fundamentado nas opiniões dos
clientes presentes aos painéis de discussão do site.
Gerentes da empresa regularmente coletam e analisam dados de negócios para me-
lhor desenvolver técnicas de marketing e merchandising. Por exemplo, ao fazer a análise de
indicadores do negócio, uma gerente do eBay percebeu uma maior demanda das vendas
de sapatos femininos. Ela enviou uma proposta para os executivos sugerindo a criação de
uma categoria separada para esse tipo específico de mercadoria e, subseqüentemente, a
inclusão de critérios de pesquisa específicos para sapatos femininos. As medidas tomadas
por essa gerente ajudaram a empresa a alcançar seu objetivo: melhorar constantemente o
processo de compra e venda para seus clientes.
Não importa o tamanho de um projeto: seu gestor precisa entender sempre a impor-
tância dos fatores mensuráveis, utilizando-os para tomar decisões apropriadas e, assim,
concretizar o projeto com sucesso.
Lashinsky, A. Meg and the Machine. Fortune Magazine, 1º de setembro de 2003, p. 69-78.
241
Além do planejamento de um cronograma para um projeto, também é necessário plane-

jar seu orçamento. Estimam-se os custos de um projeto quando uma proposta é elabora-
da para ele. Quando fica decidido que o projeto proposto será realizado, é necessária a
elaboração de um orçamento, ou plano, para definir como e quando os recursos serão
gastos durante a execução do projeto. Assim que ele se inicia, é importante monitorar
os custos reais e o desempenho do trabalho para assegurar que tudo esteja de acordo
com o orçamento. Diversos aspectos devem ser monitorados constantemente durante o
projeto, como:
• o valor real acumulado gasto desde o início do projeto;
• o valor agregado acumulado do trabalho realizado desde o início do projeto;
• o valor orçado acumulado que se planejou gastar, com base no cronograma do pro-
jeto, no início do projeto.
Esses aspectos devem ser comparados para verificar se o projeto está sendo executado
dentro do orçamento e se o valor do trabalho desempenhado está de acordo com o valor
real gasto.
Se, em qualquer ponto do projeto, for observado que o valor do orçamento vem sendo
ultrapassado ou que o valor do trabalho desempenhado não está acompanhando o valor
real gasto, deve-se empregar uma ação corretiva. Quando os custos de um projeto ficam
fora de controle, torna-se muito difícil concluir o projeto de acordo com o orçamento.
Como você verá neste capítulo, o segredo para o controle de custos eficiente está em
analisar o desempenho de custo constantemente. Identificar com antecedência as varia-
ções de custo possibilita empregar uma ação corretiva antes que a situação piore. Neste
capítulo, você aprenderá a prever, com regularidade – baseando-se no valor real gasto e
no valor do trabalho desempenhado –, se é possível concluir todo o projeto de acordo
com o orçamento. Você irá se familiarizar com:
• itens a ser considerados na estimativa de custos de um projeto;
• a elaboração de um orçamento, ou plano, para definir como e quando os recursos
serão gastos durante a execução do projeto;
• custos reais acumulados;
• a determinação do valor agregado do trabalho realizado;
• a análise do desempenho de custo;
• a estimativa do custo do projeto na conclusão;
• o controle de custos do projeto;
• a administração do fluxo de caixa.
ESTIMATIVAS DE CUSTO DO PROJETO

O planejamento de custos começa com a proposta para o projeto. Os custos do projeto são
estimados quando o fornecedor ou a equipe de projeto desenvolvem a proposta. Em alguns
casos, a proposta indicará apenas o custo final do projeto proposto. Em outros, o cliente po-
derá solicitar uma análise detalhada dos diversos custos. A seção de custos de uma proposta
pode incluir tabelas de custos estimados do fornecedor para elementos como:
1. Mão-de-obra. Essa parte fornece os custos estimados das várias categorias de profis-
sionais que possivelmente trabalharão no projeto, como, por exemplo, pintores, de-
senhistas e programadores de informática. Deve incluir as horas estimadas e o preço
por hora de trabalho de cada profissional ou categoria.
2. Materiais. Essa parte fornece o custo dos materiais que o fornecedor ou a equipe precisa
comprar para o projeto, como, por exemplo, tintas, madeira, papel de parede, plantas,
tapetes, papéis, artigos para desenho, comida, computadores ou pacotes de software.
3. Subfornecedores e consultores. Quando os fornecedores ou equipes de projeto não
têm habilidades ou recursos para a execução de certas tarefas do projeto, eles podem
Capítulo 9 Planejamento e Desempenho de Custos 243
contratar subfornecedores ou consultores para realizá-las. Exemplos dessas tarefas

são: elaborar um panfleto, desenvolver um manual de treinamento, desenvolver um
software ou oferecer uma recepção.
4. Equipamentos e aluguel de instalações. Às vezes, o fornecedor pode precisar de
equipamentos especiais, ferramentas ou instalações exclusivamente para o projeto.
No entanto, adquiri-los poderá acarretar gastos altos, se eles forem usados apenas
em um ou alguns projetos. Em tais casos, o fornecedor pode alugar os equipamentos
pelo tempo que precisar durante o projeto.
5. Viagens. Caso seja necessário viajar durante o projeto (em caso de viagens que não
sejam locais), os custos da viagem (como passagens, quartos de hotel e refeições)
devem ser incluídos.

1. Faça uma lista dos itens cujos custos
devem ser estimados.
Além dos itens anteriores, o fornecedor ou a equipe do projeto poderão incluir um valor
de contingências, para cobrir despesas imprevistas que poderão surgir durante o projeto.
Por exemplo, alguns itens podem ter sido esquecidos quando as estimativas de custo do
projeto estavam sendo preparadas; algumas tarefas podem precisar ser refeitas por não te-
rem dado bom resultado na primeira vez; custos com mão-de-obra (pagamentos, salários)
ou materiais podem aumentar gradativamente em um projeto que dure mais de um ano.
Recomenda-se que a pessoa responsável pelos custos relacionados a determinado tra-
balho seja também a responsável por elaborar as estimativas de seus custos. Isso a leva a
se comprometer e a evitar comentários tendenciosos relacionados ao fato de se ter uma
mesma pessoa responsável por elaborar todas as estimativas de custo do projeto inteiro. Em
projetos grandes que envolvem centenas de pessoas, não é nada prático que elas forneçam
estimativas de custos. Nesses casos, cada organização ou subfornecedor envolvido pode
eleger uma pessoa experiente para elaborar as estimativas dos custos pelos quais essa orga-
nização ou subfornecedor será responsável. Se um subfornecedor ou organização realizou
anteriormente projetos semelhantes e registrou os custos reais de vários itens, esses dados
poderão servir como base para as estimativas de custos do projeto atual.
Estimativas de custos precisam ser agressivas, porém realistas. Não devem ser excessiva-
mente “recheadas” com recursos de contingência para toda e qualquer eventualidade que
pode surgir a mais ou imprevistos. Se as estimativas de custo forem inflexíveis demais, o
valor do custo total estimado para o projeto provavelmente será maior que aquele que o
cliente está disposto a pagar e maior que o oferecido por fornecedores concorrentes. Entre-
tanto, se as estimativas de custo forem demasiadamente otimistas e algumas despesas im-
previstas surgirem, o fornecedor poderá perder dinheiro (em um contrato de preço global)
ou precisará solicitar ao cliente recursos adicionais para cobrir custos excedentes.
ORÇAMENTO DO PROJETO
O processo para o orçamento de um projeto envolve duas etapas. Na primeira, a estimativa
de custo é alocada para os diversos pacotes de trabalho na estrutura analítica do projeto
(Ver Capítulo 5). Na segunda, o orçamento para cada pacote de trabalho é distribuído ao
longo da duração do pacote de trabalho para que seja possível determinar quanto de seu
orçamento deveria ter sido gasto em qualquer momento do projeto.
Alocando o Custo Orçado Total

Alocar os custos totais do projeto dos diversos elementos, como mão-de-obra, materiais e
subfornecedores, para os pacotes de trabalho adequados na estrutura analítica determinará
um custo orçado total (COT) para cada pacote de trabalho. Há duas abordagens para de-
terminar o COT para cada pacote de trabalho. Uma delas ocorre “de cima para baixo”, em
que os custos totais do projeto (com mão-de-obra, materiais etc.) são analisados em relação
ao escopo de trabalho de cada pacote; nessa abordagem, uma parte do custo total do proje-
to é alocada para cada pacote de trabalho. A outra é uma abordagem que ocorre “de baixo
para cima”, com base em uma estimativa dos custos das atividades detalhadas relacionadas
a cada pacote de trabalho. Normalmente, estima-se o custo do projeto quando a proposta
inicial é elaborada, porém os detalhes não são planejados nessa hora. Ao se iniciar o pro-
jeto, entretanto, detalham-se as atividades e desenvolve-se um plano de rede. Depois de as
atividades detalhadas terem sido definidas, tempo, recursos e estimativas de custos podem
ser determinados para cada atividade. O COT de cada pacote de trabalho será a soma dos
custos de todas as atividades que compõem o pacote de trabalho.

2. A primeira etapa do processo de
orçamento do projeto consiste em alocar
os custos totais do projeto para cada
______________ na estrutura analítica,
estabelecendo-se, assim, um __________
_______ para cada pacote de trabalho.
A Figura 9.1 ilustra a alocação de custos para pacotes de trabalho individuais na estru-
tura analítica de um projeto de US$ 600.000. O valor alocado para cada pacote de trabalho
representa o COT para completar todas as atividades relacionadas ao pacote de trabalho.
Independentemente da abordagem utilizada para determinar o custo orçado total de cada
pacote de trabalho (“de baixo para cima” ou “de cima para baixo”), quando os orçamentos
para todos os pacotes de trabalho forem somados, o valor não poderá ultrapassar o custo
orçado total do projeto.
A Figura 9.2 é um diagrama de rede para um projeto de elaboração de uma máquina
de embalagem automática especializada e sua instalação na fábrica do cliente. Usando essa
máquina, o produto do cliente é colocado em caixas por meio de uma esteira rolante, de
maneira muito rápida. Este projeto servirá de exemplo no decorrer do capítulo; sendo, por-
tanto, tratado de maneira simples. O projeto compõe-se de três atividades e o diagrama
de rede mostra a duração (em semanas) de cada atividade. A Figura 9.3 mostra a estrutura
analítica e o custo orçado total de cada pacote de trabalho.
Desenvolvendo o Custo Orçado Acumulado

Logo que um custo orçado total é determinado para cada pacote de trabalho, a segunda eta-
pa para o processo de orçamento de um projeto é distribuir cada COT ao longo da duração
do pacote de trabalho. Determina-se um custo para cada período, com base no momento
em que as atividades do pacote de trabalho serão realizadas, segundo o cronograma. Logo
que o COT de cada pacote de trabalho é distribuído por período de tempo, pode-se deter-
minar quanto do orçamento deveria ter sido gasto em determinado momento. Esse valor é
calculado somando-se os custos orçados de cada período anterior ao momento em questão.
Esse valor total, conhecido como custo orçado acumulado (COC), corresponde ao valor
orçado para concluir o trabalho a ser realizado até aquele momento. O COC servirá como
referência para análise do desempenho de custos do projeto.
FIGURA 9.1 Estrutura Analítica do Projeto com Orçamentos Alocados
Projeto
$ 600.000
Contingência
$ 20.000
$ 100.000 $ 40.000
$ 60.000 $ 140.000 $ 30.000 $ 50.000
$ 100.000 $ 60.000
FIGURA 9.2 Diagrama de Rede para o Projeto Máquina de Embalagem
Concepção Construção Instalação

da Máquina da Máquina e Testes
1 4 2 6 3 2
LEGENDA
Descrição da
Atividade
FIGURA 9.3 Estrutura Analítica do Projeto para o Projeto Máquina de Embalagem
Máquina de Embalagem
$ 100.000
Concepção Construção Instalação

da Máquina da Máquina e Testes
$ 24.000 $ 60.000 $ 16.000

3. Depois que um custo orçado total
foi estabelecido para cada pacote de
trabalho, a segunda etapa no processo
de orçamento do projeto é __________
_________ cada COT ______________ o
pacote de trabalho em questão.
Para o projeto Máquina de Embalagem, a Figura 9.4 mostra como o COT de cada pacote
de trabalho é distribuído pelos períodos de tempo, com base nas durações previstas na
Figura 9.2. Apresenta-se também o custo orçado do projeto inteiro, período por período,
bem como seu custo orçado acumulado (COC). A Figura 9.4 mostra que US$ 32.000 foram
orçados para a conclusão do trabalho a ser realizado, conforme o cronograma, durante a
semana 5. Os períodos em que os custos orçados são distribuídos determinam-se geral-
mente pelas datas de início e término mais cedo das atividades contidas no plano-base do
cronograma do projeto (adaptado para levar em consideração o nivelamento de recursos
ou o cronograma limitado por recursos).

4. O _______________________________
é o valor orçado para a execução do ____
_____________ a ser desempenhado até
o momento em questão.
Com os valores do COC, é possível elaborar uma curva do custo orçado acumulado para
ilustrar despesas orçadas no decorrer do projeto. A Figura 9.5 mostra a curva do custo orçado
acumulado para o projeto Máquina de Embalagem. Embora a tabela da Figura 9.4 e a curva
de custos da Figura 9.5 mostrem o custo orçado acumulado para o projeto completo, uma
tabela e curva semelhantes podem ser criadas para cada pacote de trabalho, se desejado.
O COC para o projeto inteiro ou para cada pacote de trabalho fornece os custos de re-
ferência com os quais o custo real e o desempenho do projeto poderão ser comparados em
qualquer momento do projeto. Seria um equívoco comparar meramente os valores reais gastos
com o custo orçado total do projeto ou do pacote de trabalho, uma vez que o desempenho
FIGURA 9.4 Custo Orçado por Período para o Projeto Máquina de Embalagem
Semana
COT 1 2 3 4 5 6 7 8 9 10 11 12
Concepção da Máquina 24 4 4 8 8
Construção da Máquina 60 8 8 12 12 10 10
Instalação e Testes 16 8 8
Total 100 4 4 8 8 8 8 12 12 10 10 8 8
Acumulado 4 8 16 24 32 40 52 64 74 84 92 100
As quantias estão expressas em milhares de dólares.
FIGURA 9.5 Curva do Custo Orçado Acumulado para o Projeto Máquina de Embalagem
Custo Orçado Acumulado

(em milhares de dólares)
100 ★
90
Custo
80
Orçado
Total
70
60
50
40
30
20
10
1 2 3 4 5 6 7 8 9 10 11 12
Semanas
de custos sempre parecerá bom, desde que os custos reais sejam inferiores ao COT. No
exemplo Máquina de Embalagem, pensaríamos que o custo do projeto estava sob controle
desde que o custo real total fosse inferior a US$ 100.000. Mas o que acontece se o custo real
total ultrapassar o COT de US$ 100.000 antes de o projeto ser concluído? É tarde demais
para controlar o projeto e esperar concluí-lo dentro do orçamento – que foi ultrapassado –,
havendo ainda tarefas a serem desempenhadas; portanto, mais custos deverão ser incluídos
para finalizar o projeto!
Para se evitar esse tipo de pesadelo, é importante utilizar o custo orçado acumulado, em
vez do custo orçado total, como base de comparação com o custo real. Dessa maneira, se
o custo real começar a ultrapassar o COC, ações corretivas poderão ser empregadas antes
que seja tarde demais.
Para projetos de grande porte que envolvam muitos pacotes de trabalho ou atividades,
existem softwares de gestão de projetos para ajudar no orçamento do projeto.
DETERMINANDO O CUSTO REAL

Uma vez iniciado o projeto, é necessário observar o custo real e o custo comprometido para
que possam ser comparados ao COC.
Custo Real
Para controlar o custo real de um projeto, é necessário estabelecer um sistema para coletar,
de modo constante e regular, dados sobre os recursos que foram gastos de fato. Tal sistema
pode conter procedimentos e modos para reunir dados. Recomenda-se o estabelecimento
de uma forma de contagem com base no sistema numérico da estrutura analítica, para que
cada item do custo real possa ser cobrado no pacote de trabalho adequado. O custo real de
cada pacote de trabalho poderá, então, ser calculado e comparado ao COC.
Registros semanais, escritos ou impressos, são utilizados para reunir custos reais de
mão-de-obra. Os contratados do projeto registram a quantidade de pacotes de trabalho em
que trabalharam e o número de horas gastas em cada um deles. Depois, essas horas são
multiplicadas pela taxa de custo por hora de trabalho de cada pessoa, para determinar o
custo real em dólares. Em empresas que utilizam uma estrutura organizacional do tipo ma-
tricial, os funcionários podem ser destinados simultaneamente a vários projetos. Em casos
como esse, a pessoa precisa registrar o número correto do projeto, bem como o número do
pacote de trabalho, na folha de papel, para assegurar que os custos reais da mão-de-obra
sejam cobrados no projeto apropriado. Notas fiscais de materiais ou serviços empregados
no projeto também devem ser cobrados no número de pacote de trabalho apropriado.
Custo Comprometido
Em muitos projetos, uma enorme quantia de dinheiro é gasta em materiais ou serviços
(subfornecedores, consultores) que são empregados por mais tempo do que o período do
relatório de custos. Esses custos comprometidos precisam ser tratados de forma especial
para que o sistema inclua periodicamente uma parte dos custos totais ao custo real, em vez
de esperar a finalização dos materiais e serviços para poder cobrar os custos reais totais.
Custos comprometidos são também conhecidos como compromissos ou custos onerados.
Os custos ficam comprometidos quando um item (material, subfornecedor) é solicitado
– normalmente por compra –, mesmo que o pagamento de fato seja efetuado mais tarde,
quando o material ou serviço terminou de ser usado, foi entregue ou teve nota fiscal emi-
tida. Se o pedido de compra de um item é emitido para um fornecedor ou subfornecedor,
os recursos empregados nessa compra ficam comprometidos e não poderão mais ser gastos
em outras atividades do projeto. Deve-se considerar o valor comprometido como onera-
do, ou este deve ser reservado, pois serão necessários recursos para pagar o fornecedor
ou subfornecedor mais tarde, quando o material ou serviço for entregue e sua nota fiscal,
recebida. Por exemplo, se você contrata um fornecedor para pintar sua casa por US$ 5.000,
esse valor estará comprometido, mesmo que não pague o fornecedor antes da conclusão
do projeto.
Para realizar uma comparação realista entre o custo real e o custo orçado acumulado,
porções do valor comprometido deveriam ser incluídas no custo real, enquanto o trabalho
está sendo realizado. Em certos casos, o fornecedor ou subfornecedor poderá solicitar pres-
tações do pagamento em vez de esperar que o projeto seja concluído para receber. Em uma
situação como essa, quando o fornecedor ou subfornecedor emite notas fiscais referentes a
um pagamento parcelado, seu valor deve ser incluído no custo real do pacote de projeto.
Suponha que um projeto para a elaboração de um sistema de controle de um inventário
computadorizado inclua um subfornecedor e um consultor para desenvolver seis unidades
de software diferentes por US$ 12.000. Conforme as unidades vão sendo concluídas e entre-
gues, o consultor emite notas fiscais no valor de US$ 2.000 cada uma. Quando a nota fiscal
é recebida, deve-se considerar os US$ 2.000 como um custo real.
Imaginemos agora uma situação diferente, em que o fornecedor ou subfornecedor não
emitem notas fiscais para pagamentos parcelados, mas esperam até que o trabalho seja
concluído e entregue, para poder emitir nota fiscal com o valor total. Mesmo em casos
como esse, uma parte do valor comprometido total deveria ser incluída periodicamente no cus-
to real, pois, de fato, o trabalho está sendo executado. Por exemplo, imagine que um projeto
para remodelar o escritório de um edifício inclua um subfornecedor e um fornecedor de
aquecedores para instalação de novas unidades de aquecimento em todos os escritórios
do edifício, durante um período de quatro meses, por US$ 80.000. Todo mês, deveriam ser
incluídos US$ 20.000 no custo real, pois, de fato, o trabalho está sendo realizado, mesmo
que o subfornecedor apenas emita uma nota fiscal no valor de US$ 80.000, quando todo o
trabalho for concluído.
Comparando o Custo Real com o Custo Orçado

Conforme os dados sobre o custo real vão sendo reunidos – incluindo valores de custos com-
prometidos –, estes devem ser calculados por pacote de trabalho para que possam ser
comparados ao custo orçado acumulado. Para o projeto Máquina de Embalagem, a Figu-
ra 9.6 mostra o custo real por período de tempo de cada pacote de trabalho na semana 8.
Apresenta-se também o custo real período por período do projeto completo, bem como o
custo real acumulado (CRC).
A Figura 9.6 indica que, ao fim da semana 8, US$ 68.000 foram gastos, de fato, nesse pro-
jeto. O COC da Figura 9.4 revela que apenas US$ 64.000 foram orçados, para serem gastos
até o fim da semana 8. Trata-se de uma diferença de US$ 4.000 – o projeto está excedendo
seu orçamento.
Com base nos valores do CRC, é possível elaborar uma curva do custo real acumulado.
Desenhando-se essa curva nos mesmos eixos da curva do custo orçado acumulado, confor-
me a Figura 9.7, pode-se visualizar bem essa comparação.
Embora a tabela da Figura 9.6 e as curvas de custo da Figura 9.7 mostrem dados do pro-
jeto como um todo, tabelas e curvas semelhantes para cada pacote de trabalho podem ser
elaboradas, se desejado. A criação de curvas individuais ajudará a indicar com precisão os
pacotes de trabalho específicos que estão contribuindo com custos excedentes.
DETERMINANDO O VALOR DO TRABALHO REALIZADO

Imagine um projeto que envolva a pintura de dez cômodos semelhantes durante 10 dias (um
cômodo por dia) por um custo orçado total no valor de US$ 2.000. O orçamento é de US$ 200
por cômodo. Ao final do dia 5, percebe-se que US$ 1.000 foram gastos de fato. Se você compa-
rar as despesas com o custo orçado acumulado de US$ 1.000 em 5 dias, parece que os custos
reais estão de acordo com o previsto no orçamento. Mas essa é apenas uma parte da história.

os valores em dólares dos pacotes de
trabalho “Concepção da Máquina”
e “Construção da Máquina” que
contribuem para o custo excedente de
US$ 4.000 ao final da semana 8?
FIGURA 9.6 Custo Real por Período para o Projeto Máquina de Embalagem
Semana
Total
1 2 3 4 5 6 7 8 Gasto
Concepção da Máquina 2 5 9 5 1 22
Construção da Máquina 2 8 10 14 12 46
Instalação e Testes 0
Total 2 5 9 7 9 10 14 12 68
Acumulado 2 7 16 23 32 42 56 68 68
FIGURA 9.7 Custo Acumulado Orçado e Real para o Projeto Máquina de Embalagem
Custo Acumulado Período

(em milhares de dólares) de Relatório
100 ★
90
80
70
} $ 4.000 Custos Excedentes
60
50
40
30
LEGENDA:
20 Custo Orçado Acumulado (COC)
Custo Real Acumulado (CRC)
10
1 2 3 4 5 6 7 8 9 10 11 12
Semanas
E se, ao final do dia 5 apenas três cômodos tiverem sido pintados? Não seria um bom
resultado, pois metade do orçamento foi gasto com apenas três dos dez quartos que preci-
sam ser pintados. De outro lado, e se, ao final do dia 5, seis cômodos tiverem sido pintados?
Seria algo excelente, pois apenas metade do orçamento foi gasta na pintura de seis dos dez
cômodos. Esse exemplo serve para introduzir o conceito de valor agregado do trabalho
realizado. Gastar metade do orçamento não significa que metade do trabalho foi desem-
penhada. Caso o trabalho realizado não alcance as metas do custo real, alguma coisa está
errada, mesmo que o custo real esteja de acordo com o COC.
Valor Agregado (VA) – o valor do trabalho de fato desempenhado é o parâmetro-chave
que deve ser determinado durante o projeto. A comparação do custo real acumulado com
o custo orçado acumulado revela apenas parte da história e pode levar a conclusões equi-
vocadas sobre as condições do projeto.
Da mesma forma que é importante observar o custo real de um projeto, é necessário
estabelecer um sistema auxiliar de coleta de dados regular e constante, considerando o
valor agregado do trabalho realizado em cada pacote de trabalho. A determinação do valor
agregado envolve a coleta de dados do percentual realizado de cada pacote de trabalho
e, em seguida, a conversão dessa porcentagem em dólares, multiplicando-se o COT do
pacote de trabalho pelo percentual realizado.
Os dados do percentual realizado geralmente são estimados em cada período pela pes-
soa responsável pelo pacote de trabalho. Em muitos casos, a estimativa é subjetiva. É ex-
tremamente importante que a pessoa responsável por apresentar a estimativa do percentual
realizado faça uma avaliação honesta do trabalho realizado, relativa ao escopo do trabalho
completo do pacote de trabalho. Com freqüência, parece haver uma tendência em ser oti-
mista demais, estimando-se, precipitadamente, um percentual de trabalho realizado elevado.
Por exemplo, imagine que o líder da equipe de um pacote de trabalho com duração de
20 semanas informe que, no final da semana 10, 90% do trabalho foi concluído. Caso essa
informação não seja realista, criará uma falsa impressão de segurança, parecendo que o
desempenho do trabalho está superando o custo real. Um relatório não-realista levará o ges-
tor de projeto a concluir que o desempenho do projeto é melhor do que seu desempenho real,
o que impede o gestor de empregar ações corretivas. Quando o percentual realizado co-
meçar a se estagnar e o custo real continuar a se acumular, parecerá que o desempenho do
projeto está piorando nas últimas semanas. Na semana 20, o percentual realizado poderá ser
de apenas 96%, e o custo real poderá ter ultrapassado o custo orçado acumulado. Se ações
corretivas tivessem sido empregadas anteriormente, os problemas poderiam ter sido evita-
dos. Uma das formas de prevenir estimativas precipitadas de percentuais realizados muito
altos é ter pacotes de trabalho ou atividades com escopo e duração menores. É importante
que o responsável pela realização das estimativas avalie a quantidade de trabalho realizado
e também considere o que ainda resta para ser feito.
Depois que os dados do percentual realizado forem coletados, pode-se calcular o valor
agregado, multiplicando-se o custo orçado total do pacote de trabalho por seu percentual
realizado. Por exemplo, no projeto para pintar dez cômodos por US$ 2.000, caso três cô-
modos tenham sido terminados, pode-se afirmar com segurança que 30% do trabalho foram
realizados. O valor agregado corresponde a:
0,30 ⋅ US$ 2.000 = US$ 600

6. Calcula-se o valor agregado
acumulado, determinando-se primeiro
o _____________________________ de
cada pacote de trabalho e, em seguida,
multiplicando-se esse valor pelo _______
______________ do pacote de trabalho.
Vamos retomar o exemplo do projeto Máquina de Embalagem. Ao final da semana 8,

o pacote de trabalho “Construção da máquina” é o único em andamento e estima-se que
50% dele tenha sido realizado. O pacote de trabalho “Concepção da Máquina” já tinha sido
terminado; portanto, 100% dele foi concluído. E o pacote de trabalho “Instalação e Testes”
ainda não começou, portanto, 0% dele foi concluído. A Figura 9.8 mostra as estimativas
do percentual realizado acumulado durante cada uma das 8 semanas, para cada pacote de
trabalho. A Figura 9.9 mostra o valor agregado acumulado (VAC) associado, para cada
pacote de trabalho, que é calculado multiplicando-se cada percentual realizado pelo COT
FIGURA 9.8 Percentuais Realizados Acumulados por Período para o Projeto Máquina de
Embalagem
Semana
1 2 3 4 5 6 7 8
Concepção da máquina 10 25 80 90 100 100 100 100
Construção da máquina 0 0 0 5 15 25 40 50
Instalação e Testes 0 0 0 0 0 0 0 0
Os valores representam percentuais realizados acumulados.
FIGURA 9.9 Valor Agregado Acumulado por Período para o Projeto Máquina de
Embalagem
Semana
COT 1 2 3 4 5 6 7 8
Concepção da Máquina 24 2.4 6 19.2 21.6 24 24 24 24
Construção da Máquina 60 3 9 15 24 30
Instalação e Testes 16
Acumulado 100 2.4 6 19.2 24.6 33 39 48 54

de cada pacote de trabalho. A Figura 9.9 mostra que, ao final da semana 8, o valor agregado
do trabalho realizado nesse projeto é de US$ 54.000.
Com base nos valores do VAC, é possível elaborar uma curva do valor agregado acu-
mulado. Desenhando-se essa curva nos mesmos eixos das curvas do custo orçado acumu-
lado e do custo real acumulado, conforme a Figura 9.10, pode-se visualizar muito bem a
comparação. Embora as curvas de custo da Figura 9.10 mostrem o COC, o CRC e o VAC
para o projeto como um todo, curvas semelhantes podem ser criadas para cada pacote de
trabalho, se desejado. A elaboração de curvas ajudará a identificar em que proporção cada
pacote de trabalho tem afetado o desempenho de custo do projeto.
FIGURA 9.10 Valores Agregados, Reais e Orçados Acumulados para o Projeto Máquina
de Embalagem
Custo Acumulado Período

(em milhares de dólares) de Relatório
100 ★
90
80
70
60
50
40
30 LEGENDA:
Custo Orçado Acumulado (COC)
20
Custo Real Acumulado (CRC)
10 Valor Agregado Acumulado (VAC)
1 2 3 4 5 6 7 8 9 10 11 12
Semanas
ANÁLISE DE DESEMPENHO DE CUSTO

As quatro medidas relativas ao custo listadas a seguir são utilizadas para analisar o desem-
penho de custo:
• COT (custo orçado total)
• COC (custo orçado acumulado)
• CRC (custo real acumulado)
• VAC (valor agregado acumulado)
Essas medidas são usadas para determinar se o projeto está sendo realizado dentro do or-
çamento e se o valor do trabalho realizado está de acordo com o custo real.

7. Faça uma lista das medidas relativas
ao custo utilizadas na análise do
desempenho de custo do projeto.
Ao analisar as Figuras 9.4, 9.6 e 9.9 do projeto Máquina de Embalagem, percebemos que:
• US$ 64.000 foram orçados para a realização de todo o trabalho planejado, a ser de-
sempenhado nas primeiras 8 semanas;
• US$ 68.000 foram efetivamente gastos ao final da semana 8;
• Ao valor agregado do trabalho efetivamente realizado até o final da semana 8, cor-
respondem US$ 54.000.
Uma breve análise revela que o custo real está ultrapassando aquele orçado. O fato de o
valor do trabalho realizado não estar alcançando o custo real agrava mais ainda a situação.
É uma boa idéia representar as curvas do COC, do CRC e do VAC nos mesmos eixos,
como mostra a Figura 9.10, ao fim de cada período de relatório. Com isso, é revelado se o
desempenho de custo tende a melhorar ou piorar.
Outra forma de tratar a situação é analisar o progresso em termos de porcentagens do
custo orçado total no valor de US$ 100.000 para o projeto. Usando o formato da Figura 9.11,
no fim da semana 8, poderíamos afirmar que:
• 64% do orçamento total do projeto deveria ter sido gasto na realização de todo o
trabalho planejado, a ser desempenhado nas primeiras 8 semanas;
• 68% do orçamento total foi efetivamente gasto ao final da semana 8;
• 54% do trabalho de todo o projeto foi efetivamente realizado até o final da semana 8.
Além de representar as curvas do COC, do CRC e do VAC nos mesmos eixos, poderá ser
útil criar tabelas ou curvas para as porcentagens, o que também indicará se o desempenho
de custo tende a melhorar ou a piorar.
Índice de Desempenho de Custo

Um indicador do desempenho de custo é o índice de desempenho de custo (IDC), uma
medida da eficiência com a qual o projeto vem sendo realizado, em termo de custos. A fór-
mula para determinar o IDC é a seguinte:
Valor agregado acumulado
Índice de desempenho de custo =
Custo real acumulado
VAC
IDC =
CRC
FIGURA 9.11 Status do Projeto Máquina de Embalagem a partir da semana 8
Percentual
100
90
80
68%
70 64%
60 54%
50 Percentual
Orçado Percentual Percentual
40 que Deveria Gasto de Trabalho
Ter Sido Gasto de Fato Concluído
30
20
10

8. Qual é o índice de desempenho de
custo do pacote de trabalho “Concepção
da Máquina”, ao final da semana 5, para
o projeto Máquina de Embalagem?
No projeto Máquina de Embalagem, o IDC da semana 8 corresponde a:
US$ 54.000
CPI = = 0,79
68.000
Essa razão mostra que, para cada US$ 1 efetivamente gasto, apenas US$ 0,79 do valor agre-
gado foi recebido. Recomenda-se observar as tendências do IDC com atenção. Quando o IDC
cai abaixo de 1,0 ou reduz-se gradualmente, devem ser empregadas ações corretivas.
Variação de Custo
Outro indicador do desempenho de custo é a variação de custo (VC), que é a diferença
entre o valor agregado acumulado do trabalho realizado e o custo real acumulado. A fór-
mula para determinar a variação de custo é a seguinte:
VC = VAC – CRC
Como o IDC, esse indicador mostra a diferença entre o valor do trabalho realizado e o
custo real, mas o valor da VC é expresso em dólares.

9. Qual é a variação de custo do pacote
de trabalho “Construção da Máquina”,
ao final da semana 8, para o projeto
Máquina de Embalagem?
Tráfego de Londres
Ao tornar-se o primeiro prefeito de Londres eleito por via direta, em maio de 2000, Ken
Livingstone concentrou-se imediatamente nas questões de transporte. Criou um corpo ad-
ministrativo único, o Transporte para Londres, com a função de supervisionar as estradas e
os serviços de transporte da cidade, como ônibus, navios e táxis, que historicamente foram
administrados em separado. A missão de melhorar a infra-estrutura de transportes de Lon-
dres começou com o projeto de um novo sistema de pedágios.
Livingstone não podia ignorar o congestionamento que “mutilava aquela capital”.
Pesquisas revelaram que motoristas passavam metade de seu tempo sentados, esperando
que as ruas do centro de Londres se descongestionassem. A média das velocidades era
cerca de 15 quilômetros por hora, menor que a velocidade média alcançada por cavalos
no começo do século XVIII, ou seja, 20 quilômetros por hora. O Transporte para Londres
desenvolveu a idéia de instalar um sistema de pedágios utilizando-se câmeras para identi-
ficar os donos dos veículos e cobrar pedágio nos dias em que o carro entrasse na zona de
congestionamento definida.
Os gestores do Transporte para Londres identificaram os riscos tecnológicos que en-
volviam esse inovador sistema de cobrança de pedágios. Por tratar-se de uma idéia nova, a
equipe não pôde estudar nenhum modelo preexistente. Para minimizar os riscos, a equipe
decidiu dividir o projeto em cinco pacotes menores, podendo ser administrados separada-
mente, em vez de comprar um único grande sistema. Cada componente selecionado usaria
a melhor tecnologia existente para ele. Fornecedores concorrentes foram, antes de tudo,
selecionados para conduzir estudos de design tecnológico. Tais estudos não só ajudaram a
escolher o fornecedor certo como também a comprar uma tecnologia comprovada.
A equipe do projeto, incluindo os subfornecedores, trabalhou em conjunto, em um
único espaço físico, com os cinco componentes do sistema: tecnologia da câmera, armaze-
nagem e processamento de imagens, comunicação remota entre as câmeras e sistema de
gestão de imagens, serviços ao consumidor e rede de estabelecimentos para pagamento
em quiosques, postos de gasolina e lojas.
A procura por fornecedores e sistemas de tecnologia adequados começou em janeiro
de 2001. As entregas parciais de itens do projeto foram distribuídas no tempo, e o proje-
to foi implementado com sucesso por volta de fevereiro de 2003. A equipe instalou 688
câmeras em 203 lugares dentro de uma área de 8 milhas quadradas, definida como zona
de congestionamento. Se um carro entrar na área de cobrança entre as 7 horas e 18h30, o
número da placa será fotografado.
A câmera envia sinais analógicos para o sistema de Reconhecimento de Número de
Placas Automático, no qual os dados da placa são comparados à base de dados de proprie-
tário para que o dono do veículo seja identificado. São cobrados US$ 8 por dia de infração,
taxa por entrar na zona de congestionamento. Há várias formas de pagamento diferentes:
on-line, via mensagem de texto de celular, em quiosques, por correio e por meio de vare-
jistas em âmbito nacional. Para se evitar taxas extras, é preciso efetuar o pagamento até as
22 horas do mesmo dia. Acrescentam-se taxas por atraso depois das 22 horas, meia-noite e
de 28 dias. Os reincidentes podem ter o carro rebocado ou removido.
O Transporte para Londres relata que o tráfego na zona de congestionamento dimi-
nuiu cerca de 20% com um aumento de 5% em número de viagens. O sólido compromisso
do prefeito ajudou a manter o projeto de US$ 116,2 milhões a caminho do sucesso. Essa
atitude foi particularmente importante, pois o próprio Transporte para Londres foi uma
nova organização dirigida por um novo líder, o prefeito. A equipe conseguiu administrar
com sucesso os riscos presentes na integração de novas tecnologias com um cronograma
apertado e uma nova liderança.
Wheatley, M. How IT Fixed London’s Traffic Woes. CIO, 15 de julho de 2003, p. 54.
No projeto Máquina de Embalagem, a variação de custos da semana 8 é expressa por:

VC = US$ 54.000 – US$ 68.000 = –US$ 14.000
Esse cálculo indica que o valor do trabalho realizado durante a semana 8 é US$ 14.000 a
menos do que o valor efetivamente gasto. É também um indicador que mostra que o traba-
lho realizado não está acompanhando o custo real.
Para analisar o desempenho de custo, é importante que todos os dados coletados sejam
os mais atuais possíveis e baseados no mesmo período de relatório. Por exemplo, se os
custos forem coletados todo dia 30 de cada mês, as estimativas do percentual realizado dos
pacotes de trabalho devem ter como base o trabalho realizado até o dia 30 do mês.
ESTIMATIVA DE CUSTOS
Com base na análise do desempenho de custo real durante o projeto, é possível estimar
quais serão os custos totais na conclusão do projeto ou do pacote de trabalho. Há três mé-
todos diferentes para o cálculo do custo estimado na conclusão (CEC).
O primeiro método assume que o trabalho a ser realizado no restante do projeto ou pa-
cote de trabalho será desempenhado com a mesma taxa de eficiência do trabalho até agora
executado. A fórmula para calcular o CEC utilizando-se o primeiro método é a seguinte:
Custo orçado total

Custo estimado na conclusão =
Índice de desempenho de custo
COT
CEC =
IDC

10. Usando o primeiro método de
estimativa descrito, calcule o custo
estimado na conclusão do pacote de
trabalho “Construção da Máquina”
no projeto Máquina de Embalagem.
Para o projeto Máquina de Embalagem, o custo estimado na conclusão é expresso por:
CEC = US$ 100.000 = US$ 126.582

0,79
Na semana 8, o projeto tem uma eficiência de custo dada por um IDC igual a 0,79; se o
restante do projeto continuar sendo executado com essa mesma taxa de eficiência, o proje-
to todo irá custar efetivamente US$ 126.582. Se essa estimativa for correta, haverá um custo
excedente de US$ 26.582 sobre o custo orçado total do projeto, cujo valor é US$ 100.000.
O segundo método para calcular o custo estimado na conclusão assume que – inde-
pendentemente da taxa de eficiência do projeto ou do pacote de trabalho verificada até o
momento – o trabalho a ser realizado durante o resto do projeto ou pacote de trabalho será
executado de acordo com o orçamento. A fórmula para calcular o CEC utilizando-se esse
método é a seguinte:
Custo Custo ⎛ Custo Valor ⎞⎟
⎜
estimado = real + ⎜⎜orçado − agregado ⎟⎟⎟
na conclusão acumulado ⎜⎜⎝ total acumulado⎠⎟
CEC = CRC + (COT – VAC)
Para o projeto Máquina de Embalagem, o custo estimado na conclusão é expresso por:
CEC = US$ 68.000 + (US$ 100.000 – US$ 54.000)

= US$ 68.000 + US$ 46.000
= US$ 114.000

11. Usando o segundo método de
estimativa descrito, calcule o custo
estimado na conclusão do pacote de
trabalho “Construção da Máquina”,
no projeto Máquina de Embalagem.
Na semana 8, o custo real acumulado foi US$ 68.000, mas o valor agregado acumulado
foi de apenas US$ 54.000. Portanto, um trabalho com um valor agregado de US$ 46.000
precisa ser realizado para a conclusão do projeto. Esse método supõe que o trabalho res-
tante seja executado com uma taxa de eficiência equivalente a 1,0, embora o projeto esteja
apresentando uma taxa de eficiência de 0,79 até o fim da semana 8. Tal método resulta em
um custo estimado na conclusão igual a US$ 114.000, com um custo excedente estimado no
valor de US$ 14.000 sobre o custo orçado total do projeto.
O terceiro método para determinar o custo estimado na conclusão consiste em reavaliar
os custos para todo o trabalho restante a ser realizado e, em seguida, acrescentar os re-
sultados dessa nova estimativa ao custo real acumulado. A fórmula para o cálculo do CEC
utilizando-se esse método é a seguinte:
CEC = CRC + Nova estimativa do trabalho restante a ser realizado
Essa abordagem pode ser demorada, mas é necessária se o projeto apresentar constantes
desvios em relação aos planos ou se grandes mudanças ocorrerem.
Como parte da análise regular do desempenho de custo, recomenda-se que o CEC do
projeto seja calculado utilizando-se o primeiro ou o segundo método descritos anterior-
mente. Então, os custos excedentes ou a redução de custos poderão ser determinados.
Quando o custo na conclusão do projeto ou de um pacote de trabalho é estimado, uma
pequena variação observada em determinado período de relatório pode tornar-se um cus-
to excedente muito maior, indicando a necessidade de ações corretivas.
CONTROLE DE CUSTOS
O segredo para um controle de custos eficaz é analisar o desempenho de custo de forma
regular e pontual. É crucial que as ineficiências e variações de custo sejam identificadas
a tempo, de modo que uma ação corretiva possa ser tomada antes que a situação piore.
Uma vez que os custos do projeto estejam fora de controle, pode ser muito difícil concluir
o projeto dentro do orçamento.
O controle de custos envolve as seguintes etapas:
1. Análise do desempenho de custo para determinar quais pacotes de trabalho possam

exigir uma ação corretiva.
2. Decisão de qual ação corretiva específica deve ser tomada.
3. Revisão do plano do projeto, incluindo as estimativas de custo e tempo, para incor-
porar a ação corretiva planejada.
A análise do desempenho de custo deve incluir a identificação dos pacotes de trabalho

que tenham uma variação de custo VC negativa ou um índice de desempenho de custo IDC
menor que 1,0. Além disso, devem ser identificados os pacotes de trabalho para o quais a
VC ou o IDC tenham piorado desde o período de relatório anterior. Um esforço concentra-
do deve ser aplicado aos pacotes de trabalho de variações negativas, a fim de reduzir o cus-
to ou melhorar a eficiência do desempenho de trabalho. O valor da VC tem de determinar a
prioridade para a aplicação desses esforços concentrados, ou seja, deve ser dada prioridade
absoluta ao pacote de trabalho com menor VC negativa.

12. Ao analisar o desempenho de custo,
é importante identificar todos os
pacotes de trabalho que possuem
uma variação de custo _______________
ou um índice de desempenho de custo
inferior a ___________________.
Ao avaliar os pacotes de trabalho que tenham uma variação de custo negativa, você
deve se concentrar na tomada de ações corretivas para reduzir os custos de dois tipos de
atividades:
1. Atividades que serão realizadas próximas. Não planeje reduzir os custos das ativida-
des agendadas para um futuro distante. Você terá um feedback mais adequado dos
efeitos das ações corretivas se elas forem feitas em curto prazo. Se você posterga
ações corretivas para um futuro distante, a variação de custo negativa pode piorar
ainda mais, antes que as ações corretivas sejam implementadas. Conforme o projeto
avança, sobra cada vez menos tempo para que as ações corretivas possam ser toma-
das.
2. Atividades que tenham uma grande estimativa de custo. Adotar medidas corretivas
que reduzam o custo de uma atividade de US$ 20.000 em 10% terá maior impacto do que
eliminar uma atividade de US$ 300. Normalmente, quanto maior o custo estimado
para uma atividade, maior a oportunidade para uma grande redução de custo.

13. Ao avaliar pacotes de trabalho
que possuem uma variação de custo
negativa, você deve se concentrar
no emprego de ações corretivas para
reduzir os custos das atividades que
serão realizadas em _________________
prazo e naquelas cujas estimativas de
custo são _________________.
Existem várias maneiras de reduzir os custos das atividades. Uma delas é preferir ma-
teriais menos caros, mas que cumpram com as especificações exigidas. Talvez possa ser
encontrado outro fornecedor que tenha o mesmo material por preço mais baixo. Outra
alternativa é designar uma pessoa com maior habilidade ou experiência para realizar a ati-
vidade ou ajudar que esta seja feita com mais eficiência.
Reduzir o escopo ou os requisitos para o pacote de trabalho ou atividades específicas
é outra maneira de reduzir os custos. Por exemplo, um empreiteiro pode decidir passar
somente uma camada de tinta em um cômodo em vez de duas, como planejado original-
mente. Aumentar a produtividade por meio de melhores métodos e tecnologia é também
outra alternativa para reduzir os custos. Por exemplo, ao alugar um equipamento pulveri-
zador de tinta automático, o empreiteiro pode reduzir substancialmente o custo e o tempo
de pintura de um cômodo a um valor mais baixo do que se os pintores utilizassem rolos e
pincéis.
Em muitos casos, haverá uma compensação entre tempo e custo – reduzir as variações
de custo envolverá a redução do escopo do projeto ou o atraso do cronograma. Se a varia-
ção de custo negativa é muito grande, pode-se exigir uma redução substancial da qualidade
ou escopo do trabalho para ajustar o projeto de volta ao orçamento. O escopo, o orçamento,
o cronograma ou a qualidade de todo o projeto poderiam correr riscos. Em alguns casos,
o cliente e o fornecedor ou a equipe do projeto pode ter de reconhecer que um ou mais
desses elementos não podem ser alcançados. Isso poderia resultar em capital adicional pro-
videnciado pelo cliente para cobrir o orçamento ultrapassado previsto ou também resultar
em uma discussão contratual sobre quem causou o excesso de custos e quem deve pagar
por ele – o cliente ou o fornecedor.
O segredo para um controle de custos eficaz é tratar agressivamente as variações de
custos negativas e as ineficiências de custos tão logo sejam identificadas, em vez de esperar
que as coisas melhorem à medida que o projeto avança. Problemas de custo resolvidos
rapidamente terão menos impacto sobre o escopo e o cronograma. Uma vez que os custos
estejam fora de controle, para voltar ao orçamento, é provável que seja necessária a redu-
ção do escopo do projeto ou a prorrogação do cronograma do projeto.
Até mesmo quando os projetos têm somente variações de custo positivas, é importante
não deixar que saiam do controle. Se o desempenho de custo de um projeto é positivo,
deve ser feito um esforço concentrado para mantê-lo dessa forma. Quando um projeto
apresenta problemas com o desempenho de custos, fica difícil ajustá-lo novamente.
GERINDO O FLUXO DE CAIXA

É importante gerir o fluxo de caixa de um projeto. Essa atividade envolve garantir que sejam
recebidos do cliente pagamentos suficientes e a tempo, de maneira que haja recursos sufi-
cientes para cobrir os custos de realização do projeto – folha de pagamento dos funcionários,
despesas com materiais, notas fiscais de terceiros e despesas de viagem, por exemplo.

14. O segredo para administrar o fluxo
de caixa está em assegurar que a ______
________________ de capital se dê mais
rapidamente que a _________________.
O segredo para gerir o fluxo de caixa é assegurar que o dinheiro entre mais rápido do que
saia. Se não houver dinheiro suficiente disponível para cobrir as despesas, deve-se fazer
um empréstimo. O empréstimo aumenta o custo do projeto, porque qualquer valor que seja
tomado emprestado deve ser pago de volta para seu concessor acrescido de juros.
O fluxo de dinheiro que entra vindo do cliente pode ser controlado pelas condições de
pagamento estipuladas no contrato. Do ponto de vista do fornecedor, é melhor receber do
cliente pagamentos antecipados do que no final do projeto. O fornecedor pode tentar negociar
condições de pagamento que exijam que o cliente cumpra um ou mais dos seguintes itens:
• Pague uma entrada no início do projeto. Essa exigência é razoável quando o forne-
cedor precisa adquirir e entregar uma quantidade significativa de materiais durante
as primeiras etapas do projeto.
• O planejamento de custos começa com a proposta para o projeto, momento em

que estes são estimados.
• O responsável pelos custos associados ao trabalho deve fazer as estimativas desses
custos. Isso gera compromisso de sua parte.
• As estimativas de custos devem ser agressivas, porém realistas.
• Uma vez iniciado o projeto, é importante monitorar os custos reais e o desempenho
do trabalho para garantir que tudo esteja dentro do orçamento.
• Deve-se instalar um sistema para coletar, de forma regular e oportuna, dados sobre
gastos reais e comprometidos, e o valor agregado (percentual realizado) do traba-
lho feito, para que possam ser comparados ao custo orçado acumulado (COC).
• Se, a qualquer momento durante o projeto, ficar determinado que ele excede o
orçamento, ou que o valor do trabalho realizado não está de acordo com a quanti-
dade real de gastos, devem ser tomadas ações corretivas imediatas.
• É importante usar o custo orçado acumulado (COC), em vez do custo orçado total
(COT), como o padrão de referência em relação ao qual o custo real acumulado
(CRC) é comparado. Seria enganoso comparar os gastos reais com o custo orçado
total, já que o desempenho de custos sempre será bom, contanto que os custos
reais estejam abaixo do COT.
• A fim de permitir uma comparação realista do custo real acumulado com o custo or-
çado acumulado, porções do custo comprometido devem ser consideradas custos
reais, enquanto o trabalho associado estiver em andamento.
• O valor agregado do trabalho de fato conduzido é um parâmetro-chave, que deve
ser determinado e relatado ao longo do projeto.
• Para cada período de relatório, devem ser obtidos dados de percentual realizado
da pessoa responsável pelo trabalho. É importante que esse responsável faça uma
avaliação honesta do trabalho realizado em relação a todo o escopo de trabalho.
• Uma forma de se evitar estimativas de percentuais realizados infladas é manter os
pacotes de trabalho ou atividades pequenos em termos de escopo e duração. É im-
portante que a pessoa que estima o percentual realizado avalie não apenas quanto
trabalho foi realizado, mas também o que ainda resta a ser feito.
• O segredo para um controle eficaz de projeto é analisar o desempenho de custos
de forma oportuna e regular. A identificação precoce de variações de custo (VC)
permite que sejam adotadas ações corretivas antes que a situação piore.
• Para analisar o desempenho de custo, é importante que todos os dados coletados
sejam os mais atuais possíveis e baseados no mesmo período de relatório.
• As tendências do índice de desempenho de custos (IDC) devem ser cuidadosamen-
te monitoradas. Se o IDC ficar abaixo de 1,0, ou ficar gradualmente menor, deve-se
tomar ações corretivas.
• Como parte da análise regular de desempenho de custos, o custo estimado na con-
clusão (CEC) deve ser calculado.
• O segredo para o controle eficaz de custos é tratar de pacotes de trabalho ou ativi-
dades com variações de custo negativas ou ineficiências de custo de forma agressi-
va, assim que forem identificadas. Deve-se envidar um esforço concentrado nessas
áreas. A quantidade de variação de custo negativa tem de determinar a prioridade
de aplicação desses esforços concentrados.
• Ao tentar reduzir variações de custo negativas, concentre-se em atividades que se-

rão realizadas em curto prazo e naquelas cuja estimativa de custo seja elevada.
• O tratamento precoce de problemas de custos trará menor impacto sobre o escopo
e o cronograma. Se os custos ficarem fora de controle, voltar para o orçamento se
torna mais difícil, e provavelmente exigirá que se reduza o escopo do projeto ou
que se estenda seu cronograma.
• O segredo para a gestão de fluxo de caixa é garantir que o caixa entre mais rápido
do que saia.
• É desejável receber pagamentos (entrada de caixa) do cliente o mais cedo possível
e adiar os pagamentos (saída de caixa) para subfornecedores e subcontratados o
máximo possível.
• Faça pagamentos mensais iguais relativos à duração esperada do projeto. A saída de

caixa geralmente é menor nas etapas iniciais do projeto. Se entrar mais dinheiro do
que sair durante a parte inicial do projeto, o fornecedor poderá investir um pouco
do caixa excedente e receber juros. Os recursos economizados podem depois ser
usados para cumprir demandas maiores de saída de caixa mais adiante no projeto.
• Faça pagamentos regulares, como pagamentos mensais ou semanais, em vez de pa-
gamentos trimestrais.

15. Se não há recursos suficientes
para cobrir os gastos, o fornecedor
provavelmente precisará _____________
dinheiro. Isso será somado ao custo do
projeto, pois o fornecedor deve pagar
______________ também.
O pior cenário, do ponto de vista do fornecedor, ocorre quando o cliente faz somente
um pagamento ao final do projeto. Nessa situação, o fornecedor precisa emprestar dinheiro
a fim de ter caixa disponível para pagar as despesas durante todo o projeto.
A saída de caixa do fornecedor também pode ser controlada pelas condições de paga-
mento, nesse caso por meio de contratos com os subfornecedores. O fornecedor quer adiar
os pagamentos (saída de caixa) o máximo possível. Por exemplo, um fornecedor que gas-
tou US$ 100.000 em material gostaria de esperar até que todo o material fosse entregue
antes de pagar o subfornecedor. Se a nota fiscal do subfornecedor estabelece que a data
de vencimento é 30 dias, o fornecedor provavelmente esperará até aproximadamente o 27o
dia para fazer o pagamento.

O software de gestão de projetos facilita razoavelmente como lidar com as considerações
sobre os custos de um projeto. Todos os custos associados a cada recurso de um projeto
podem ser armazenados e o software calcula o orçamento de cada pacote de trabalho e do
projeto inteiro. Ele calculará os custos reais à medida que o projeto se desenvolver, bem
como os custos finais. Como recursos diversos possuem diferentes taxas, que serão co-
bradas em diversos momentos do projeto, o software de gestão de projetos normalmente
permite que o usuário estruture de formas diferentes as taxas para cada recurso, bem como
a hora em que as cobranças para tais recursos serão, de fato, executadas. Em qualquer
ponto do projeto, estimativas de custos, o custo orçado total alocado, o custo orçado acumu-
lado, o custo real, o valor agregado, os custos comprometidos, o índice de desempenho de
custo, a variação de custo e a estimativa de custo na conclusão podem ser calculados para
cada tarefa, pacote de trabalho ou todo o projeto, apenas com um clique do mouse. Tabelas
e gráficos de custos normalmente são disponibilizados para ajudar na análise do desempe-
nho de custo. Veja o Apêndice A para obter uma discussão completa sobre o software de
gestão de projetos.
RESUMO
Estimam-se os custos de um projeto quando uma proposta é elaborada para ele. Quando fica
decidido que ele será realizado, é necessário elaborar um orçamento, ou plano, para definir
como e quando os recursos serão gastos durante sua execução. Assim que o projeto se inicia,
é importante monitorar os custos reais e o desempenho do trabalho para assegurar que tudo
esteja de acordo com o orçamento. Diversos aspectos devem ser monitorados, a intervalos
constantes, durante o projeto: o valor real acumulado gasto e o valor agregado acumulado
do trabalho realizado, ambos desde o início do projeto e o valor orçado acumulado que se
planejou gastar, com base no cronograma, no início do projeto.
O planejamento de custos começa com a proposta para o projeto. A seção de custos
de uma proposta pode incluir tabelas de custos estimados do fornecedor para elementos,
como: mão-de-obra, materiais, subfornecedores e consultores, equipamentos, aluguel de
instalações e viagens. Além disso, a proposta deverá conter um valor de contingências para
cobrir despesas imprevistas.
O processo para o orçamento de um projeto envolve duas etapas. Na primeira, a estima-
tiva de custo do projeto é alocada para os diversos pacotes de trabalho na estrutura analítica
do projeto. Na segunda, o orçamento para cada pacote de trabalho é distribuído ao longo
de sua duração, para que seja possível determinar quanto de seu orçamento deveria ter sido
gasto em qualquer momento do projeto.
Alocar os custos totais do projeto de diversos elementos, como mão-de-obra, materiais e
subfornecedores, para os pacotes de trabalho adequados na estrutura analítica determinará
um custo orçado total (COT) para cada um. Assim que um custo orçado total é determinado
para cada um deles, a segunda etapa do processo de orçamento de um projeto é distribuir
cada COT ao longo da duração do pacote de trabalho em questão, para determinar quanto
do orçamento deveria ter sido gasto em determinado momento. Esse valor é calculado so-
mando-se os custos orçados de cada período anterior ao momento em questão. Esse valor
total, conhecido como custo orçado acumulado (COC), será usado para analisar o desem-
penho de custos do projeto. O COC para o projeto inteiro ou para cada pacote de trabalho
fornece um valor de referência com o qual o custo real e o desempenho do projeto poderão
ser comparados em qualquer momento do projeto.
Uma vez iniciado o projeto, é necessário observar o custo real e o custo comprometido
para que possam ser comparados com o COC. Além disso, é preciso monitorar o valor
agregado do trabalho que está sendo desempenhado. A determinação do valor agregado
envolve a coleta de informações do percentual realizado para cada pacote de trabalho e,
em seguida, sua conversão em dólares, multiplicando-se o COT do pacote de trabalho pelo
percentual realizado. Tal valor pode ser, então, comparado ao custo orçado acumulado e
ao custo real acumulado.
Em seguida, o desempenho do custo do projeto poderá ser analisado, observando-
se o custo orçado total, o custo orçado acumulado, o custo real acumulado e o valor
agregado acumulado, que são utilizados para determinar se o projeto vem sendo realizado
dentro do orçamento e se o valor do trabalho realizado está de acordo com o custo real.
Um indicador do desempenho de custo é o índice de desempenho de custo (IDC) para
medir a eficiência com a qual o projeto está sendo executado, em termo de custos. Calcu-
la-se o IDC dividindo-se o valor agregado acumulado pelo custo real acumulado. Outro
indicador do desempenho de custo é a variação de custo (VC), que é a diferença entre o
valor agregado acumulado do trabalho realizado e o custo real acumulado.
Com base na análise do desempenho de custo real durante o projeto, é possível estimar
quais serão os custos totais na conclusão do projeto ou do pacote de trabalho. Há três mé-
todos diferentes para o cálculo do custo estimado na conclusão (CEC). O primeiro método
assume que o trabalho a ser realizado no restante do projeto ou pacote de trabalho será
desempenhado com a mesma taxa de eficiência do trabalho até agora executado. O segundo
método assume que – independentemente da taxa de eficiência do projeto ou do pacote
de trabalho verificada até agora – o trabalho a ser realizado durante o resto do projeto ou
pacote de trabalho será executado de acordo com o orçamento. O terceiro método para
determinar o custo estimado na conclusão consiste em reavaliar os custos para todo o tra-
balho restante a ser realizado e, em seguida, acrescentar os resultados dessa nova estimativa
ao custo real acumulado.
O segredo para um controle de custos eficiente está em analisar constantemente o desem-
penho de custo. É fundamental identificar com antecedência variações de custo e ineficiên-
cias para que possam ser adotadas ações corretivas antes que a situação piore. O controle
de custo consiste em analisar o desempenho de custo para que se determinem quais paco-
tes de trabalho precisam ser corrigidos; é necessário decidir que ação corretiva específica
deve ser empregada e revisar o plano do projeto (inclusive estimativas de custos e tempo)
para poder incorporar a ação corretiva planejada.
É importante administrar o fluxo de caixa de um projeto. Esse processo implica assegu-
rar que os pagamentos efetuados pelos clientes sejam recebidos a tempo, havendo assim
dinheiro suficiente para cobrir os custos de execução do projeto (folha de pagamento de
funcionários, despesas com materiais, faturas de subfornecedores e despesas com viagens,
por exemplo). O segredo para administrar o fluxo de caixa está em assegurar que a entrada
de capital se dê mais rapidamente que a saída.
PERGUNTAS
1. Descreva o motivo pelo qual é necessário desenvolver um orçamento-base para um
projeto.
2. A proposta para um projeto normalmente inclui uma seção de custos. Enumere e des-
creva os itens que deveriam ser incluídos nessa seção.
3. O que significa o termo contingências? Os custos de contingência deveriam ser incluí-
dos em uma proposta de projeto? Explique sua resposta.
4. Qual é o problema em se fazer estimativas de custos extremamente conservadoras ou
agressivas?
5. Descreva o processo orçamentário do projeto.
6. Defina: COT, COC, CRC, VAC, IDC, VC e CEC. Como é calculado cada um deles?
7. Por que é necessário identificar os custos reais e comprometidos assim que o projeto
começa?
8. Por que é necessário calcular o valor agregado do trabalho realizado? Como se faz isso?
9. Como o índice de desempenho de custo é calculado? O que significa estar abaixo de
1,0? E acima de 1,0?
10. Como a variação de custo é calculada? O que significa o fato de ela ser negativa? E po-
sitiva? Ao avaliar um pacote de trabalho com uma variação de custo negativa, quais os
dois tipos de atividades nas quais você deve se concentrar? Por quê?
11. Qual é o segredo para a administração de fluxos de caixa? Como essa meta pode ser
alcançada?
12. a. Consulte a tabela a seguir. Qual é o custo orçado acumulado no final da semana 6?
Semana
COT 1 2 3 4 5 6 7 8 9 10
Tarefa 1 30 10 15 5
Tarefa 2 70 10 10 10 20 10 10
Tarefa 3 40 5 5 25 5
Tarefa 4 30 5 5 20
Total 170 10 25 15 10 25 15 35 10 5 20
Acumulado
b. A tabela a seguir se refere aos custos reais. Qual é o custo real acumulado ao final
da semana 6? Determine se os custos são excedentes ou reduzidos. Por que isso está
acontecendo?
Semana
1 2 3 4 5 6
Tarefa 1 10 16 8
Tarefa 2 10 10 12 24 12
Tarefa 3 5 5
Tarefa 4
Total 10 26 18 12 29 17
Acumulado
c. A tabela a seguir mostra os percentuais acumulados de trabalho realizado ao final da

semana 6. Qual é o valor agregado acumulado do projeto ao final da semana 6? Ele
é positivo?
Semana
1 2 3 4 5 6
Tarefa 1 30 80 100
Tarefa 2 10 25 35 55 65
Tarefa 3 10 20
Tarefa 4
Os valores representam percentuais realizados acumulados.
d. Qual é o valor do IDC no final da semana 6? E o da VC?

e. Calcule o valor do CEC usando os dois primeiros métodos descritos no capítulo.
Além disso, descreva o terceiro método que poderia ser usado para calcular o CEC.
1. Procure na Internet ferramentas para análise de custos. Descreva o que descobriu. Se
possível, faça o download de uma cópia demo de um pacote de software que ofereça
algumas ferramentas para análise de custos.
2. Procure na Internet estimativas de custo e discuta de que forma são semelhantes ou
diferentes dos métodos descritos no capítulo.
3. Para as perguntas 3 a 5, visite o Project Management World Today no site http://www.
pmforum.org. Clique em “PM World Today” e consulte alguns artigos recentes. Men-
cione pelo menos cinco áreas tratadas nesses artigos.
4. Clique em “Cases” e revise pelo menos um estudo de caso. O projeto foi um sucesso?
Por que foi ou por que não? Quais foram os erros e os acertos do gestor do projeto?
5. Procure no site informações relacionadas às discussões deste capítulo. Que dicas são
dadas em relação às considerações sobre custos em gestão de projetos?

Lucrativos
Este caso é continuação do estudo de caso dos Capítulos 5, 6, 7 e 8.
PERGUNTAS
1. No item 2 do Capítulo 7 são fornecidos os custos reais de cada atividade concluída.

Agora, determine os custos reais gastos até o dia 15 de agosto (incluindo qualquer par-
cela de custos comprometidos) de cada atividade planejada para estar em andamento
até essa data.
Elabore uma estimativa do percentual realizado de trabalho concluído para essas
mesmas atividades em andamento até o dia 15 de agosto.
2. Usando o plano, o cronograma e as estimativas de custo de atividades do item 1 do
Capítulo 7, elabore uma tabela de custo orçado por período (semelhante à Figura 9.4)
e represente em um gráfico a curva do custo orçado acumulado (COC) (semelhante à

Figura 9.5) para o projeto.
3. Usando os dados de custos reais (até 15 de agosto) do item 1 anterior, elabore uma
tabela de custo real por período (semelhante à Figura 9.6) e acrescente uma curva de
custo real acumulado (CRC) no gráfico de COC, elaborado no item 2 acima (semelhante
à Figura 9.7).
4. Utilizando os dados do percentual realizado (até o dia 15 de agosto) do item 1 anterior,
elabore uma tabela de valor agregado acumulado (VAC) por período (semelhante à
Figura 9.9) e acrescente uma curva de valor agregado acumulado (VAC) nos gráficos de
COC e CRC (semelhante à Figura 9.10).
5. A partir do dia 15 de agosto, calcule para todo o projeto:
• o índice de desempenho de custo (IDC);
• a variação de custo (VC);
• o custo estimado na conclusão (CEC).
6. Caso o CEC no item 5 ultrapasse o custo orçado total (COT) do projeto, quais são as suges-
tões que sua equipe poderia dar para reduzir os custos de atividades em andamento ou de
atividades ainda não iniciadas, a fim de atingir o CEC, de acordo com o COT do projeto?
ATIVIDADE EM GRUPO
Divida os integrantes do curso nos mesmos grupos de três ou quatro pessoas da atividade
de grupo do capítulo anterior e responda às perguntas anteriores.
Bom trabalho! Você terminou o estudo desse caso! Se tiver elaborado a rede, os crono-
gramas, as tabelas e os gráficos manualmente com caneta e papel, o trabalho provavelmente
foi tedioso, propenso a erros, frustrante e demorado. Um software de gestão de projetos,
como o Microsoft Project, é capaz de automatizar tais tarefas, permitindo que você utilize
seu tempo de forma mais eficaz ao analisar o cronograma do projeto e o desempenho de
custos, administrando, assim, o projeto com sucesso.

Este caso é continuação do estudo de caso dos Capítulos 5, 6, 7 e 8.
PERGUNTAS
1. No item 2 do Capítulo 7, são fornecidos os custos reais de cada atividade concluída.

Agora determine os custos reais gastos até o dia 31 de março (incluindo qualquer par-
cela de custos comprometidos) de cada atividade planejada para estar em andamento
até essa data.
Elabore uma estimativa do percentual realizado de trabalho desempenhado para
cada uma das mesmas atividades em andamento até o dia 31 de março.
2. Usando o plano, o cronograma e as estimativas de custo de atividades do item 1 do
Capítulo 7, elabore uma tabela de custo orçado por período (semelhante à Figura 9.4)
e represente em um gráfico a curva do custo orçado acumulado (COC) (semelhante à
Figura 9.5) para o projeto.
3. Usando os dados de custos reais (até 31 de março) do item 1 anterior, elabore uma
tabela de custo real por período (semelhante à Figura 9.6) e acrescente uma curva de
custo real acumulado (CRC) no gráfico de COC, elaborado no item 2 acima (semelhante
à Figura 9.7).
4. Usando os dados do percentual realizado (até o dia 31 de março) do item 1 anterior,

elabore uma tabela de valor agregado acumulado (VAC) por período (semelhante à
Figura 9.9) e acrescente uma curva de valor agregado acumulado (VAC) nos gráficos de
COC e CRC (semelhante à Figura 9.10).
5. Até dia 31 de março, calcule para todo o projeto:
• o índice de desempenho de custo (IDC);
• a variação de custo (VC);
• o custo estimado na conclusão (CEC).
6. Caso o CEC no item 5 ultrapasse o custo orçado total (COT) do projeto, que sugestões
sua equipe poderia dar para reduzir os custos de atividades em andamento ou de ativi-
dades ainda não iniciadas, a fim de atingir o CEC, de acordo com o COT do projeto?
ATIVIDADE EM GRUPO
Bom trabalho! Você encerrou o estudo desse caso! Se tiver elaborado a rede, os crono-
gramas, as tabelas e os gráficos manualmente com caneta e papel, o trabalho provavelmen-
te foi tedioso, propenso a erros, frustrante e demorado. Um software de gestão de projetos,
como o Microsoft Project, é capaz de automatizar tais tarefas, permitindo que utilize seu
tempo de forma mais eficaz ao analisar o cronograma do projeto e o desempenho de cus-
tos, administrando, assim, o projeto com sucesso.

Discutiremos neste apêndice como o Microsoft Project pode ser utilizado para sustentar as
técnicas discutidas com base no exemplo de Estudo de Mercado Consumidor.
Para obter o Relatório de Resumo do Projeto mostrado na Figura 9A.1, no menu View,
clique em Reports, selecione Overview e clique em Select; em seguida, selecione Project
Summary e clique em Select. Caso você tenha atualizado suas informações de tarefas, esse
relatório irá exibir a situação real versus a planejada de datas, horas de trabalho e custos.
O relatório de tarefas de nível superior mostrado na Figura 9A.2 é outro tipo de Relatório
Geral. No menu View, clique em Reports, selecione Overview e clique em Select; em segui-
da, escolha Top Level Tasks e clique em Select. Esse relatório fornece as datas de início e
de término, o percentual realizado e os custos de cada tarefa.
Cinco diferentes relatórios-padrão de custos podem ser obtidos no Microsoft Project.
Para obtê-los, no menu View, clique em Reports, selecione Costs e clique em Select. Você
verá o menu da Figura 9A.3 indicando os cinco subtipos de relatórios de custos.
O Relatório de Orçamento mostrado na Figura 9A.4 demonstra o custo total, o custo
planejado e a variação de cada atividade.
O Relatório de Fluxo de Caixa mostrado na Figura 9A.5 fornece uma análise das finanças
a cada semana.
Para obter uma tabela de custos semelhante à exibida na Figura 9A.6, no menu View,
clique em Gantt Chart. Em seguida, no menu View, aponte para Table e selecione Costs no
menu. Essa tabela fornece informações sobre os custos restantes, reais, planejados e totais
de cada tarefa, além de quaisquer variações.
Você também pode criar uma tabela de variação de custos para recursos. Para isso, pre-
cisa visualizar Resource Sheet (no menu View, clique em Resource Sheet) e depois visualize
Cost Table (no menu View, aponte para Table e selecione Costs no menu).
Você pode criar uma tabela que mostre o valor agregado para cada tarefa. No menu
View, clique em Gantt Chart; depois, no menu View, aponte para Tables e selecione Entry.
FIGURA 9A.1 Relatório de Resumo do Projeto
Isso fará você voltar ao modo de exibição default. No menu View, aponte para Table e
clique em More Tables para abrir o menu de tabelas adicionais disponíveis. Passe por toda
a lista e escolha Earned Value, como mostra a Figura 9A.7.
Você verá a tabela da Figura 9A.8. Essa tabela fornecerá diversas informações, como o
custo orçado, real e agregado do trabalho realizado, bem como quaisquer variações.
Um Relatório do Valor Agregado também está disponível. No menu View, clique em Re-
ports, selecione Costs e clique em Select. Escolha Earned Value e clique em Select. A partir
desses dados, você poderá fazer novos planos.
FIGURA 9A.2 Relatório de Tarefas de Nível Superior
FIGURA 9A.3 Menu de Relatório de Custos
FIGURA 9A.4 Relatório de Orçamento
FIGURA 9A.5 Relatório de Fluxo de Caixa
FIGURA 9A.6 Tabela de Variação de Custo para Tarefas
FIGURA 9A.7 Menu de Tabelas Adicionais (More Tables)
FIGURA 9A.8 Tabela de Valor Agregado
Parte 3
AS PESSOAS: O SEGREDO PARA O SUCESSO
DE UM PROJETO
CAPÍTULOS
10 O Gestor de 11 A Equipe de 12 Comunicação e 13 Tipos de Organi-
Projetos Projeto Documentação do zação
Projeto de Projeto
Discute as responsabili- Trata do desenvolvi- Discute a importância da Explica as várias formas
dades do gestor de mento e crescimento de comunicação oral e escri- nas quais as pessoas
projetos de forma bem- equipes, das caracte- ta eficaz, da capacidade podem ser organizadas
sucedida, assim como o rísticas de equipes de de ouvir, das reuniões de para trabalhar em pro-
desenvolvimento dessas projeto eficazes, da projeto e das apresenta- jetos.
habilidades. formação de equipes, da ções e relatórios.
resolução de conflitos e
da solução de proble-
mas, além da gestão do
tempo.
Os capítulos da Parte 3 concentram-se na importância das pessoas envolvidas em um pro-

jeto. São elas, e não os procedimentos ou técnicas, as peças fundamentais para se atingir o
objetivo do projeto. Os procedimentos e técnicas são simplesmente ferramentas que ajudam
as pessoas a fazer seu trabalho.
O gestor de projetos traz um aporte de liderança à equipe de projeto – liderança no
planejamento, na organização e no controle de todos os esforços necessários para se atingir
o objetivo do projeto. A responsabilidade final do gestor de projetos é garantir a satisfação
do cliente com a conclusão do escopo de trabalho com qualidade, dentro do orçamento
e do prazo. O gestor de projetos deve possuir as habilidades necessárias para inspirar sua
equipe e ganhar a confiança do cliente.
A equipe de projeto é um grupo de pessoas que trabalham de forma interdependente
para atingir o objetivo do projeto. Trabalho em equipe é o esforço cooperativo por parte dos
membros da equipe para atingir esse objetivo comum. A eficácia da equipe de projeto pode
fazer a diferença entre o sucesso e o fracasso do projeto. Embora sejam necessários planos e
técnicas de gestão de projetos, as pessoas – o gestor de projetos e a equipe de projeto – são
o segredo para o sucesso do projeto.
Para garantir esse sucesso, várias estruturas são usadas para organizar as pessoas que
trabalharão nesses projetos. Contudo, independentemente da forma como a equipe é or-
ganizada, a comunicação entre a equipe de projeto e o cliente, dentro da própria equipe e
entre a equipe de projeto e instâncias decisórias superiores é fundamental para o sucesso.
277
Capítulo O GESTOR DE PROJETOS
10 Responsabilidades do Gestor de
Projetos
Planejamento
Organização
Desenvolvendo as Aptidões
Necessárias para ser Gestor de
Projetos
Delegação
Controle Gerindo Mudanças
Aptidões do Gestor de Projetos Resumo
Capacidade de Liderança Perguntas
Capacidade de Desenvolver Exercícios na Internet
Pessoas Estudo de Caso no 1 Codeword
Habilidades de Comunicação Perguntas
Habilidades Interpessoais Atividade em Grupo
Capacidade de Lidar com o Estudo de Caso no 2 Uma
Estresse Empresa de E-Business em
Capacidade de Resolver Crescimento
Problemas Perguntas
Capacidade de Gerir o Tempo Atividade em Grupo
278
Ca pítulo De z
O Federal Bureau of Investigation (FBI)
O Federal Bureau of Investigation (FBI), a agência de investigação do Departamento de Jus-
tiça Norte-Americano, inclui na lista das dez maiores prioridades a missão de atualizar sua
infra-estrutura de tecnologia da informação. O FBI espera atualizar sua infra-estrutura de TI
por meio do projeto Trilogia. O projeto inclui a instalação de uma rede de alta velocidade
que interconecte todos os escritórios do FBI, fornecendo estações de trabalho e softwares
de última tecnologia para todos os funcionários do FBI, além da implementação do Arqui-
vo de Casos Virtual, que permitirá às pessoas dentro do FBI compartilharem informações.
O projeto Trilogia teve início em novembro de 2000, quando os principais objetivos
originais eram modernizar hardwares obsoletos e conectar os escritórios de campo do FBI
à Internet. Depois, após setembro de 2001, o FBI reorganizou suas prioridades, estabeleceu
novas políticas de segurança dentro da organização e adotou uma missão expandida. Em
resposta a essas mudanças, os requisitos do projeto Trilogia tiveram de mudar. Exigências
mais rigorosas de segurança foram acrescentadas. Um novo componente de base de da-
dos, chamado Arquivo de Casos Virtual, também foi adicionado para tornar os dados aces-
síveis por toda a agência.
O projeto teve sucesso no fornecimento de novos hardwares e softwares para os fun-
cionários e na construção de uma nova infra-estrutura de rede. Contudo, uma análise ex-
terna realizada pelo Conselho Nacional de Pesquisa (NRC) em julho de 2003 revela que, em
sua opinião, o projeto Trilogia tem um grande risco de fracassar. A análise externa ressalta
problemas nas áreas de arquitetura organizacional, de concepção do sistema, de gestão
de programas e de contratos e de recursos humanos. A análise aponta que a introdução de
nova tecnologia em qualquer ambiente em fase de mudança é desafiadora. O FBI precisará
estabelecer novos procedimentos operacionais, e seus funcionários terão de desenvolver
novos conjuntos de aptidões para que a tecnologia seja implementada com sucesso.
Para evitar que a Trilogia fosse um projeto fracassado, o NRC ofereceu as seguintes
recomendações para a equipe de projeto:
1. Criação de um plano de contingência para retornar ao antigo sistema, o Arquivo
de Casos Automatizado, caso o Arquivo de Casos Virtual não funcione. Como não
se desenvolveu um protótipo para o Arquivo de Casos Virtual, ninguém sabe o que
esperar quando o FBI passar do antigo sistema para o novo.
2. A liderança sênior deve se envolver mais no projeto Trilogia. O NRC recomenda
que os líderes seniores despendam tempo para considerar sua arquitetura organi-
zacional, de forma que as novas tecnologias se encaixem na missão global do FBI.
Caso contrário, o novo sistema muito provavelmente não conseguirá atender as
suas necessidades.
3. Planejamento adequado de tempo para testar o novo sistema. Como o projeto já
está bastante atrasado, a equipe de projeto pode ficar tentada a tomar um atalho,
realizando poucos testes para que o sistema seja introduzido o mais rápido possí-
vel, o que provavelmente levaria a um fracasso na implementação.
Esse projeto de upgrade de TI envolve informações sensíveis de segurança, uma mudan-
ça drástica nas operações no ambiente de trabalho, a exigência por novas habilidades dos
funcionários e a demanda por uma conclusão rápida. A equipe de projeto Trilogia pode
superar esses desafios e evitar o fracasso usando princípios sólidos de gestão de projetos.
Anderson, C. FBI Nears Completion of Computer Upgrade. Associated Press, 26 de março de 2004.
McGroddy, J. e Lin, H. A Review of the FBI’s Trilogy Information Technology Modernization Program. Washington, DC: National
Academies Press, 2004.
279
280 Parte 3 As Pessoas: O Segredo para o Sucesso de um Projeto
São as pessoas – não os procedimentos e as técnicas (discutidos nos outros capítulos)

– os elementos decisivos para se alcançar o objetivo do projeto. Procedimentos e técnicas
são somente ferramentas que ajudam as pessoas a executar o trabalho. Por exemplo, um
artista precisa ter tinta, telas e pincéis para pintar um quadro, mas são suas habilidades e
seu conhecimento que permitem a criação de um quadro com essas ferramentas. Dessa
forma, também na gestão de projetos, as habilidades e o conhecimento das pessoas envol-
vidas são vitais para a produção dos resultados. Este capítulo enfoca uma pessoa muito
importante: o gestor de projetos. Você irá conhecer as:
• responsabilidades do gestor de projetos;
• habilidades necessárias para gerenciar com êxito os projetos e as técnicas para desen-
volver tais habilidades;
• abordagens para uma delegação eficaz;
• maneiras como o gestor de projetos pode gerir e controlar as mudanças no projeto.
RESPONSABILIDADES DO GESTOR DE PROJETOS

É responsabilidade do gestor de projetos certificar-se de que o cliente está satisfeito, pois
o trabalho foi concluído com qualidade, dentro do orçamento e do prazo. O gestor de
projetos tem a responsabilidade principal pela liderança no planejamento, na organização
e no controle dos esforços despendidos para que o objetivo do projeto seja alcançado. Em
outras palavras, o gestor de projetos lidera a equipe do projeto para alcançar o objetivo de
cada projeto. Se a equipe fosse um time de futebol, o gestor seria o técnico; se ela fosse
uma orquestra, ele seria o maestro. O gestor de projetos coordena as atividades dos vários
membros da equipe para garantir que eles realizem as tarefas corretas na hora certa, como
um grupo coeso.
Planejamento
Primeiro, o gestor de projetos define claramente o objetivo do projeto, sobre o qual chega a
um acordo com o cliente. Depois o gestor comunica esse objetivo para a equipe do projeto,
a fim de criar uma visão do que constituirá sua conquista de êxito. O gestor de projetos
lidera o desenvolvimento de um plano para alcançar o objetivo do projeto. Ao envolver a
equipe do projeto na elaboração do plano, ele garante um plano mais abrangente do que se
desenvolvesse esse plano sozinho. Além disso, tal participação faz a equipe comprometer-
se com a execução do plano. O gestor de projetos revisa o plano com o cliente para obter
um endosso e em seguida estabelece um sistema de informação para a gestão do projeto
– que pode ser tanto manual como informatizado – para comparar o progresso real com o
progresso planejado. É importante que esse sistema seja explicado à equipe do projeto, de
maneira que ela possa usá-lo adequadamente para gerir o projeto.

1. Quais os dois benefícios que o gestor
de projetos consegue ao envolver
a equipe na elaboração do plano?
Organização
Organizar é garantir os recursos apropriados para a realização do trabalho. Primeiro, o ges-
tor de projetos deve decidir as tarefas que devem ser executadas pela equipe interna e as
tarefas que devem ser feitas por terceiros ou por consultores. Para as tarefas que serão exe-
Capítulo 10 O Gestor de Projetos 281
cutadas internamente, o gestor deve ter o compromisso por parte das pessoas específicas
que trabalharão no projeto. Para as tarefas que serão realizadas por terceiros, ele claramente
não só define os serviços e o escopo do trabalho, como também negocia um contrato com
cada empresa terceirizada. O gestor de projetos ainda atribui responsabilidades e delega
autoridade a terceiros ou a pessoas específicas para as mais diversas tarefas, subentenden-
do-se que eles serão responsáveis pela execução dentro do cronograma e do orçamento
acordados. Para projetos grandes que envolvem muitas pessoas, o gestor pode designar
líderes de grupos específicos de tarefas. Por fim, e mais importante, a tarefa de organização
implica a criação de um ambiente em que as pessoas estejam altamente motivadas para
trabalharem juntas como uma equipe de projeto.

2. O gestor de projetos deve garantir os
__________________ para a realização
do trabalho, atribuir ______________
e delegar ______________ a pessoas
específicas para as mais diversas tarefas.
Controle
Para controlar o projeto, o gestor implementa um sistema de informação para a gestão do
projeto, criado para acompanhar o progresso real e compará-lo com o progresso planejado.
Desse modo, o sistema ajuda o gestor a distinguir empenho de resultados reais. Os mem-
bros da equipe do projeto monitoram as tarefas a eles atribuídas e regularmente geram da-
dos sobre progresso, cronograma e custos. Esses dados são complementados por reuniões
regulares de análise crítica do projeto. Se o progresso real não corresponde ao progresso
planejado ou se ocorrem imprevistos, o gestor de projetos deve tomar uma atitude imediata.
O gestor recebe os dados e o parecer dos membros da equipe a respeito da ação corretiva
apropriada e de como replanejar essas partes do projeto. É importante que esses problemas,
como também os problemas em potencial, sejam identificados com antecedência, e uma
ação corretiva seja conjuntamente tomada. O gestor de projetos não pode ter uma atitude
de: “vamos esperar e ver como as coisas se resolvem”, pois as coisas nunca se resolvem
sozinhas. O gestor de projetos deve intervir e ser proativo, resolvendo os problemas antes
que eles piorem.

3. Quais são as duas funções do sistema
de informação para a gestão do projeto
implementado pelo gestor de projetos?
O gestor de projetos tem o papel de líder no planejamento, na organização e no controle

do projeto, mas não deve tentar fazer tudo isso sozinho. Ele deve envolver a equipe nessas
funções para obter seu compromisso em relação à conclusão bem-sucedida do projeto.
APTIDÕES DO GESTOR DE PROJETOS

O gestor de projetos é um elemento-chave para o sucesso de um projeto. Além de ter lide-
rança no planejamento, na organização e no controle do projeto, o gestor deve possuir um
conjunto de habilidades que, ao mesmo tempo, inspire a equipe do projeto a ter sucesso,
bem como ganhe a confiança do cliente. Os gestores de projetos eficazes têm grande capa-
cidade de liderança, capacidade para estimular as pessoas a evoluir, excelentes habilidades
interpessoais e de comunicação, capacidade de lidar com o estresse, habilidade para solu-
cionar problemas e para administrar o tempo.

4. Quais são as três funções de
gestão de projetos que o gestor tem
responsabilidade de liderar?
Capacidade de Liderança
Ter liderança é fazer as coisas acontecerem por meio dos outros. O gestor de projetos al-
cança resultados por meio da equipe. A liderança de um projeto implica inspirar as pessoas
designadas para o projeto a trabalhar como uma equipe a fim de implementar o plano e
alcançar o objetivo do projeto com sucesso. O gestor precisa criar para a equipe uma visão
do resultado e dos benefícios do projeto. Por exemplo, o gestor de um projeto industrial
pode descrever o novo leiaute da produção de modo a demonstrar os benefícios desse
projeto, como eliminação de pontos de estrangulamento na linha de produção, aumento
da produtividade e simplificação do controle de estoques. Quando os membros da equipe
do projeto podem prever os resultados, eles ficam mais motivados para trabalhar como
equipe que executa com êxito um projeto.

5. A liderança de um projeto implica
_____________ as pessoas designadas
para o projeto a trabalhar como uma
equipe para implementar o ___________
_ e alcançar o _______________________
_______________ com sucesso.
Uma gestão de projetos eficaz requer um estilo de liderança consultivo e participativo,

em que o gestor orienta e treina a equipe do projeto. É preferível esse estilo a uma abor-
dagem de gestão diretiva, autocrática e hierárquica. Ter liderança implica que o gestor
de projetos forneça orientação, e não instruções. O gestor de projetos deve estabelecer os
parâmetros e as diretrizes sobre o que precisa ser feito, enquanto os membros da equipe
determinam como fazê-lo. O gestor eficaz não diz às pessoas como fazer o trabalho.
A liderança de um projeto requer envolvimento e autonomia da equipe. As pessoas que-
rem ter controle sobre o seu trabalho e mostrar que podem atingir metas e encarar desafios.
O gestor de projetos deve envolver as pessoas em decisões que as afetem e capacitá-las
para tomar decisões dentro da área de responsabilidade que lhes foi atribuída. Criar uma
cultura de projeto que capacita a equipe não significa somente atribuir responsabilidades
por tarefas aos membros da equipe, mas também delegar autonomia para que tomem de-
cisões relacionadas ao cumprimento dessas tarefas. Os membros da equipe devem receber
a responsabilidade para planejar e decidir como cumprir suas tarefas, controlar o progresso
de seu trabalho e solucionar os problemas que possam retardar esse progresso. Dessa for-
ma, eles aceitam ter a responsabilidade pela realização do escopo de seu trabalho dentro
do orçamento e do cronograma.

6. A liderança de um projeto exige
_____________________ e ____________
_________ da equipe do projeto.
Ao capacitar pessoas para tomar decisões que afetem o trabalho, o gestor de projetos
deve estabelecer diretrizes claras e, se necessário, alguns limites. Por exemplo, os mem-
bros da equipe podem ser autorizados a implementar a própria solução para um problema,
contanto que a decisão não ultrapasse o orçamento ou inviabilize o cronograma. Do contrá-
rio, pode ser necessária uma consulta ao líder da equipe ou ao gestor do projeto. Do mes-
mo modo, quando uma decisão tomada por uma pessoa ou por um grupo de pessoas da
equipe tiver um impacto negativo no trabalho, no orçamento ou no cronograma de outros
membros da equipe, pode-se exigir uma consulta ao gestor do projeto. Por exemplo, supo-
nha que um membro da equipe insista em não encomendar certos materiais até confirmar
os resultados de testes particulares, mas que essa atitude leve outros membros da equipe a
ficar com o cronograma atrasado. Nesse caso, o gestor do projeto pode convocar todos os
membros da equipe implicados para uma reunião de discussão do problema.
Um gestor de projetos competente sabe o que motiva a equipe e cria um ambiente in-
centivador, no qual as pessoas trabalham como parte de uma equipe de alto desempenho e
são estimuladas a se superar. O gestor de projetos pode criar um ambiente assim apoiando
a participação e o envolvimento de todos. As técnicas para se fazer isso envolvem agendar
reuniões de projeto em que todas as pessoas participam nos debates, solicitar idéias em
uma conversa particular com alguns dos membros e ter vários membros da equipe partici-
pando de apresentações com o cliente ou a direção geral da empresa. O gestor de projetos
deve mostrar que valoriza as contribuições de cada membro da equipe, pedindo opiniões
e sugestões. Por exemplo, o gestor de projetos deve incentivar os membros da equipe a
perguntar as opiniões uns dos outros. Além de permitir que cada um aprenda com o conhe-
cimento e a experiência dos outros, essa atitude cria um senso de apoio e respeito mútuo
dentro da equipe em relação à habilidade única que cada pessoa traz para a equipe.

7. O gestor de projetos competente sabe
o que ________________ os membros da
equipe e cria um ambiente ___________
_______, no qual as pessoas trabalham
como parte de uma equipe de alto
desempenho.
O gestor de projetos deve tomar cuidado para não criar situações que desanimem as
pessoas. Quando as expectativas não são claras, é provável que surja certo desânimo. Con-
sidere o seguinte exemplo: em uma segunda-feira, o gestor de projetos diz a Gayle para
realizar uma tarefa o mais rápido possível. E então, na sexta-feira, ele pergunta se a tarefa já
foi executada. Quando Gayle responde que não terminará a tarefa até a sexta-feira seguin-
te, o gestor, aborrecido, diz: “Na verdade, eu precisava que estivesse feita até hoje!”. Se o
gestor tinha um prazo final específico, deveria ter comunicado a Gayle no início.
Outra maneira de desanimar uma equipe de projeto é submeter seus membros a pro-
cedimentos desnecessários, como a elaboração, por escrito, de relatórios que basicamente
reproduzem o que é verbalizado nas reuniões semanais do projeto. Além disso, reuniões
improdutivas também podem diminuir a motivação.
A subutilização de pessoas cria uma outra situação problemática. Designar alguém para
uma função que esteja muito abaixo de seu nível de competência, em vez de lhe apresentar
desafios, também diminui a motivação. Ainda mais prejudicial é “gerenciar em excesso”,
dizendo às pessoas como elas devem fazer o trabalho. Tal abordagem fará que as pessoas
pensem que o gestor de projetos não confia nelas, o que criará um sentimento de: “se você
está me dizendo como fazer meu trabalho, por que você não o faz sozinho?”. Assim sendo,
os gestores de projetos eficazes não somente devem criar um ambiente incentivador, mas
também precisam tomar cuidado para não fazer coisas que possam ter o efeito contrário.
O gestor de projetos pode promover a motivação por meio do reconhecimento de
cada membro e da equipe do projeto como um todo. Isso deve ser feito durante todo o
projeto e não só no seu final. As pessoas gostam de sentir que estão contribuindo para
o projeto e precisam ser reconhecidas por isso. O reconhecimento pode ser feito de várias
formas, e não só financeiramente. Pode ser em forma de incentivo verbal, elogios, críticas
construtivas ou prêmios. Esse reforço positivo ajuda a estimular o comportamento desejado
– o comportamento que é reconhecido ou recompensado torna-se um hábito. Uma equipe
pode ser reconhecida por concluir uma tarefa importante dentro do orçamento e antes
do prazo ou por identificar uma maneira inovadora de acelerar o cronograma do projeto.
Esse reconhecimento incentivará a equipe a tentar repetir tais feitos no futuro.
Outra forma de reconhecimento por parte do gestor de projetos é demonstrar um in-
teresse verdadeiro pelo trabalho de cada pessoa da equipe. Pode-se conseguir isso dedi-
cando-se o máximo de atenção a cada pessoa quando ela explica o trabalho que faz. Um
breve comentário final como: “muito obrigado(a)”, “bom trabalho” ou “parece muito legal”
mostra à pessoa que suas contribuições são reconhecidas e apreciadas. Outras formas de
reconhecimento podem ser um memorando de: “muito obrigado(a) pelo bom trabalho” ou
de felicitação, ou algum tipo de divulgação, como um artigo ou fotografia na revista da em-
presa, a entrega de um certificado ou placa de honra ao mérito, ou ainda atribuir-lhe uma
posição de maior responsabilidade na equipe do projeto.
O reconhecimento deve ser dado logo após a ação. Se passar muito tempo entre a ação
e o reconhecimento, haverá menor efeito sobre o desempenho futuro. Na verdade, a pessoa
pode achar que o gestor de projetos não está interessado em sua contribuição. Quando for
possível, as atividades de reconhecimento devem envolver outras pessoas além daquela a
ser reconhecida. As pessoas gostam de ser reconhecidas na frente de seus companheiros
de trabalho. O gestor de projetos, por exemplo, pode fazer um comentário positivo sobre
a equipe ou sobre algumas pessoas específicas durante uma reunião de projeto ou diante
do cliente ou da direção geral da empresa. O gestor de projetos deve tentar fazer do reco-
nhecimento um evento divertido, por exemplo, recompensando a pessoa com algum tipo
de prêmio de inovação ou com um almoço em um restaurante. O gestor de projetos eficaz
nunca monopoliza sua atenção ou tenta tirar proveito do trabalho das outras pessoas.

8. As pessoas querem sentir que estão
fazendo uma ________________ para o
projeto e precisam ser _______________.
O gestor de projetos dá o tom à equipe do projeto, estabelecendo um ambiente de con-

fiança, de altas expectativas e de satisfação. Para promover uma atmosfera de confiança,
ele deve cumprir sua palavra e honrar seus compromissos. Agindo dessa forma, o gestor
dá o exemplo, demonstrando que essa postura é esperada de todos da equipe. O gestor de
projetos perde credibilidade se deixa de dar atenção a qualquer sugestão, pergunta ou inte-
resse. Em casos em que as coisas não podem ser feitas ou não funcionam como planejado
ou esperado, o gestor de projetos precisa dar um esclarecimento para que sua credibilidade
não seja prejudicada.

9. Um gestor de projetos dá o tom à
equipe do projeto, estabelecendo um
ambiente de _______________, de altas
_______________ e de _______________.
Os gestores de projetos eficazes têm grandes expectativas sobre si mesmos e sobre cada
pessoa da equipe do projeto. Eles acreditam que as pessoas tendem a corresponder ao que
é esperado delas. Se o gestor de projetos mostra confiança nos membros da equipe e tem
altas expectativas sobre o desempenho deles, a equipe sempre conseguirá superar os de-
safios. Os gestores de projetos devem ter o pensamento otimista de que podem vencer até
mesmo os obstáculos que parecem ser insuperáveis na realização do projeto. No entanto,
se o gestor de projetos não equilibra suas expectativas e otimismo com a realidade, a equi-
pe pode ficar frustrada. São exemplos de expectativas não realistas: comprometer-se com
um cronograma extremamente ambicioso para concluir uma tarefa complicada ou esperar
que um produto sofisticado de software, desenvolvido recentemente, funcione sem erros na
primeira vez em que é usado. Um gestor de projetos imprudente e negligente não ganha a
confiança da equipe do projeto ou do cliente.
Os projetos precisam ser prazerosos. Os gestores de projetos devem gostar do que fa-
zem e incentivar a mesma atitude positiva por parte dos membros da equipe do projeto.
A maioria das pessoas que trabalham nos projetos procura por associação e socialização
– elas não querem trabalhar isoladas. A equipe do projeto precisa passar por uma sociali-
zação antes de começar a funcionar eficazmente como uma equipe de alto desempenho. O
gestor pode facilitar esse processo de socialização, criando um senso de camaradagem en-
tre os membros da equipe. Uma técnica é promover confraternizações periódicas – almoços
ou jantares – para a equipe do projeto. Outra técnica é, se possível, acomodar toda a equipe
em um único escritório. Ter um ambiente de trabalho aberto, em vez de cada um ficar atrás
de uma porta fechada, vai promover uma futura socialização, por facilitar a interação entre
as pessoas. Por fim, o gestor de projetos deve aproveitar as oportunidades para comemorar
os bons resultados, especialmente na fase inicial do projeto. Logo que se conquista uma
meta, o gestor de projetos pode levar comida ou bebida para comemorar com a equipe
ou organizar um almoço para depois de uma reunião de trabalho. Essas atividades criam
um ambiente de socialização, conversa informal e contribuem para a construção de uma
verdadeira equipe e, assim, torna o trabalho mais prazeroso. Quem disse que o trabalho
não pode ser divertido?

10. As pessoas que trabalham nos
projetos procuram por _______________
e _______________ — elas não querem
trabalhar ______________.
Para que tenha liderança, o gestor de projetos deve estar altamente motivado e dar
exemplo positivo para a equipe do projeto, ou seja, é necessário praticar o que se defende.
Se um gestor de projetos espera que a equipe fique até mais tarde para terminar o trabalho
e manter o projeto dentro do cronograma, ele deveria ficar também, em vez de ir embora
mais cedo. Tudo que o gestor faz e diz serve de exemplo para a equipe em termos de compor-
tamento esperado. Um gestor de projetos deve manter uma atitude positiva – sem comentários
negativos, sem queixas, sem menosprezos ou acusações e sem observações depreciativas
– e deixar claro que é inadmissível um comportamento negativo ao se trabalhar em equipe.
Os gestores de projetos eficazes têm uma atitude de “pode ser feito”, um desejo de enfren-
tar e superar obstáculos. Eles vencem os desafios e fazem as coisas. Focam maneiras de se
fazer o trabalho em vez de dar justificativas quando não podem fazê-lo. Um bom gestor de
projetos não é intimidado por barreiras ou desculpas. Ele tem autoconfiança e mostra ter
confiança nos membros da equipe do projeto.

11. A liderança exige que o gestor de
projetos esteja altamente ____________
e que dê um ________________________
para a equipe do projeto.
Dizem que...
Há aqueles que fazem as coisas acontecerem;
aqueles que deixam as coisas acontecerem;
aqueles que se perguntam o que aconteceu.
O gestor de projetos lidera ao fazer as coisas acontecerem!
Capacidade de Desenvolver Pessoas

O gestor de projetos eficaz tem um compromisso com o treinamento e o progresso das
pessoas que trabalham no projeto. Ele usa o projeto como uma oportunidade para agregar
valor à base de experiência de cada pessoa, de maneira que todos os membros da equipe
estejam mais instruídos e competentes no final do projeto do que quando o começaram.
O gestor de projetos deve criar um ambiente no qual as pessoas possam aprender com as
tarefas que realizam e as situações que vivem ou observam. Além disso, ele deve passar
para a equipe a importância de atividades de contínuo autodesenvolvimento. Um modo de
incentivar essas atividades é conversar sobre a importância do autodesenvolvimento nas
reuniões da equipe do projeto, ou ainda, fazer uma reunião com cada membro no início de
sua atribuição e motivá-los a tirar vantagem dessa atribuição para expandir seus conheci-
mentos e habilidades. Um bom gestor de projetos acredita que todas as pessoas são valiosas
para a organização e que elas podem dar contribuições cada vez maiores por meio de um
aprendizado contínuo. Ele enfatiza o valor do autodesenvolvimento ao motivar as pessoas
a tomar iniciativa. Por exemplo, dar atribuições desafiadoras ou novas ou pedir que parti-
cipem de seminários. Um projeto apresenta muitas oportunidades para as pessoas expandir
o conhecimento técnico, além de desenvolver habilidades de comunicação, de solução de
problemas, de liderança, de negociação e de administração do tempo.

12. Um bom gestor de projetos acredita
que todas as pessoas são _____________
para a organização e que elas podem
dar contribuições cada vez maiores por
meio de um ________________________.
California Public Employee Retirement System
Em 1o de abril de 2004, o Sistema de Aposentadoria Pública da Califórnia (CalPERS) inaugurou
um novo website que fornece informações personalizadas a aproximadamente 1,5 milhão
de titulares de contas e permite que o maior sistema de aposentadoria pública dos Estados
Unidos reduza consideravelmente o volume de papel, disponibilizando on-line o processo
inicial de coleta dos dados necessários para a abertura de alguns tipos de contas novas.
Com base nesse e em vários outros projetos, Alex Salkever, da Business Week Online, reuniu
alguns conselhos de gestores de projetos experientes e consultores de TI sobre o sucesso
de projetos. Ele sintetizou essas idéias deste modo: faça uma análise rigorosa; reúna os
complementares; assuma a responsabilidade; tenha cuidado com pessoas esquisitas; faça
muitas perguntas e alcance as metas. O que ele estava dizendo era basicamente para fazer
o seguinte:
Seleção do Projeto
Escolha projetos que se encaixem na missão global do negócio. Projetos de TI podem ser
caros e são propensos ao fracasso. Estabeleça um processo de seleção de projeto que te-
nha vários níveis de análises para aprovação. Da mesma forma, não aprove um projeto
grande de TI enquanto os processos internos não tiverem sido avaliados. Um projeto de
TI caro e de grande porte pode ser evitado por meio de pequenas mudanças que tragam
mais eficácia.
Equipe de Projeto
Tente encontrar um grupo de pessoas com habilidades complementares e bons hábitos
de comunicação. Designe um funcionário como o responsável pelos resultados do projeto.
Se um projeto exige alto nível de manutenção, pense em usar recursos internos. Contrate
pessoas externas se aquelas habilidades forem necessárias apenas por um curto período
de tempo. Se o projeto for para um cliente, este também deve designar seu próprio líder de
projeto. O cliente terá mais chances de ter sucesso no resultado do projeto e, assim, pode
evitar custos excedentes e outros problemas.
Fornecedor
Faça sua lição de casa. Verifique o potencial de fornecedores que enviam uma proposta
em resposta à sua CP conversando com as referências indicadas por eles. Tente descobrir
clientes antigos que não foram indicados como referência. Analise e prepare-se cuidadosa-
mente para negociar todos os contratos. A Especificação de Serviço deve ser bastante de-
talhada. Muitas vezes, os fornecedores designam outras pessoas para trabalhar no projeto;
portanto, faça questão de ter a palavra final sobre o pessoal contratado pelo fornecedor.
Produtos de Prateleira (off-the-shelf)
Se possível, compre um pacote de softwares que forneça a maioria dos recursos desejados
para o projeto. Desse modo, modificações mínimas serão necessárias. Essa decisão pode
ser menos cara do que a de modificar muito um produto de preço mais baixo.
Comunicação
Programe reuniões regulares entre o líder/os executivos do projeto e o fornecedor. Isso
pode ajudar a identificar problemas e cuidar deles a tempo. Comunique-se com todos os
funcionários, parceiros e clientes que serão afetados pelo novo projeto.
Controle
Construa um mapa e uma linha de tempo específicos e estabeleça restrições para prevenir
uma extensão do escopo. Sem controles adequados para o cronograma e o escopo, o pro-
jeto provavelmente vai ultrapassar o orçamento.
Salkever, A. Taming the IT Project Monster. Business Week Online, 16 de abril de 2004.
Um gestor de projetos capacitado oferece oportunidades para o aprendizado e desen-

volvimento, motivando as pessoas a tomar a iniciativa, a correr riscos e a tomar decisões.
Em vez de criar medo do fracasso, o gestor reconhece que os erros fazem parte do apren-
dizado e da experiência de crescimento. O gestor do projeto pode tentar “esticar” tarefas
que exijam de um membro da equipe a ampliação de seus conhecimentos para que este
faça mais do que ele acredita ser capaz de fazer. Por exemplo, uma tarefa de concepção de
um produto que implique o uso de tecnologia óptica para sensores pode ser atribuída a um
engenheiro com conhecimento limitado à tecnologia óptica. Isso exigirá que ele aprenda
mais sobre o assunto, deixando-o mais preparado para projetos futuros da organização.

13. Em vez de criar medo do __________,
o gestor de projetos reconhece que os
erros fazem parte do ________________
e da experiência __________________.
Outra coisa que o gestor de projetos pode fazer é identificar situações em que pessoas
com menos experiência possam aprender com as mais experientes. Por exemplo, uma pes-
soa que faz processamento de dados pode ser designada para trabalhar com um analista
de dados, de maneira que possa aprender como analisar e interpretar os dados. Nessas si-
tuações, o gestor de projetos deve dizer às pessoas mais experientes que parte do trabalho
delas no projeto é instruir, treinar e ensinar as pessoas com menos experiência.

14. Um bom gestor de projetos valoriza
e espera um _____________________
contínuo.
Uma última maneira como o gestor de projetos pode capacitar as pessoas é dar sessões
de treinamento. Por exemplo, se uma pessoa da equipe não possui experiência de fazer
apresentações em público ou tem poucas habilidades de apresentação, o gestor de pro-
jetos pode fazê-la participar de um seminário sobre como realizar apresentações eficazes.
Depois pode lhe ser dada a oportunidade de aplicar o que aprendeu, fazendo apresenta-
ções nas reuniões com a equipe. O gestor de projetos também pode fazer treinamentos para
ajudá-la a melhorar, até que ela seja capaz de fazer uma apresentação para o cliente.
Durante as conversas com a equipe, o gestor de projetos deve perguntar: “o que você
aprendeu trabalhando no projeto?”. Cada resposta ajudará o gestor a determinar que outras
atividades de desenvolvimento ou oportunidades de aprendizado são necessárias. Fazer
esse tipo de pergunta também deixa a mensagem de que o gestor de projetos valoriza e
espera o autodesenvolvimento contínuo.
Habilidades de Comunicação
Os gestores de projetos devem ser bons comunicadores. Eles precisam comunicar-se regular-
mente com a equipe do projeto, como também com qualquer empresa terceirizada, com o
cliente e com a alta direção da própria empresa. É crucial uma comunicação eficaz e freqüen-
te para manter o projeto em progresso, identificar problemas em potencial, solicitar sugestões
para melhorar o desempenho do projeto, manter a satisfação do cliente e evitar surpresas.
Um alto nível de comunicação é importante, principalmente no início do projeto, para

construir uma boa relação de trabalho com a equipe do projeto e estabelecer expectativas
claras com o cliente.

15. Faça uma lista de cinco razões pelas
quais é importante que o gestor de
projetos estabeleça uma comunicação
freqüente.

16. Um alto nível de comunicação é
importante principalmente no início do
projeto para construir uma boa _______
______________ com a equipe do projeto
e para estabelecer __________________
claras com o cliente.
Os gestores de projetos eficazes comunicam e compartilham informações de diferentes

maneiras. Eles fazem reuniões e conversas informais com a equipe do projeto, com o clien-
te e com a alta direção da empresa. Também providenciam relatórios por escrito para o
cliente e para a alta direção. Todas essas tarefas exigem que o gestor de projetos tenha boas
habilidades de comunicação oral e escrita. Aprendemos mais escutando do que falando.
Por isso, os bons gestores de projetos passam mais tempo escutando do que falando. Eles
não dominam a conversa sim ouvem as expectativas e necessidades expressas pelo cliente e
as idéias e preocupações da equipe do projeto. Para iniciar um diálogo em alguma questão
importante, eles propõem debates e conversas e, para estimular o diálogo, fazem perguntas
e solicitam comentários e idéias. Por exemplo, quando um gestor de projetos introduz um
assunto em uma reunião de equipe, ele deve pedir respostas ou idéias dos outros, em vez
de somente emitir sua opinião sobre o assunto e passar para o próximo item da pauta. Todo
gestor de projetos deve sair do seu escritório com freqüência e atender mais aos membros
da equipe, comentando, por exemplo, uma opinião ou idéia que a pessoa expressou na
reunião de equipe, mas que não tenha sido adotada na reunião.

17. Quais são as três maneiras de um
gestor de projetos se comunicar?
O gestor de projetos estabelece uma comunicação contínua com o cliente para mantê-
lo informado e determinar se há alguma mudança nas expectativas. O gestor de projetos
precisa manter o nível de satisfação do cliente durante todo o projeto, conversando com ele
com regularidade, programando, por exemplo, uma ligação telefônica com o cliente toda
sexta-feira à tarde.

18. Os bons gestores de projetos passam
mais tempo __________________ do que
_________________.
A comunicação precisa ser pontual, honesta e sem ambigüidades. As comunicações

efetivas dão credibilidade e constroem confiança, além de evitar o surgimento de boatos.
Suponha que um membro da equipe seja designado temporariamente para outro projeto
que necessite de sua experiência para ajudar a solucionar um problema crítico. Quando a
equipe descobre que um dos membros não está mais trabalhando no projeto, podem surgir
boatos de que ele foi mandado embora por ultrapassar o orçamento ou que ele deixou o
projeto por estar descontente. O gestor de projetos precisa convocar uma reunião com a
equipe para informar aos membros que ele foi temporariamente realocado e que vai retor-
nar em algumas semanas.

19. Dê três razões pelas quais o gestor
de projetos deve estabelecer uma
comunicação contínua com o cliente.
É importante para o gestor de projetos dar um rápido feedback à equipe e ao cliente.

Tanto as boas como as más notícias devem ser compartilhadas prontamente. Para que o
gestor de projetos seja eficaz, os membros precisam receber informações atualizadas, prin-
cipalmente um feedback do cliente que possa levar a mudanças no escopo do projeto, no
orçamento ou no cronograma.

20. Por que a comunicação feita pelos
gestores de projetos precisa ser pontual,
honesta e sem ambigüidades?
O gestor de projetos deve criar uma atmosfera que promova uma comunicação aberta e
oportuna, sem qualquer medo de represália, e tem de aceitar os diferentes pontos de vista.
Por exemplo, uma pessoa com dificuldades para realizar uma tarefa deve poder levar o pro-
blema para o conhecimento do gestor de projetos sem que seja penalizada por isso.
As comunicações de projeto serão discutidas mais adiante no Capítulo 12.
Habilidades Interpessoais
Habilidades interpessoais são fundamentais para um gestor de projetos. Estas dependem
de boas habilidades de comunicação oral e escrita, como foi discutido na seção anterior.
O gestor de projetos precisa estabelecer expectativas claras dos membros da equipe do
projeto, de maneira que todos saibam a importância de seu papel para a conquista do ob-
jetivo do projeto. O gestor pode fazer isso, envolvendo a equipe no desenvolvimento de
um plano de projeto que mostre quais pessoas estão designadas para quais tarefas e como
essas tarefas se encaixam entre si. Quase como um treinador de time de futebol, o gestor
de projetos deve enfatizar que a contribuição de cada um é valiosa, para que a execução
do plano tenha sucesso.
É importante que o gestor de projetos desenvolva uma relação com todas as pessoas
da equipe. Isso pode parecer uma atividade demorada, mas não é necessariamente assim.
Ela exige que você reserve um tempo para uma conversa informal com cada membro da
equipe do projeto e com cada pessoa-chave da organização do cliente. Essas conversas,
promovidas pelo gestor de projetos, podem ser feitas durante o trabalho ou fora do es-
critório – durante um almoço, uma viagem de negócios ou quando assistem juntos a uma
partida de futebol. Essas situações são oportunidades para o gestor ouvir de cada membro
da equipe o que os motiva, qual a sua percepção do andamento das coisas, quais são suas
preocupações e como eles se sentem em relação às coisas. Suponha, por exemplo, que Car-
los menciona que gosta de fazer demonstrações de produtos, mas que preferiria desenvol-
ver mais suas habilidades para apresentações formais. Sabendo disso, o gestor de projetos
pode lhe pedir que faça uma demonstração do software de gráficos que ele desenvolveu na
próxima reunião de análise crítica com o cliente. Ou ainda, o gestor de projetos pode lhe
pedir para fazer uma apresentação na próxima reunião interna de análise crítica de projeto,
o que pode ser menos estressante para Carlos praticar suas habilidades de apresentação.
A meta de autodesenvolvimento de Carlos, que surgiu de uma conversa informal iniciada
pelo gestor de projetos, poderia não ter sido descoberta em qualquer outra situação.

21. O gestor de projetos deve ter uma
__________________________ informal
com cada membro da equipe do projeto e
com cada pessoa-chave da organização
__________________________.
O gestor de projetos deve tentar saber qual é o interesse pessoal de cada pessoa sem
ser invasivo. Ele pode falar sobre seus hobbies ou sobre a sua família e ver se o membro
da equipe também fala sobre o assunto. O gestor de projetos deve procurar áreas de in-
teresse comum com cada pessoa, como esportes, culinária, time de futebol, crianças ou
cidade natal.

22. O gestor de projetos deve fazer
perguntas _______________________ e
_______________________.
Em conversas informais, o gestor de projetos deve fazer perguntas abertas e ouvir com
atenção. É impressionante a quantidade de informações que você pode conseguir em res-
posta a uma simples pergunta do tipo: “como vão as coisas?”. Mostre interesse sincero so-
bre o que a pessoa diz, pois, se você se mostrar desinteressado, a pessoa não continuará a
conversa. Dessa forma, é importante dar um feedback e estimular comentários, como “isso
é interessante” ou “conte-me mais sobre isso”.
Boas habilidades interpessoais capacitam um gestor de projetos a simpatizar com as
pessoas quando surgem circunstâncias especiais – em caso de, por exemplo, um membro
da equipe estar desanimado por causa de problemas técnicos no desenvolvimento de um
software ou caso esteja desatento porque a esposa está se recuperando de um acidente
de carro. É claro que o gestor de projetos deve ser sincero ao animá-lo e ao oferecer-lhe
apoio.
Quando se encontra com um membro da equipe do projeto, ou no corredor ou no
supermercado, o gestor de projetos deve aproveitar a oportunidade. Em vez de apenas
cumprimentar com um simples “oi” ou “boa-tarde”, o gestor deve parar e tentar travar uma
conversa com o membro da equipe, mesmo sendo breve. Pode ser sobre qualquer assunto,
desde “está preparado para a nossa reunião com o cliente na semana que vem?” até “o
time da sua filha ganhou ontem?”. Um gestor de projetos eficaz cria e preserva essas rela-
ções interpessoais durante todo o projeto.
Um gestor de projetos precisa ter boas habilidades interpessoais para tentar influenciar
o pensamento e as ações dos outros. Durante o projeto, ele terá de convencer e negociar
com o cliente, com a equipe do projeto e com a alta direção da empresa. Por exemplo, o
gestor de um projeto de construção pode precisar convencer o cliente a desistir de fazer
uma mudança no escopo do projeto que exigiria um aumento de custos. Ou ainda, o gestor
do projeto de um show de talentos beneficente de uma instituição da cidade pode ter de
usar suas habilidades interpessoais para convencer um artista a trabalhar no projeto. Essas
situações não podem ser levadas de modo autoritário – são necessárias boas habilidades
interpessoais para se chegar ao resultado desejado.
Um gestor de projetos também precisa de boas habilidades interpessoais para lidar
com discordâncias e desavenças entre os membros da equipe. Tais situações podem exigir
um tratamento delicado por parte do gestor de projetos, a fim de mediar uma resolução em
que ninguém seja desprestigiado e que o trabalho do projeto não seja afetado. O tema de
resolução de conflitos será discutido mais adiante no Capítulo 11.
Capacidade de Lidar com o Estresse

Os gestores de projetos precisam ser capazes de lidar com o estresse que pode surgir em
algumas situações de trabalho. O estresse pode ser alto quando: um projeto corre perigo
de não alcançar seu objetivo por causa do aumento de seus custos, atraso de cronograma
ou por problemas técnicos com o equipamento ou com o sistema; mudanças no escopo
são exigidas pelo cliente; ou quando surgem conflitos dentro da equipe do projeto com
relação à solução mais apropriada para um problema. Nesses momentos, uma atividade
de projeto pode ficar tensa e intensa. O gestor não deve entrar em pânico, e sim man-
ter a calma. O gestor de projetos eficaz é capaz de enfrentar condições de constantes
mudanças. Até mesmo com os planos mais bem preparados, os projetos estão sujeitos a
imprevistos que podem causar uma desordem imediata. É necessário manter a tranqüili-
dade e evitar que o pânico e a frustração cheguem à equipe do projeto, ao cliente ou à
alta direção da empresa.
Em certas ocasiões, o gestor de projetos precisa atuar como um mediador entre a equipe
do projeto e o cliente ou a alta direção. Se o cliente ou a alta direção não estiverem satisfeitos
com o progresso do projeto, o gestor tem de assumir a responsabilidade e certificar-se de
que a equipe do projeto não tenha desanimado. O gestor deve falar sobre qualquer des-
contentamento para a equipe do projeto, de maneira que a inspire a vencer o desafio. Da
mesma forma, pode haver vezes em que a equipe do projeto tenha queixas com relação às
exigências ou relutâncias do cliente para fazer mudanças. Também nesse caso o gestor de
projetos precisa atuar como intermediador, absorvendo as reclamações e transformando-as
em desafios para a equipe do projeto.
O gestor de projetos precisa ter um bom senso de humor. Se usado adequadamente, o
humor pode ajudar um gestor de projetos a lidar com o estresse e a quebrar a tensão. Como
o gestor de projetos serve de exemplo para a equipe do projeto e demonstra qual é o com-
portamento adequado para o projeto, o humor deve ser de bom gosto. Um gestor não deve
contar piadas inapropriadas ou ter coisas impróprias pregadas na parede do escritório e
desde o início deve deixar claro para a equipe que tal comportamento é inaceitável e não
será tolerado.

23. O gestor de projetos precisa ter um
bom senso de _______________ e precisa
estar _______________ em forma.
O gestor de projetos pode melhorar a habilidade de lidar com o estresse, mantendo a

forma por meio de exercícios regulares e alimentação saudável. Também pode organizar
atividades de combate ao estresse para a equipe do projeto, como esportes, passeios ou
caminhadas.
Capacidade de Resolver Problemas
Um gestor de projetos precisa ser um bom solucionador de problemas. Embora seja mais
fácil identificar problemas do que resolvê-los, um bom solucionador de problemas começa
com a identificação antecipada do problema ou de um problema em potencial. A antecipa-
ção possibilita mais tempo para elaborar uma boa solução. Além disso, se um problema é
identificado com antecedência, pode ser menos custoso para resolvê-lo, e ele pode ter me-
nos impacto sobre as outras partes do projeto. Uma boa identificação de problema requer
um sistema de informação ágil e orientado por dados precisos, uma comunicação oportuna
e aberta entre a equipe do projeto, os terceirizados e o cliente, e um pouco de ousadia,
com base na experiência.
O gestor de projetos deve estimular os membros da equipe a identificar problemas com
antecedência e a resolvê-los sozinhos. A equipe precisa ser auto-suficiente para solucionar
problemas e não esperar ou depender do gestor para começar.
Quando um problema é potencialmente crítico e pode colocar em perigo o cumprimen-
to do objetivo do projeto, os membros da equipe precisam transmitir essa informação para o
gestor de projetos com antecedência para que ele possa liderar o esforço pela solução do
problema. Uma vez identificado, o gestor de projetos pode precisar buscar dados adicionais
e fazer perguntas esclarecedoras para entender de fato o problema e sua grandeza. Deve
ser perguntado aos membros da equipe se eles têm alguma sugestão de como o problema
pode ser solucionado. Ao trabalhar com os membros apropriados da equipe do projeto, o
gestor deve, portanto, utilizar suas habilidades analíticas para avaliar a informação e elaborar
a solução ideal. É importante que o gestor de projetos possua a habilidade de ver a “situação
como um todo” e de como as soluções em potencial podem afetar outras partes do projeto,
em especial as relações com o cliente ou com a alta direção. Depois que a solução ideal te-
nha sido elaborada, o gestor de projetos delegará sua implementação às pessoas apropriadas
da equipe do projeto.
A resolução de problemas será discutida mais adiante, no Capítulo 11.

24. Ao solucionar problemas, o gestor de
projetos precisa ser capaz de ter _____
___________ e de como as soluções em
potencial podem afetar outras partes do
projeto.
Capacidade de Gerir o Tempo

Os bons gestores de projetos gerem muito bem o tempo. Os projetos requerem muita
energia por envolver muitas atividades simultâneas e diversos imprevistos. Para fazer o uso
favorável do tempo disponível, o gestor de projetos tem de ter autodisciplina, ser capaz de
priorizar as coisas e mostrar disposição para delegar.
A gestão do tempo é mais discutida no Capítulo 11.

25. Quais são as habilidades que um
gestor de projetos eficaz tem?
DESENVOLVENDO AS APTIDÕES NECESSÁRIAS

PARA SER GESTOR DE PROJETOS
As pessoas não nascem com as habilidades que um gestor de projetos precisa, mas, ao con-
trário, as desenvolvem. Há várias maneiras de desenvolver as habilidades necessárias para
ser um gestor de projetos eficaz.
1. Ganhar experiência. Trabalhe no maior número de projetos que puder. Cada projeto
apresenta uma oportunidade de aprendizado. É melhor se os projetos não forem todos do
mesmo tipo. Por exemplo, se você é um engenheiro civil e trabalha em um grande escri-
tório de projetos e somente participou de projetos de construções escolares, você pode
procurar a oportunidade de ser designado para outro tipo de projeto, como um museu ou
uma igreja. Da mesma forma, procure ter várias funções em cada projeto. Em um projeto,
você pode desenvolver um software, enquanto em outro você pode pedir para ser um líder
de grupo ou ter a chance de interagir mais com o cliente. O propósito de variar os projetos
e as funções é expor-se ao maior número possível de gestores de projetos, clientes e outras
pessoas com experiência em projetos. Cada experiência representa uma oportunidade de
aprender com as demais pessoas.
É possível pedir que alguém seja seu mentor enquanto você trabalha em um projeto.
Essa pessoa deve ser alguém que possua habilidades as quais você está tentando desenvol-
ver. Pode ser útil também observar como os outros participantes do projeto empregam as
habilidades. Veja o que eles fazem, de certo ou de errado. Por exemplo, suponha que você
queira desenvolver suas habilidades de apresentação. Quando as pessoas fizerem apresen-
tações no projeto, observe o que elas fazem bem (como mostrar entusiasmo e envolver o
público) e o que fazem de errado (como ficar na frente dos recursos visuais, de modo que
nem todo mundo possa vê-los, ou contar piadas inapropriadas no início da apresentação).
Lembrar-se dessas coisas o ajudará quando você tiver de fazer uma apresentação. É menos
penoso aprender com os erros dos outros que com os próprios.
2. Peça o feedback de outras pessoas. Se quer melhorar suas habilidades de resolver pro-
blemas, pergunte a um mentor, por exemplo, se ele tem observado alguma coisa que você
poderia fazer para melhorar nas situações de resolução de problemas. Se ele lhe disser que
você tem uma tendência para chegar a conclusões precipitadas, tente levar mais tempo para
descobrir todos os fatos ou ouvir o ponto de vista das outras pessoas.
3. Faça uma auto-avaliação e aprenda com os próprios erros. Se você concluiu uma
tarefa de projeto, mas, por exemplo, ultrapassou o orçamento ou atrasou o cronograma,
pergunte a si mesmo o que aconteceu, o que poderia ter feito diferente e como fará da pró-
xima vez. Talvez você precise trabalhar mais a gestão de tempo, enfocando primeiro as
atividades mais importantes.
4. Entreviste os gestores de projetos com habilidades que você queira desenvolver. Se
você quiser desenvolver habilidades de liderança, por exemplo, procure gestores de proje-
tos que você considera líderes eficazes. Pergunte-lhes como desenvolveram essa habilida-
de e que sugestões lhe dariam. Ofereça-se para pagar um almoço se essa é a única hora em
que você pode encontrá-los. Pode ser um bom investimento.
5. Participe de programas de treinamento. Existem muitos seminários, workshops, ví-
deos, CDs e materiais de estudo sobre todas as habilidades discutidas na seção anterior. Há
também cursos e seminários sobre o tema gestão de projetos. Ao participar de seminários,
busque oportunidades de aprender com estas três fontes: o ministrante, os materiais e os
outros participantes.
6. Faça parte de organizações. Associar-se ao Project Management Institute lhe dará

oportunidades de participar em encontros e conferências com outras pessoas envolvidas
com gestão de projetos. Entrar para uma associação como a Toastmasters International lhe
dará a chance de desenvolver boas habilidades de apresentação. Veja no Apêndice B uma
lista de organizações de gestão de projetos.
7. Leia. Assine jornais ou procure artigos relacionados às habilidades que você quer
desenvolver. Existem muitos artigos sobre como aperfeiçoar suas habilidades. Pergunte a
outras pessoas se elas conhecem algum bom livro ou artigo sobre um assunto específico
– suas indicações podem economizar tempo de pesquisa por bons materiais.
8. Seja voluntário. O ambiente de trabalho não é o único local onde você pode desen-
volver suas habilidades. Podem faltar oportunidades no trabalho para o desenvolvimento
de certas habilidades. Pense em envolver-se com uma organização de voluntariado, na qual
você possa não só contribuir para a comunidade ou para uma causa específica, mas tam-
bém desenvolver habilidades de liderança.

26. a. Identifique uma habilidade que
você queira desenvolver.
b. Identifique três coisas que você pode
fazer para desenvolver essa habilidade.
c. Selecione uma das três coisas
relacionadas acima e escolha uma data
até a qual você vai ter feito isso.
O aprendizado e o desenvolvimento são atividades para a vida toda – não existe

um limite. Seu chefe pode lhe dar o apoio e o estímulo, além de fornecer os recursos
(tempo e dinheiro). A organização tem de reservar fundos para treinamento e ativida-
des de desenvolvimento de pessoal. Você, no entanto, tem a responsabilidade principal
por desenvolver suas habilidades. Você tem de tomar a iniciativa e ter a vontade. Você
tem de fazer acontecer.
DELEGAÇÃO
A delegação envolve capacitar a equipe para alcançar o objetivo do projeto e tornar cada
membro apto para atingir os resultados esperados de sua área de responsabilidade. É o ato
de permitir que as pessoas executem com sucesso as tarefas a elas atribuídas. A delegação
implica mais que apenas atribuir tarefas para membros específicos da equipe do projeto. Ela
inclui dar aos membros da equipe a responsabilidade de alcançar os objetivos do trabalho
e a autoridade para tomar decisões e realizar ações para conseguir os resultados esperados,
bem como a responsabilidade final pela execução desses resultados.

27. A delegação envolve ______________
a equipe para alcançar o ______________
e capacitar cada membro para atingir
os _________________________ de sua
área de responsabilidade.
Aos membros da equipe do projeto, são determinadas metas específicas que devem ser
alcançadas em termos do escopo do trabalho, produtos ou resultados tangíveis de serem al-
cançados, o orçamento disponível e o prazo ou cronograma admissível para suas áreas de
responsabilidade. Eles planejam os próprios métodos de alcançar os resultados desejados
e exercem controle sobre os recursos que precisam para fazer o trabalho.
A delegação é um dever para um gestor de projetos eficaz. É parte da sua responsabi-
lidade na organização do projeto. Delegar não é “passar a responsabilidade”. O gestor de
projetos é, no final das contas, responsável pelos resultados do projeto. O gestor que en-
tende e pratica delegação assegura um desempenho eficaz por parte da equipe do projeto
e cria as condições necessárias para a cooperação e o trabalho em equipe.
Uma delegação eficaz exige boas habilidades de comunicação. Os membros da equipe
do projeto precisam compreender que o trabalho de implementação do projeto lhes foi de-
legado. O gestor de projetos tem a responsabilidade de proporcionar um claro entendimento
do que é esperado em termos de resultados específicos. Não é suficiente que o gestor de
projetos diga: “Fulano, você trabalha com o design” ou “Sicrano, você faz a publicidade”.
Em vez disso, ele precisa definir o que especificadamente constitui cada tarefa e seu re-
sultado desejado. Isso inclui escopo do trabalho, os produtos ou resultados tangíveis a ser
efetuados e a qualidade, orçamento e cronograma esperados. Esses elementos devem ser
definidos e acordados entre o gestor do projeto e os membros da equipe antes de começar
qualquer trabalho. No entanto, o gestor de projetos não deve dizer às pessoas como fazer
a tarefa. Isso deve ser deixado ao encargo delas, para que assim possam ser criativas. Se é
dito às pessoas como executar as tarefas, elas não ficarão tão comprometidas em alcançar
os resultados desejados e sentirão que o gestor de projetos não tem muita confiança em
suas capacidades.

28. Os gestores de projetos não devem
dizer às pessoas _____________ fazer as
tarefas a elas atribuídas.
Se for para os membros da equipe executarem suas tarefas com sucesso, devem ser
dados a eles os recursos e a autoridade para exercer controle sobre esses recursos. Estes
podem incluir pessoas, dinheiro e instalações. Os membros da equipe devem ser capazes
de recorrer à experiência dos demais, adquirir materiais e ter acesso a recursos quando
necessários. Aos membros da equipe, deve ser dada a autoridade para tomar decisões com
relação ao uso de recursos, contanto que eles fiquem dentro dos limites do orçamento e
do cronograma.
A delegação envolve a seleção de membros da equipe do projeto que sejam os mais
qualificados para realizar cada tarefa, além de capacitá-los para isso. O gestor de projetos
precisa saber as capacidades e limitações de cada membro da equipe do projeto ao atri-
buir as tarefas. O gestor de projetos não pode delegar a uma pessoa uma série de tarefas
que exijam mais tempo do que ela tem disponível. Por exemplo, não se pode esperar de
uma pessoa que, trabalhando sozinha, pinte seis cômodos em uma semana, quando se
estima dois dias para pintar cada cômodo. Da mesma forma, o gestor de projetos não pode
esperar que as pessoas realizem tarefas para as quais não têm a experiência adequada. Por
exemplo, não se pode presumir que uma pessoa sem conhecimento suficiente de química
ou técnicas de análise faça uma análise química. A delegação, no entanto, proporciona uma
oportunidade de designar para as pessoas tarefas desafiadoras, ou “elásticas”, a fim de de-
senvolver e ampliar suas capacidades e habilidades. Portanto, quando o gestor de projetos
estiver delegando, deve considerar não só as capacidades atuais da pessoa, mas também
seu potencial. Tarefas desse tipo incentivam as pessoas a assumir a responsabilidade como
um desafio e mostrarem que podem atender às expectativas do gestor de projetos.

29. Ao designar pessoas para tarefas
específicas, o gestor de projetos precisa
levar em consideração ______________,
______________ e ______________ da
pessoa.
Quando um gestor de projetos autoriza os membros da equipe a tomar decisões asso-

ciadas com a realização do trabalho, ele dá liberdade para que façam o necessário para
realizar o trabalho sem interferência. Entretanto, o gestor de projetos deve entender que,
ao executar o trabalho e tomar decisões, as pessoas podem cometer erros e fracassar.
Se o gestor de projetos não aceita erros, ele induz as pessoas à procurá-lo para revisar e
aprovar todas as pequenas coisas que fazem. Esse medo de errar intimidará a equipe do
projeto. Uma delegação eficaz exige que o gestor tenha confiança em cada membro da
equipe do projeto.
No momento em que a equipe do projeto estiver executando suas tarefas, o gestor de
projetos deve deixá-la trabalhar. No entanto, ele deve estar disponível para instruir e ad-
vertir as pessoas quando necessário. Um gestor de projetos eficaz toma cuidado para não
tirar a autonomia das pessoas, dando ordens, dizendo como as coisas devem ser feitas ou
tomando decisões no lugar delas. Em vez disso, o gestor deve demonstrar confiança na
capacidade dos membros da equipe e encorajá-los.

30. Uma delegação eficaz exige que o
gestor de projetos tenha _____________
em cada membro da equipe do projeto.
A delegação exige que as pessoas sejam responsáveis por alcançar os resultados es-
perados de suas tarefas. Para auxiliar os membros da equipe a controlar seus esforços de
trabalho, o gestor precisa instalar um sistema de controle e de informação para a gestão do
projeto. Esse sistema dever manter informados o gestor de projetos e a equipe e auxiliar
na tomada de decisão. O sistema pode incluir uma rotina de relatório de informação com-
putadorizado e o requisito de que sejam feitas reuniões regulares com a equipe ou com os
membros individuais para verificação do progresso. Esse sistema deve focar a mensuração
e avaliação do progresso relativamente aos resultados esperados de cada tarefa, e não so-
mente o monitoramento dos recursos utilizados. O gestor deve se interessar em saber se
o escopo do trabalho para cada tarefa está progredindo de acordo com o plano e se será
concluído dentro do orçamento disponível e no cronograma exigido. O gestor não pode
encarar a informação de que “a equipe trabalhou até às 22h todos os dias da semana”
como um sinal de que o trabalho está em ordem. O gestor mostra aos membros da equipe
que a delegação exige que eles sejam responsáveis por alcançar os resultados esperados
e não somente por se manter ocupados. As pessoas com autonomia aceitam essa respon-
sabilidade. Ao monitorar o progresso, o gestor de projetos deve estimular os membros da
equipe, mostrando seu interesse sincero no trabalho deles e reconhecendo e apreciando o
progresso da equipe.

31. A delegação exige que as pessoas
sejam _______________ em alcançar os
resultados esperados.
A seguir, estão alguns dos obstáculos mais comuns que uma delegação eficaz pode en-
contrar e o que pode ser feito para superá-los.
• O gestor de projetos tem interesse por uma tarefa ou por coisas que ele acredita fazer
melhor ou mais rápido. Nesse caso, ele deve se conter e ter mais confiança nas outras
pessoas. Um gestor de projetos precisa entender que os outros podem fazer as coisas
não exatamente do mesmo modo que ele faria.
• O gestor de projetos não confia na capacidade dos outros para realizar o trabalho.
Nesse caso, ele deve ter certeza de que conhece as capacidades, o potencial e as limi-
tações de cada membro da equipe do projeto ao selecionar a pessoa mais adequada
para cada tarefa.
• O gestor de projetos tem medo de perder o controle do trabalho e não saber o que
está acontecendo. Nesse caso, ele deve estabelecer um esquema regular de monito-
ramento e avaliação do progresso em direção aos resultados esperados.
• Os membros da equipe temem uma repreensão se cometerem erros ou não têm
autoconfiança. Nesse caso, o gestor de projetos tem de mostrar confiança em cada
membro, dar incentivos com regularidade e entender que os erros são oportunidades
para aprender, e não motivos para repreensões.
A Figura 10.1 mostra diversos níveis de delegação. O sexto nível representa a total
autonomia da equipe do projeto. Na maioria das vezes, o gestor de projetos deve delegar
FIGURA 10.1 Graus de Delegação
Grau mais Baixo Investigue o problema. Forneça-me todos os fatos,

de Delegação e eu decidirei o que fazer e quem irá fazê-lo.
Investigue o problema. Forneça-me todas as

alternativas possíveis e eu recomendarei uma.
Eu as avaliarei e decidirei o que fazer.
Diga-me qual medida você gostaria de adotar.

Espere por minha aprovação.
Investigue o problema. Diga-me qual medida

você irá tomar. Faça-o, a menos que eu diga não.
Investigue o problema e adote uma medida.

Informe-me sobre o que você fez.
Grau mais Alto Investigue o problema e adote uma medida.

de Delegação Você decide se é necessário ou não me informar.
nesse nível. No entanto, pode haver situações que exijam um grau menor de delegação. Por
exemplo, um nível inferior de delegação pode ser recomendável se houver um problema
crítico para se atingir o objetivo do projeto, quando, por exemplo, os custos ultrapassam
de modo significativo o orçamento ou ocorrem falhas constantes no teste de um protótipo.
Da mesma forma, pode ser conveniente um menor nível de delegação se a pessoa estiver
realizando uma tarefa muito desafiadora.
A Figura 10.2 é uma lista de verificação para avaliar sua eficiência de delegação. Ela
pode ser usada pelo gestor de projetos como um instrumento de auto-avaliação. Ele tam-
bém pode pedir que a equipe responda à lista para dar um feedback sobre sua delegação.
Em qualquer um dos casos, o gestor de projetos deve se esforçar para melhorar nos aspec-
tos que forem mal avaliados.
GERINDO MUDANÇAS
Em um projeto, a única coisa que você pode ter certeza é que ocorrerão mudanças. Mesmo
nos planos mais bem programados podem haver mudanças, as quais podem ser:
• iniciadas pelo cliente;
• iniciadas pela equipe do projeto;
• causadas por imprevistos durante a execução do projeto;
• exigidas pelos usuários dos resultados do projeto.
FIGURA 10.2 Lista de Verificação de Delegação
Quão eficaz você é para delegar?

Nem um pouco Um pouco Muito
1. Sua equipe tem uma compreensão clara

dos resultados esperados? 1 2 3 4 5
2. Sua equipe tem todos os recursos necessários
para cumprir com o que foi delegado? 1 2 3 4 5
3. Você se concentra nos resultados esperados
dos membros da equipe em vez de nos detalhes
de como eles fazem seu trabalho? 1 2 3 4 5
4. Você tem um sistema para acompanhar
e monitorar o progresso? 1 2 3 4 5
5. Os membros da equipe compreendem como e quando
devem lhe informar sobre seu progresso e quando devem
buscar sua orientação? 1 2 3 4 5
6. Sua equipe entende como o progresso será mensurado
e avaliado? 1 2 3 4 5
7. Sua equipe pode conversar com você livremente sobre
problemas sem temer críticas? 1 2 3 4 5
8. Os membros da equipe sentem que têm liberdade para
fazer seu trabalho sem que você os gerencie
de forma excessiva? 1 2 3 4 5
9. Os membros da equipe sentem que podem fazer seu
trabalho sem medo de cometer erros? 1 2 3 4 5
10. Você incentiva os membros da equipe a tomar
decisões dentro do nível de autoridade
que você lhes delegou? 1 2 3 4 5
11. Você fornece orientação quando é necessário? 1 2 3 4 5
12. Você estimula e dá apoio às sugestões de sua equipe? 1 2 3 4 5

32. As mudanças podem ser iniciadas
pelo ___________ ou pela ____________
ou pode ser causada por _____________
durante a realização do projeto.
Um aspecto importante do trabalho do gestor de projetos é gerir e controlar mudan-

ças para minimizar qualquer impacto negativo sobre a realização com sucesso do objetivo
do projeto. Algumas mudanças são triviais, mas outras podem afetar significantemente
o escopo, o orçamento ou o cronograma do trabalho. Decidir mudar a cor de um cômodo
antes de pintá-lo é uma mudança trivial. Optar por um sobrado depois de o empreiteiro já
ter terminado a construção da estrutura para uma casa térrea é uma mudança de maior im-
portância, que certamente aumentaria o custo do projeto e provavelmente atrasaria a data
de conclusão.

33. O trabalho do gestor de projetos é
________________ e ________________
as mudanças para ________________
qualquer impacto negativo sobre a
realização com sucesso do objetivo do
projeto.
O impacto de uma mudança sobre a realização do objetivo do projeto pode ser alterado
quando esta é identificada durante o projeto. Geralmente, quanto mais tarde as mudanças
são identificadas no projeto, maiores são os efeitos sobre a realização do objetivo do projeto.
Os aspectos mais prováveis de serem afetados são o orçamento e a data de conclusão. Isso
ocorre principalmente quando o trabalho que já foi realizado precisa ser “desfeito” para se
adaptar à mudança exigida. Por exemplo, sairia muito caro mudar a tubulação e a fiação da
construção de um escritório depois que as paredes e o teto foram terminados, já que seria
preciso refazer uma ou mais paredes antes de instalar novos tubos e fios. No entanto, se
essa mudança fosse feita no início do projeto – por exemplo, quando a construção estivesse
sendo projetada –, a adaptação seria mais fácil e menos custosa. As plantas seriam alteradas
para que as instalações fossem executadas corretamente na primeira vez.
No início do projeto, deve-se estabelecer os procedimentos referentes à maneira como
as mudanças serão documentadas e autorizadas. Esses procedimentos devem incluir a co-
municação entre o gestor do projeto e o cliente e entre o gestor e a equipe do projeto. Se
as mudanças forem acordadas oralmente em vez de por escrito e se não houver nenhuma
indicação do impacto que estas terão no escopo, no orçamento ou no cronograma do pro-
jeto, o custo do projeto pode ser maior que o esperado, e o cronograma pode atrasar mais
que o previsto. Imaginemos, por exemplo, que o sr. Silva ligue para o empreiteiro contrata-
do e peça que seja acrescentada uma lareira na casa que está sendo construída. Baseado na
autorização oral, o empreiteiro instala a lareira e a chaminé. Depois, quando ele o informa
do custo adicional, o sr. Silva fica chocado.
– Você deveria ter me contado antes de realizar o trabalho, diz o sr. Silva.
– Mas o senhor me disse para fazer isso. Parecia que estava mesmo decidido, replica o
empreiteiro.
– Bom, eu não vou pagar isso tudo! É um valor exorbitante!, responde o sr. Silva. E a
discussão continua.
Sempre que um cliente exigir mudanças, o gestor de projetos deve pedir que os mem-
bros apropriados da equipe estimem os efeitos sobre o custo e o cronograma do projeto.
O gestor de projetos deve, em seguida, apresentar essas estimativas para o cliente e exigir sua
aprovação antes de prosseguir. Se o cliente concordar com as mudanças, o cronograma e o
orçamento do projeto devem ser alterados para incorporar as tarefas e os custos adicionais.
Às vezes, os clientes tentam conseguir que algumas mudanças sejam feitas gratuitamente,
fazendo-as parecer triviais ou ludibriando o gestor do projeto ao negociar somente com um
dos membros da equipe. O gestor de projetos precisa ter certeza de que os membros da
equipe não concordarão com mudanças que possam exigir mais pessoas/horas e provocar
o risco de ultrapassar o orçamento de uma tarefa em especial ou de todo o projeto.

34. No início do projeto, o gestor de
projetos deve estabelecer ___________
_______ referentes à maneira de como
as mudanças serão ________________ e
________________.
Às vezes, as mudanças são iniciadas pelo gestor de projetos ou por sua equipe. Por
exemplo, suponha que um membro da equipe apareça com uma nova abordagem que uti-
liza um tipo de sistema computacional diferente do que o cliente queria originalmente e vai
reduzir substancialmente o custo do projeto. Nesse caso, o gestor de projetos apresentaria
uma proposta para a mudança e obteria a aprovação do cliente antes de fazer tal mudança.
O cliente provavelmente aprovaria a mudança se os custos forem reduzidos sem causar
nenhuma piora no desempenho do sistema. No entanto, ele pode não concordar se o ges-
tor de projetos lhe pedir a prorrogação da data de conclusão do projeto ou mais recursos
financeiros porque a equipe do projeto encontrou dificuldades causadas por um atraso no
cronograma ou um excesso de custos. O contratante pode ter de aceitar o excesso de custos
ou gastar dinheiro extra para acrescentar mais recursos temporariamente e levar o projeto
de volta ao cronograma esperado.
O gestor de projetos precisa deixar claro para a equipe que nenhuma mudança no tra-
balho deve ser feita se aumentar os custos além do que foi orçado, atrasar o cronograma
ou produzir resultados que não atendam às expectativas do cliente. Por exemplo, em um
projeto técnico, um engenheiro de software pode considerar que agradaria o cliente se fi-
zesse uma pequena otimização no software, além do exigido. No entanto, ele não agradaria
o gestor de projetos gastando dinheiro com um monte de “pequenas otimizações” que são
“legais”, mas desnecessárias!
Algumas mudanças se tornam necessárias por causa de imprevistos, como uma tempes-
tade que inunda o canteiro de obras de um edifício, a não aprovação de um novo produto
em testes ou o falecimento repentino ou demissão de um membro importante da equipe.
Esses acontecimentos terão um impacto no cronograma ou no orçamento e exigirão modi-
ficações no plano do projeto. Em alguns casos, os imprevistos podem levar o projeto a ser
abandonado. Por exemplo, se os resultados dos testes iniciais de um projeto de pesquisa
para desenvolvimento de um material cerâmico avançado não são satisfatórios, a empresa
pode decidir interromper o projeto em vez de gastar mais dinheiro sem ter nenhuma chance
de sucesso.
Talvez o tipo de mudança mais difícil de gerir seja a exigida pelos usuários dos resul-
tados do projeto. Em algumas situações, o gestor de projetos é responsável não só por
gerenciar o desenvolvimento de um sistema novo ou melhorar o sistema existente, mas
também por implementar o sistema resultante para os usuários, que terão de mudar o modo
como eles realizam o trabalho. Por exemplo, em um projeto para conceber, desenvolver
• Gestores de projetos bem-sucedidos aceitam a responsabilidade de garantir que o

cliente fique satisfeito e que o escopo do trabalho seja concluído com qualidade e
dentro do orçamento e do prazo.
• O gestor de projetos precisa ser proativo no planejamento, na comunicação e no
fornecimento de liderança à equipe para que o objetivo do projeto seja alcançado.
• O gestor de projetos precisa inspirar a equipe de projeto a ter sucesso e a ganhar a
confiança do cliente.
• Ao envolver a equipe no desenvolvimento do plano do projeto, o gestor de projetos
garante a elaboração de um plano mais abrangente e ganha o comprometimento
da equipe para realizá-lo.
• Gestores de projetos bem-sucedidos são proativos no tratamento de problemas. Eles
não têm um comportamento do tipo: “vamos esperar e ver como as coisas saem”.
• O gestor de projetos precisa ter um sistema de informação para a gestão do projeto
que diferencie o empenho da equipe de resultados reais.
• Gestores de projetos eficazes têm forte capacidade de liderança, habilidade para
desenvolver pessoas, excelentes habilidades de comunicação, boas habilidades interpes-
soais, capacidade para lidar com o estresse, resolver problemas e gerir o tempo.
• A gestão eficaz de projetos requer um estilo de liderança participativa e consultiva,
no qual o gestor oferece orientação e aconselhamento à equipe. O gestor eficaz de
projetos não diz às pessoas como fazer seu trabalho.
• Os gestores de projeto demonstram que valorizam as contribuições de membros
da equipe ao buscar seus conselhos e sugestões.
• Os gestores de projetos podem estimular a motivação por meio do reconhecimento.
As pessoas querem sentir que estão dando sua contribuição e precisam ser reco-
nhecidas. O reforço positivo ajuda a estimular o comportamento desejado; o com-
portamento que é reconhecido ou recompensado se repete.
• O gestor eficaz de projetos não monopoliza, não busca os “holofotes” nem tenta
levar o crédito pelo trabalho dos outros.
• Gestores de projetos competentes são otimistas e têm expectativas altas, porém
realistas, em relação a si mesmos e a cada pessoa da equipe do projeto.
• Os projetos devem ser prazerosos. Os gestores devem apreciar seu trabalho e in-
centivar a mesma atitude positiva por parte dos membros da equipe. O gestor do
projeto deve dar um exemplo positivo para a equipe em termos de comportamen-
to esperado.
• Um bom gestor de projetos fornece oportunidades para aprendizado e desenvol-
vimento, incentivando os membros da equipe a tomar iniciativas, assumir riscos e
tomar decisões. Em vez de criar o medo do fracasso, o gestor percebe que os erros
fazem parte do processo de aprendizado e da experiência de crescimento.
• Bons gestores de projetos passam mais tempo ouvindo que falando. Eles escutam
as necessidades expressas pelo cliente e as idéias e preocupações da equipe de
projeto.
• A comunicação por parte dos gestores de projetos precisa ser oportuna, honesta e
sem ambigüidades.
• O gestor de projetos deve criar uma atmosfera que promova a comunicação aberta
e oportuna, sem medo de represália e ser compreensivo em relação a pontos de
vista diferentes.
• Quando eventos imprevistos causam tumulto em um projeto, os gestores de proje-

tos eficazes permanecem tranqüilos; não entrando em pânico.
• Para usar seu tempo de forma eficaz, os gestores de projetos precisam ter autodis-
ciplina, serem capazes de priorizar e estarem dispostos a delegar.
• No início de um projeto, o gestor precisa estabelecer procedimentos sobre como as
mudanças serão documentadas e autorizadas.
e implementar um novo sistema informatizado de cobrança, faturamento e pedidos que

substitua os sistemas manuais em uso, o gestor de projetos pode ser responsável não só
por gerenciar o projeto de concepção e desenvolvimento do novo sistema, mas também
por fazer os usuários entenderem a mudança do sistema manual antigo para o novo sistema
informatizado.
Há algumas coisas que o gestor de projetos pode fazer para facilitar a implementação de
uma mudança. Uma comunicação mais aberta e um clima de confiança são pré-requisitos
para realizar alterações, diminuir a resistência a mudanças e ganhar a confiança das pes-
soas para fazê-las. É importante obter o apoio e a confiança dos usuários com relação ao
novo sistema, e não somente a aceitação de que eles precisam de um sistema melhor. O
gestor de projetos precisa compartilhar informações sobre a mudança com os usuários. Essa
comunicação tem de ser feita com prontidão, de modo integral, com honestidade e regular-
mente. Isso significa que o gestor de projetos deve promover discussões com os usuários
antes que o novo sistema seja desenvolvido, e não esperar que ele esteja pronto para ser
implementado. Falar sobre o sistema no início do projeto ajuda a evitar boatos. O gestor de
projetos precisa contar aos usuários por que a alteração está sendo feita e quais serão seus
efeitos e benefícios. Eles precisam acreditar que serão beneficiados. Caso contrário, temerão
a mudança em vez de apoiá-la.
As discussões e reuniões são uma boa oportunidade para as pessoas expressarem suas
preocupações, medos e ansiedades. A ansiedade e o medo do desconhecido podem causar
estresse nas pessoas e criar resistência a mudanças. Nas reuniões de discussão de uma mu-
dança iminente, o gestor de projetos não deve favorecer polêmicas ou ser defensivo, mas,
sim, mostrar empatia com relação às preocupações e medos das pessoas, em vez de ignorar
ou banalizar esses sentimentos. Se possível, o gestor de projetos deve levar os usuários a
participar da decisão de mudar, por exemplo, de um sistema manual para um informatiza-
do. Ele ainda deve envolvê-los no planejamento e concepção do sistema. Afinal, são eles
os usuários. O gestor de projetos pode oferecer suporte e compensações para ajudar a
assegurar o êxito da implementação do novo sistema. Uma compensação pode ser um trei-
namento de informática, que levará os usuários a se sentir mais instruídos e valorizados. Por
último, o gestor de projetos precisa ser paciente. Os benefícios esperados serão atingidos
somente quando o novo sistema estiver sendo totalmente utilizado.
Sempre vão ocorrer alterações nos projetos. O gestor de projetos tem de gerir e controlar
essas mudanças, de maneira que o projeto não fique fora de controle.
RESUMO
É responsabilidade do gestor de projetos certificar-se de que o cliente está satisfeito com
uma conclusão do escopo de trabalho com qualidade, dentro do orçamento e do prazo.
O gestor de projetos tem a responsabilidade principal pela liderança no planejamento, na
organização e no controle dos esforços despendidos para alcançar o objetivo. Em termos
de planejamento, o gestor tem de definir claramente o objetivo do projeto e chegar a um
acordo com o cliente sobre esse objetivo. Em termos de organização, o gestor de projetos
deve assegurar os recursos apropriados para a realização do trabalho. Em termos de contro-

le, o gestor de projetos precisa acompanhar o progresso real e compará-lo com o progresso
planejado.
O gestor de projetos é um elemento-chave para o sucesso de um projeto e precisa ter
um conjunto de habilidades que ajudem a equipe do projeto a ter sucesso. O gestor de pro-
jetos precisa ser um bom líder que inspira as pessoas a trabalhar como uma equipe, a fim de
implementar o plano e alcançar o objetivo do projeto com êxito; deve ter compromisso com
o treinamento e o desenvolvimento das pessoas que trabalham no projeto; ser um comuni-
cador eficaz que interage regularmente com a equipe do projeto, assim como com qualquer
pessoa terceirizada, com o cliente e com a alta direção da própria empresa; e ter boas ha-
bilidades interpessoais. É importante que o gestor de projetos desenvolva uma relação com
cada pessoa da equipe do projeto e saiba usar eficientemente suas habilidades interpessoais
para tentar influenciar o pensamento e as ações das outras pessoas. Um gestor de projetos
eficaz deve lidar com o estresse e ter um bom senso de humor. Além disso, deve ser um
bom solucionador de problemas. Embora seja mais fácil identificar problemas do que re-
solvê-los, um bom solucionador de problemas começa com a identificação antecipada do
problema ou de um problema em potencial. Os bons gestores de projetos também sabem
administrar bem o tempo.
Essas habilidades fundamentais podem ser desenvolvidas com a experiência, procurando
o feedback dos outros, fazendo uma auto-avaliação e aprendendo com os próprios erros,
observando gestores eficazes de projetos, participando de programas de treinamento, en-
trando para organizações da área, lendo e também por meio de trabalho voluntário em
organizações em que essas habilidades possam ser testadas.
Os gestores de projetos precisam ser bons delegadores. A delegação implica capacitar
a equipe para alcançar o objetivo do projeto e capacitar cada membro para atingir os re-
sultados esperados de sua área de responsabilidade. É o ato de permitir que as pessoas
executem com sucesso as tarefas a elas atribuídas.
Outro componente importante do trabalho do gestor de projetos é gerir e controlar mu-
danças para minimizar qualquer impacto negativo sobre a realização com sucesso do obje-
tivo do projeto. Para conseguir isso, o gestor, no início do projeto, deve estabelecer proce-
dimentos referentes à maneira como as mudanças serão documentadas e autorizadas.
PERGUNTAS
1. Descreva o que o gestor de projetos deve fazer para executar a função de planejamento.
Dê alguns exemplos.
2. Descreva o que o gestor de projetos deve fazer para executar a função de organização.
Dê alguns exemplos.
3. Descreva o que o gestor de projetos deve fazer para executar a função de controle. Dê
alguns exemplos.
4. Quais são as habilidades fundamentais para um gestor de projetos eficaz? Como essas
habilidades podem ser desenvolvidas?
5. Descreva por que um gestor de projetos precisa de boas habilidades de comunicação
oral e escrita.
6. O que o termo habilidades interpessoais significa? Dê alguns exemplos de habilidades
interpessoais e explique por que elas são importantes.
7. Quais são algumas das ações do gestor de projetos que podem ajudar a criar um am-
biente no qual a equipe do projeto se sinta motivada?
8. O que o termo delegação significa? Por que a delegação é essencial para a gestão de
projetos? Dê alguns exemplos.
9. Quais são os obstáculos para uma delegação eficaz?

10. Por que é importante gerir mudanças durante um projeto? Como se inicia uma mudan-
ça? Dê alguns exemplos.
11. Descreva algumas maneiras como um gestor de projetos pode fazer um projeto ficar
mais prazeroso e os membros da equipe mais comprometidos com o projeto.
12. Pense em um projeto em que você está trabalhando atualmente. Descreva o que fez
o gestor desse projeto ser eficaz ou ineficaz. Como ele poderia ter feito um trabalho
melhor?
~clements.
1. Jerry Madden, diretor associado do Diretório de Projetos de Vôo do Centro de Vôos
Espaciais de Goddard, na Nasa, compilou um website excelente, que relaciona cem
regras para gestores de projeto da Nasa. As regras abrangem uma grande variedade
de áreas, incluindo comunicação, tomada de decisões, ética e falhas. O endereço do
site é: http://web.mit.edu/pm/100rules.html.
2. Busque na web idéias sobre liderança. Com base em sua pesquisa, descreva breve-
mente o estilo de liderança e algumas sugestões de um de seus líderes favoritos.
3. Pesquise na Internet idéias sobre delegação eficaz. Descreva o que encontrou. Como
isso se relaciona aos tópicos apresentados neste capítulo?
4. Visite a página do Project Management Institute, no endereço: http://www.pmi.org.
Explore o link Career Headquarters. Descreva pelo menos três dos cargos de gestão
de projetos anunciados lá.
5. Visite a página do Project Management Institute, no endereço: http://www.pmi.org.
Na área de Membership, imprima e resuma o Código de Ética dos Associados (Mem-
ber Code of Ethics).
ESTUDO DE CASO Nº 1 Codeword

Codeword é uma empresa de médio porte que projeta e fabrica sistemas eletrônicos para
aeronaves militares. Ela concorre com outras empresas, a fim de ganhar contratos para o
fornecimento desses sistemas. Seu principal cliente é o governo. Quando recebe um contra-
to, a Codeword cria um projeto para realizar o trabalho. A maioria dos projetos varia de 10
a 50 milhões de dólares em termos de custos; sua duração costuma ser de um a três anos. A
Codeword pode ter de 6 a 12 projetos sendo realizados em um determinado momento, em
vários estágios de conclusão – alguns que acabaram de começar e outros em fase final.
A Codeword tem vários gestores de projetos que se reportam ao gestor geral; outras
pessoas se reportam ao seu gestor funcional. Por exemplo, todos os engenheiros eletrôni-
cos se reportam a gestor de engenharia eletrônica, que se reporta ao gestor geral. O gestor
funcional designa pessoas específicas para trabalhar em vários projetos. Algumas pessoas
trabalham em período integral em um projeto, enquanto outras dividem seu tempo entre
dois ou três projetos. Embora as pessoas sejam designadas para trabalhar para um gestor de
projetos em um projeto específico, do ponto de vista administrativo, elas ainda se reportam
a seu gestor funcional.
Jack Kowalski trabalha na empresa há cerca de oito anos, desde que se formou em en-
genharia eletrônica. Ele foi promovido até chegar a gestor eletrônico sênior e se reporta ao
gestor de engenharia elétrica. Ele trabalhou em vários projetos e é muito respeitado dentro
da empresa. Jack vem pedindo uma oportunidade para trabalhar como gestor de projetos.
Quando a Codeword fecha um contrato de US$ 15 milhões para projetar e construir um

sistema eletrônico avançado em uma nova aeronave, o gestor geral promove Jack a gestor
de projeto e pede que ele conduza o projeto.
Jack trabalha com os gestores funcionais a fim de conseguir as melhores pessoas disponí-
veis para atuar no projeto. A maioria delas são colegas que trabalharam com Jack em pro-
jetos anteriores. Contudo, com o cargo de engenheiro eletrônico sênior vago, o gestor de
engenharia elétrica não tem ninguém com o nível apropriado de experiência para designar
para o projeto de Jack. Então o gestor contrata uma nova pessoa, Alfreda Bryson. Tirada
de um concorrente, ela tem Ph.D. em engenharia eletrônica e 20 anos de experiência. Ela
conseguiu arrematar um belo salário – maior que o de Jack. Ela é designada para o projeto
de Jack em tempo integral, como engenheira eletrônica sênior.
Jack desenvolve um interesse especial pelo trabalho de Alfreda e pede que ela se reúna
com ele, a fim de discutirem suas abordagens para a concepção. Contudo, a maioria dessas
reuniões se transforma em monólogos, com Jack sugerindo como Alfreda deveria fazer a
concepção do sistema e dando pouca atenção ao que ela diz.
Finalmente, Alfreda pergunta a Jack por que ele está gastando muito mais tempo revi-
sando o trabalho dela do que o de outros engenheiros no projeto. Ele responde: “Não tenho
de checar o trabalho deles. Sei como, pois estive trabalhando com eles em outros projetos.
Você é nova aqui, e quero ter a certeza de que entende a forma como fazemos as coisas,
que pode ser diferente do modo que você fazia em seu emprego anterior”.
Outra ocasião, Alfreda mostra a Jack o que ela acredita ser uma abordagem de con-
cepção criativa que resultaria em um sistema de custo mais baixo. Jack diz a ela: “Eu nem
sequer tenho Ph.D., mas posso ver que isso não funciona. Não seja tão esotérica; fique
apenas com a boa engenharia básica.”
Durante uma viagem a negócios com Dennis Freeman, outro engenheiro designado
para o projeto e que conhece Jack há seis anos, Alfreda diz que está frustrada com a for-
ma como Jack a trata. “Jack está agindo mais como o engenheiro eletrônico do projeto que
como gestor do projeto”, ela diz a Dennis. “Além do mais, eu já me esqueci mais sobre a
concepção de produtos eletrônicos do que Jack jamais soube! Ele não está nem um pouco
atualizado sobre as metodologias de concepção de eletrônicos.” Ela também diz a Dennis
que está planejando discutir o assunto com o gestor de engenharia eletrônica e que jamais
teria aceito o emprego na Codeword se soubesse que seria assim.
PERGUNTAS
1. Você acha que Jack está pronto para atuar como gestor de projetos? Por quê? Como ele
poderia ter se preparado para esse novo papel?
2. Qual é o maior problema na forma como Jack interage com Alfreda?
3. Por que você acha que Alfreda não teve uma discussão aberta com Jack sobre a forma
como ele a trata? Se ela o abordasse diretamente, como você acha que ele reagiria?
4. Como você acha que o gestor de engenharia eletrônica resolverá essa situação? O que
ele deve fazer?
ATIVIDADE EM GRUPO
Os participantes do curso devem ser divididos em grupos de quatro ou cinco para discutir
as seguintes perguntas:
• O que deve ser feito para remediar a situação?
• O que poderia ter sido feito para evitar essa situação?
Em seguida, cada grupo deve eleger um porta-voz e apresentar suas conclusões para a
turma toda.
ESTUDO DE CASO Nº 2 Uma Empresa de E-Business em

Crescimento
Ivana é proprietária da ICS, Inc., uma firma de consultoria de sistemas de informação com
20 funcionários. Eles basicamente concebem e implementam projetos de tecnologia de in-
formação para empresas de pequeno e médio portes na região metropolitana. Embora a ICS
tenha um nível suficiente de negócios, o ambiente está se tornando mais competitivo à me-
dida que mais empresários estão abrindo as próprias empresas de consultoria de tecnologia
da informação. Ivana faz toda a parte de marketing para a ICS e é o principal contato entre
a firma e seus clientes.
A ICS acabou de receber um contrato de uma empresa que faz parte do ranking da
Fortune 100, para conceber e implementar um sistema de e-business para um de seus
centros de distribuição. A empresa bateu vários concorrentes, incluindo algumas firmas
nacionais de consultoria de maior porte, ao ganhar esse contrato. Isso se deveu em parte
ao fato de a ICS elaborar uma proposta com os preços mais baixos possíveis e de Ivana
prometer ao cliente que o projeto seria concluído em seis meses, ainda que o cliente tenha
especificado que este precisava ser concluído em nove meses ou menos. Ela sabe que, se
a ICS concluir esse projeto com sucesso e provar que pode bater o cronograma esperado
pelo cliente, isso levaria a um contrato maior para implementar sistemas semelhantes nos
outros centros de distribuição do cliente em todo o país.
Assim que soube que a ICS tinha ganhado o contrato, Ivana ligou para oito de seus fun-
cionários, com os quais ela gostaria de trabalhar no projeto. “Alguns de vocês podem não
saber, mas eu enviei uma proposta para um cliente muito importante, o maior que já tive-
mos, para implementar um sistema de e-business para um de seus centros de distribuição.
Esse é um projeto muito importante para mim porque, se tivermos sucesso, haverá outros
projetos futuros com esse cliente, e a ICS pode se tornar uma grande firma de consultoria
– que é o meu sonho. Devo dizer-lhes que se trata de um contrato de preço global e que re-
duzi nosso preço ao máximo para aumentar nossas chances de ganhar o contrato. Também
prometi a eles que poderíamos concluir o projeto em seis meses, ainda que tenham ficado
satisfeitos com nove meses. Então, quero ser bastante clara com todos vocês, esse projeto é
muito importante para mim e para a ICS; portanto, espero que cada um gaste o tempo que
for necessário para realizá-lo no prazo. Vocês terão de rearranjar o resto de seu trabalho
nesse meio tempo. E, gostaria de enfatizar, erros não serão tolerados. Há muita coisa em
risco. Preciso sair para um almoço de negócios agora. Mas aqui estão cópias da proposta
que enviei. Analisem-na e depois se reúnam para começar a executá-la.
Enquanto saíam da sala de reunião, Patrick, designer de sistemas, disse: “Vamos todos
ler a proposta e nos reunirmos por volta das 9 horas amanhã para estabelecermos quem
precisa fazer o quê”.
Ivana ouviu o comentário de Patrick e se manifestou: “Amanhã? Talvez vocês não te-
nham percebido quão importante esse projeto é para mim. Sugiro que leiam a proposta
agora e reúnam-se hoje à tarde ou à noite”.
Ester, programadora, disse: “Tenho uma consulta no meu obstetra esta tarde para meu
check-up de seis meses”.
Ivana rapidamente respondeu: “Bem, você terá de remarcar a consulta. O bebê não vai
nascer nos próximos três meses mesmo. Qual é o problema? Minha mãe teve cinco filhos
com uma parteira, sem médico, e todos sobrevivemos”.
Quando Ivana foi embora, Ester, com lágrimas nos olhos, disse a Harvey, também pro-
gramador: “Que bruxa! Se eu não precisasse dos benefícios do plano de saúde, pediria
demissão hoje”.
O grupo reuniu-se à tarde. Patrick tomou as rédeas da discussão, por ser o funcionário
mais antigo. Harvey, o outro designer de sistemas do grupo, um dos mais novos e jovens,
perguntou: “Patrick, você vai ser um tipo de líder desse projeto?”.
“As coisas não funcionam exatamente assim por aqui. Nós todos sabemos quem é a
verdadeira gestora de projetos, não é?”, respondeu Patrick. E a maioria do grupo respondeu
em uníssono: “Ivana!”. E todos riram.
Enquanto o grupo discutia a proposta, várias perguntas foram surgindo. E havia uma
diferença de opinião entre Patrick e Harvey em relação à abordagem para a concepção
do sistema. A visão de Patrick era menos arriscada, mas poderia levar mais tempo; a abor-
dagem de Harvey era mais arriscada, mas levaria menos tempo, caso funcionasse. Patrick
disse: “Vou tentar me reunir com Ivana amanhã de manhã e obter algumas respostas, se
isso for possível”.
“Talvez devêssemos todos nos reunir com ela”, disse Harvey.
“Ivana não é muito fã de reuniões longas com muita gente. Ela acha que isso é desper-
diçar o tempo de todos”, respondeu Patrick.
Patrick se reuniu com Ivana na manhã seguinte. “Bem, todo mundo já sabe o que fa-
zer?”, perguntou ela.
“Na verdade, ontem, ficamos até tarde da noite discutindo a proposta e temos algumas
perguntas. A proposta pareceu ambígua em alguns..”..
Ivana interrompeu: “Ambígua? O cliente não achou que estava ambígua. Eu não acho
que esteja ambígua. Então me diga por que você acha que está ambígua”.
“Bem, por exemplo, Harvey e eu pensamos em dois esquemas de concepção diferentes;
um mais arriscado, mas que levaria menos tempo, o outro menos arriscado, mas que pode-
ria demorar mais tempo”, afirmou Patrick.
“Uma reunião e vocês ficam discutindo uns com os outros feito crianças”, Ivana disse
rispidamente. “Vocês nunca ouviram falar de trabalho em equipe? O que eu quero é o se-
guinte: menos arriscado em menos tempo. Sem ‘deveria’, ‘poderia’, ‘levaria’. Vocês dois têm
de descobrir um jeito e não perder mais tempo. Por que eu sempre tenho de tomar todas
as decisões aqui? E mais, não tenho o dia todo. E fico feliz em saber que todos estavam
dispostos a trabalhar até tarde, porque esse é o tipo de compromisso que precisaremos para
entregar esse projeto a tempo. Você sabe, eu pago salários altos, mas espero que as pessoas
façam o que for preciso para entregar o trabalho. E, se alguém não conseguir lidar com
isso, pode tentar encontrar emprego em outro lugar. Vão ver que a grama do vizinho nem
sempre é mais verde”.
Quando Patrick se virou e saiu de seu escritório, Ivana disse: “Aliás, como recompensa
por ter ganhado o contrato, vou me dar férias de duas semanas na Europa. E diga aos outros
que, quando voltar, espero encontrar o projeto em perfeito andamento e sem brigas”.
Mais tarde, quando Ivana andava pelo corredor, ela viu Ester e disse: “Suponho que
você tenha conseguido remarcar aquela consulta”.
Ester respondeu: “Sim, mas só para daqui a duas semanas. Vai ser difícil conseguir man-
ter o ritmo de trabalho nesses últimos três meses”.
“Difícil?”, respondeu Ivana. “Deixe-me dizer a você o que é difícil. Ajudei a criar meus
quatro irmãos mais novos depois que minha mãe morreu dando à luz minha irmã caçula.
Depois batalhei para fazer faculdade, tendo aulas à noite por quase dez anos enquanto
cuidava de meus quatro filhos. Então, da próxima vez que achar que está difícil para você,
pense em quão difícil foi para outras pessoas também. Espero que consiga fazer a maior
parte do seu trabalho no projeto antes que o bebê nasça. Estou contando com você”.
Por volta das 18 horas, Harvey passou no escritório de Ivana. “Tem um minuto?”, ele
perguntou.
“Um minuto, eu tenho”, respondeu Ivana. “Mas vou encontrar uma amiga para jantar,
então seja rápido”.
“Haverá uma conferência de informática em Las Vegas no próximo mês”, disse Harvey,
“e gostaria de saber se você me autorizaria a ir. Tem muitas coisas novas que eu poderia
aprender para nos ajudar nesse projeto”.
“Você só pode estar brincando!”, respondeu Ivana. “Você quer que eu pague para
mandar você a uma conferência, para você ficar se divertindo enquanto temos um prazo a
cumprir nesse projeto? E todos os outros vão ficar aqui se matando de trabalhar? Você não
tem noção de prioridade? Não se sente nem um pouco responsável pelo resto da equipe de
projeto? Juro, sou a única pessoa aqui que pensa em trabalho em equipe! Talvez, quando
o projeto terminar, você consiga encontrar uma conferência que seja mais próxima e mais
barata. Tenho de ir. Aliás, diga para aqueles que vão ficar até tarde hoje para desligar a
cafeteira antes de sair. Ela ficou ligada na noite passada”. Ivana, passando bruscamente por
Harvey para sair da sala, ainda murmurou: “Às vezes, eu me sinto como se tivesse de ser a
mãe de todo mundo aqui”.
PERGUNTAS
1. Considerando o estilo de gestão de Ivana, como o grupo de funcionários designado

para o projeto deveria agir?
2. Como os membros do projeto deveriam interagir com Ivana ao longo do projeto?
3. Em sua opinião, por que Ivana se comporta dessa forma?
4. Os membros do projeto devem conversar com Ivana sobre seu estilo de gestão? Em
caso afirmativo, como?
ATIVIDADE EM GRUPO
Escolha cinco alunos do curso para encenar esse caso na frente da classe. Uma pessoa será
o narrador descrevendo a cena e o desenrolar da história. Os outros quatro participantes
farão os papéis de Ivana, Patrick, Ester e Harvey e lerão suas falas.
No fim da encenação, peça que todos os alunos discutam suas respostas para as pergun-
tas relacionadas ao caso.
Capítulo A EQUIPE DE PROJETO
11 Desenvolvimento e Eficácia da
Equipe de Projeto
Estágios de Desenvolvimento e
Crescimento da Equipe
Gestão do Tempo
Resumo
Perguntas
A Equipe de Projeto Eficaz
Estudo de Caso nº 1 RD
Barreiras para a Eficácia da Processing
Equipe
Perguntas
Como Ser um Membro Eficaz
Atividade em Grupo
da Equipe
Estudo de Caso nº 2 Problemas
Construção da Equipe
em Equipes
Comportamento Ético
Perguntas
Conflito em Projetos
Atividade em Grupo
Fontes de Conflito
Lidando com Conflitos
Resolução de Problemas
Uma Abordagem em Nove Etapas
para a Resolução de Problemas
Brainstorming
310
Ca pítulo Onze
Como Escolher uma Equipe de Projeto
Na busca de Kathleen Melymuka por conselhos sobre como selecionar uma equipe de proje-
to, ela compartilha uma lição pessoal aprendida por Bill Hagerup, especialista em gestão de
projetos na Ouellette and Associates Inc., firma de consultoria em Bedford, New Hampshire.
No começo de sua carreira como gestor de projetos, Bill se recorda de participar de uma
reunião com outros gestores para escolher membros para as equipes de seus respectivos
projetos. Os gestores experientes escolheram primeiro, e Bill acabou ficando com quem
sobrou. Ele não teve uma boa experiência com sua equipe de projeto. Quando chegou o
momento de buscar uma nova equipe, ele entrou em contato com todas as pessoas que
tinham maior capacidade técnica para o novo projeto e convenceu-as a fazer parte de sua
equipe de projeto. Infelizmente, ele novamente não teve uma boa experiência com sua equi-
pe. Dessa vez, os membros altamente qualificados de sua equipe não se davam bem.
A lição que tiramos da história de Bill é que uma boa equipe de projeto precisa de uma
combinação equilibrada entre competência técnica, capacidade de trabalhar em equipe
e personalidades. Aqui vão alguns conselhos de outros gestores de projeto sobre como
escolher uma equipe:
1. Mantenha a equipe o menor possível.
Uma equipe com muitos membros que não sejam essenciais e pessoas com as
mesmas competências é difícil de gerir. A comunicação fica difícil e demorada,
principalmente com pessoas com níveis diferentes de comprometimento. Uma
gestora de projetos diz que a melhor equipe com a qual já trabalhou tinha apenas
quatro pessoas. Cada uma tinha um papel bem definido, entendia claramente os
objetivos do projeto e trabalhava de forma eficiente para atingi-los. Ela acredita
que o trabalho de uma equipe pequena é muito mais eficiente que o de grandes
equipes.
2. Encontre pessoas com atitudes e comportamentos positivos.
Um projeto provavelmente será bem-sucedido se os membros da equipe tiverem
boa ética no trabalho, forem alegres e respeitosos uns com os outros. Um membro
descrente na equipe pode aumentar o risco de fracasso do projeto. Um gestor de
projetos aconselha que, se tiver de escolher entre uma pessoa com habilidades
específicas e uma com boa atitude, a última é a melhor opção; essa pessoa será
aquela em quem a equipe pode confiar para realizar o trabalho.
3. Uma equipe diversificada pode aumentar a probabilidade de sucesso do projeto.
Para um projeto de alto risco, selecione pessoas com atitudes e estilos de tomada
de decisão diversos. Johanna Rothman, presidente da Rothman Consulting, em
Arlington, Massachusetts, diz que a tecnologia da informação tende a atrair tipos
semelhantes de pessoas. Um bom gestor de projetos deve neutralizar essa tendên-
cia. Por exemplo, um projeto muito arriscado pode tirar proveito de uma equipe
na qual alguns membros são do tipo que tomam decisões rápidas, sem considerar
alternativas, enquanto outros preferem despender tempo para investigar todas as
opções.
4. A familiaridade permite que a equipe se torne produtiva rapidamente.
Uma equipe que trabalhou bem antes saberá como estabelecer a comunicação
entre seus membros e não precisará de muito tempo para aprender os diferentes
estilos de trabalho e preferências. Lembre-se de que as pessoas são o segredo do
sucesso. Forme a equipe de projeto certa e suas chances de sucesso aumentarão!
Melymuka, K. How to Pick a Project Team. Computerworld, v. 38, edição 15, 12 de abril de 2004.
311
Uma equipe é formada por um grupo de pessoas que trabalha de forma conjunta em bus-
ca de um objetivo comum. O trabalho em equipe é o esforço cooperativo de membros
de uma equipe para alcançar esse mesmo objetivo. A eficácia ou ineficácia da equipe de
projeto podem levar ao sucesso ou ao fracasso do projeto. Embora o planejamento e as
técnicas de gestão sejam necessários, a chave para o sucesso do projeto são as pessoas
– o gestor do projeto e a equipe do projeto. O sucesso do projeto depende de uma equi-
pe eficaz. Este capítulo trata do desenvolvimento e da manutenção de uma equipe de
projeto eficaz. Você ficará familiarizado com:
• desenvolvimento e crescimento das equipes;
• características de equipes de projeto eficazes e barreiras para a eficácia;
• a construção da equipe;
• fontes de conflito durante o projeto e abordagens para lidar com esses conflitos;
• resolução de problemas;
• gestão de projetos eficaz.

1. Uma equipe é um grupo de pessoas
que trabalham _________________ para
alcançar ______________ comum.

2. Trabalho de equipe é um esforço
_________________ por parte dos
membros de uma equipe para alcançar
um objetivo _______________.
DESENVOLVIMENTO E EFICÁCIA DA EQUIPE DE PROJETO

Um relacionamento interpessoal demora a se desenvolver. No começo, ambos estão curio-
sos, um em relação ao outro, mas também apreensivos, hesitando em baixar guarda e se
abrir. Ao se conhecer um pouco, começam a perceber diferenças de valores e atitudes, o
que pode causar desentendimentos. Você fica ansioso para saber se o relacionamento vai
durar, ou se deveria durar. Ao trabalhar-se as diferenças, vocês acabam se conhecendo
melhor e tornando-se amigos. Por fim, são capazes de desenvolver uma relação próxima, o
que ajuda a se abrir um com o outro, aceitar as diferenças e gostar de praticar as mesmas
atividades juntos.
Da mesma forma, as equipes passam por vários estágios de desenvolvimento. Em muitos
projetos, pessoas que nunca trabalharam juntas são alocadas na mesma equipe de projeto. Esse
grupo precisa se tornar uma equipe eficaz, para que o objetivo do projeto seja alcançado
com sucesso.
Estágios de Desenvolvimento e Crescimento da Equipe

B.W. Tuckman dividiu o desenvolvimento de uma equipe em quatro estágios: formação,
agitação, normalização e execução (veja Figura 11.1).
Capítulo 11 A Equipe de Projeto 313
FIGURA 11.1 Estágios de Desenvolvimento da Equipe
Primeiro Estágio Formação
Segundo Estágio Agitação
Terceiro Estágio Normalização
Quarto Estágio Execução
FORMAÇÃO
A formação corresponde ao estágio inicial do processo de desenvolvimento de uma equipe
de projeto. Envolve uma fase de transição, ou seja, a pessoa passa de indivíduo para mem-
bro de equipe. Como na fase da “paquera” em um relacionamento, nessa hora os membros
de uma equipe começam a se conhecer. Nesse estágio, eles geralmente têm expectativas
positivas e estão ansiosos para começar a trabalhar no projeto. O grupo começa a estabele-
cer uma identidade e tenta definir e planejar as tarefas que precisam ser executadas. Nessa
fase, entretanto, pouco trabalho real é realizado, devido ao nível alto de ansiedade das
pessoas com relação ao trabalho em si e ao relacionamento com os demais membros. Não
sabem ao certo o papel que eles, ou os outros membros da equipe de projeto, exercerão.
No estágio de formação, a equipe precisa de orientação. Os membros dependem de que o
gestor do projeto lhes proporcione orientação e suporte.

3. Durante o estágio de formação, _____
____________ trabalho real é realizado
devido ao _____________________ nível
de ansiedade das pessoas.
Os sentimentos característicos desse estágio incluem exaltação, precipitação, descon-

fiança, ansiedade e incertezas. As pessoas fazem muitos questionamentos no estágio de
formação: “Qual é nossa função?”, “Quem são os outros membros da equipe?”, “Como eles
são?”. Ficam ansiosos para saber se irão se identificar com os demais e se serão aceitos. Por
não saberem como as outras pessoas reagirão, podem hesitar em fazer parte da equipe.
Questionam se sua entrada será valorizada e se suas funções no projeto atenderão a seus
interesses pessoais e profissionais.

4. No estágio de formação, as pessoas
fazem muitos ____________________.
No estágio de formação, o gestor do projeto precisa dar orientação e suporte à equipe.

Ao orientar seus membros, o gestor deve comunicar com clareza o objetivo do projeto, vi-
sualizar um resultado positivo para este, bem como os benefícios que serão alcançados. As
limitações do projeto relativas ao escopo do trabalho, os níveis de qualidade, o orçamento
e cronograma devem ser mencionados. O gestor também precisa discutir a composição
da equipe: as razões para a escolha dos membros; a importância de seus conhecimentos
e habilidades complementares; as funções de cada um no processo de concretização dos
objetivos do projeto. Outra tarefa do gestor do projeto nesse estágio é dar suporte. Isso
inclui definir procedimentos e processos iniciais para a operação em equipe, bem como
tratar de itens como canais de comunicação, aprovações e papelada. Esses processos e
procedimentos podem ser aprimorados pelos membros da equipe à medida que estes se
desenvolvem nos estágios posteriores. Para aliviar um pouco a ansiedade, o gestor do pro-
jeto deve discutir seu modo de gestão e as expectativas que possui em relação ao trabalho
e ao comportamento da equipe do projeto. É importante atribuir algumas tarefas iniciais à
equipe. Nessa hora, o gestor do projeto consegue fazer a equipe participar da elaboração
dos planos do projeto.

5. Durante o estágio de formação,
o gestor do projeto precisa dar ________
_____ e _____________ à equipe
do projeto.
AGITAÇÃO
O segundo estágio de desenvolvimento da equipe é conhecido como agitação. Assim como
a adolescência, é uma fase difícil, mas deve ser superada. Não dá para escapar ou evitar.
O objetivo do projeto fica mais óbvio neste estágio. Os membros da equipe começam a
colocar em prática suas habilidades nas tarefas que lhes são atribuídas e o trabalho pas-
sa a fluir pouco a pouco. A realidade poderá, no entanto, desapontar os membros, cujas
expectativas iniciais não sejam correspondidas. Por exemplo, tarefas mais longas ou mais
difíceis do que se previa; limitações de cronogramas ou custos maiores do que se esperava.
Ao iniciar suas tarefas, os membros da equipe sentem-se cada vez mais insatisfeitos por
depender da orientação e da autoridade do gestor do projeto. Ou seja, podem reagir de
forma negativa em relação ao gestor e aos processos operacionais e procedimentos esta-
belecidos no estágio de formação. Os membros da equipe passam agora a testar os limites
e a flexibilidade do gestor do projeto e das regras estabelecidas. No estágio de agitação,
surgem os conflitos e aumentam as tensões. É necessário que haja consentimento quanto
aos métodos empregados no tratamento e na resolução dos conflitos. Há pouco ânimo e
disposição nessa fase. Os membros podem resistir à formação de uma equipe; querem ex-
pressar individualismo em vez de dedicação em equipe.

6. Durante o estágio de agitação,
os ________________ aparecem e a
______________ aumenta.
O estágio de agitação caracteriza-se por frustração, raiva e hostilidade. Ao começar suas

tarefas, as pessoas questionam mais suas funções e responsabilidades dentro da equipe.
Quando iniciam procedimentos operacionais, questionam a viabilidade e necessidade des-

ses procedimentos. Querem saber o limite do controle e da autoridade que possuem.

7. Durante o estágio de agitação,
os membros da equipe querem saber
quanto de ____________ e ____________
eles têm.
Na fase de agitação, o gestor do projeto ainda tem de ditar as regras, porém com menos
intensidade que no estágio anterior. Ele precisa esclarecer e definir melhor as responsabili-
dades individuais e as atividades conjuntas entre os membros da equipe. É necessário fazer
que os membros se envolvam nas resoluções de problemas e decidam de forma cooperativa,
para que a equipe se fortaleça. Recomenda-se que o gestor do projeto reconheça e tolere
as insatisfações expressas pelos membros da equipe; ele não deve considerá-las como algo
pessoal ou agir de forma defensiva. É o momento em que deve ser gerado um ambiente de
compreensão e apoio. É importante dar aos membros a chance de expressar suas preocupa-
ções. É função do gestor do projeto orientar e favorecer a resolução de conflitos; ele não deve
tentar reprimir insatisfações, na expectativa de que elas simplesmente desapareçam. Se forem
ignoradas, as insatisfações poderão aumentar, o que mais tarde pode gerar comportamentos
inadequados, colocando em risco o sucesso do projeto.

8. Durante o estágio de agitação, o
gestor do projeto precisa dar ________
______ e favorecer a _____________ de
_____________.
NORMALIZAÇÃO
Após o esforço envolvido no estágio de agitação, a equipe de projeto passa para o estágio
de normalização de desenvolvimento. O relacionamento entre os membros da equipe,
bem como entre esta e o gestor do projeto, normaliza-se. A maioria dos conflitos pessoais
foi resolvida. Em geral, os conflitos são menos intensos que no estágio de agitação. As in-
satisfações também diminuem, uma vez que as expectativas dos membros se adequaram à
realidade da situação – ao trabalho a ser feito, aos recursos disponíveis, às limitações e às
outras pessoas envolvidas. A equipe de projeto aceitou seu ambiente operacional. Os pro-
cedimentos do projeto estão melhores e mais eficientes. A equipe passa a exercer controle e
a tomar decisões. A coesão no trabalho começa a se desenvolver. Há uma noção de equipe.
As pessoas sentem-se incluídas e aceitam as outras como parte da equipe também. Valoriza-
se cada componente pela contribuição para alcançar o objetivo do projeto.

9. No estágio de normalização,
os ______________ e as ______________
diminuem, a _____________ começa a
se desenvolver e surge um sentido de
________________.
Um sentimento de confiança começa a se desenvolver, visto que os membros da equipe

passam a confiar uns nos outros. Informações, idéias e sentimentos são compartilhados com
maior intensidade; a cooperação aumenta. As pessoas dão e pedem um feedback e sentem
que podem expressar, com liberdade e de forma construtiva, suas emoções e críticas. Surge
um sentimento de camaradagem, à medida que a equipe passa por um processo de sociali-
zação. Os membros podem ficar amigos também fora do ambiente de trabalho.

10. Durante o estágio de normalização,
um sentimento de _____________
começa a se desenvolver. Há uma troca
maior de _______________, ___________
e _______________; a ________________
aumenta.
Durante o estágio de normalização, o gestor do projeto passa a ditar menos regras e a

proporcionar mais suporte. O desempenho do trabalho acelera e a produtividade aumenta.
O gestor deve reconhecer o progresso do trabalho desenvolvido pela equipe.

11. No estágio de normalização,
o _________________________ acelera
e a _______________________ aumenta.
EXECUÇÃO
O quarto e último estágio de desenvolvimento e crescimento de equipe é o estágio de exe-
cução. Nele, a equipe está altamente comprometida e ansiosa para alcançar o objetivo do
projeto. O nível de desempenho do trabalho é alto. A equipe tem um sentimento de união
e orgulho na realização de suas tarefas. A confiança é grande. A comunicação é aberta,
franca e oportuna. Nesse estágio, os integrantes trabalham individualmente ou, se necessá-
rio, temporariamente em subequipes. Há um alto grau de interdependência – os membros
colaboram e ajudam uns aos outros freqüentemente e com disposição, a fim de realizar suas
tarefas. A equipe sente-se totalmente autônoma. Conforme os problemas são identificados,
as pessoas apropriadas formam uma subequipe para solucioná-los e decidir como a solução
deve ser implementada. Há um sentimento de satisfação, visto que há progresso e que este
é reconhecido. Cada membro constata que a equipe está tendo crescimento profissional
como resultado do trabalho no projeto.

12. Durante o estágio de execução,
há um alto grau de _________________
— os membros ___________________
e _______________ uns aos outros
freqüentemente e têm disposição para
realizar além das próprias tarefas.
No estágio de execução, o gestor do projeto delega totalmente responsabilidade e auto-

ridade e, assim, capacita a equipe. Ele se foca em ajudá-la a executar o plano do projeto e
em reconhecer os membros pelo progresso e realização das tarefas. Nesse estágio, o gestor
do projeto se concentra na execução do projeto em relação ao orçamento, ao cronograma,
ao escopo e ao plano. O papel do gestor é dar suporte para o desenvolvimento e a im-
plementação de ações corretivas se o progresso real fica aquém do progresso planejado.
Também nesse estágio, o gestor atua como mentor, favorecendo o crescimento e o desen-
volvimento profissional das pessoas que trabalham no projeto.

13. Durante o estágio de execução, o
gestor do projeto __________________
totalmente responsabilidade e
autoridade e, assim, dá poderes à equipe
do projeto.
A Figura 11.2 ilustra graficamente os níveis de desempenho do trabalho e de entendi-

mento da equipe durante os quatro estágios de desenvolvimento e crescimento. A quantida-
de de tempo e de esforço que uma equipe gasta para atravessar cada estágio depende de di-
versos fatores, como o número de pessoas, se seus membros trabalharam juntos alguma vez
antes, a complexidade do projeto e as habilidades dos membros de trabalhar em equipe.

14. Quais são os quatro estágios
de desenvolvimento e crescimento de
equipe?
FIGURA 11.2 Nível de Funcionamento em Vários Estágios de Desenvolvimento da Equipe
Formação Agitação Normalização Execução

Alto
Baixo
Sentimento de Equipe
Desempenho do Trabalho
A Equipe de Projeto Eficaz

Uma equipe de projeto é mais que um grupo de pessoas designadas para trabalhar em um
projeto. Uma equipe de projeto é um grupo de pessoas interdependentes que trabalham
em cooperação para alcançar o objetivo do projeto. Ajudá-las a se desenvolver e crescer
em uma equipe eficaz e coesa faz parte do esforço do gestor do projeto e de cada membro
da equipe. Como foi observado no início do capítulo, a eficácia da equipe – ou a falta dela
– pode fazer a diferença entre o sucesso ou o fracasso do projeto. Embora os planos e as
técnicas de gestão de projetos sejam necessários, as pessoas (o gestor do projeto e a equipe
do projeto) são o segredo para o sucesso. Para que o projeto tenha sucesso, é preciso uma
equipe de projeto eficaz.
Algumas das características associadas a equipes eficazes são:
• um claro entendimento do objetivo do projeto;

• expectativas claras em relação ao papel e às responsabilidades de cada pessoa;
• uma orientação aos resultados;
• um alto grau de cooperação e colaboração;
• um nível alto de confiança.
UM CLARO ENTENDIMENTO DO OBJETIVO DO PROJETO
O escopo, o nível de qualidade, o orçamento e o cronograma precisam ser bem definidos

a fim de que uma equipe de projeto seja eficaz. Para que o objetivo do projeto seja alcan-
çado, todos os membros da equipe devem ter a mesma visão do resultado do projeto e dos
benefícios que serão proporcionados.
EXPECTATIVAS CLARAS EM RELAÇÃO AO PAPEL E ÀS RESPONSABILIDADES DE

CADA PESSOA
Os membros de uma equipe eficaz sabem como o trabalho de cada um contribui para o
projeto, pois participaram do desenvolvimento dos planos. Eles valorizam a experiência,
as habilidades e as contribuições um dos outros para alcançar o objetivo do projeto. Cada
pessoa aceita sua responsabilidade por uma parte do projeto.

15. Uma equipe de projeto eficaz tem um
claro entendimento do _____________
do projeto e claras expectativas sobre o
______________ e as _________________
de cada pessoa.
UMA ORIENTAÇÃO AOS RESULTADOS
Cada integrante de uma equipe eficaz tem um forte comprometimento em alcançar o obje-
tivo do projeto. Ao dar bom exemplo, o gestor do projeto estabelece o tom para o nível de
energia. Os membros da equipe têm entusiasmo e vontade de gastar o tempo e a energia
necessários para obter sucesso. Por exemplo, as pessoas mostram vontade de fazer horas
extras, de trabalhar nos fins de semana ou de não almoçar quando necessário para manter
o projeto nos trilhos.
UM ALTO GRAU DE COOPERAÇÃO E COLABORAÇÃO
Uma comunicação aberta, franca e oportuna é a norma para uma equipe de projeto eficaz.
Todos compartilham prontamente informações, idéias e sentimentos. Ninguém têm vergo-
nha de pedir ajuda. Os membros da equipe atuam como recursos uns para os outros, em
vez de somente fazerem as tarefas a eles atribuídas. Eles querem ver os outros membros
terem sucesso na realização das tarefas e sempre estão à disposição para ajudar e dar su-
porte a alguém que não esteja progredindo ou esteja em dificuldade. Eles dão e aceitam
feedbacks e críticas construtivas. Por causa dessa cooperação, a equipe tem criatividade
para solucionar problemas e tomar decisões na hora certa.

16. As equipes de projeto eficazes têm
uma orientação de ________________,
cada pessoa da equipe tem um forte
comprometimento em alcançar o
_______________ do ________________.
Há um alto grau de _________________ e
____________________.
UM NÍVEL ALTO DE CONFIANÇA
Os membros de uma equipe eficaz entendem a interdependência e aceitam que cada in-
tegrante é importante para o sucesso. Eles podem contar uns com os outros para tudo – e
com o nível de qualidade esperado. Os membros da equipe preocupam-se uns com os
outros. Por aceitarem as diferenças, sentem-se à vontade para serem eles mesmos. As dife-
renças de opinião são apoiadas, expressas com liberdade e respeitadas. As pessoas podem,
sem medo de repreensões, levantar questões que gerem desacordos ou conflitos. As equi-
pes eficazes resolvem os conflitos por meio de um feedback construtivo e oportuno e de
uma confrontação positiva das questões. Elas não suprimem o conflito, mas o consideram
normal e o encaram como uma oportunidade para seu crescimento e aprendizado.

17. As equipes de projeto eficazes têm
um nível alto de ________________. Elas
são capazes de resolver conflitos por
meio de um ______________ construtivo
e oportuno e uma ___________________
positiva das questões.
A Figura 11.3 é uma lista de verificação para se classificar a eficácia de uma equipe de
projeto. Recomenda-se que os membros da equipe respondam a esse instrumento de ava-
liação periodicamente durante o projeto. Depois de contar os pontos de cada membro, a
equipe, em que se inclui o gestor do projeto, deve discutir como melhorar as áreas em que
houver classificação baixa.
FIGURA 11.3 Lista de Verificação da Eficácia da Equipe
QUÃO EFICAZ É SUA EQUIPE DE PROJETO?

Nem um pouco Um pouco Muito
1. Sua equipe tem um claro entendimento

da própria meta? 1 2 3 4 5
2. O escopo do projeto, o nível de qualidade,
o orçamento e o cronograma são bem definidos? 1 2 3 4 5
3. Todos têm expectativas claras sobre
o próprio papel e as responsabilidades? 1 2 3 4 5
4. Todos têm expectativas claras sobre o papel
e as responsabilidades dos outros membros? 1 2 3 4 5
5. Todos sabem a experiência e as habilidades
que cada pessoa leva para a equipe? 1 2 3 4 5
6. Sua equipe tem orientação aos resultados? 1 2 3 4 5
7. Todos têm um forte comprometimento em
alcançar o objetivo do projeto? 1 2 3 4 5
8. Sua equipe tem um nível alto de entusiasmo e energia? 1 2 3 4 5
9. Sua equipe tem um alto grau de
cooperação e de colaboração? 1 2 3 4 5
10. A norma é ter comunicações oportunas,
sinceras e abertas? 1 2 3 4 5
11. Os membros facilmente compartilham
informações, idéias e sentimentos? 1 2 3 4 5
12. Os membros sentem liberdade para
pedir ajuda aos demais? 1 2 3 4 5
13. Os membros estão sempre dispostos
a ajudar a outro membro? 1 2 3 4 5
14. Os membros da equipe dão feedback e
fazem críticas construtivas? 1 2 3 4 5
15. Os membros da equipe aceitam feedback
e críticas construtivas? 1 2 3 4 5
16. Existe um nível alto de confiança
entre os membros da equipe do projeto? 1 2 3 4 5
17. Os membros cumprem o que dizem que vão fazer? 1 2 3 4 5
18. Existe uma abertura para se discordar
do ponto de vista das outras pessoas? 1 2 3 4 5
19. Os membros da equipe entendem-se
e aceitam as diferenças? 1 2 3 4 5
20. Sua equipe resolve conflitos construtivamente? 1 2 3 4 5
Barreiras para a Eficácia da Equipe

Embora toda equipe de projeto tenha potencial para ser altamente eficaz, geralmente exis-
tem barreiras que impedem que esse nível de eficácia seja alcançado. A seguir, estão algu-
mas barreiras que podem reduzir a eficácia da equipe do projeto e algumas sugestões de
como superá-las.
METAS POUCO DEFINIDAS

O gestor do projeto precisa articular o objetivo, bem como o escopo, o nível de qualidade,
o orçamento e o cronograma do projeto. Ele tem de criar uma visão do resultado do projeto
e dos benefícios que serão proporcionados. Essa informação deve ser comunicada logo na
primeira reunião de projeto. Nessa reunião, o gestor pergunta aos membros da equipe se
entenderam tudo o que foi dito e responde às eventuais dúvidas. Depois, deve-se fornecer
a cada um dos membros a informação por escrito, com eventuais esclarecimentos dados
durante a reunião inicial.

18. O gestor do projeto precisa articular
o __________________ do projeto com
freqüência. Nas reuniões periódicas, ele
sempre deve perguntar se alguém tem
alguma _________________ sobre o que
deve ser cumprido.
Periodicamente, o gestor precisa discutir o objetivo do projeto em reuniões de análise

do status do projeto. Nessas reuniões, ele sempre deve perguntar se alguém tem alguma
pergunta sobre o que deve ser cumprido. Não é suficiente dizer à equipe qual é o objetivo
do projeto somente uma vez, no início do projeto. O gestor do projeto deve dizer, escrever,
distribuir e repetir esse objetivo com freqüência.
DEFINIÇÃO INCERTA DOS PAPÉIS E DAS RESPONSABILIDADES

As pessoas podem julgar que seus papéis e responsabilidades são ambíguos ou que há
uma superposição nas responsabilidades de algumas pessoas. No início do projeto, o ges-
tor do projeto deve conversar em particular com cada membro da equipe para explicar
por que eles foram selecionados para o projeto, descrever seus papéis e responsabilidades
e detalhar como esses papéis estão relacionados com as funções e responsabilidades dos
outros membros. Os membros da equipe do projeto precisam ter liberdade para pedir que
o gestor do projeto esclareça qualquer área de ambigüidade ou superposição que apareça.
Conforme a equipe desenvolve o plano do projeto, as tarefas de cada membro precisam
ser identificadas por meio de alguma ferramenta, como uma estrutura analítica de projeto,
uma matriz de responsabilidade, um gráfico de Gantt ou um diagrama de rede (todos foram
discutidos na Parte 2 do livro). Devem ser distribuídas cópias desses documentos a todos,
para que cada membro da equipe possa ver não somente suas tarefas, mas também as dos
outros membros e como todas funcionam juntas.

19. O gestor do projeto deve conversar
em particular com cada membro da
equipe do projeto para explicar por que
ele foi ________________ para o projeto
e descrever os _________________ e as
_________________ esperados.
FALTA DE UMA ESTRUTURA DE PROJETO

As pessoas podem sentir que todos estão trabalhando em diferentes direções ou que não
existe nenhum procedimento estabelecido para a operação da equipe. Essa também é uma
razão pela qual o gestor do projeto tem de fazer a equipe participar do desenvolvimento
do plano do projeto.
Uma ferramenta, como o diagrama de rede (discutido na Parte 2), mostra como o traba-
lho de cada um é importante para cumprir com o objetivo do projeto. No início do projeto,
o gestor do projeto deve estabelecer procedimentos de operação preliminares que direcio-
nem questões como canais de comunicação, aprovações e requisitos de documentação.
Cada procedimento, bem como a lógica para estabelecê-lo, precisa ser explicado à equipe
em uma reunião de projeto. Os procedimentos devem também ser entregues por escrito
aos demais membros. Se alguns deles não seguirem os procedimentos ou os modificarem,
o gestor do projeto precisa reforçar a importância de todos seguirem de forma rigorosa os
procedimentos estabelecidos. No entanto, o gestor precisa estar aberto a sugestões para eli-
minar ou modernizar os procedimentos caso eles não contribuam mais para o desempenho
eficaz e eficiente do projeto.

20. O gestor do projeto precisa
estabelecer __________________ de
operação preliminares no início
do projeto, mas estar aberto a sugestões
para _______________ e _____________
os procedimentos quando eles não
_____________ mais para o desempenho
eficiente e eficaz do projeto.
FALTA DE COMPROMETIMENTO
Os membros da equipe podem aparentar falta de comprometimento com seu trabalho no
projeto ou com o objetivo do projeto. Para opor-se a tal indiferença, o gestor precisa expli-
car a cada pessoa a importância de seu papel na equipe e como ela pode contribuir para
o sucesso do projeto. O gestor também precisa perguntar aos membros da equipe quais
são seus interesses pessoais e profissionais e mostrar-lhes de que maneiras a realização do
projeto pode ajudar a satisfazer esses interesses. Ele deve tentar determinar o que motiva
cada pessoa e, em seguida, criar um ambiente em que haja esses motivadores. O gestor do
projeto também precisa reconhecer as realizações de cada pessoa, apoiando e incentivando
seu progresso.

21. O gestor do projeto deve tentar
determinar o que ___________ cada
pessoa e, então, criar um _____________
em que haja esses motivadores.
MÁ COMUNICAÇÃO
A comunicação ineficiente ocorre quando os membros da equipe não sabem o que está
acontecendo no projeto e quando as pessoas não compartilham informações. É importante
que o gestor do projeto faça reuniões de análise do status do projeto com regularidade,
com publicação de uma pauta. Deve-se pedir que vários membros da equipe informem o
status de seu trabalho.

22. É importante que o gestor do projeto
faça reuniões de ___________________
do projeto com regularidade, com
publicação de uma pauta. A __________
________ e _______________ devem ser
incentivados durante a reunião.
Deve-se incentivar a participação e perguntas. Todos os documentos do projeto, como

planos, orçamentos, cronogramas e relatórios, precisam ser mantidos atualizados e distri-
buídos de maneira oportuna a toda a equipe do projeto. O gestor do projeto deve incentivar
os membros da equipe a compartilhar informações entre eles, a colaborar e a solucionar
problemas sempre que necessário, em vez de esperar por reuniões oficiais. Além disso,
colocar todos os membros da equipe em um único escritório pode melhorar a comunicação
do projeto.
MÁ LIDERANÇA
Para evitar que a equipe do projeto sinta que o gestor do projeto não está tendo uma lide-
rança eficaz sobre a equipe, o gestor tem de estar disposto a pedir um feedback da equipe
periodicamente, fazendo perguntas do tipo: “O que você acha de meu trabalho?” ou “Como
você acha que posso melhorar minha liderança?”. No entanto, ele deve estabelecer primeiro
um ambiente de projeto em que as pessoas sintam liberdade para dar feedback sem medo
de represália. O gestor do projeto deve declarar em uma reunião no início do projeto que
um feedback será exigido periodicamente e que sugestões de como melhorar suas habilida-
des de liderança serão sempre bem-vindas. Por exemplo, um gestor de projetos pode dizer
que está interessado em melhorar suas habilidades de liderança de maneira a aumentar a
própria contribuição para o sucesso do projeto. Evidentemente, o gestor deve estar dispos-
to a seguir as sugestões apropriadas, mesmo que acarretem um treinamento adicional, na
mudança de seu comportamento ou na modificação de procedimentos do projeto.

23. Um gestor de projetos deve solicitar
periodicamente sugestões das outras
pessoas, a fim de melhorar suas
habilidades de ____________________.
ROTATIVIDADE DE MEMBROS DA EQUIPE DO PROJETO

Quando a composição de uma equipe muda com freqüência, ou seja, quando são designa-
das continuamente novas pessoas para um projeto enquanto outras o deixam, o fluxo de
pessoas pode ser dinâmico demais para a consolidação da equipe. Uma equipe de projeto
formada por um pequeno número de pessoas com atribuições de longo prazo será mais
eficaz que uma equipe composta de um grande número de pessoas com atribuições de
curto prazo. O gestor do projeto tem de selecionar para a equipe pessoas que sejam su-
ficientemente versáteis em experiência e em habilidades, para que possam contribuir em
muitas áreas e, assim, serem designadas para um projeto que dure um longo período de
tempo. Embora o gestor não deva tentar adiantar o projeto recrutando várias pessoas de pou-
ca experiência, as quais seriam designadas somente para intervalos curtos do projeto, em
alguns casos, pode ser mais apropriado designar pessoas com experiência específica para
uma única tarefa e por tempo limitado.

24. Uma equipe de projeto formada por
um ______________ número de pessoas
com atribuições de ____________ prazo
será mais eficaz do que uma equipe
composta por um ____________ número
de pessoas com atribuições de ________
prazo.
COMPORTAMENTO DISFUNCIONAL
Às vezes, algum membro da equipe apresenta um comportamento transgressor quanto ao
desenvolvimento de uma equipe eficaz – hostilidade, excesso de brincadeiras ou comen-
tários depreciativos, por exemplo. O gestor do projeto precisa conversar com essa pessoa,
mostrar seu comportamento transgressor e explicar que é inadmissível por causa do impac-
to sobre o resto da equipe. Pode-se indicar a essa pessoa uma orientação, um seminário de
treinamento ou uma terapia, se for apropriado. O gestor deve deixar claro, no entanto, que,
se o comportamento disfuncional continuar, a pessoa será excluída da equipe. É evidente
que o gestor do projeto precisa estar preparado para realmente tomar alguma atitude se for
necessário.

25. Quais são algumas das barreiras
para a eficácia de uma equipe?
Como Ser um Membro Eficaz da Equipe

Ser membro de uma equipe de projeto deve ser uma experiência de crescimento satisfatória
e enriquecedora para todas as pessoas. No entanto, o crescimento não acontece por si só.
Ele requer senso de responsabilidade, trabalho duro, mente aberta e vontade de se auto-
desenvolver. Embora o gestor do projeto seja o responsável final pelo sucesso do projeto,
cada membro da equipe compartilha dessa responsabilidade à medida que precisa ajudar a
criar e cultivar um ambiente de projeto positivo e eficaz.
Os membros eficazes de uma equipe planejam, controlam e se sentem responsáveis por
seus esforços de trabalho. Eles têm expectativas elevadas sobre si mesmos e se esforçam
para cumprir suas tarefas dentro do orçamento e com o cronograma adiantado. Eles admi-
nistram bem o tempo e fazem as coisas acontecerem, em vez de deixarem que aconteçam
sozinhas. Os membros eficazes de uma equipe não trabalham em uma tarefa simplesmente
A Equipe Colaborativa
De acordo com gestores de projetos veteranos, uma boa equipe de projeto é composta de
um reduzido número de pessoas com habilidades e estilos de trabalho complementares. É
possível construir uma equipe “completa” com pessoas que podem ser descritas por essas
categorias de estilos de trabalho clássicos:
• O Arquiteto – pensa em todas as soluções possíveis para um problema. Essa pessoa
evita que a equipe escolha a primeira e única idéia viável antes de explorar outras
possibilidades.
• O Facilitador – pode mediar a tomada de decisões. Essa pessoa aponta vantagens e
desvantagens para cada opção e ajuda o grupo a escolher uma delas.
• O Advogado do Diabo – irá desafiar as decisões. As pessoas serão forçadas a discutir
e defender suas opiniões.
• O Sujeito das Grandes Idéias – apresenta soluções que os outros podem não ter
pensado. Isso estimula a criatividade e a possível descoberta de novas oportunida-
des.
• O Âncora – certifica-se de que o plano de ação proposto é viável. Essa pessoa conhe-
ce as regras e certifica-se de que a equipe as cumpra.
• O Prático – entende o usuário final. Isso garante que o resultado ou produto final
seja aceito pelo cliente.
Uma vez montada a equipe perfeita, como o gestor do projeto transforma um grupo
de pessoas em uma equipe de trabalho? Segundo Joni Daniels, em The Collaborative Ex-
perience, o primeiro passo é entender as fases de desenvolvimento de equipe, conforme
descrito neste livro. Em seguida, usar as seguintes sugestões de exercícios em equipe para
evitar conflitos.
1. Informe claramente um objetivo para a equipe no início do projeto e repita-o vá-
rias vezes no seu decorrer. Um objetivo de equipe ajudará a manter o foco quando
políticas da empresa interferirem. O objetivo da equipe é fazer uma recomenda-
ção, conduzir um estudo e depois recomendar uma solução? A equipe vai ficar res-
ponsável pelo desenvolvimento e implementação de um sistema? Daniels afirma:
“Um grupo se transforma em equipe quando seu objetivo comum é compreendi-
do por todos os membros”.
2. Os membros da equipe devem conhecer os pontos fortes e fracos de cada um. No
início do projeto, eles devem compartilhar entre si as respostas para as seguintes
perguntas:
• Por que eu estou na equipe? Qual é o meu papel?
• Quais são minhas habilidades, talentos e conhecimentos?
• Quais são algumas das áreas que eu gostaria de desenvolver?
• Qual é a minha responsabilidade nesse projeto? O que não é minha responsabi-
lidade?
• Quais são meus possíveis pontos fracos nesse projeto?
3. “A verdade é que as pessoas tendem a se esquecer de como elas querem se com-
portar com o passar do tempo. As pessoas simplesmente reagem”. Daniels tam-
bém recomenda que os membros da equipe criem os próprios padrões de com-
portamento. Com base nas suas experiências passadas, cada pessoa é convidada a
relacionar as características das melhores e piores equipes. Os membros da equipe
compartilham e discutem suas listas. Em seguida, eles colaboram para criar uma
lista com as melhores características de equipe, para que sua nova equipe a utilize
como uma diretriz para um bom comportamento. Além disso, criam uma lista das
piores características de equipe para lembrar a todos os comportamentos a serem
evitados.
Daniels, J. The Collaborative Experience. Industrial Management¸ maio/junho de 2004.

Malymuka, K. How to Pick a Project Team. Computerword, v. 3, 12 de abril de 2004.
até que seja pedido para pararem – eles se dirigem e cumprem até o fim com as tarefas
e atividades. Todos têm orgulho de fazer um trabalho de qualidade e não esperam que
outros membros da equipe terminem, organizem ou refaçam algum trabalho incompleto
ou malfeito por eles. Cada membro pode contar com os demais integrantes para realizar
suas respectivas tarefas com qualidade e de modo oportuno, de maneira a não atrasar ou
impedir seu trabalho.

26. Os membros eficazes de uma equipe
planejam, controlam e se sentem ____
_____________ pelos próprios esforços
de trabalho. Eles têm ________________
elevadas sobre si mesmos.
Membros eficazes de uma equipe participam e comunicam-se. Em vez de se isolar e

esperar que sejam feitas perguntas, falam espontaneamente e participam nas reuniões.
Eles tomam a iniciativa e conversam com outros membros da equipe e com o gestor do
projeto de modo claro, oportuno e sem ambigüidades. Dão um feedback construtivo uns
aos outros. Os membros eficazes sentem-se particularmente responsáveis pela identificação
de problemas – ou de problemas em potencial – com a maior antecipação possível, sem
acusar ou responsabilizar as pessoas, o cliente ou o gestor do projeto pelo surgimento de
problemas. Os membros eficazes de uma equipe não são só identificadores de problemas,
mas também solucionadores. Quando um problema é identificado, eles sugerem soluções
alternativas e sempre estão prontos e dispostos a colaborar com os outros membros para
solucionar o problema, mesmo se estiver fora de sua área de responsabilidade. Os membros
eficazes não têm uma atitude de: “não é problema meu” ou: “não é meu trabalho”. Em vez
disso, dispõem-se a reunir esforços para ajudar a equipe a alcançar o objetivo do projeto.

27. Os membros eficazes de uma equipe
________________ e ________________.
Eles não são apenas identificadores de
problemas, mas também _____________
______________.
Os membros eficazes de uma equipe ajudam a criar um ambiente de projeto construtivo

e positivo, no qual não há lugar para discórdias, além de aceitar a composição diversa da
equipe do projeto e ter respeito por todos os membros da equipe. Eles consideram o ponto
de vista dos outros e não deixam que o orgulho, a teimosia ou a arrogância tomem o lugar
da colaboração, da cooperação e do compromisso. Os membros eficazes de uma equipe
colocam o sucesso do projeto acima do sucesso pessoal.

28. Pense em projetos nos quais você
trabalhou. Quais são algumas das
características pessoais dos membros
dessas equipes que lhes permitiram
dar contribuições eficazes?
Já foi dito que não há EU na palavra EQUIPE – não existem vencedores ou perdedores.
Quando um projeto é bem-sucedido, todo mundo ganha!
Construção de Equipe
O lendário técnico de beisebol Casey Stengel disse certa vez: “É fácil selecionar os jogado-
res. Fazer com que joguem juntos é o mais difícil”. A construção de equipe – desenvolver
um grupo de pessoas que cumpra o objetivo do projeto – é um processo contínuo. É uma
responsabilidade tanto do gestor como da equipe. A construção da equipe ajuda a criar uma at-
mosfera de sinceridade e confiança. Os membros possuem um sentido de união e um forte
comprometimento em alcançar o objetivo do projeto. O Capítulo 10 discutiu várias coisas
que o gestor de projetos pode fazer para cultivar e sustentar a construção de equipes. Neste
capítulo, vamos abordar algumas coisas que a equipe de projeto pode fazer para ajudar no
processo da própria construção.

29. A construção de equipe é uma
responsabilidade tanto do gestor do
projeto como da equipe do projeto.
A socialização entre os membros favorece a construção da equipe. Quanto mais os

membros se conhecem, melhor é a construção da equipe. Para assegurar que os membros
se comuniquem uns com os outros com freqüência, situações que cultivem a socialização
podem ser promovidas pelos próprios membros da equipe.

30. A __________________ entre os
membros da equipe favorece a ______
______________________. Os membros
precisam ________________ uns com os
outros com freqüência.
A equipe pode pedir que os membros sejam dispostos fisicamente em uma única área
de escritórios durante todo o projeto. Quando trabalham próximos, há uma maior chance de
ir ao escritório ou ao setor de trabalho uns dos outros. Além disso, eles passam com mais
freqüência por áreas comuns, como nos corredores, por exemplo, e, assim, têm a opor-
tunidade de parar para conversar. As conversas não devem ser sempre relacionadas com
trabalho. É importante que os membros da equipe se conheçam pessoalmente, sem invadir
a intimidade alheia. Amizades pessoais surgirão durante o projeto. Ter a equipe inteira do
projeto localizada em um mesmo ambiente de trabalho evita o sentimento de “nós contra
eles” que pode nascer quando partes da equipe são dispostas em diferentes andares de
um edifício ou de uma planta. Se trabalharem fisicamente separados, pode resultar em
uma equipe de projeto formada, na verdade, por diversos subgrupos, em vez de uma
verdadeira equipe.
A equipe pode promover eventos sociais para comemorar resultados, como a conquista
de uma meta crítica – a aprovação do teste de um sistema ou o sucesso de uma reunião de
análise de projeto com um cliente, por exemplo. Os eventos também podem ser programa-
dos periodicamente somente com a intenção de aliviar o estresse. Ir a uma pizzaria ou a um
restaurante, realizar um almoço informal na sala de conferência, organizar um churrasco com

a família de todos, fazer uma viagem para ver algum campeonato esportivo ou uma grande
produção de teatro são exemplos de eventos que a equipe pode promover para cultivar a
socialização e a construção da equipe. É importante que essas atividades tenham a participa-
ção de todos. Embora nem todos possam comparecer no dia do evento, todo mundo deve
ser pelo menos convidado. Os membros precisam fazer o maior número possível de pessoas
da equipe (e de suas famílias, se elas participam) saberem desses eventos. Um bom método
é sentar-se sempre próximo de alguém que você não conheça muito bem e puxar conversa
com essa pessoa – faça perguntas, ouça o que ela diz, procure conversar sobre interesses co-
muns. É importante que as pessoas evitem formar “panelinhas” que sempre ficam juntas em
todos os eventos. Promover eventos sociais não só ajuda a criar um clima de camaradagem,
mas também torna mais fácil para as pessoas engrenarem uma conversação aberta e sincera
enquanto trabalham juntas no projeto.
Além de organizar atividades sociais, a equipe pode convocar reuniões periódicas de
equipe, diferentes das reuniões de projeto. O propósito das reuniões de equipe é discutir
abertamente questões como as seguintes: Estamos trabalhando como uma equipe? Quais
são as barreiras que o trabalho em equipe está enfrentando (como procedimentos, recur-
sos, prioridades ou comunicação)? Como podemos superar essas barreiras? O que podemos
fazer para melhorar o trabalho em equipe? Se o gestor do projeto participa das reuniões
de equipe, ele deve ser tratado como qualquer outro membro – os membros da equipe
não devem olhar para o gestor do projeto esperando respostas e este não pode abusar da
autoridade nem desconsiderar o consenso da equipe, já que é uma reunião de equipe e
não uma reunião de projeto. Deve-se discutir somente as questões relacionadas à equipe,
e não ao projeto.
Os membros devem cultivar a construção de equipe da maneira que puderem. Eles
não devem esperar que o gestor do projeto seja o único responsável pela construção da
equipe.
COMPORTAMENTO ÉTICO
Bill parou no escritório de Patrícia e disse: – Patrícia, o que você acha de a gente não vir
trabalhar essa tarde e ir jogar golfe? Nosso chefe não está por aqui hoje. Se alguém perguntar,
podemos dizer que estamos indo ao local da construção verificar alguns materiais. A gente
tem trabalhado muito e por isso merecemos; nem precisamos descontar das férias. Somos
muito mais produtivos do que qualquer outra pessoa da equipe. Eu disse para nosso chefe
que vai levar dez dias para realizar essa tarefa, mas, na verdade, a gente deve gastar cerca de
seis dias, como eu já tinha pensado. Então... a gente tem tempo de sobra.
O comportamento de Bill é ético? O que Patrícia deveria fazer? Se fosse proprietário de
uma pequena empresa e descobrisse que algum de seus funcionários agiu assim, o que
você faria?
Existem situações em que, em vez de fazer a coisa certa, as pessoas preferem justificar
seus atos com pensamentos do tipo: “não estou fazendo mal a ninguém” ou: “todo mundo
faz isso”. Algumas pessoas tentam convencer outras a fazer o mesmo, ou a participar des-
se tipo de conduta, para dizer que não tem nada de errado se uma outra pessoa também
concordou em fazer.
Um comportamento ético não é necessário somente dentro de uma organização de proje-
to, mas é crucial nas relações de negócios com o cliente, com os fornecedores e com os ter-
ceirizados. Os clientes e os fornecedores querem fazer negócios com um contratante ou com
uma organização de projeto em que eles confiem. Isso é importante principalmente quanto
às informações que o gestor do projeto ou os membros da equipe transmitem ao cliente. É
inadmissível reter ou alterar informações, principalmente em situações em que os riscos de
segurança em potencial sejam preocupantes. Certamente pode haver áreas críticas a informar.
Por exemplo, quando você informa um cliente de um problema em potencial? Imediatamente
depois que o problema é identificado, depois de tentar resolver o problema ou depois de

ter pensado em um plano de ação para solucioná-lo? O cliente vai reagir rapidamente? É im-
portante comunicar-se honestamente sobre essas situações de maneira oportuna, ou seja, no
momento certo, de modo objetivo e não de forma alarmante e enganosa.
No projeto, existem situações que podem favorecer oportunidades para um comporta-
mento antiético ou de má conduta. Alguns exemplos são:
• Pedir intencionalmente um valor baixo por uma proposta com o propósito de alterar os va-
lores depois que o contrato tenha sido assinado, cobrando do cliente um preço mais alto.
• Comprar materiais de fornecedores que dêem “propinas” ou brindes se você fechar
negócios com eles, em vez de usar práticas de concorrência justas e claras.
• Ser desonesto no relatório de número de horas trabalhadas para assim cobrar mais
do cliente.
• Aumentar ou adulterar relatórios de despesas de viagem.
• Plagiar o trabalho dos outros e tirar vantagem disso.
• Utilizar intencionalmente materiais ou modelos de segunda linha ou que não sejam
seguros.
• Fazer uso pessoal de materiais ou equipamentos do projeto.
• Pressionar a equipe do projeto a cobrar mais ou menos horas do que eles realmente
trabalharam para enganar a direção ou o cliente, dizendo que os gastos do projeto
estão dentro do orçamento.
• Aprovar intencionalmente resultados de testes incorretos ou imprecisos.
• Subornar fiscais para que aprovem o trabalho que não seria aprovado pela fiscali-
zação.
Existem muitas ocasiões durante um projeto que são contestáveis no que diz respeito a
mau comportamento. Por exemplo, se o cronograma fica atrasado é por que o contratante
ou os membros da equipe fizeram estimativas de tempo impraticáveis ou por que foram
ingenuamente otimistas em achar que o trabalho pudesse ser feito na duração estimada?
Isso sem dúvida indica uma “intenção” ou o ato de agir propositadamente – a intenção era
enganar? A intenção de distorcer os fatos, fraudar e fazer declarações falsas é totalmente
antiética.
O que uma organização de projeto pode fazer para promover um comportamento ético
e reduzir as chances de uma má conduta?
Certamente o gestor do projeto deve dar o tom e estabelecer as expectativas, além de ser
um bom exemplo de comportamento ético. Se a equipe do projeto vê o gestor agindo ou
tomando decisões que são eticamente questionáveis, eles podem pensar que está correto
e que podem fazer o mesmo. O gestor do projeto deve se comprometer em fazer sempre o
que é certo e justo e transmitir as mesmas atitudes para a equipe do projeto.
Existem duas ações que uma organização de projeto pode adotar para ajudar a prevenir
uma má conduta: apresentar uma diretriz por escrito sobre comportamento ético e provi-
denciar um treinamento sobre ética no trabalho. A diretriz sobre comportamento ético deve
incluir temas como expectativas, processo de denúncia de má conduta e as conseqüências
de cometer práticas antiéticas. No início do projeto, o gestor deve fazer uma reunião de
equipe para discutir a importância do comportamento ético e depois falar sobre isso com
regularidade nas reuniões durante todo o projeto. Devem ser incentivadas, reconhecidas e
apreciadas as ações éticas, como uma equipe que emite uma declaração sobre um modelo
que não apresenta segurança, por exemplo. Má conduta ou conflito de áreas de interesse
devem ser solucionados e deve-se tomar uma ação disciplinar apropriada para demonstrar
que esse tipo de comportamento é inadmissível e que não será tolerado.
Uma abordagem útil é organizar uma sessão de treinamento sobre comportamento éti-
co para informar a equipe da diretriz da organização e apresentar estudos de caso nesses
encontros. Os funcionários que participam de treinamentos sobre ética têm menos pro-
babilidade de apresentar mau comportamento. Organizar esse tipo de treinamento passa
uma mensagem de que a organização do projeto valoriza bastante o comportamento ético.

Também quando novos membros entram para a equipe do projeto, como parte de uma
reunião de orientação, o gestor deve discutir novamente a importância e as expectativas de
um comportamento ético.
Os membros da equipe do projeto precisam ser informados de que, se não estiverem
certos, ou se estiverem indecisos, se uma situação é ética ou de conflito de interesses, eles
devem levar isso ao conhecimento do gestor do projeto antes de adotar qualquer atitude.
A organização de projeto deve também estabelecer um processo que seja seguro para as
pessoas que queiram denunciar qualquer ato que considerem antiético ou de má conduta.
Por exemplo, esse processo pode incluir um procedimento em que as pessoas possam fazer
denúncias anônimas ou relatar e discutir essas questões com um departamento indepen-
dente, como o diretor dos Recursos Humanos. Se um caso de má conduta for denunciado
– por exemplo, alguém alega que uma pessoa da equipe do projeto está falsificando os
relatórios de despesas de viagem –, a organização tem de investigar completamente o caso
para contrapor fatos e boatos antes de tomar uma ação disciplinar.
O comportamento ético é de responsabilidade de todos, e não só do gestor do projeto.
Cada membro da equipe do projeto deve se sentir responsável por seus atos. A integridade
pessoal é o alicerce para a ética no trabalho. As pessoas que têm a mentalidade de tentar
“escapar (para não ser pego)” corroem esse alicerce. Outros membros da equipe do projeto
precisam igualmente pressionar tais pessoas a ajudar a modificar esse comportamento, dei-
xando claro que não toleram, não aceitam, não querem fazer parte e não concordam com
esse tipo de comportamento.

31. Existem duas ações que uma
organização de projeto pode tomar
para ajudar a prevenir uma má conduta:
apresentar uma ____________________
sobre comportamento ético e
providenciar um ____________________
sobre ética no trabalho.
Os princípios-chave que guiam um comportamento ético nos projetos são:

• Tratar os outros do mesmo modo como você gostaria de ser tratado.
• Não fazer nada que você não gostaria que sua família, seus amigos, vizinhos ou co-
legas de trabalho lessem em um jornal ou de alguma forma ficassem sabendo.
CONFLITO EM PROJETOS
Os conflitos em projetos são inevitáveis. Você pode considerar que o conflito é ruim e que
deve ser evitado. No entanto, as diferenças de opinião são naturais e devem ser espera-
das. Seria um erro tentar suprimir um conflito, visto que este também pode ser benéfico.
O conflito dá a oportunidade de obter novas informações, considerar alternativas, desenvol-
ver soluções melhores para os problemas, intensificar a construção de equipe e aprender.
Como parte do processo de construção de equipe, o gestor e a equipe precisam reconhecer
abertamente que, com certeza, ocorrerão divergências durante a realização do projeto e,
por isso, devem sempre chegar a um consenso de como lidar com eles. Essas discussões
precisam acontecer no início do projeto e não somente quando ocorrer a primeira situação
de conflito ou depois de haver uma explosão emocional.
As seções seguintes discutem as fontes de conflito em um projeto e as abordagens para
lidar com elas.
Fontes de Conflito
Em um projeto, pode surgir um conflito em diferentes situações, envolvendo membros da
equipe do projeto, o gestor do projeto e até mesmo o cliente. A seguir, seguem sete fontes
de conflito em potencial nos projetos.
ESCOPO DO TRABALHO
Os conflitos podem surgir de diferenças de opinião sobre como o trabalho deve ser
feito, sobre quanto do trabalho deve ser realizado ou sobre em que nível de qualidade ele
deve ser feito. Considere os seguintes casos:
• Em um projeto de desenvolvimento de um sistema de acompanhamento de pedido,
um dos membros da equipe julga que se deve usar tecnologia de código de barras,
enquanto outra pessoa da equipe opina que se deve usar estações de entrada de
dados por digitação. Esse é um conflito sobre a abordagem técnica de trabalho.
• Em um projeto de organização de um festival, um membro da equipe considera que
é suficiente enviar mala-direta para as casas da cidade, enquanto outro membro opi-
na que se deve enviar para todo o estado e colocar um anúncio nos jornais. Esse é
um conflito sobre quanto do trabalho deve ser realizado.
• Como parte de um projeto de construção de uma casa, um contratante passa somente
uma demão de tinta em cada cômodo da casa. No entanto, em uma vistoria, o clien-
te acha insuficiente e exige que o contratante passe uma segunda demão sem custo
adicional. Esse é um conflito sobre o nível de qualidade do trabalho.
ATRIBUIÇÕES DE RECURSOS
Pode surgir um conflito sobre as pessoas específicas designadas para trabalhar em certas
tarefas ou sobre a quantidade de recursos atribuídos para determinadas tarefas. Em um pro-
jeto de desenvolvimento de um sistema de acompanhamento de pedido, a pessoa designada
para a tarefa de desenvolver o software de aplicação gostaria de ser designada para trabalhar
no banco de dados porque lhe daria a oportunidade de ampliar seus conhecimentos e habi-
lidades. No projeto do festival, os membros da equipe encarregados de pintar as barracas
podem achar necessário ter mais voluntários para ajudá-los a terminar o trabalho a tempo.
CRONOGRAMA
Um conflito pode resultar de diferenças de opinião sobre a seqüência em que o trabalho
deve ser feito ou sobre quanto tempo o trabalho deve levar. Quando, durante o estágio de
planejamento no início do projeto, um membro da equipe estima que levará seis semanas
para terminar suas tarefas, o gestor do projeto pode dizer: – É muito tempo. Desse jeito, não
terminaremos o projeto a tempo. Você tem de fazer isso em quatro semanas.
CUSTO
Normalmente surge um conflito sobre quanto o trabalho deve custar. Por exemplo, supo-
nha que uma empresa de pesquisa de mercado tivesse um cliente com um custo estimado
para a realização de uma pesquisa nacional e, quando o projeto estivesse cerca de 75%
pronto, dissesse ao cliente que o projeto provavelmente custaria 20% mais que a estimativa
original. Ou suponha que mais pessoas fossem designadas para adiantar um projeto com o
cronograma atrasado, mas levando as despesas a excederem o orçamento. Quem deveria
pagar pelos custos excedentes?
PRIORIDADES
É provável que surja um conflito quando as pessoas são designadas para trabalhar em
diversos projetos simultaneamente ou quando várias pessoas precisam utilizar ao mesmo
tempo um recurso limitado. Por exemplo, suponha que uma pessoa tenha sido designada
para trabalhar parte de seu tempo em uma equipe de projeto dentro de sua empresa para
modernizar alguns dos procedimentos da empresa. No entanto, ela tem um aumento ines-
perado da sua carga normal de trabalho e não consegue passar a quantidade de tempo
prevista em suas atribuições de projeto, atrasando conseqüentemente o cronograma. O que
tem maior prioridade? Sua função no projeto ou seu trabalho habitual? Suponha ainda
que uma empresa tenha um computador potente capaz de realizar complicadas análises de
dados científicos. Várias equipes de projeto precisam acessar um mesmo computador para
checarem seus respectivos cronogramas. Quem não conseguir utilizar o computador ficará
com o cronograma atrasado. Que equipe tem a prioridade?
QUESTÕES ORGANIZACIONAIS
Uma variedade de questões organizacionais pode causar conflito, principalmente no estágio
de agitação de desenvolvimento de equipe (discutido no início deste capítulo). É possível
que existam divergências sobre a necessidade de certos procedimentos estabelecidos pelo
gestor do projeto com respeito à documentação ou às formas de aprovação. O conflito
pode resultar de uma má comunicação ou de uma comunicação ambígua, da falta de troca
de informações ou de tomada de decisões a tempo. Por exemplo, é provável surgir um
conflito se o gestor do projeto insistir que todo o fluxo de comunicação passe por ele. Ou-
tro caso pode acontecer se não houver reuniões suficientes para análise crítica do status do
projeto, pois, nesse caso, quando se faz uma reunião dessas, são reveladas informações que
teriam sido úteis se contadas várias semanas antes. Como resultado da falta de informação,
alguns membros da equipe talvez tenham de refazer alguns de seus trabalhos. Por fim, pode
haver um conflito entre alguns dos membros da equipe e o gestor do projeto por causa de seu
estilo de liderança.
DIFERENÇAS PESSOAIS
Um conflito pode surgir entre os membros da equipe do projeto também devido a precon-
ceitos ou diferenças de valores e atitudes pessoais. No caso de um projeto que esteja atrasa-
do, se um dos membros fizer horas extras para acertar o cronograma, ele pode ressentir-se
se outro membro da equipe sempre sair no horário normal para jantar com a esposa.

32. Quais são as fontes comuns
de conflitos em projetos?
Pode haver fases durante o projeto em que não exista nenhuma divergência. No entanto,
em algumas fases ocorrerão muitos conflitos de várias fontes que precisam ser controlados.
Os conflitos são inevitáveis nos projetos, mas podem ser benéficos se forem controlados
adequadamente.
Lidando com Conflitos

Os conflitos não devem ser resolvidos somente pelo gestor do projeto. As diferenças entre
os membros da equipe devem ser solucionadas pelas próprias pessoas envolvidas. Se for
tratado adequadamente, o conflito pode ser benéfico. Este causa problemas que devem ser
solucionados, estimulando discussões e fazendo as pessoas aclarar as suas visões. O con-
flito pode forçar as pessoas a buscar novas abordagens, cultivar a criatividade e melhorar
o processo de resolução de problemas. Se for tratado adequadamente, o conflito ajuda na
construção de equipe. Caso contrário, pode ter um impacto negativo na equipe do projeto.
Ele tem o poder de destruir a comunicação – as pessoas param de conversar e de trocar
informações. É capaz de também diminuir a vontade dos membros de ouvir e respeitar o

ponto de vista dos outros, quebrando a unidade de equipe e reduzindo o nível de confiança
e de abertura.

33. Se for tratado propriamente, um
conflito pode ser _______________.
Os pesquisadores Blake e Mouton e Kilmann e Thomas identificaram cinco abordagens

que as pessoas usam para lidar com os conflitos.
EVITANDO OU CONCORDANDO
Nesta abordagem, as pessoas envolvidas em um conflito se retratam para evitar um desacor-
do real ou em potencial. Por exemplo, se uma pessoa discorda de outra, esta simplesmente
pode ficar em silêncio. No entanto, esse tipo de atitude pode levar o conflito a se acumular
e a piorar com o tempo.
COMPETINDO OU COAGINDO
Nesta abordagem, o conflito é visto como uma situação em que um perde e outro ganha.
O valor de sair ganhando do conflito é maior que o valor dado à relação entre as pessoas.
A pessoa com esse tipo de postura controla o conflito, exercendo autoridade sobre a outra.
Por exemplo, em um conflito entre o gestor do projeto e um dos membros da equipe sobre
que tipo de técnica adotar na elaboração de um sistema, o gestor do projeto pode simples-
mente abusar de sua autoridade e dizer: – Faça isso do meu jeito. Esse tipo de abordagem
para lidar com um conflito pode resultar em ressentimento e corromper a harmonia do
ambiente de trabalho.
ACOMODANDO OU CONCILIANDO-SE
Esta abordagem enfatiza a busca por áreas de comum acordo dentro do conflito e minimiza
o valor de se discutirem diferenças. Os assuntos que podem ferir sentimentos não devem
ser discutidos. Nesta abordagem, o valor dado à relação entre as pessoas é maior que o rele-
gado à resolução da questão. Embora essa abordagem possa fazer do conflito uma situação
suportável, ela não resolve a questão.
FAZENDO CONCESSÕES
Nesta abordagem, os membros da equipe procuram uma posição intermediária. Eles se fo-
cam em adotar um meio-termo e buscam por uma solução que propicie alguma satisfação
para cada uma das partes envolvidas. No entanto, a solução pode não ser a ideal. Considere
o caso em que os membros da equipe estão estabelecendo as estimativas de duração para
várias tarefas do projeto. Um dos membros diz: – Eu acho que essa vai levar 15 dias. Um
outro diz: – De jeito nenhum. Ela não deve demorar tanto. Talvez cinco ou seis dias.
Nesse caso, eles rapidamente adotam um meio-termo e chegam a um acordo sobre dez
dias, que pode não ser a melhor estimativa.
COLABORAÇÃO, CONFRONTAÇÃO OU RESOLUÇÃO DE PROBLEMAS

Na abordagem de resolução de problemas, confrontação e colaboração, os membros da
equipe enfrentam a questão de forma direta. Eles procuram chegar a um resultado em que
todos saiam ganhando. Eles valorizam bastante tanto o resultado do conflito como a relação
entre as pessoas. Cada um deve abordar o conflito com uma atitude construtiva e com von-
tade de agir de boa-fé com os demais para resolver a questão. Existe uma troca de opiniões
sincera sobre como cada um vê o conflito. As diferenças são exploradas e trabalhadas até o
fim para encontrar a melhor solução possível. Cada um se dispõe a mudar ou redefinir sua
posição conforme trocam opiniões a fim de chegar à solução ideal. Para que essa aborda-
gem funcione, é necessário ter um ambiente de trabalho saudável (veja a discussão sobre
equipes de projeto eficazes) em que as relações são sinceras e gentis, e as pessoas não têm
medo de repreensão por serem honestas umas com as outras.
As diferenças podem aumentar e se transformar em argumentos emocionais. Quando as
pessoas tentam resolver um conflito, não podem se deixar levar pelas emoções. No entanto,
precisam ser capazes de administrar a situação sem suprimir suas emoções. Elas precisam
entender o ponto de vista do outro. A seção seguinte fornece uma abordagem útil para uma
resolução de problema colaborativa.

34. Quais são as cinco abordagens para
lidar com conflitos?
Conflitos desnecessários podem ser evitados ou minimizados por meio de: um envolvi-
mento da equipe do projeto no princípio do planejamento; uma definição clara do papel
e das responsabilidades de cada membro; uma comunicação oportuna, sincera e aberta;
procedimentos claros de operação; e esforços sinceros para uma construção de equipe por
parte do gestor do projeto e da equipe do projeto.
RESOLUÇÃO DE PROBLEMAS
Não é comum que uma equipe complete um projeto sem se deparar com alguns proble-
mas. Normalmente, vários imprevistos surgem durante o caminho, alguns mais sérios que
outros. Por exemplo, o projeto pode ficar atrasado em algumas semanas, pondo em risco
sua conclusão até a data exigida pelo cliente. Ou então surgem problemas de orçamento
– talvez 50% do dinheiro tenha sido gasto, mas apenas 40% do trabalho realizado. Alguns
problemas são de natureza técnica – um novo sistema de sensor óptico não está fornecen-
do a precisão necessária para os dados, ou um novo equipamento de montagem de alta
tecnologia continua emperrando e destruindo componentes caros. A eficiência com que a
equipe de projeto resolve os problemas pode fazer a diferença entre o sucesso e o fracasso
do projeto. Portanto, uma abordagem disciplinada, criativa e eficaz para a resolução de
problemas é necessária. A seguir, apresentamos uma abordagem em nove etapas para a
resolução de problemas, seguida de uma discussão sobre brainstorming – técnica útil em
várias etapas da abordagem de resolução de problemas.
Uma Abordagem em Nove Etapas para a Resolução de Problemas

1. Desenvolva uma declaração do problema. É importante começar com uma declaração
escrita do problema, que forneça sua definição e seus limites. Esse procedimento fornece
um veículo para que os membros da equipe de resolução do problema concordem sobre a
natureza exata do problema que estão tentando resolver. A declaração de problema deve
incluir uma medida quantitativa da extensão do problema.
• Um exemplo de declaração insuficiente do problema é: “Estamos atrasados”. Um exem-
plo melhor de declaração de problema seria: “Estamos atrasados em duas semanas.
Parece que não vamos conseguir cumprir a data de entrega para o cliente, que é de
quatro semanas a partir de hoje, e que vamos entregar o projeto apenas duas semanas
depois, a não ser que façamos alguma coisa. Se não cumprirmos com a data final o
cliente terá direito a uma redução de 10% no preço, segundo o contrato”.
• Outro exemplo de declaração insuficiente do problema é: “O sistema de sensor não

funciona”. Uma declaração melhor seria: “O sistema de sensor está fornecendo dados
errôneos quando mede os cantos arredondados das peças”.
Quanto mais específica ou quantitativa for a declaração do problema, melhor, porque
quaisquer formas de mensuração serão úteis posteriormente como critérios para avaliar se
ele foi ou não resolvido.
2. Identifique possíveis causas para o problema. Pode haver vários motivos pelos quais um
contratempo ocorreu ou está ocorrendo. Isso vale especialmente no caso de problemas técni-
cos. Pegue um projeto envolvendo o desenvolvimento de um sistema de computadores com
múltiplos usuários, nos quais os dados não estão sendo transmitidos do computador central
para todas as estações de trabalho dos usuários. A causa poderia ser um defeito de hardware
ou software, ou então um problema com o computador central ou com algumas das estações
de trabalho. Uma técnica freqüentemente usada para identificar as possíveis causas de um
problema é o brainstorming, o qual será discutido mais adiante neste capítulo.
3. Reúna dados e verifique as causas mais prováveis. Nos estágios iniciais do processo de
resolução de problemas, a equipe normalmente está reagindo aos sintomas, e não tratando
daquilo que pode causar o problema. É particularmente provável que isso aconteça quando
o problema é descrito em termos de sintomas. Imagine que uma pessoa vá ao médico e
diga que anda tendo dores de cabeça. O médico percebe que as causas poderiam ser mui-
tas, como estresse, um tumor, mudança na alimentação ou influência do ambiente. Então,
ele tentará reunir dados adicionais sobre as causas mais prováveis, fazendo perguntas ou
pedindo que o paciente realize alguns exames. O médico vai usar essas informações para
diminuir a lista de possíveis causas para o sintoma. É importante que a equipe vá além dos
sintomas e reúna os fatos antes de passar para a próxima etapa: a identificação de possíveis
soluções. Do contrário, muito tempo será gasto no desenvolvimento de soluções para os
sintomas em vez de se tratar a causa do problema. Reunir dados, seja por meio de pergun-
tas, de entrevistas, da realização de testes ou exames, da leitura de relatórios ou da análise
de dados, leva tempo. Contudo, isso deve ser feito para concentrar o trabalho da equipe no
resto do processo de resolução de problemas.
4. Identifique possíveis soluções. Essa é a etapa divertida e criativa do processo de re-
solução de problemas. E é também a etapa crítica do processo. Os membros da equipe
precisam ter o cuidado de não recorrer à primeira solução sugerida, ou à mais óbvia. Eles
podem ficar decepcionados mais tarde, caso a solução escolhida dessa forma não dê certo
e eles tiverem de voltar ao quadro branco. Por exemplo, quando um projeto está atrasado
em duas semanas, a solução óbvia pode ser simplesmente perguntar ao cliente se o projeto
pode ser entregue com duas semanas de atraso. Contudo, essa solução pode surtir um efei-
to contrário. Se o gestor do projeto entrar em contato com o cliente e perguntar se o projeto
pode ser entregue com atraso, o cliente pode reagir de forma negativa, ameaçar desistir de
fazer negócios com a empresa e conversar com o chefe sobre o atraso no projeto. A técnica
de brainstorming, discutida mais adiante, é muito útil nessa etapa para ajudar a identificar
as várias soluções possíveis.
5. Avalie as soluções alternativas. Após a identificação de diversas soluções possíveis,
conforme a etapa 4, é necessário avaliá-las. Podem surgir várias soluções boas, mas diferen-
tes, para o problema. Cada solução viável deve ser avaliada. A questão agora é: “avaliada
em relação a quê?”. É necessário estabelecer critérios. Portanto, nessa etapa, a equipe de
resolução de problemas deve primeiro estabelecer os critérios em relação aos quais as solu-
ções alternativas serão avaliadas. Uma vez estabelecidos os critérios, a equipe pode usar uma
ficha de avaliação semelhante à apresentada na Figura 3.3. Cada critério deve ser ponderado
de uma forma coerente com a sua importância. Por exemplo, o custo para a implementação de
uma solução pode ter um peso mais alto do que o tempo estimado para implementá-lo. As-
sim como a de número 3, essa etapa pode levar certo tempo caso você precise reunir dados
para avaliar as soluções alternativas de forma inteligente. Por exemplo, coletar informações
sobre os custos de peças ou materiais necessários para algumas das soluções pode levar
tempo, principalmente se você precisar fazer estimativas de preços com fornecedores. Cada
membro da equipe de resolução de problemas deve preencher uma ficha de avaliação para
cada uma das possíveis soluções. Essas fichas serão usadas na próxima fase.
6. Determine a melhor solução. Nesta etapa, as fichas de avaliação preenchidas na
etapa 5 pelos membros da equipe do projeto são usadas para ajudar a determinar a melhor
solução. Elas se tornam uma base de discussão entre os membros da equipe. As fichas
não são o único mecanismo para a determinação da melhor solução, mas, sim, como um
instrumento auxiliar no processo de tomada de decisões. Nesse ponto, torna-se importante
ter uma equipe equilibrada e variada em termos de experiência. A decisão sobre qual é a
melhor solução baseia-se no conhecimento e na experiência dos membros da equipe de
resolução de problemas, em conjunto com as fichas de avaliação.
7. Revise o plano do projeto. Uma vez escolhida a melhor solução, é necessário preparar
um plano para implementá-la. Tarefas específicas precisam ser identificadas com as du-
rações e custos estimados. As pessoas e os recursos necessários para cada tarefa também
devem ser identificados. Os membros da equipe de projeto que serão responsáveis pela
implementação da solução devem desenvolver essas informações sobre o plano. Essas in-
formações serão incorporadas ao plano geral do projeto para determinar que impacto terá
a solução, se for o caso, sobre outras partes do projeto. Saber se a solução irá causar outros
problemas é de especial interesse. Por exemplo, a melhor saída para o problema com o
sistema de sensor pode ser encomendar uma nova peça de um fornecedor, mas se o forne-
cedor precisar de dois meses para fazer e enviar a peça, essa solução pode acabar atrasando
todo o projeto e pôr em risco sua conclusão na data exigida. Se esse fato não foi levado
em conta na etapa 5, a equipe de resolução de problemas precisará analisar novamente a
solução para determinar se ela ainda é a melhor opção.
8. Implemente a solução. Após o estabelecimento de um plano para a implementação
da melhor solução, os membros apropriados da equipe devem ir em frente e realizar as
respectivas tarefas.
9. Determine se o problema foi resolvido. Uma vez implementada a solução, é importante
determinar se o problema foi de fato resolvido. Nesse ponto, a equipe volta à declaração
de problema da etapa 1 e compara os resultados da implementação da solução com for-
mas de mensuração do problema definidas na declaração de problema. A equipe precisa se
perguntar: – A solução selecionada surtiu os efeitos esperados? O problema foi resolvido?
A solução pode ter resolvido o contratempo apenas parcialmente, ou talvez não tenha re-
solvido o problema de forma alguma. Por exemplo, talvez após a instalação da nova peça
encomendada para o sistema de sensores este continue fornecendo dados errôneos. Se o
defeito não foi resolvido, a equipe de resolução de problemas precisa voltar às etapas 2 e
3 para ver o que mais poderia estar causando o problema.
Dependendo da magnitude e da complexidade do problema, o processo de resolução
de problemas em nove etapas apresentado anteriormente pode levar de algumas horas a
vários meses. A equipe de resolução de problemas deve incluir as pessoas mais familiari-
zadas com o problema e também aquelas com conhecimentos específicos que podem ser
necessários. Às vezes, a pessoa com o conhecimento necessário vem de fora da equipe,
como um consultor, capaz de oferecer uma nova perspectiva sobre o problema.

35. Quais são as nove etapas envolvidas
na resolução de problemas?
Brainstorming
Brainstorming é uma técnica usada na resolução de problemas, na qual todos os membros
de um grupo contribuem com idéias espontâneas. Antes que os membros da equipe elejam
uma solução para um problema, eles devem se certificar de que exploraram o máximo de
opções e idéias possível. O brainstorming é uma forma de gerar um grande número de idéias
e se divertir com isso. O brainstorming gera empolgação, criatividade, melhores soluções e
maior comprometimento. É particularmente útil em duas fases da abordagem de nove eta-
pas para a resolução de problemas: etapa 2, identifique possíveis causas para o problema,
e etapa 4, identifique possíveis soluções.
Durante o brainstorming, a quantidade de idéias geradas é mais importante que a qua-
lidade das idéias. O objetivo é que o grupo produza o máximo de idéias possível, incluindo
idéias novas e pouco ortodoxas.
A equipe senta-se ao redor de uma mesa, tendo um mediador com um flip chart ou
quadro-branco para anotar as idéias. Para começar o processo, um membro declara uma
idéia. Por exemplo, durante uma sessão de brainstorming para um projeto que está atra-
sado em duas semanas, o primeiro membro pode dizer: “fazer hora extra”. Depois é a vez
de o próximo membro declarar uma idéia, como: “adicionar colaboradores temporários”.
E assim por diante. O processo continua ao redor da mesa, com cada pessoa declarando
apenas uma idéia por vez. Se não conseguir pensar em nada quando for a vez dela, ela
simplesmente diz “passo”. Algumas pessoas trarão sugestões que complementam idéias
previamente mencionadas por outras. A complementação envolve a combinação de várias
idéias em uma, ou o aprimoramento de uma idéia de outra pessoa. À medida que as idéias
são dadas, o mediador as anota no flip chart ou no quadro. Esse processo circular continua
até que ninguém mais consiga ter uma idéia nova, ou até que o tempo acabe.
Duas regras importantes devem ser seguidas para que o brainstorming funcione: sem dis-
cussão e sem comentários de julgamento. Assim que o participante expressar sua idéia, é a vez
do próximo. As pessoas devem simplesmente expressar uma idéia – e não discutir, justificar
ou tentar vendê-la. Os demais não podem fazer nenhum tipo de comentário, nem de apoio
nem de julgamento, e ninguém pode fazer perguntas para a pessoa que declarou a idéia. É
evidente que comentários “matadores”, do tipo, “Isso nunca vai dar certo”,”Essa é uma idéia
idiota” ou “O chefe não vai querer isso” não são permitidos, e os participantes também devem
ter o cuidado de não usar linguagem corporal – erguer as sobrancelhas, tossir, sorrir malicio-
samente ou suspirar – para enviar mensagens de julgamento.

36. Em uma sessão de brainstorming,
a ______________ de idéias geradas é
mais importante do que a ____________
das idéias.
O brainstorming pode ser uma maneira divertida e eficaz de ajudar uma equipe de
resolução de problemas a chegar à melhor solução possível.
GESTÃO DO TEMPO
As pessoas envolvidas em um projeto normalmente ficam bastante ocupadas trabalhando
nas tarefas atribuídas a elas, fazendo comunicações, preparando documentos, participando
de reuniões e viajando. Portanto, uma boa gestão de tempo é essencial para uma equipe de
projeto de alto desempenho. A seguir, estão algumas sugestões para ajudar você a gerenciar
seu tempo de forma eficaz:
1. Ao final de cada semana, identifique várias (de duas a cinco) metas que quer al-
cançar na próxima semana. Relacione as metas em ordem de prioridade, com a mais
importante (não a mais urgente) primeiro. Leve em consideração o tempo que você terá
disponível; observe seus horários para aquela semana para ver se estão agendadas reuniões
ou outros compromissos. Não tente criar uma lista com várias páginas, extensiva, com todas
as coisas que gostaria de fazer. Mantenha essa lista de metas à vista, para que a veja com
freqüência.
2. Ao final de cada dia, faça uma lista de coisas para o dia seguinte. Os itens da lista
diária de coisas a fazer devem viabilizar o cumprimento das metas que estabeleceu para a
semana. Relacione os itens em ordem de prioridade, novamente com o mais importante (e
não necessariamente o mais fácil ou mais urgente) primeiro. Antes de preparar a lista de
coisas a fazer, observe seus horários para o dia seguinte, para verificar quanto tempo você
terá disponível para dedicar à realização de cada item da lista. Reuniões ou compromissos
podem reduzir a quantidade de tempo disponível. É bom deixar um pouco de tempo livre
na em agenda do dia para acomodar imprevistos. Não faça uma lista extensa de tudo o que
gostaria de fazer se não houver tempo para fazer tudo – isso só causa frustração.
Relacione apenas aquilo que puder realmente ser feito. Não crie o hábito de julgar que
tudo o que não for feito pode simplesmente ser adiado para o próximo dia. Você vai acabar
com mais itens adiados que realizados!
É importante escrever a lista em algum lugar, e não apenas memorizá-la. O ato de escre-
vê-la gera o compromisso de cumpri-la.
3. Leia a lista de metas antes de qualquer outra coisa na manhã seguinte e mantenha-a
à vista o dia todo. Deixe todas as outras coisas de lado e comece a trabalhar no primeiro
item. Foco e autodisciplina são extremamente importantes. Não desvie sua atenção para itens
menos importantes que possam ser menos desafiadores, como ler e arquivar seus e-mails.
Quando completar uma tarefa, risque-a da lista; isso dará uma sensação de dever cumpri-
do. Em seguida, comece o próximo item. Mais uma vez, não se deixe envolver com tarefas
menos importantes no intervalo entre as conclusões dos itens de sua lista.
4. Controle interrupções. Não permita que ligações telefônicas, mensagens de e-mail ou
visitantes desviem sua atenção da realização dos itens de sua lista. Você pode reservar um
espaço de tempo todos os dias para retornar e fazer ligações e checar seus e-mails em vez
de permitir que isso interrompa seu trabalho ao longo do dia. Sua porta deve ficar fecha-
da durante um tempo para que as pessoas saibam que você não deseja ser interrompido.
Quando estiver trabalhando em um item específico da sua lista, afaste outros papéis para
acabar com a tentação de pegá-los e começar a pensar em outra coisa.
5. Aprenda a dizer não. Não se deixe envolver em atividades que vão consumir seu
tempo, mas não irão contribuir para a realização de suas metas. Você pode ter de recusar
convites para participar de reuniões ou viagens, atuar em comitês ou revisar documentos.
Talvez seja necessário cortar bate-papos de corredor. Aprenda a dizer não, ou se compro-
meterá demais, tornando-se uma pessoa muito ocupada sem atingir suas metas.
6. Faça bom uso do tempo de espera. Por exemplo, sempre leve um material de leitu-
ra para o caso de ficar preso em um aeroporto, congestionamento ou no consultório do
dentista.
7. Tente lidar com a maior parte da papelada de uma só vez. Cuide de suas correspon-
dências ou e-mails no fim do dia, para não se distrair de sua lista. Pode haver alguma coisa
em suas correspondências que o leve a acrescentar um item nas atividades, para o próximo
dia. Ao verificar suas correspondências, tome uma providência em relação a cada documen-
to enquanto estiver segurando-o ou lendo-o:
• Se for uma mensagem não solicitada (junk mail), jogue fora ou exclua sem ler.
• Se for possível jogar a mensagem fora ou excluí-la depois de lida, faça isso; arquive so-
mente mensagens que você não conseguirá encontrar em outro lugar quando precisar.
• Se a mensagem precisar de resposta, escreva-a à mão no documento e devolva-o ao
remetente ou digite uma breve resposta de e-mail.
• Se o documento exigir muito tempo para ser lido, reserve um horário em suas listas
futuras de coisas a fazer (caso o item possa ter uma contribuição importante para
• O sucesso de um projeto exige uma equipe eficaz. Embora sejam necessários pla-
nos e técnicas de gestão de projetos, as pessoas – o gestor e a equipe do projeto
– são o segredo para o sucesso do projeto.
• Reunir um grupo de pessoas para trabalhar em um projeto não cria uma equipe.
Colaborar para o desenvolvimento e o crescimento dessas pessoas, a fim de formar
uma equipe coesa e eficaz, exige esforço por parte do gestor do projeto e de cada
membro da equipe.
• As características das equipes de projeto eficazes incluem um entendimento claro
do objetivo do projeto, expectativas claras em relação ao papel e às responsabilida-
des de cada pessoa, uma orientação aos resultados, um alto grau de cooperação e
colaboração e um alto nível de confiança.
• Cada membro da equipe do projeto precisa ajudar a criar e incentivar um ambiente
de projeto positivo.
• Membros de equipes eficazes têm expectativas elevadas em relação a si mesmos.
Eles planejam, controlam e sentem-se responsáveis por seu trabalho individual.
• Membros de equipes eficazes têm uma comunicação aberta, franca e oportuna.
Eles prontamente compartilham informações, idéias e sentimentos. Eles oferecem
feedback construtivo uns aos outros.
• Membros de equipes eficazes vão além de simplesmente realizar as tarefas atribuí-
das a eles; eles agem como recursos uns para os outros.
• O gestor e a equipe precisam reconhecer abertamente que existe a possibilidade de
divergências durante a execução do projeto e chegar a um consenso sobre como os
conflitos devem ser administrados.
• Equipes de projeto eficazes resolvem os conflitos pelo feedback construtivo e opor-
tuno e da confrontação positiva dos problemas. O conflito não é suprimido; ao con-
trário, ele é encarado como normal e como uma oportunidade de crescimento.
• Se administrado corretamente, o conflito pode ser benéfico. Ele traz os problemas à
tona para que sejam abordados. Além disso, incentiva a discussão e exige que as pes-
soas esclareçam seus pontos de vista. Também pode estimular a criatividade e me-
lhorar a capacidade de resolução de problemas.
• O conflito não deve ser tratado e resolvido apenas pelo gestor do projeto; os confli-
tos entre membros da equipe devem ser tratados pelas pessoas envolvidas.
• Cada pessoa deve abordar o conflito com uma atitude comunicativa e com disposi-
ção para trabalhar de boa-fé com as outras pessoas para resolver os problemas.
• Para gerir o tempo de forma eficaz, os membros da equipe devem estabelecer me-
tas semanais e fazer uma lista de tarefas para cada dia.
suas metas semanais) ou coloque-o em sua pasta para que você possa lê-lo enquanto
estiver preso a caminho de algum lugar (veja item 6 antes).
8. Recompense-se no fim da semana se tiver cumprido todas as suas metas. Seja honesto
com você mesmo. Recompense-se por atingir todas as suas metas, e não por trabalhar duro
e ficar ocupado, mas sem atingi-las. Para você, a recompensa deve ser um incentivo ou
compensação diretamente ligados ao cumprimento de suas tarefas. Se você não atingir suas
metas semanais, não se recompense. Do contrário, a recompensa não terá significado e não
constituirá um incentivo para você atingir suas metas.

37. Quais são algumas das coisas que
você pode fazer para administrar o
tempo com eficácia?
RESUMO
Uma equipe é um grupo de pessoas que trabalham independentemente para alcançar um
objetivo comum. O trabalho em equipe é o esforço cooperativo por parte dos membros de
uma equipe em alcançar esse objetivo comum. A eficácia da equipe do projeto – ou a falta
dela – pode fazer a diferença entre o sucesso ou o fracasso do projeto.
As equipes de projeto passam por vários estágios de desenvolvimento. A formação, o
estágio inicial do processo de desenvolvimento da equipe, envolve a transição em que
a pessoa passa de indivíduo para membro de equipe. Durante esse estágio, os membros
começam a se conhecer. Durante o estágio de agitação, os conflitos aparecem e a tensão
aumenta. A motivação e a auto-estima ficam baixas. Os membros podem até resistir a uma
formação de equipe. No entanto, depois de enfrentar a fase de agitação, a equipe passa
para o estágio de normalização. Até esse momento, as relações entre os membros da equipe
e entre a equipe e o gestor do projeto normalizam-se, e a maioria dos conflitos interpessoais
é resolvida. O quarto e último estágio do desenvolvimento e crescimento é o estágio de
execução. Nesse estágio, a equipe está altamente comprometida e ansiosa para alcançar o
objetivo do projeto. Os membros têm um sentimento de união.
As características geralmente associadas a equipes de projeto eficazes incluem um bom
entendimento do objetivo do projeto, claras expectativas sobre o papel e as responsabili-
dades de cada pessoa, uma orientação aos resultados, um alto grau de cooperação e cola-
boração e um nível alto de confiança. As barreiras para a eficácia da equipe incluem metas
pouco definidas, definição pouco nítida do papel e das responsabilidades, falta de estrutura
de projeto, ausência de comprometimento, má comunicação, má liderança, rotatividade dos
membros da equipe do projeto e comportamento disfuncional.
A construção de equipe – desenvolver um grupo de pessoas que cumpra com o ob-
jetivo do projeto – é um processo contínuo. É uma responsabilidade tanto do gestor do
projeto quanto da equipe do projeto. A socialização entre os membros da equipe favorece
a construção da equipe. Para facilitar a socialização, eles podem pedir que sejam dispostos
fisicamente em um único andar de escritórios durante todo o projeto, além de participar
em eventos sociais.
O comportamento ético é necessário em projetos e é crucial nas relações de negócios
dos membros do projeto com o cliente, com os fornecedores e com as empresas terceiri-
zadas. Os clientes e os fornecedores querem fazer negócios com um contratante ou uma
organização de projeto em que possam confiar. A intenção de distorcer os fatos, fraudar e
fazer declarações falsas é totalmente antiética. Existem duas ações que uma organização de
projeto pode adotar para ajudar a prevenir uma má conduta: apresentar uma diretriz por
escrito sobre comportamento ético e providenciar um treinamento sobre ética no trabalho.
A diretriz sobre comportamento ético deve incluir temas como expectativas, processo de
denúncia de má conduta e as conseqüências de se cometer práticas antiéticas. Má conduta
ou conflito de áreas de interesse devem ser solucionados e deve-se tomar uma ação disci-
plinar apropriada para mostrar que esse tipo de comportamento é inadmissível e que não
será tolerado. Cada membro da equipe do projeto deve se sentir responsável por seus atos.
A integridade das pessoas é o alicerce para a ética no trabalho.
Os conflitos são inevitáveis. Pode surgir um conflito em diferentes situações, envolven-
do membros da equipe do projeto, o gestor do projeto e até mesmo o cliente. As fontes
de conflitos em potencial em projetos incluem diferenças de opinião sobre: como o traba-
lho deve ser feito, quanto do trabalho deve ser realizado, em que nível de qualidade ele
deve ser feito, quem deve ser designado para trabalhar em cada tarefa, em que seqüência
o trabalho deve ser feito, quanto tempo o trabalho deve levar e quanto deve custar. Um
conflito também pode surgir por causa de preconceitos ou de diferenças de valores e ati-
tudes pessoais.
Os conflitos não devem ser resolvidos somente pelo gestor do projeto. Um conflito en-
tre os membros da equipe deve ser solucionado pelas próprias pessoas envolvidas. Se for
tratado adequadamente, o conflito pode ser benéfico, pois ajuda os problemas a virem à
tona e serem resolvidos.
Não é comum que uma equipe execute todo um projeto sem se deparar com alguns pro-
blemas pelo caminho. As nove etapas para um bom processo de resolução de problemas
são: desenvolver uma declaração do problema, identificar possíveis causas, reunir dados e
verificar as causas mais prováveis, identificar possíveis soluções, avaliar as soluções alter-
nativas, determinar a melhor solução, revisar o plano do projeto, implementar a solução e
determinar se o problema foi resolvido. Brainstorming é uma técnica usada na resolução
de problemas na qual todos os membros de um grupo contribuem com idéias espontâneas.
No brainstorming, a quantidade de idéias geradas é mais importante do que a qualidade
das idéias.
Uma boa gestão de tempo é essencial para uma equipe de projeto de alto desempenho.
Para que gerenciem o tempo de forma eficaz, os membros da equipe devem identificar se-
manalmente várias metas, fazer a cada dia uma lista de afazeres, focar-se na execução da
lista de cada dia, controlar interrupções, aprender a dizer não para as atividades que não
contribuirão para a realização das metas, fazer bom uso do tempo de espera, tentar lidar com
a maior parte da papelada de uma só vez e recompensar-se pelo cumprimento das metas.
PERGUNTAS
1. Discuta os estágios do desenvolvimento de equipe. Descreva o processo, os problemas
e o nível de produtividade de cada estágio.
2. Quais são algumas das características associadas a equipes de projeto eficazes? Pode-se
dizer o mesmo para a eficácia de um casal, de uma orquestra ou de um time de futebol
profissional? Por que sim ou por que não?
3. Quais são algumas das barreiras comuns para a eficácia da equipe? Pense em um pro-
jeto em equipe em que esteja trabalhando. Discuta sobre as barreiras para o sucesso
desse projeto.
4. Por que se diz que não há um EU na palavra EQUIPE? Você concorda ou discorda? Por
quê?
5. Ao trabalhar em um projeto em classe, como você pode ser um membro eficaz?
6. Descreva três atividades que facilitam o processo de construção da equipe. O gestor do
projeto deve iniciar todas elas?
7. Qual é o papel desempenhado pelo gestor do projeto em relação ao comportamento
ético da equipe? Quais são as etapas que podem ser tomadas para ajudar a assegurar
um alto nível de comportamento ético? Descreva uma situação em que você ficou em
confrontação entre uma decisão ética e o resultado de sua decisão.
8. Discuta alguns tipos de conflitos que podem surgir durante um projeto. Descreva duas
situações em que você tenha vivido esses tipos de conflito.
9. Descreva os métodos de lidar com conflitos em um projeto. Como o conflito foi contro-
lado na situação descrita na resposta da questão 7?
10. O gerente de um banco local observou que, depois da instalação de um novo sistema
de informação na instituição, algumas das transações dos clientes não estavam sendo
registradas. Ele sabia que esse problema poderia levar a sérias dificuldades financeiras,
como também ao descontentamento dos clientes. Descreva como ele poderia aplicar o
processo de resolução de problema em nove etapas descrito neste capítulo para solu-
cionar o problema.
11. Com um amigo, conduza uma sessão de brainstorming para mencionar o maior núme-
ro possível de palavras relacionadas ao corpo humano que tenham apenas três letras.
12. Como as pessoas podem administrar o tempo de maneira mais eficaz? Qual dessas su-
gestões você pratica atualmente? Para a próxima semana, tente administrar melhor o seu
tempo. Siga todos os conselhos dados no livro. No fim da semana, escreva um resumo
de sua experiência.
~clements.
1. Pesquise na Internet para descobrir idéias sobre equipes eficazes de projeto. Resuma
o que encontrar e compare com o que foi apresentado neste capítulo.
2. Busque na web idéias sobre fontes de conflito e estratégias para a resolução de con-
flitos. Resuma o que encontrar e compare com o que foi apresentado neste capítulo.
3. Procure idéias sobre gestão de tempo. Imprima pelo menos um site e discuta aquelas
que você acredita serem as cinco estratégias mais eficazes para a gestão de seu tempo.
4. A ProjectNet é uma organização do Reino Unido que edita uma revista mensal cha-
mada Project Manager Today. Visite o site da revista no endereço: http://www.
pmtoday.co.uk e cadastre-se para receber uma edição grátis de cortesia.
5. Procure na Internet um estudo de caso sobre a formação de equipes de projeto. O
gestor de projeto teve sucesso na formação de sua equipe? Justifique sua resposta.
Descreva pelo menos um dilema ético que o gestor ou a equipe do projeto podem
ter enfrentado durante o projeto.
ESTUDO DE CASO nº 1 RD Processing

A RD Processing, Inc. é uma empresa que presta serviços de processamento de dados para
outras empresas locais. Ela está nesse ramo há 20 anos e tem 90 funcionários, dos quais
60 trabalham no edifício Big Tower, em uma região comercial no subúrbio de uma cida-
de grande. Quarenta dessas pessoas trabalham no quinto andar, onde a empresa aluga o
espaço há 12 anos; as outras 20 ficam no nono andar, onde a empresa conseguiu alugar
mais espaço à medida que foi crescendo. As pessoas dessas duas áreas encontram-se no
restaurante do edifício, mas não se conhecem muito bem. Seis meses atrás, a RD Processing
comprou a DataHelps, uma firma semelhante, quando seu dono decidiu se aposentar. Esta
está no mercado há dez anos, tem 30 funcionários e fica localizada do outro lado da cidade,
no edifício comercial Green Valley.
O Big Tower II, um novo edifício comercial, foi recentemente construído ao lado do
edifício original, o Big Tower. Maria Alomar, proprietária da RD Processing, tem a opção
de alugar um andar inteiro no Big Tower II. Isso seria espaço suficiente para alojar todos os
90 funcionários em um mesmo local e ainda deixar espaço para crescimento.
Maria estabeleceu uma equipe de projeto de três pessoas, uma de cada localidade atual,
para sugerir um leiaute ao novo espaço comercial. Christina Lin, que trabalha no quinto an-
dar, é supervisora e está na empresa há 18 anos. Jessica Tarasco, que trabalha no nono andar,
é a especialista em computação, e está na empresa há 5 anos. Sharon Nesbitt, que atua no
processamento de dados, trabalha no edifício Green Valley e está na DataHelps desde que
a empresa foi aberta, há 10 anos.
A equipe de projeto está realizando sua primeira reunião na sala de conferências da

empresa, no quinto andar do edifício Big Tower. Sharon chega atrasada. É apenas sua se-
gunda visita ao edifício, e o trânsito estava pior do que ela havia imaginado. Christina fala
primeiro: – Conheço bastante o fluxo de trabalho e os problemas e tenho uma idéia bem
clara de como devemos usar o novo espaço para o qual nos mudaremos.
– Nós vamos mesmo nos mudar para aquele novo espaço?, pergunta Sharon.
– Sim, responde Christina abruptamente.
Jessica se manifesta. – Um dos meus vizinhos me disse que sua empresa passou por uma
consolidação semelhante, e eles fizeram um levantamento com todos os funcionários para
pedir sua opinião. Talvez devêssemos fazer algo semelhante.
– Não precisamos perder tempo fazendo isso, afirma Christina. – Trabalho aqui há tem-
po suficiente para saber o que precisa ser feito.
– Acho que você está certa, diz Jessica.
Christina continua: – Agora, vamos ao trabalho. Eu sugiro...
Sharon interrompe: – Consolidação? Você disse consolidação? Isso significa que vamos
fazer cortes? É isso? Ouvi boatos sobre demissões quando a RD Processing adquiriu a Da-
taHelps.
– Isso é ridículo!, responde Christina.
– Demissões? Mesmo?, pergunta Jessica. – Eles nunca me demitirão, não com os meus
conhecimentos de informática. Eles precisam muito de mim. Além disso, eu arrumaria outro
emprego em um minuto.
– Estamos nos desviando do assunto, intervém Christina. – Vamos trabalhar, senão fica-
remos aqui o dia todo.
– Espere um pouco, Sharon interrompe novamente. – Temos assuntos mais importantes
para tratar aqui do que essa porcaria de leiaute de escritório! Estou dizendo, ninguém que
trabalha no Green Valley quer se mudar para o novo escritório. Gostamos de onde estamos.
Podemos ir até o shopping a pé na hora do almoço, e os funcionários deixam seus filhos na
escolinha do outro lado da rua. E vamos ter de dirigir mais 30 minutos para ir e voltar do
trabalho todos os dias. As pessoas podem não conseguir chegar para pegar seus filhos antes
que a escolinha feche, às 18 horas. Acho que temos muitos outros problemas para resolver
antes de pensarmos em leiaute de escritório. Não existem mais alternativas?
– Estou aberta para sugestões, diz Jessica.
Christina suspira, olha para baixo, e diz diretamente: – Você está deixando isso mais
complicado do que precisa ser. Podemos passar agora para o leiaute do escritório? Não é
isso o que deveríamos estar fazendo?
PERGUNTAS
1. Por que Maria quer se mudar para um novo edifício comercial? Quais são algumas das
vantagens e desvantagens da mudança?
2. Christina, Jessica e Sharon estão atuando como uma equipe de forma eficaz? Justifique
sua resposta.
3. O que Christina, Jessica e Sharon deveriam ter feito de forma diferente?
4. Dê algumas sugestões sobre como essa equipe pode funcionar de forma mais eficaz.
ATIVIDADE EM GRUPO
Conduza uma discussão aberta entre os participantes do curso sobre as seguintes questões:
• Como a equipe deveria proceder?
• Como cada um dos membros da equipe poderia ter lidado melhor com a situação?
ESTUDO DE CASO Nº 2 Problemas em Equipes

Colin e Raouf estão tendo uma de suas típicas conversas paralelas durante uma reunião
quando Henri, claramente irritado, olha para Colin. – Nos meus 20 anos de experiência,
nunca vi um design de hardware tão ruim. Um aluno do primeiro ano de faculdade faria
melhor, disse Henri, levantando a voz para Colin. – Não é de se espantar que estejamos
atrasados um mês no cronograma. Agora vamos ter de gastar mais tempo e dinheiro para
fazer um novo design. Se estivesse em sã consciência, Colin, deveria ter pedido a ajuda
de alguém. Vou discutir a situação com Jack quando ele voltar na sexta. É isso – reunião
encerrada. Precisamos passar mais tempo trabalhando do que batendo papo nas reuniões.
Todos os outros membros da equipe de projeto ficaram um tanto surpresos pelo sermão de
Henri, mas essa não foi a primeira vez. Eles sentiram muito por Colin, mas outros deles já
haviam sentido a ira de Henri no passado.
Henri é líder da equipe de sistemas de hardware, e Colin é o projetista de sistemas de
hardware designado para a equipe de Henri. Jack, o gestor do projeto, ficou fora da cidade
vários dias para uma reunião com o cliente e pediu que Henri realizasse a reunião semanal
de projeto em sua ausência.
Após a reunião, Colin foi até a sala de Raouf, que é o desenvolvedor de software. Colin
e Raouf criaram laços de amizade no último ano. Os dois descobriram que se formaram na
mesma universidade, com poucos anos de diferença. Eles estão entre os jovens membros
da equipe de projeto, com Fátima, a líder da equipe de sistemas de software. – Vou pegar
esse babaca, nem que seja a última coisa que faça, Colin disse a Raouf.
– Calma, Colin. Você tem razão: ele é um babaca. Todos sabem que ele não sabe o que
está fazendo; pois não tem capacidade para isso. Nós todos sabemos qual é a dele, res-
pondeu Raouf. – Mas observe que Henri nunca se comporta dessa forma na frente de Jack.
Só quando Jack não está por perto ou em reuniões das quais ele não participa, continuou
Raouf.
– Bem, vou falar com Jack logo cedo na sexta-feira quando ele voltar e contar-lhe sobre
Henri. Ninguém precisa agüentar esse tipo de coisa na frente de todo mundo, disse Colin.
– Talvez você devesse conversar com Henri primeiro, Colin, sugeriu Raouf.
– Ah, sim!, ironizou Colin.
– O que você pensa que Jack irá fazer?, perguntou Raouf.
– Demiti-lo, espero, respondeu Colin.
– Duvido, Raouf afirmou: – Jack está sempre relevando as coisas com Henri, como se
tivesse pena dele ou algo parecido.
– Talvez Jack devesse se preocupar com todas as boas maçãs e se livrar dessa maçã
podre!, retrucou Colin.
Jack voltou ao escritório na sexta-feira de manhã. Ele estava acabando de tirar o paletó
quando Colin apareceu. – Jack, em uma das reuniões de projeto, você disse que tinha uma
política de portas abertas, então vim aqui conversar sobre um problema com Henri, disse
Colin. Jack começou a abrir sua maleta, pois tinha muita coisa para fazer após ter estado
fora a semana toda. Ele viu que Colin estava chateado, então disse: – Claro, Colin, tenho uns
dez minutos antes de me reunir com nosso departamento de contratos para passar algumas
emendas no contrato.
Colin respondeu rapidamente: – Não vou me demorar. Só quero dizer que, na sua au-
sência, Henri me acusou de ser preguiçoso na frente de toda a equipe do projeto. Ele me
culpou pelo atraso de um mês. Ele sempre faz esse tipo de coisa. Por que você permite
que isso aconteça? Ninguém gosta dele. Você não pode se livrar dele ou designá-lo para
outro projeto?
Jack ficou surpreso. Ele respondeu: – Colin, você me parece realmente chateado. Vamos
nos reunir na segunda-feira, quando eu tiver mais tempo, e você aproveita o fim de semana
para esfriar a cabeça.
– Não há nada mais a dizer. É só isso. Você pode perguntar a qualquer um se não acre-
dita em mim, respondeu Colin enquanto saía da sala de Jack.
Jack pediu que Rosemary, sua assistente administrativa, que tinha intencionalmente ou-
vido a conversa de fora da sala de Jack, marcasse uma reunião com Henri para aquela tarde.
Na reunião, Jack conversou com Henri sobre os comentários de Colin. Jack sabia que Henri
estava estressado porque seu filho havia sido preso recentemente por venda de drogas.
Henri disse a Jack: – Tenho a impressão de que Jack exagerou e deu uma dimensão muito
grande para as coisas. Durante a reunião, disse a Colin que havia algumas falhas no seu
projeto e sugeri que ele se reunisse com alguns colegas e desse uma olhada nisso. Você
sabe como são esses jovens; eles precisam aprender a ser responsáveis por suas atitudes.
– E sobre o projeto estar atrasado? Isso é novidade para mim, perguntou Jack.
Henri respondeu: – Bem, não quis dizer que a culpa era de Colin. Para ser sincero, Fá-
tima e sua equipe de garotos craques em software não trabalham duro. Quer dizer, sempre
os vejo fazendo brincadeiras e rindo uns dos outros e importunando a minha equipe de
hardware. Não é de se espantar que o projeto esteja atrasado. De qualquer forma, não se
preocupe com Colin. Ele é jovem e precisa aprender a não levar críticas tão a sério. Vou
falar com ele. Vou dizer-lhe para parar de andar com a turma do software para que não
desenvolva outros hábitos ruins.
Naquela mesma sexta-feira, Colin passou convidando a maioria dos jovens membros
da equipe de projeto para tomarem um chope depois do expediente. Eram quase todos da
equipe de software, além de Rosemary, assistente administrativa de Jack. Ela está interessa-
da em Colin e há tempos esperava que ele a convidasse para sair. Ela disse a Colin que ou-
viu Henri dizer a Jack que Fátima e a equipe de software estavam causando atrasos no pro-
jeto porque passavam muito tempo brincando em vez de trabalhar. Mais ao final da tarde,
Colin foi falar com Fátima e Raouf, que estavam juntos: – Tenho informações em primeira
mão de que Henri disse a Jack que o projeto está bastante atrasado por causa de sua equipe
de software. Sugiro que vá falar com Jack. Henri está envenenando esse projeto. Se Jack
acreditar nele, todos nós seremos demitidos antes que esse projeto acabe. Ei, tive coragem
de ir conversar com Jack. Agora vocês têm que fazer o mesmo. Temos que nos unir contra
Henri. Jack precisa saber que Henri não toma cuidado com o que fala e está desunindo
toda a equipe de projeto, provocando discórdia, e é por isso que o projeto está atrasado.
Em outras palavras, o projeto nunca vai dar certo enquanto Henri estiver trabalhando nele.
E isso vai afetar a carreira de todos nós – ficarmos associados a um projeto que não deu
certo. Jack não vai ter escolha quando perceber que somos todos nós contra Henri.
PERGUNTAS
1. Quais são algumas das coisas que Colin poderia ter feito durante ou após a reunião
quando Henri o atacou verbalmente?
2. Há mais alguma coisa que Raouf poderia ter feito durante ou após sua reunião com
Colin para evitar que a situação piorasse?
3. Jack poderia ter levado essa reunião com Colin de uma forma melhor? Há alguma coisa
que Jack poderia ter feito após sua reunião com Colin e antes de se encontrar com Hen-
ri? Quais são algumas das coisas que Jack poderia ter feito em sua reunião com Henri?
4. O que Fátima deveria fazer?
ATIVIDADE EM GRUPO
Divida a classe em quatro grupos e distribua uma das perguntas relacionadas ao caso para
cada grupo. Peça que eles discutam a pergunta e formulem respostas. Cada grupo deve
eleger um porta-voz para apresentar suas respostas na frente da classe.
Capítulo COMUNICAÇÃO E DOCUMENTAÇÃO
DO PROJETO
12 Comunicação Pessoal
Comunicação Oral
Comunicação Escrita
Documentação de Projeto e
Controle de Mudanças
Resumo
Perguntas
Ouvindo de Forma Eficaz
Reuniões Exercícios na Internet
Tipos de Reunião de Projeto Estudo de Caso no 1 Comunicação
no Escritório
Reuniões Eficazes
Perguntas
Apresentações
Atividade em Grupo
Preparando-se para uma
Apresentação Estudo de Caso no 2 Comunicação
Internacional
Fazendo a Apresentação
Perguntas
Relatórios
Atividade em Grupo
Tipos de Relatórios de Projeto
Preparando Relatórios Úteis
346
Ca pítulo Doze
A comunicação com Imagens Digitais na Indústria da Construção
As imagens digitais tornaram-se componentes essenciais para a documentação de proje-
tos na indústria da construção. Os gestores de projetos descobriram que as imagens digi-
tais são úteis para os projetos de construção por proporcionarem uma comunicação rápida
e eficaz entre as diversas pessoas que participam da equipe. Com imagens digitais, o gestor
de projetos pode rapidamente mostrar o progresso aos proprietários da construção ou
apresentar aos arquitetos, engenheiros e empreiteiros os problemas que requerem aten-
ção imediata.
Alguns recursos especiais das câmeras digitais permitem proteger as imagens, como
a impressão da data e hora nas fotos e um software usado para impedir sua adulteração,
o que podem fazer uma foto digital ser útil tanto para argumentar a favor quanto contra
uma queixa legal.
Michael Mahesh, da Bechtel Corp., tirou mais de 10 mil fotos digitais em 16 meses,
durante a Fase 1 do Projeto de Restauração Urbana/PATH. Ele entrou para o projeto em
2002 como engenheiro de controle para ajudar a restabelecer o serviço ferroviário da Auto-
ridade Portuária Trans-Hudson (PATH) entre Nova Jersey e o centro da cidade de Nova York.
A Fase 1 do projeto é a construção de uma estação provisória da PATH no local do World
Trade Center (WTC) em Nova York, com serviços de colocação de trilhos e escavação de
túnel, além da expansão da estação ferroviária Exchange Place, na cidade de Jersey, Nova
Jersey.
A Fase 2 inclui a construção de um terminal fixo no local do WTC. Essas imagens di-
gitais da Fase 1, de US$ 566 milhões, podem ser dispostas em um álbum de fotos para
documentar com eficácia o progresso do projeto. As fotos podem facilmente substituir
centenas de páginas de anotações geradas no passado, quando as máquinas digitais ainda
não tinham se tornado um instrumento popular de documentação.
Essa nova forma de comunicação de projeto permite que arquitetos, engenheiros,
empreiteiros e proprietários acompanhem as operações juntos e respondam aos proble-
mas na hora certa, além de fazer deles melhores comunicadores. As grandes vantagens
são a transparência, a economia e a velocidade. As fotos digitais podem também ajudar a
justificar queixas legais válidas, como também invalidar outras. Essa tecnologia é de fácil
acesso, já que as máquinas custam, em média, de US$ 400 a US$ 600. Como resultado, a
relação custo–benefício é bastante compensadora para seu uso no setor da construção.
Tudor, H. Project Teams Use Digital Cameras to Shoot It, Then Share It. Engineering News Record, v. 251, n. 26, 29 de dezembro
de 2003.
North Jersey Transportation Planning Authority Inc., FY 2005 Unified Planning Work Program. Volume VI: Other Regional Trans-
portation Planning Initiatives, p. 25.
347
Este capítulo discute um elemento vital para o desempenho eficaz de um projeto: a

comunicação. Ela acontece entre a equipe do projeto e o cliente, entre os membros da
equipe do projeto e entre a equipe do projeto e hierarquias superiores. A comunicação
pode envolver duas pessoas ou um grupo. Ela pode ser oral ou escrita. Pode acontecer
pessoalmente ou envolver alguns meios de comunicação, como telefone, mensagem de
voz, e-mail, cartas, memorandos, videoconferência ou um software de rede. Pode ser for-
mal, como por meio de um relatório ou uma apresentação em uma reunião, ou informal,
como uma conversa no corredor ou uma mensagem de e-mail. Este capítulo trata de
muitos formatos de comunicação. Você aprenderá:
• sugestões para aumentar a comunicação pessoal, como discussões frente a frente,
conversas por telefone, cartas e memorandos;
• a ouvir de forma eficaz;
• vários tipos de reuniões de projeto e sugestões para uma reunião eficaz;
• apresentação formal de projeto e sugestões para uma apresentação eficaz;
• relatórios de projeto e sugestões sobre como preparar relatórios úteis;
• documentação de projeto e controle de mudanças.
COMUNICAÇÃO PESSOAL
Uma comunicação pessoal freqüente e eficaz é crucial para manter o progresso do projeto,
identificar problemas em potencial, solicitar sugestões para melhorar o desempenho do
projeto, manter-se informado sobre a satisfação do cliente e evitar surpresas. A comunica-
ção pessoal pode dar-se por meio de palavras ou por linguagem não-verbal, como a lingua-
gem corporal. Ela pode acontecer pessoalmente ou envolver alguns meios de comunicação,
como telefone, mensagem de voz, e-mail, cartas, memorandos, videoconferência ou um
software de rede. A comunicação pessoal pode ser oral ou escrita.
Comunicação Oral
A comunicação pessoal oral pode acontecer pessoalmente ou por telefone, por mensagem
de voz ou videoconferência. A informação pode ser transmitida de maneira mais precisa
e oportuna por meio da comunicação oral. Esse tipo de comunicação propicia um espaço
para discussões, esclarecimentos, entendimentos e um feedback imediato. A comunicação
frente a frente também propicia uma oportunidade para observar a linguagem corporal que
acompanha a comunicação. Até mesmo a conversa por telefone permite ao interlocutor
perceber o tom, a inflexão e a emoção da voz. A linguagem corporal e o tom de voz são
elementos importantes que enriquecem a comunicação oral. As situações frente a frente
possibilitam uma oportunidade ainda maior para uma rica comunicação que uma conversa
por telefone.

1. Identifique dois tipos de comunicação
pessoal oral.

2. A linguagem corporal pode ser
usada não só pela pessoa que fala,
mas também pelo _________________,
como uma maneira de dar um _________
_____ para a pessoa que fala.
Capítulo 12 Comunicação e Documentação do Projeto 349
A linguagem corporal pode ser usada não somente pela pessoa que fala, mas também
pelo ouvinte, como reação à mensagem. A linguagem corporal positiva pode incluir o
contato olho no olho, um sorriso, gestos com as mãos, corpo ereto e sinais de positivo
com a cabeça. A linguagem corporal negativa pode ser o franzimento das sobrancelhas, os
braços cruzados, a cabeça baixa, uma inquietação, um olhar fixo ou um desvio de olhar, a
distração com papéis ou um bocejar. Nas comunicações pessoais, as pessoas precisam ser
sensíveis à linguagem corporal, que reflete a diversidade cultural dos participantes, sejam
eles outros membros da equipe, seja o cliente. Ao comunicar-se com pessoas de outras cul-
turas ou países, você precisa estar informado de seus costumes com relação a cumprimentos,
gestos, presentes e protocolo. Por exemplo, os gestos, a proximidade da pessoa com quem
está falando e o contato físico têm diferentes significados em diferentes culturas.

3. Na comunicação pessoal, as pessoas
precisam ser sensíveis à linguagem
corporal que reflete a ________________
_________ dos participantes.
Ao comunicar-se oralmente, a pessoa deve tomar cuidado para não fazer comentários
ou usar palavras e frases que possam ser interpretados como machistas, racistas, precon-
ceituosos ou ofensivos. Para ser ofensivo, um comentário não tem de ser necessariamente
dirigido a uma pessoa em particular. Uma observação feita em um grupo pode ser desagra-
dável para várias pessoas. Algumas podem julgar que certa declaração seja danosa a elas
mesmas ou a um conhecido. Mesmo quando feitos sem intenção ou só de brincadeira, os
comentários sobre ética, apelidos, dialetos, religião, características físicas, aparências ou
maneirismos podem ser ofensivos.
Um alto grau de comunicação frente a frente é especialmente importante no início do
projeto para cultivar a construção de equipe, desenvolver boas relações de trabalho e es-
tabelecer expectativas mútuas. Dispor a equipe do projeto em uma área comum facilita a
comunicação. É muito mais fácil ir até a sala de alguém para perguntar alguma coisa que
ligar para a pessoa e talvez esperar vários dias para receber um retorno. No entanto, uma
mensagem de voz permite às pessoas se comunicarem oralmente de maneira oportuna, en-
quanto isso não é possível em uma comunicação frente a frente. Nem sempre é viável situar
a equipe de projeto em uma área comum, principalmente se a equipe possui membros ou
terceirizados de diferentes localidades geográficas. Nesse caso, uma videoconferência pode
ser útil, se for acessível.

4. Os membros da equipe do projeto
precisam ser ___________ para iniciar
uma comunicação oportuna para
_________ e ________ informações.
Os membros da equipe de projeto precisam ser proativos para iniciar uma comunicação
oportuna com os demais integrantes e com o gestor de projetos para obter e fornecer infor-
mações, em vez de esperar o dia de uma reunião de equipe, que pode acontecer depois de
várias semanas. O gestor de projetos, em particular, deve sair de sua sala regularmente e se
dirigir a cada membro da equipe. Ele deve tomar a iniciativa de visitar o cliente ou ir à sala
do diretor para ter uma comunicação frente a frente, em vez de esperar ser chamado para
uma reunião. Se, para fazer uma visita ao cliente, é necessária uma longa viagem, o gestor
de projetos deve fazer ligações periódicas para se comunicar entre as visitas.

5. Identifique dois métodos que você
pode usar para dar feedback durante a
comunicação oral.
A comunicação oral deve ser direta e sem ambigüidades. Às vezes, tentar ser muito
diplomático, principalmente para comunicar um problema ou uma preocupação, pode pro-
vocar equívocos e resultar em falsas expectativas. Você precisa verificar se foi entendido o
que quis comunicar, pedindo um feedback da pessoa. Se não tiver certeza se algo que você
disse foi compreendido pela pessoa, pergunte a ela o que entendeu. Do mesmo modo, se
não estiver claro o que a outra pessoa está tentando comunicar, resuma o que você acha
que ela disse para assegurar um entendimento recíproco.
Por último, é importante saber a hora adequada para a comunicação oral. Por exemplo,
você não deve invadir o escritório de um colega de trabalho e interrompê-lo no momento em
que ele faz algo importante. Em vez disso, nessa situação, pergunte-lhe quando seria uma boa
hora para conversarem. Você deve dizer quanto de tempo precisa para conversar com ele e o
que quer discutir. Desse modo, ele saberá se deve esperar por uma conversa de dez minutos
sobre um assunto trivial ou por uma conversa de uma hora sobre um assunto crítico. Do
mesmo modo, ao ligar para outra pessoa, você deve determinar no início da ligação quais
são os temas que quer discutir e quanto tempo essa conversa pode demorar, bem como
perguntar em seguida se o momento é bom ou se você deve voltar a ligar em uma hora
mais conveniente.
Comunicação Escrita
A comunicação pessoal escrita é geralmente executada por meio de memorandos internos
para a equipe do projeto e cartas externas para o cliente ou para outras pessoas externas à
empresa, como os terceirizados. Esses meios de comunicação podem ser transmitidos em
cópias impressas por e-mail ou software de rede.
Memorandos e cartas são meios de se comunicar eficientemente com um grupo de
pessoas quando é impraticável fazer uma reunião ou quando as informações precisam ser
divulgadas rapidamente. A comunicação escrita deve ser usada somente quando necessário,
e não só para gerar papelada. Os participantes do projeto geralmente são muito ocupados e
não têm tempo para ler memorandos triviais que contenham informações que poderiam ser
comunicadas oralmente na próxima reunião de equipe.
Um memorando ou uma carta pode ser apropriado para depois de uma conversa frente
a frente ou de uma ligação telefônica para registrar decisões ou ações, em vez de somen-
te confiar na memória da pessoa. Quando um memorando é utilizado para registrar uma
comunicação oral, podem ser entregues cópias às pessoas que não participaram dessa co-
municação, mas que precisam saber das informações. Além disso, essa comunicação escrita
pode ser importante se um membro da equipe deixa o projeto – a pessoa que o substituirá
terá um registro das comunicações feitas com relação às ações e decisões anteriores.
A comunicação escrita deve ser usada principalmente para informar, confirmar e solicitar
algo – por exemplo, para lembrar a equipe do projeto de que o cliente fará uma visita em
certa data ou para solicitar aos membros que providenciem dados escritos para um relatório
trimestral de progresso do projeto para o cliente.

6. Quais são as duas formas de
comunicação escrita pessoal?
Os memorandos e as cartas devem ser claros e concisos, sem longas dissertações ou

anexos volumosos. Os participantes do projeto, por estarem sempre ocupados com suas
tarefas de trabalho, consideram que o excesso de papelada ou de e-mails mais atrapalha
do que ajuda.
OUVINDO DE FORMA EFICAZ

“Sei que você acha que entendeu o que você pensa que me ouviu dizer. Mas o que você
não vê é que o que você pensa que ouviu não é o que eu quis dizer.”

7. A falta da capacidade de ___________
pode causar uma ________________ na
comunicação entre as pessoas.
O coração da comunicação não são as palavras, e sim a compreensão – não só para ser
entendido, mas também para entender. Metade de uma comunicação eficaz é a habilidade
de ouvir. Não saber ouvir pode causar uma ruptura na comunicação.
A seguir, estão algumas das barreiras mais comuns para a eficácia da capacidade de ouvir:
• Fingir que está escutando. Você ouve e pensa mais rápido que a média das pessoas
fala. Isso pode fazer com que você se distraia, se entedie ou pense sobre o que você
quer dizer em resposta.
• Distrações. Se você tenta fazer outra coisa, como atender ao telefone ou ler, en-
quanto estiver conversando com alguém, não será capaz de se concentrar na fala da
pessoa. Também é fácil distrair-se com as pessoas que passam ou com alguma coisa
do lado de fora da janela.
• Ter idéias preconcebidas e mente fechada. Ouvir somente o que está de acordo com
seus pensamentos e ignorar as coisas com as quais você discorda é conhecido
como escuta seletiva. Idéias preconcebidas na hora de ouvir alguém podem também
ser atribuídas a opiniões sobre a roupa, a aparência, o tom de voz e os maneirismos
do falante.
• Impaciência. Se você está ansioso para que o falante conclua ou para ter a chance
de interrompê-lo e, conseqüentemente, poder falar, pode atrapalhar o raciocínio do
falante.
• Tirar conclusões precipitadas. Se você começa a tirar conclusões sobre o que está
sendo dito antes de o falante terminar, pode não escutar toda a história ou todos
os fatos.

8. Faça uma lista das barreiras mais
comuns para a capacidade de ouvir
com eficácia.
Ouvir é mais do que somente deixar que a outra pessoa fale. Deve ser um processo
ativo, e não passivo. Uma escuta ativa aumenta o entendimento e reduz as chances de con-
flito. A seguir estão algumas sugestões para melhorar a habilidade de ouvir:
• Foque-se na pessoa que fala. Olhar para a pessoa que está falando o ajuda a se con-
centrar e a prestar atenção na linguagem corporal do falante.
• Empenhe-se em ouvir ativamente. Dê um feedback verbal e não-verbal para a pessoa
que fala. Essa reação pode ser por meio de linguagem corporal, como concordar com
a cabeça sobre alguma coisa que ela diz, sorrir ou simplesmente ouvir atentamente.
O feedback também pode ser um comentário verbal que não requeira uma resposta
do falante, como, por exemplo, “interessante”, “entendo”, ou “hã-hã”. Pode também
ser uma interpretação do que o falante disse, como: “o que você está dizendo é...”,
ou “o que você quer dizer...”. Sua interpretação dará ao falante uma oportunidade
para esclarecer quaisquer mal-entendidos.
• Faça perguntas. Quando você precisa de um esclarecimento ou de mais informações
sobre algo que a pessoa disse, faça uma pergunta para aprofundar o tema, como:
“você poderia falar mais sobre isso?”.
• Não interrompa. Quando uma pessoa estiver falando, ouça tudo o que ela tem para
dizer ou espere uma pausa apropriada antes de interromper com uma pergunta ou
um comentário. Não interrompa nem mude de assunto antes de o falante terminar a
mensagem.

9. Quais são algumas das coisas que
você pode fazer para melhorar sua
habilidade de ouvir?
Habilidade para ouvir é importante se os membros da equipe do projeto querem ser

eficazes em comunicar-se uns com os outros e com o cliente.
REUNIÕES
Uma reunião pode ser um veículo para cultivar a construção de equipe e reforçar as ex-
pectativas, os papéis e o compromisso dos membros em relação ao objetivo do projeto.
Esta seção trata dos vários tipos de reuniões que podem acontecer durante um projeto e dá
sugestões de como assegurar sua eficácia.
Tipos de Reunião de Projeto

Os três tipos mais comuns de reuniões de projeto são:
• Reuniões de análise de status.
• Reuniões de resolução de problemas.
• Reuniões de análise crítica de concepção técnica.
É comum que um contrato entre o cliente e o fornecedor de projeto determine a neces-
sidade de reuniões periódicas de análise de status e reuniões específicas de análise crítica.
REUNIÕES DE ANÁLISE DE STATUS

Uma reunião de análise de status de projeto é geralmente liderada ou convocada pelo
gestor. Em geral, envolve todas ou algumas das equipes do projeto, além do cliente e/ou
instâncias de decisão superiores. Os principais propósitos dessa reunião são informar, iden-
Outra Reunião de Equipe?
Reuniões de equipe ou de departamento geralmente têm a fama de serem uma perda
de tempo e as pessoas normalmente sentem que nada é resolvido nessas ocasiões. No
entanto, a reunião de negócios é um instrumento importante de comunicação. Há uma
estimativa de que aconteçam 11 milhões de reuniões, ou mais, na América do Norte todos
os dias. A maioria dos profissionais participa em média de 62 reuniões por mês. Laura Bo-
gomolny dá alguns conselhos, de suas entrevistas com consultores de gestão, sobre como
conduzir uma reunião de negócios significativa.
A primeira dica de Laura é determinar o propósito da reunião. Se o objetivo é dissemi-
nar informações, considere usar outras formas de comunicação, como o e-mail. As pessoas
geralmente pensam que as reuniões informativas não são um uso sábio do tempo. Se a
quantidade de informações for muito grande, ou se houver necessidade de colaboração no
planejamento e na tomada de decisão, marque uma reunião. Todos devem ser informados
de seu propósito.
A segunda dica é convidar as pessoas certas para a reunião. Não faça alguém perder
tempo se essa pessoa não precisa participar. No entanto, não exclua alguém necessário
para a tomada de uma decisão e para fazer aprovações. Convide todos com antecipação
e providencie uma pauta detalhada, que deve incluir um esboço dos tópicos, as pessoas
designadas e responsáveis em cada tópico, a quantidade de tempo alocado para cada um
deles e o tempo dos intervalos.
O ambiente de reunião também é uma consideração importante. As pessoas normal-
mente gostam de aperitivos, mas a comida pode distrair a atenção delas. Escolha uma sala
com temperatura regulável e iluminação adequada. As pessoas que se sentem desconfor-
táveis e mal localizadas prestam ainda menos atenção na reunião e em seu propósito. O
líder superior da equipe deve se sentar à ponta da mesa ou, se uma discussão aberta for
necessária, utilizar uma mesa redonda.
Comece a reunião pontualmente e mantenha o enfoque. Estabeleça regras básicas,
sobre telefones celulares e o momento de sair da sala. Indique uma secretária para tomar
notas da reunião. Para as questões que não estiverem diretamente relacionadas ao objeti-
vo da reunião, faça uma observação a fim de discuti-las depois.
Fique voltado para os resultados. Encerre oportunamente e com um resumo das de-
cisões e uma lista das próximas ações a tomar. Uma boa reunião deve terminar com um
plano de ação ou uma lista de idéias. Combine uma data para a reunião seguinte. Ouças
as opiniões que possam surgir ao final – algumas não são dadas durante a reunião, mas
podem ser decisivas para o progresso do projeto. Discussões pós-reunião podem ser muito
informativas.
Bogomolny, L. To the Rescue. Canadian Business, Vol. 77, Ed. 9, 26 de abril de 2004.
tificar problemas e estabelecer tarefas. As reuniões de análise de status devem acontecer

com uma certa regularidade para que os problemas e os problemas em potencial possam
ser identificados com antecedência e para prevenir surpresas que poderiam pôr em risco o
cumprimento do objetivo do projeto. Por exemplo, essas reuniões podem acontecer sema-
nalmente com a equipe e com menos freqüência com o cliente – talvez mensalmente ou
trimestralmente, dependendo da duração total do projeto e dos requisitos contratuais.

10. Quais são os principais propósitos de
uma reunião de análise de status?
FIGURA 12.1 Pauta de Reunião de Análise do Status do Projeto
Reunião de Equipe de Análise

do Status do Projeto
Pauta
8h Realizações desde a última reunião

• Hardware Steve
• Software Alex
• Documentação Wendy
8h30 Custos, cronograma e escopo do trabalho Jack
• Status
• Tendências
• Previsões
• Variações
8h45 Ações corretivas, se necessário Conforme o caso
9h15 Oportunidades de melhoria Todos
9h30 Discussão aberta Todos
9h50 Designação de tarefas Jack
10h Encerramento
Um exemplo de pauta para uma reunião de análise de status é mostrado na Figura 12.1.
A seguir, estão alguns dos tópicos que podem ser discutidos em cada item da pauta:
• Realizações desde a última reunião. Deve-se identificar as metas-chave do projeto
que foram alcançadas e analisar as ações sobre a pauta da reunião anterior.
• Custo, cronograma e escopo de trabalho – status. O desempenho deve ser comparado
ao plano-base. É importante que o status seja fundamentado em informações atuali-
zadas com respeito às tarefas concluídas e às despesas reais.
• Custo, cronograma e escopo de trabalho – tendências. Deve-se identificar qualquer
tendência positiva ou negativa no desempenho do projeto. Mesmo se um projeto
estiver com o cronograma adiantado, o fato de ter apresentado deslizes nas várias
semanas anteriores pode indicar que uma ação corretiva deve ser iniciada nesse mo-
mento, antes que o projeto fique com o cronograma atrasado.
• Custo, cronograma e escopo de trabalho – previsões. Baseando-se no status, nas ten-
dências reais e nas tarefas do projeto que ainda devem ser concluídas, a data prevista
para a conclusão do projeto e o custo previsto para isso devem ser analisados e
comparados com o objetivo do projeto e o plano-base.
• Custo, cronograma e escopo de trabalho – variações. Deve-se identificar qualquer
diferença entre o progresso real e o progresso planejado com relação ao custo e
ao cronograma para os pacotes e as tarefas do trabalho do projeto. Essas variações
podem ser positivas (por exemplo, estar com o cronograma adiantado) ou negativas
(como ultrapassar o orçamento depois de concluir certa quantidade de trabalho). As
variações negativas ajudarão a detectar tanto os problemas atuais como os em po-
tencial. Deve-se dar atenção especial para as partes do projeto que tiveram variações
negativas e continuam piorando.
• Ações corretivas. Em alguns casos, ações corretivas para resolver problemas e pro-
blemas em potencial podem ser adotadas exatamente na reunião de análise de status
– por exemplo, receber a aprovação do cliente ou da diretoria para proceder à com-
pra de certos materiais ou a autorização para fazer horas extras e trazer o projeto de
volta para o cronograma. Em outros casos, pode ser preciso fazer reuniões separadas
de resolução de problemas para que os membros apropriados da equipe possam
desenvolver ações corretivas.
• Oportunidades de melhoria. Estas também devem ser identificadas com as áreas de
problemas e as ações corretivas associadas. Por exemplo, um membro da equipe do
projeto pode indicar que as especificações técnicas poderiam ser cumpridas com a
utilização de um material ou uma peça de equipamento alternativos, que seja subs-
tancialmente menos caro do que a opção que a equipe originalmente planejou usar.
Ou pode sugerir que um tempo significante poderia ser economizado ao copiar e
modificar superficialmente um software já existente, em vez de desenvolver outro
totalmente novo.
• Atribuição de tarefas. Algumas tarefas específicas devem ser identificadas e atribuídas
a membros específicos da equipe. Para cada tarefa, a pessoa responsável e a data de
conclusão estimada devem ser anotadas. A data de conclusão deve ser estimada pela
pessoa responsável pela tarefa. Quando as pessoas verbalizam seu compromisso com
uma data na reunião, na frente de outros, elas geralmente se esforçam para cumprir
essa data.
Deve-se notar que ouvir as informações fornecidas na reunião de análise de status é uma
das maneiras, mas não a única, de um gestor de projetos obter o verdadeiro entendimento
do status do projeto. Ele precisa validar o que foi dito na reunião de análise por meio de uma
conversa pessoal com os membros da equipe. O gestor de projetos também deve pedir para
ver qualquer produto tangível, ou deliverables, como desenhos, protótipos ou relatórios.
Isso tanto validará a conclusão real daquela tarefa (e não apenas quase ou essencialmente
concluída) como também mostrará que o gestor está de fato interessado no trabalho do pro-
fissional e que sua participação é importante para a realização do projeto com êxito.
REUNIÕES DE RESOLUÇÃO DE PROBLEMAS

Quando um problema ou um problema em potencial é identificado por um membro da equipe
do projeto, essa pessoa pode convocar prontamente uma reunião de resolução de problemas
com outros membros da equipe, em vez de esperar por uma futura reunião de análise de
status. A identificação e a resolução de problemas o mais cedo possível é muito importante
para o sucesso do projeto.

11. Verdadeiro ou falso: quando
os membros da equipe do projeto
identificam problemas ou problemas em
potencial, devem esperar até a próxima
reunião de análise de status para
colocá-los em discussão.
O gestor e a equipe precisam estabelecer algumas diretrizes no início do projeto sobre

quem deve iniciar as reuniões de resolução de problemas e quando elas devem ocorrer,
assim como o nível de autorização exigido para implementar ações corretivas.
As reuniões de resolução de problemas devem obedecer a uma boa abordagem de re-
solução de problemas, como os itens a seguir:
1. Elabore uma declaração de problema.

2. Identifique as causas em potencial do problema.
3. Reúna dados e verifique as causas mais prováveis.
4. Identifique possíveis soluções.
5. Avalie as soluções alternativas.
6. Determine a melhor solução.
7. Revise o plano do projeto.
8. Implemente a solução.
9. Verifique se o problema foi resolvido.
Essa abordagem de resolução de problemas em nove etapas foi discutida com mais de-
talhes no Capítulo 11.
REUNIÕES DE ANÁLISE CRÍTICA DE CONCEPÇÃO TÉCNICA
Os projetos que envolvem uma fase de concepção, como um de sistema de informação,

podem precisar de uma ou mais reuniões de análise crítica de concepção técnica para
assegurar que o cliente concorda e aprova a abordagem de concepção desenvolvida pelo
fornecedor do projeto.
Considere o exemplo de uma empresa que contrata um consultor para fazer a concep-
ção, o desenvolvimento e a implementação de um sistema de informação, a fim de acom-
panhar os pedidos de clientes desde a entrada até o recibo de pagamento. A empresa pode
exigir que o consultor analise a concepção do sistema com os representantes apropriados
da empresa antes que a próxima fase do projeto (desenvolvimento detalhado do sistema
e compra de hardware e software) seja aprovada. Em um último estágio do projeto, a em-
presa pode solicitar que certos funcionários analisem e aprovem a interface do computador
e o formato de saída desenvolvidos pelo consultor para assegurar que cumprem com as
necessidades e as expectativas das pessoas que vão utilizar o sistema.
Em muitos projetos técnicos, existem duas reuniões de análise crítica de concepção:
1. Uma reunião preliminar de análise crítica de concepção depois de o fornecedor ter

concluído as especificações conceituais iniciais, os desenhos ou os fluxogramas. O
propósito dessa reunião preliminar de análise crítica de concepção técnica é obter
o acordo do cliente de que a abordagem de concepção cumpre com os requisitos
técnicos e conseguir a aprovação do cliente antes que o fornecedor encomende
materiais que tenham um prazo longo de entrega (para, desse modo, não atrasar o
cronograma do projeto).
2. Uma reunião final de análise crítica de concepção depois de o fornecedor ter con-
cluído as especificações detalhadas, os desenhos, os formatos de relatório e tela,
e assim por diante. O propósito dessa reunião final de análise crítica de concepção é
conseguir a aprovação do cliente antes de o fornecedor iniciar a construção, a mon-
tagem e a produção dos deliverables do projeto.

12. Para projetos técnicos, normalmente
existem duas reuniões de análise crítica
de concepção: uma reunião ___________
de análise de concepção e uma reunião
______________ de análise crítica de
concepção.
Reuniões Eficazes
Antes, durante e depois, a pessoa que convoca ou conduz a reunião pode seguir várias
etapas para assegurar que a reunião seja eficaz.
ANTES DA REUNIÃO
• Determine se a reunião é realmente necessária ou se outro mecanismo, como uma
chamada em conferência, é mais apropriado.
• Determine o propósito da reunião. Por exemplo, a reunião irá compartilhar informa-
ções, planejar, coletar dados ou idéias, tomar uma decisão, convencer ou negociar,
resolver um problema ou avaliar o status?
• Determine quem precisa participar da reunião, dado seu propósito. O número de par-
ticipantes deve ser o número mínimo necessário para alcançar o propósito da reunião.
Os membros da equipe do projeto geralmente estão ocupados com suas tarefas e não
querem participar de reuniões nas quais não irão contribuir ou com as quais não têm
nada a ganhar. As pessoas que são convidadas a comparecer devem saber por que
isso lhes está sendo pedido.
• Distribua uma pauta da reunião com antecedência às pessoas convidadas. A pauta
deve incluir:
O propósito da reunião.
Tópicos a serem discutidos (os itens devem ser listados do mais importante para o me-
nos importante. Se o tempo se esgotar, os itens mais importantes terão sido discutidos).
O tempo alocado para cada tópico e quem tratará dele, fará a apresentação ou lide-
rará a discussão.

13. Para assegurar que uma reunião seja
eficaz, quais são alguns dos passos que
a pessoa que convoca ou conduz a
reunião deve tomar antes da reunião?
A Figura 12.2 é um exemplo de pauta para uma reunião de análise de projeto com o cliente.
Com a pauta, deve ser anexado qualquer documento ou dados que os participantes precisam
analisar antes da reunião. É preciso dar um intervalo suficiente entre a divulgação do anún-
cio e a data da reunião para permitir que os participantes se preparem adequadamente.
Talvez alguns participantes precisem reunir e analisar os dados, preparar uma apresentação
ou materiais para serem distribuídos.
• Prepare recursos visuais ou materiais para serem distribuídos. Gráficos, tabelas, dia-
gramas, fotos e protótipos são recursos visuais eficazes. Geralmente, esses materiais
enfocam a discussão e evitam muitas informações desconexas e mal-entendidos.
Uma imagem vale mais que mil palavras!
• Organize uma sala de reunião. A sala deve ter o tamanho suficiente para que as pes-
soas não se sintam apertadas ou desconfortáveis. As cadeiras precisam ser dispostas
de maneira que todos os participantes possam se ver – isso incentiva a participação.
Os recursos visuais e os acessórios apropriados da sala (projetor, tela, videocassete,
painéis flip chart, lousas) devem ser testados antes de se iniciar a reunião. Deve-se
fazer intervalos se a reunião for longa. Por exemplo, servir um pequeno almoço a fim
de permitir que as discussões da reunião continuem nesse momento.
FIGURA 12.2 Pauta de Reunião de Análise do Projeto com o Cliente
Reunião de Análise do
Projeto com o Cliente
Pauta
8h Abertura para comentários Jeff

8h15 Análise técnica
• Concepção do sistema Joe
• Treinamento Cathy
• Planos de instalação Jim
10h Intervalo
10h15 Status do projeto Jeff
• Cronograma
• Custos
11h Mudanças propostas Joe
11h45 Decisões e tarefas Jeff
12h Discussão aberta (almoço)
13h Encerramento
Em alguns casos, uma sala de conferência deve ser designada como “sala de projeto”,
onde acontecerão todas as reuniões ou onde os membros da equipe podem se reunir para
discutir resolução de problemas. Essas salas podem ter planos de projeto, cronogramas,
gráficos de status e diagramas de sistema afixados nas paredes para fácil acesso de todos
os membros da equipe do projeto.
DURANTE A REUNIÃO
• Comece a reunião com pontualidade. Se o líder da reunião espera por alguns parti-
cipantes atrasados, as pessoas terão o costume de chegar atrasadas por saberem que
a reunião não começará na hora certa de qualquer forma. Se começar pontualmente,
as pessoas terão o costume de chegar na hora certa, em vez de passar o constrangi-
mento de entrar em uma reunião já em andamento.
• Designe uma pessoa para tomar notas. Alguém deve ser nomeado (de preferência
antes da reunião) para tomar notas. Estas devem ser concisas e tratar de decisões,
tarefas e datas de conclusão estimadas. As atas de reunião muito detalhadas podem
ser uma tarefa pesada tanto para serem escritas como para serem lidas mais adiante,
e por essa razão devem ser evitadas.
• Analise o propósito da reunião e a pauta. Seja conciso e não faça um longo discurso.
• Modere, mas não domine as reuniões. O gestor de projetos não deve liderar todas as
discussões, mas fazer com que outros participantes liderem as discussões dos tópicos
a eles designados.
Um bom moderador irá:
Manter o progresso da reunião dentro da programação estabelecida.
Incentivar a participação, especialmente das pessoas que parecem indecisas em par-

ticipar.
Restringir o discurso dos participantes que tenham tendência a falar muito, a repetir
idéias e desviar o assunto.
Controlar interrupções e conversas paralelas.
Esclarecer os pontos colocados em questão.
Resumir as discussões e fazer transições para os tópicos seguintes da pauta.
É útil discutir as diretrizes de reunião em uma reunião de equipe no início do
projeto para que todos entendam que comportamento se espera durante as reu-
niões. Um exemplo de código de conduta para reuniões de equipe é mostrado na
Figura 12.3.

14. Verdadeiro ou falso: é sempre
uma boa idéia esperar que todos
os participantes cheguem para
depois começar a reunião, mesmo se
ultrapassar a hora de início marcada.
• Resuma os resultados da reunião no final e certifique-se de que todos os participantes

tenham um claro entendimento de todas as decisões e tarefas. O líder da reunião deve
verbalizá-las para ajudar a evitar qualquer mal-entendido.
• Não ultrapasse o tempo de reunião do cronograma. Os participantes podem ter ou-
tros compromissos ou reuniões. Se nem todos os tópicos da pauta foram discutidos,
é melhor programar outra reunião para as pessoas envolvidas com eles. De qualquer
forma, esses tópicos devem ser os de menor prioridade, pois os da pauta foram or-
ganizados em ordem de maior para menor importância.
• Avalie o processo de reunião. Algumas vezes, no final da reunião, os participantes
devem discutir abertamente o que aconteceu ao determinar se alguma mudança deve
ser feita para melhorar a eficácia de futuras reuniões.
A Figura 12.4 é uma lista de verificação para classificar a eficácia de uma reunião. Os
membros da equipe podem responder a esse instrumento de avaliação periodicamente
durante o projeto. Depois de somar os pontos de todos os membros, a equipe, incluindo o
gestor, deve discutir como melhorar as áreas em que receberam baixa pontuação.
DEPOIS DA REUNIÃO
Publique os resultados da reunião dentro de 24 horas após a reunião. O documento-resu-

mo deve ser conciso, em apenas uma página, se possível. Deve confirmar as decisões que
foram tomadas e listar as tarefas correspondentes, incluindo a pessoa responsável, a data
de conclusão estimada e os deliverables esperados. Também pode listar quem esteve pre-
sente ou ausente. Os resultados da reunião devem ser distribuídos para todas as pessoas
que foram convidadas, mesmo para as que não compareceram. As notas não devem incluir
uma narrativa detalhada das discussões. A Figura 12.5 é uma amostra de lista de tarefas da
reunião.
As reuniões eficazes, como os projetos de sucesso, requerem um bom planejamento e
bom desempenho.
FIGURA 12.3 Código de Conduta para Reunião de Equipe
Reunião de Equipe
New Pig Corporation
Gestão de Qualidade de Equipe
Código de Conduta
Mantenha-se no tópico que estiver sendo discutido.
Inicie e encerre a reunião pontualmente.
Uma pessoa fala de cada vez.
Todos têm a responsabilidade de participar.
Esteja preparado.
Seja franco, honesto e sincero.
Evite comentários sarcásticos ou irônicos.
O tom geral das reuniões deve ser positivo.
Elimine comentários negativos.
Faça críticas construtivas.
Preste atenção em tudo. Procure primeiro entender
para depois ser entendido.
Não converse sobre assuntos triviais.
As idéias pertencem ao grupo, e não a cada pessoa.
A equipe tem apenas uma voz depois de tomar
uma decisão. Deve permanecer unida.
Reforce um comportamento positivo.
Mantenha a tranqüilidade. Se você a perde,
é o errado – e ninguém mais.
FIGURA 12.4 Lista de Verificação da Eficácia da Reunião
QUÃO EFICAZES SÃO SUAS REUNIÕES?

Nem um Um pouco Muito
pouco
1. A pauta é enviada a tempo de permitir uma preparação? 1 2 3 4 5

2. A pauta é seguida adequadamente? 1 2 3 4 5
3. É alocado tempo suficiente para cada tópico? 1 2 3 4 5
4. A sala é apropriada? 1 2 3 4 5
5. As pessoas certas comparecem? 1 2 3 4 5
6. As reuniões começam pontualmente? 1 2 3 4 5
7. Os participantes sabem por que foram convidados? 1 2 3 4 5
8. Os objetivos da reunião foram compreendidos? 1 2 3 4 5
9. Os objetivos de cada tópico são claros? 1 2 3 4 5
10. As reuniões são mantidas em ordem
e não se permite confusão? 1 2 3 4 5
11. Há um equilíbrio de participação entre todos os presentes? 1 2 3 4 5
12. Os participantes ouvem uns aos outros? 1 2 3 4 5
13. O líder mantém o controle? 1 2 3 4 5
14. As reuniões apresentam um tom positivo e produtivo? 1 2 3 4 5
15. As reuniões terminam pontualmente? 1 2 3 4 5
16. As decisões e as tarefas são documentadas
e os documentos são distribuídos? 1 2 3 4 5
17. As reuniões utilizam o tempo de forma adequada? 1 2 3 4 5
FIGURA 12.5 Lista de Tarefas
Tarefas
da Reunião de Análise de Status do Projeto Realizada em 1o de março
Tarefa Quem Até Quando
1. Revisar documento de requisitos de sistema Tyler 10 de março

2. Agendar reunião de análise com o cliente Jim 11 de março
3. Alterar o pedido de compra de
computadores de 15 para 20 Maggie 19 de março
4. Avaliar a viabilidade de sistema de
reconhecimento de caracteres ópticos
e de código de barras para entrada
de dados Hannah 19 de março
APRESENTAÇÕES
Geralmente o gestor de projetos ou os membros da equipe são convocados para fazer uma
apresentação formal. O público pode ser os representantes da organização do cliente, a
alta direção da organização em que está sendo realizado o projeto, a própria equipe do
projeto ou o público externo, como em uma conferência. O público pode ser uma pessoa
(o cliente) ou centenas de assistentes em uma conferência nacional. A apresentação pode
ser de dez minutos, de uma hora ou mais. O tema pode ser uma visão geral do projeto,
o status atual do projeto, um problema grave que esteja atrapalhando a realização bem-
sucedida do objetivo do projeto, como a previsão de um atraso para o cronograma ou de
um excesso de custos, ou uma tentativa de convencer o cliente a expandir ou redirecionar
o escopo de trabalho do projeto.
Nessas situações, você, o falante, está em foco. A seguir, estão algumas sugestões que
podem ajudar você a preparar e a fazer sua apresentação.
Preparando-se para uma Apresentação

• Determine o propósito da apresentação. A intenção é informar ou convencer? O que
você quer realizar? Por exemplo, você deseja que o público entenda o projeto ou
quer que o cliente concorde com as mudanças sugeridas para o escopo de trabalho
do projeto?
• Conheça o público. Qual é o nível de conhecimento ou familiaridade do público com
o tema? Qual é o cargo que ocupam? São executivos seniores e importantes tomado-
res de decisão ou têm o mesmo cargo que você?
• Faça um esboço da apresentação. Somente depois de ter feito um esboço, você deve
escrever toda a apresentação. Leia-a várias vezes, mas não tente decorá-la.
• Use uma linguagem simples que o público possa entender. Não utilize jargões, siglas
ou vocabulário técnico ou sofisticado, pois o público pode não entender. Não tente
impressionar com o poder de sua fala! Não faça comentários que possam ser interpre-
tados como machistas, racistas, preconceituosos, ofensivos, irônicos ou profanos.
• Prepare anotações ou um esboço final que usará ou consultará durante sua apresen-
tação. Sim, não tem problema algum usar anotações.
• Ensaie, ensaie, ensaie – mais do que você acha que deve. Você pode fazer um teste
para os seus colegas. Peça o feedback deles e solicite sugestões sobre como você
poderia melhorar sua apresentação.
• Prepare recursos visuais e faça testes antes da reunião. Certifique-se de que os re-
cursos visuais possam ser lidos pela pessoa que se sentar mais distante na sala onde
a apresentação será feita. Se for usado um grande auditório, certifique-se de que os
recursos visuais são abrangentes o suficiente. Os recursos visuais, como gráficos,
diagramas e tabelas, precisam ser simples e não repletos de informações – não deve
haver muito texto e os diagramas não devem ser muito detalhados. Deve haver ape-
nas uma idéia por gráfico ou slide. Gráficos multicoloridos são mais atraentes que os
totalmente em preto-e-branco, mas escolha as cores com cuidado – você pode en-
tediar o público com gráficos coloridos demais ou com combinações de cores que
dificultem a leitura do texto.
• Distribua cópias dos materiais. Se os membros da equipe não tiverem de fazer muitas
anotações, eles poderão prestar total atenção em sua apresentação.
• Solicite os equipamentos audiovisuais com antecedência. Se os equipamentos, como
projetor, projetor de slides, microfone, atril, caneta laser ou projetor de vídeo, forem
de uso geral, você não deve solicitar no último momento antes da apresentação, pois
pode não haver equipamento disponível.

15. Quais são as coisas importantes
que se deve fazer ao se preparar uma
apresentação?
• Entre na sala de reunião enquanto ainda estiver vazia e familiarize-se com o am-
biente. Fique no lugar onde fará a apresentação (na parte da frente da sala, no atril
ou no palco). Faça testes com o projetor e o microfone.
Fazendo a Apresentação
• Um pouco de nervosismo é normal; todos os oradores sentem. Tente se lembrar de que
você sabe mais sobre o que está falando do que a maioria do público.
• Saiba as primeiras duas ou três frases de sua apresentação. As palavras de abertura
são cruciais, por isso você deve sabê-las na ponta da língua. Elas devem ser expres-
sas de modo confiante e descontraído. É aí que se estabelece a sua credibilidade com
o público. Você não pode se confundir nas palavras de abertura ou dizer alguma
coisa que possa alienar o público.
• Use a abordagem dos 3 C em sua apresentação:
Primeiro, conte ao público sobre o que você irá falar (seu esboço).
Depois, conte ao público o que você tem a dizer (o corpo de sua apresentação).
Finalmente, conte ao público sobre o que você falou (seu resumo).
• Fale com o público, e não para ele. Mantenha o maior contato possível com os olhos
do público e consulte suas anotações o menor número de vezes possível (você ficará
tranqüilo se tiver praticado muitas vezes anteriormente).
• Fale claramente e com confiança. Não fale rápido nem devagar demais. Use senten-
ças curtas e compreensíveis, e não sentenças longas, complexas e incoerentes. Faça
uma pausa apropriada depois de um tópico importante ou antes de passar para um
novo tópico. Use um tom de voz apropriado para dar ênfase. Não faça seu discurso
de forma monótona.
• Use uma animação apropriada para ajudar a destacar um argumento. Faça movi-
mentos com as mãos, expressões faciais e use a linguagem corporal. Não fique para-
do em um único ponto, ande pela sala, se possível. Em um grande auditório, é melhor
usar um microfone sem fio que ficar preso em um atril com um microfone fixo. Se
você realmente movimentar-se pela sala, seja ela pequena, seja um auditório, olhe
sempre para o público enquanto fala, e nunca dê as costas ao público. Por exemplo,
não olhe somente para a tela do projetor para ler seu recurso visual. Elabore uma
única idéia para ilustrar cada recurso visual e dê exemplos, se possível.
• Não fique na frente de seus recursos visuais. Não fique em uma posição onde você
bloqueie a visão do público, como na frente da tela do projetor, do painel flip chart
ou de qualquer outro equipamento.
• Cause interesse por sua apresentação. Desenvolva sua “história” com lógica e sentido.
Aumente gradualmente o ritmo de sua apresentação.
• Siga os tópicos principais de seu esboço. Não desvie o assunto nem se perca com os
tópicos ou com seu esboço. Você irá desperdiçar tempo e confundir o público.
• Ao falar sobre os pontos principais, explique para o público por que eles são impor-
tantes.
• Resuma seus pontos em um único tópico antes de passar para o próximo tópico de seu
esboço.
• Saiba suas palavras de encerramento. O encerramento é tão importante quanto a

abertura. Relacione o encerramento com o propósito da apresentação. Termine com
convicção e confiança.

16. Quais são as coisas importantes que
se deve ter em mente ao se fazer uma
apresentação?
• Reserve um tempo para interação com o público, se possível. Pergunte se alguém tem
alguma pergunta. Você deve estabelecer no início de sua apresentação se haverá um
tempo para perguntas ao final ou se o público pode interromper a apresentação para
fazer perguntas. A segunda opção pode ser arriscada se você tiver um tempo deter-
minado para falar ou uma pauta para cumprir. No entanto, se for uma apresentação
para um cliente, realizada em uma pequena sala de reunião, responder a perguntas
durante a exposição pode ser mais apropriado do que fazer o cliente esperar até o
final para fazer todas as perguntas. Na verdade, parte de sua estratégia de apresen-
tação pode ser direcionar o cliente a uma discussão para que este exponha suas
opiniões.
• Ao responder a perguntas, seja sincero, imparcial e confiante. Diga ao cliente caso
você não saiba a resposta ou não possa divulgá-la. Essa é uma resposta legítima. Não
fique na defensiva ao responder.
RELATÓRIOS
Os relatórios escritos são tão importantes quanto os orais para comunicar informações so-
bre o projeto. Os tipos exigidos, o conteúdo, o formato, a freqüência e a distribuição de
relatórios que a organização do projeto deve preparar devem ser especificados pelo cliente
no contrato.
Alguns relatórios podem ser distribuídos para um grande público. É importante saber
quem receberá as cópias. O público pode ser muito diverso e incluir pessoas que estejam
bem informadas sobre o projeto, como também aquelas que sabem apenas o que lêem nos
relatórios periódicos que recebem. As pessoas que recebem os relatórios podem ter dife-
rentes níveis de experiência técnica e algumas delas talvez não entendam certas linguagens
técnicas ou jargões.

17. Os relatórios de projeto devem ser
escritos para tratar do que é de interesse
dos ____________, e não do que é de
interesse da pessoa que ___________ o
relatório.
É importante ter em mente que os relatórios devem ser escritos para tratar do que é de
interesse dos leitores, e não do que é de interesse da pessoa que os escreve.
As seções a seguir discutem dois tipos comuns de relatórios de projeto e oferece suges-
tões para garantir relatórios úteis.
Tipos de Relatórios de Projeto

Os dois tipos mais comuns de relatórios de projeto são:
• relatórios de progresso;
• relatório final.
RELATÓRIOS DE PROGRESSO
É importante ter em mente que o relatório de progresso não é um relatório de atividades.
Não confunda atividade ou carga de trabalho com progresso e realizações. O cliente, em
particular, tem interesse sobre as realizações do projeto – qual foi o progresso conseguido
para a conquista do objetivo do projeto, e não quais atividades a equipe executou.

18. O propósito principal dos relatórios
de projeto é informar as ______________
do projeto e não quais ______________ a
equipe realizou.
Os relatórios sobre o progresso do projeto podem ser preparados pelos membros da

equipe para o gestor ou para o gerente funcional (em uma organização matricial), pelo ges-
tor para o cliente, ou pelo gestor para a alta direção da empresa em que está sendo reali-
zado o projeto.
Os relatórios de progresso geralmente tratam de um período específico, chamado de
período de relatório, que pode ser de uma semana, um mês, um trimestre ou qualquer
outro período que melhor se ajuste ao projeto. A maioria dos relatórios de progresso trata
somente do que aconteceu no período de relatório, em vez do progresso cumulativo desde
o início do projeto.
Uma amostra de esboço para um relatório de progresso de projeto é apresentada na Fi-
gura 12.6. A seguir, alguns dos itens que podem ser incluídos em um relatório de progresso
de projeto:
• Realizações desde o relatório anterior. Essa seção deve identificar as principais metas
do projeto que foram alcançadas. Pode também incluir um relatório sobre realizações
(ou falta delas) das metas específicas estabelecidas para o período de relatório.
• O status atual do desempenho do projeto. Os dados sobre custos, cronograma e esco-
po de trabalho são comparados ao plano-base.
• O progresso para a resolução de problemas identificados anteriormente. Se não houve
nenhum progresso sobre os itens relacionados nos relatórios de progresso anteriores,
deve ser feito um esclarecimento.
• Problemas ou problemas em potencial desde o relatório anterior. Os problemas po-
dem ser: (1) técnicos, como protótipos que não funcionam ou resultados de teste
que não são o que era esperado; (2) de cronograma, como atrasos ocasionados porque
algumas tarefas demoraram mais do que o esperado, houve atraso na entrega de ma-
teriais ou um mau tempo provocou atrasos; e (3) de custos, como ter ultrapassado o
orçamento porque os materiais custaram mais do que foi estimado originalmente ou
foram utilizadas mais horas de trabalho nas tarefas que havia sido planejado.
• Ações corretivas planejadas. Esta seção deve especificar as ações corretivas a serem
tomadas durante o próximo período de relatório para solucionar cada um dos pro-
blemas identificados. Deve ser incluída uma declaração que explica se o objetivo
do projeto será colocado em risco, no que diz respeito ao escopo, à qualidade, aos
custos ou ao cronograma, por qualquer uma dessas ações corretivas.
FIGURA 12.6 Esboço de Relatório do Progresso do Projeto
Relatório do Progresso do Projeto

do Período de 1o de Julho a 30 de Setembro
Sumário
1. Realizações desde o relatório anterior
2. Status atual do desempenho do projeto
2.1 Custos
2.2 Cronograma
2.3 Escopo do trabalho
3. Progresso em direção à resolução de problemas identificados anteriormente
4. Problemas ou problemas em potencial desde o relatório anterior
5. Ações corretivas planejadas
6. Metas a serem alcançadas durante o próximo período de relatório
• Metas a serem alcançadas durante o próximo período de relatório. Essas metas devem
estar atualizadas de acordo com o último plano de projeto acordado.
Nenhuma das informações do relatório de progresso deve ser uma surpresa para os
leitores. Por exemplo, qualquer problema identificado precisa ter sido discutido oralmente
antes da preparação do relatório de progresso escrito.
RELATÓRIO FINAL
O relatório final é geralmente um resumo do projeto. Não é nem uma acumulação dos rela-
tórios de progresso, nem uma história minuciosa sobre o que aconteceu durante o projeto.
O relatório final pode incluir:
• A necessidade original do cliente.
• O objetivo original do projeto.
• As exigências originais do cliente.
• Os benefícios reais versus os benefícios previstos para o cliente como um resultado do
projeto.
• O grau que o objetivo original do projeto alcançou. Se não foi alcançado, deve-se
incluir um esclarecimento.
• Uma breve descrição do projeto.
• Futuras considerações. Esta seção poderia incluir as ações que o cliente pode querer
considerar no futuro para aumentar ou expandir os resultados do projeto. Por exem-
plo, se o projeto apresentava um edifício de escritórios, nas futuras considerações,
podem se acrescentar um estacionamento, uma academia de ginástica ou uma creche
ao edifício. Se o projeto está organizando um festival de artes, nas futuras considera-
ções podem se alterar a data ou adotar uma medida para melhorar o fluxo do tráfego
de pedestres.
• Uma listagem de todos os deliverables (equipamentos, materiais, softwares, documen-
tos como desenhos e relatórios, e assim por diante) fornecida para o cliente.

19. Verdadeiro ou falso: um relatório
final de projeto é um acúmulo dos
relatórios de progresso preparados
durante o projeto.
• Dados do teste de aceitação final de um sistema ou peça de equipamento, no formato

exigido pelo cliente para aprovar os resultados do projeto.
Preparando Relatórios Úteis

Levar em consideração as seguintes diretrizes quando estiver preparando os relatórios do
projeto garantirá a elaboração de relatórios úteis e valiosos:
• Faça um relatório conciso. Não tente impressionar os leitores com o volume de seu
relatório, pois ele não equivale às realizações ou ao progresso do projeto. Se o rela-
tório for breve, haverá uma chance maior de ser lido. Além disso, a elaboração de um
relatório pode ser uma atividade que consome tempo. Portanto, o gestor de projetos
deve tentar minimizar o tempo necessário pela equipe para desenvolver dados para
os relatórios.
• Escreva como você falaria. Use frases curtas e compreensíveis em vez de sentenças
de parágrafos longos e complexos. Parágrafos longos induzirão o leitor a pular a
página e, assim, perder pontos importantes. Use uma linguagem simples que os
variados leitores entenderão. Não utilize jargões ou siglas que alguns possam não
entender. Leia o relatório em voz alta para analisar o conteúdo e o estilo. Está fácil
de ler e entender ou parece incompleto e confuso?
• Coloque primeiro os pontos mais importantes, no relatório e em cada parágrafo. Al-
guns leitores têm a tendência de ler a primeira frase e depois passar por cima do
resto do parágrafo.
• Utilize representações gráficas quando possível (como gráficos, diagramas, tabelas
ou figuras). Lembre-se de que uma imagem vale mais do que mil palavras. Não faça
gráficos com muita informação. Coloque um conceito ou ponto por gráfico. É melhor
ter vários gráficos fáceis de entender que um único confuso.
• Preste muita atenção tanto no formato do relatório quanto em seu conteúdo. O rela-
tório deve ser acessível, atraente e organizado de maneira a ser compreensível para
os leitores. Ele não deve ser confuso ou ter um tamanho de letra muito pequena
para não dificultar a leitura. Não deve conter cópias confusas de materiais, gráficos
ou formulários que tenham sido reduzidos a um tamanho ilegível.

20. Quais são algumas das diretrizes
importantes que se deve ter em mente
ao preparar um relatório?
Os relatórios escritos, assim como a comunicação oral, deixam uma impressão – positiva
ou negativa – para o público. Deve-se ter atenção e ponderação ao preparar relatórios; a
preparação precisa ser vista como uma oportunidade para deixar uma impressão positiva, e
não como uma atividade penosa e de perda de tempo. Nas reuniões, periodicamente, pode
valer a pena pedir um feedback dos leitores dos relatórios com relação à sua utilidade, suas
necessidades e seus interesses e solicitar qualquer sugestão para otimizar os relatórios.
DOCUMENTAÇÃO DE PROJETO E CONTROLE DE MUDANÇAS

Além dos relatórios de projeto, muitos outros documentos podem ser criados tanto pela
equipe quanto pelo cliente durante o projeto. Alguns exemplos são: um mapa da locali-
zação da barraca em um acampamento para uma excursão de escoteiros; um manual de
instrução para a montagem de quiosques para um festival de artes; plantas para a amplia-
ção de uma casa; a listagem de um programa de computador para controle dos movimentos
de um robô. Os documentos do projeto podem ser textos, desenhos, formulários, listas,
manuais, fotos, fitas de vídeo ou softwares, que podem ser apresentados em uma folha de
papel grande (por exemplo, um desenho de engenharia ou plantas) ou em um disquete ou
CD-ROM (por exemplo, um documento ou um software).
Revisões dos documentos do projeto podem ser ocasionadas por mudanças iniciadas
pelo cliente ou pela equipe. Algumas mudanças são triviais, outras são muito significativas,
pois afetam o escopo de trabalho do projeto, os custos e o cronograma. Um exemplo de
mudança trivial é a atualização de desenhos e de manuais de instrução para a montagem
de quiosques de um festival porque alguém doou placas de identificação para colocar ne-
les. Um exemplo de mudança significativa é a alteração da localização, do tamanho e do
tipo de algumas das janelas como exigência do cliente após ver a construção da casa em
andamento. Nesse caso, é importante que o empreiteiro pare de trabalhar com essas janelas
e informe o cliente de qualquer custo adicional ou atraso de cronograma que possa ser cau-
sado pelas mudanças exigidas. Essas mudanças devem ser documentadas por escrito para o
cliente, o qual deve aprová-las antes que se dê prosseguimento ao trabalho e que qualquer
novo material seja encomendado.

21. As revisões de documentos do
projeto podem resultar de mudanças
iniciadas pelo _______________ ou pela
___________________.
Durante todo o projeto, vários documentos serão revisados para incorporar mudanças.
É importante que a equipe saiba qual é a última versão de um documento para que possa
realizar o trabalho corretamente, baseada nos documentos e nas informações mais atuais.
Por exemplo, o comprador não gostaria que o construtor utilizasse plantas desatualizadas se
o arquiteto acabou de fazer revisões que mudam a localização das paredes interiores.
É uma boa prática colocar em cada página de cada tipo de documento (1) a data da
última revisão; (2) o número da revisão seguinte; e (3) as iniciais da pessoa que fez as mu-
danças. Por exemplo, uma anotação no canto inferior direito de uma planta de reforma de
um escritório pode indicar:
Rev. 4, 29/12/01, ES
Essa anotação significa que a última versão da planta é a revisão de número 4, feita em 29
de dezembro de 2001, por Elisabeth Smith (ES).
Tão importante quanto manter atualizados o número e a data da revisão nos documen-
tos é distribuir a tempo os documentos atualizados para as pessoas apropriadas envolvidas
no projeto. Quando as mudanças são feitas nos documentos, as versões atualizadas devem
ser entregues imediatamente a todos os membros da equipe cujo trabalho será afetado pe-
las alterações. Além disso, deve-se anexar a esses documentos revisados um memorando
que explique as mudanças feitas no documento anterior. Isso ajudará as pessoas que rece-
• Uma comunicação pessoal freqüente e eficaz é crucial para o sucesso da gestão de

projetos.
• É importante ter um alto grau de comunicação frente a frente no início do projeto
para promover a construção de equipe, desenvolver boas relações de trabalho e
estabelecer expectativas recíprocas.
• A linguagem corporal e a diversidade cultural devem ser consideradas nas comuni-
cações.
• Tome cuidado para não fazer comentários ou usar palavras e frases que possam ser
interpretados como machistas, racistas, preconceituosos ou ofensivos.
• O coração da comunicação é a compreensão – não só para ser entendido, mas tam-
bém para entender. Metade de uma comunicação eficaz é a habilidade de ouvir.
Não saber ouvir pode causar uma ruptura na comunicação.
• A comunicação deve ser direta, sem ambigüidades, livre de jargões técnicos e não
ofensiva.
• A conquista da satisfação do cliente requer uma comunicação contínua com ele
para mantê-lo informado e para determinar se as expectativas mudaram. Pergunte
regularmente ao cliente seu nível de satisfação com o progresso do projeto.
• Mantenha o cliente e a equipe do projeto informados do status do projeto e dos
problemas em potencial de maneira oportuna.
• As reuniões de status do projeto devem ser realizadas com regularidade. Discuta as
diretrizes de reunião em uma reunião de equipe de projeto logo no início para que
todos entendam que comportamento é esperado durante as reuniões de projeto.
• Não confunda carga de trabalho e atividades com realizações ao comunicar o pro-
gresso do projeto.
• Os relatórios devem ser escritos para tratar do que é de interesse dos leitores, e não
do que é de interesse da pessoa que o elabora.
• Faça relatórios concisos. Preste atenção tanto no formato, organização, aparência e
legibilidade como no conteúdo.
• No início do projeto, deve ser acordado como as mudanças serão autorizadas e
documentadas.
• Assim que forem atualizados, os documentos devem ser distribuídos a todos os
membros da equipe cujo trabalho será afetado.
berão o documento – elas não precisarão voltar ao documento anterior para comparar o
novo com o antigo e tentar encontrar as mudanças. Se apenas poucas mudanças são feitas
em um documento, pode-se exigir que sejam distribuídas somente as páginas específicas
que foram alteradas. Quando as mudanças são muito grandes, pode ser melhor distribuir
todo o documento revisado em vez de somente as páginas revisadas.
No início do projeto, deve ser feito um acordo entre o fornecedor e o cliente, como
também entre o gestor e a equipe, com relação às maneiras como as mudanças serão docu-
mentadas e autorizadas. Se as mudanças forem permitidas oralmente, em vez de por escrito,
e se não for feita nenhuma indicação do impacto que as mudanças terão sobre o escopo de
trabalho, os custos ou cronograma, fatalmente aparecerão problemas pelo caminho.

22. No início do projeto, deve ser feito um
acordo com relação às maneiras como as
mudanças serão __________________ e
___________________.
Os membros da equipe do projeto devem tomar cuidado para não concordarem com
mudanças sem saber se precisarão de mais horas de trabalho. Se o cliente não concorda em
pagar por horas adicionais, o fornecedor deve absorver os custos e diminuir os riscos de
ultrapassar o orçamento para uma tarefa específica. Veja o Capítulo 10 para mais discussões
sobre mudanças de gestão.
RESUMO
A comunicação do projeto está dividida em várias formas, como comunicação pessoal, reu-
niões, apresentações, relatórios e documentação de projeto. Ela pode ser frente a frente ou
utilizar algum meio de comunicação, como telefone, mensagem de voz, e-mail, videoconfe-
rência ou software de rede. Pode ser formal ou informal. A comunicação pessoal pode ser
tanto oral como escrita. A comunicação pessoal oral pode ser frente a frente ou por telefone
e assim as informações podem ser transmitidas de forma mais precisa e mais oportuna. Esse
tipo de comunicação propicia um espaço para discussões, esclarecimentos, entendimentos
e um feedback imediato. A linguagem corporal e o tom de voz são elementos importantes
da comunicação oral e, com a diversidade cultural, devem ser considerados nas comunica-
ções. A comunicação oral deve ser direta, sem ambigüidades, livre de jargão técnico e não
ofensiva. Pedir feedback aumenta a compreensão.
A comunicação pessoal escrita é geralmente realizada por meio de memorandos inter-
nos e cartas externas, que podem ser usados para comunicar-se eficientemente com um
grande grupo de pessoas, mas não devem ser utilizados para questões triviais. As comu-
nicações escritas devem ser claras e concisas e utilizadas principalmente para informar,
confirmar e solicitar algo.
Ouvir é uma parte importante para se fazer uma comunicação eficaz. Não saber ouvir
pode causar uma ruptura na comunicação. As barreiras mais comuns para a eficácia da
capacidade de ouvir são: fingir que está escutando, distrações, idéias preconcebidas e
mente fechada, impaciência e conclusões precipitadas. A habilidade de ouvir pode ser me-
lhorada ao focar-se na pessoa que fala, empenhar-se em ouvir ativamente, fazer perguntas
e não interromper.
As reuniões são outro espaço para a comunicação do projeto. Os três tipos mais co-
muns de reuniões de projeto são a de status, a de resolução de problemas e a de análise
crítica de concepção técnica. Os propósitos de uma reunião de análise de status são
informar, identificar problemas e estabelecer tarefas. Os tópicos geralmente tratam de
realizações desde a reunião anterior; custos, cronograma e escopo do trabalho – status,
tendências, previsões e variações; ações corretivas; oportunidades de melhoria, e atribui-
ção de tarefas. As reuniões de resolução de problemas são convocadas quando surgem
problemas ou problemas em potencial. Elas devem ser realizadas para elaborar uma de-
claração de problema, identificar as causas, coletar dados, identificar e avaliar as possíveis
soluções, determinar a melhor solução, revisar o plano, implementar e avaliar a solução.
As reuniões de análise crítica de concepção técnica são realizadas em projetos que in-
cluem uma fase de concepção. Geralmente, faz-se uma reunião de análise de concepção
preliminar, em que o cliente analisa a conceituação inicial, e uma reunião de análise crítica
de concepção final, em que o cliente analisa os documentos de concepção detalhados e
concluídos. Essas reuniões são um mecanismo para obter a aprovação do cliente antes de
proceder ao restante da realização do projeto.
Antes da reunião, deve-se determinar seu propósito e os participantes, elaborar e dis-
tribuir uma pauta, além de preparar os materiais e a sala. A reunião deve começar pon-
tualmente, deve-se tomar notas e a pauta deve ser revisada. O líder da reunião precisa
moderar, e não dominar a reunião. Depois, as decisões e as tarefas devem ser publicadas
e distribuídas.
Os gestores de projetos e os membros das equipes são geralmente chamados para fazer
uma apresentação formal. Ao preparar-se para a apresentação, é importante determinar o
propósito dela, saber qual o público-alvo, fazer um esboço, elaborar anotações, providen-
ciar recursos visuais, providenciar cópias de materiais a serem distribuídos e ensaiar. Você
deve começar dizendo para o público sobre o que irá falar, depois mencionar todo o con-
teúdo e, no final, deve fazer um resumo sobre o que você falou na apresentação. Esta deve
ser clara, simples, interessante e terminar pontualmente.
Relatórios escritos são geralmente solicitados durante um projeto. Os dois tipos mais
comuns de relatórios são os de progresso e os finais. Os relatórios de progresso geralmente
tratam das realizações desde o relatório anterior, do status atual do projeto, de qualquer
problema em potencial que tenha sido identificado e das ações corretivas que são plane-
jadas, além das metas que devem ser alcançadas durante o próximo período de relatório.
Os relatórios finais fornecem um resumo do projeto, e geralmente incluem tópicos como a
necessidade original do cliente, o objetivo e os requisitos originais, os benefícios resultan-
tes, uma descrição do projeto e uma lista de deliverables produzidos. Todos os relatórios
precisam ser claros e concisos e devem ser escritos como você falaria. Eles devem tratar do
que é de interesse dos leitores, e não do escritor.
Durante todo o projeto, podem ser criados muitos tipos de documentos, como manuais
e desenhos, que precisam ser revisados para acrescentar mudanças feitas pelo cliente ou
pela equipe. No início do projeto, deve-se chegar a um acordo sobre como as mudanças
serão documentadas e autorizadas.
PERGUNTAS
1. Discuta por que a comunicação oral é importante para o sucesso do projeto e descreva
algumas maneiras de aumentar a comunicação.
2. Discuta por que a comunicação escrita na forma de memorandos e cartas externas é
importante para o sucesso do projeto e descreva algumas maneiras de aumentar tal
comunicação.
3. Por que a capacidade de ouvir é importante para uma comunicação eficaz? Como você
pode melhorar sua capacidade de ouvir?
4. Nos próximos dias, observe a linguagem corporal das pessoas com quem você se co-
munica. Descreva alguns dos itens positivos e negativos da linguagem corporal dessas
pessoas.
5. Discuta por que é importante ser sensível à composição diversa de uma equipe de pro-
jeto, principalmente com relação à comunicação.
6. Qual é o propósito das reuniões de análise de status? Quando devem ser realizadas? O
que deve ser tratado nessas reuniões?
7. Por que são realizadas reuniões de resolução de problemas? Quem deve ser convocado
para essas reuniões? Descreva a abordagem que deve ser seguida.
8. Qual é o propósito das reuniões de análise crítica de concepção técnica? Quais são os
dois tipos diferentes de análises críticas de concepção técnica? Quem deve participar? O
que deve ser tratado em cada tipo de reunião?
9. O que deve ser feito antes para se preparar adequadamente para uma reunião?
O que deve ser feito durante uma reunião para assegurar sua eficácia?
10. Se lhe for pedido que aconselhe alguém sobre como se preparar e como fazer uma
apresentação importante, o que você diria? Para cada passo listado, descreva por que é
importante.
11. Por que os relatórios de progresso são uma parte integral das comunicações do projeto?
O que deve ser incluído? Em que eles diferem de um relatório final?
12. Por que é importante controlar as mudanças feitas nos documentos do projeto? Como é
possível alcançar um controle eficaz?
~clements.
1. Faça uma busca na Internet sobre comunicações em projetos. Resuma pelo menos
um site e compare-o com o que foi apresentado neste capítulo. Que novas visões
você adquiriu por meio desse site?
2. Faça uma busca na Internet sobre capacidade de ouvir com eficácia. Identifique
algumas técnicas úteis que não foram apresentadas neste capítulo.
3. Faça uma busca na Internet sobre reuniões eficazes. Identifique algumas técnicas
úteis que não foram apresentadas aqui. Além disso, identifique pelo menos uma
ferramenta que permita a realização de reuniões on-line ou eletrônicas. Descreva os
recursos dessa ferramenta.
4. Faça uma busca na Internet sobre relatórios de projeto. Imprima e descreva pelo
menos um site que discuta métodos eficazes para escrever relatórios de projeto.
5. Atualmente, para melhorar a comunicação, muitos projetos têm seu próprio site. Busque
na web pelo menos uma ferramenta em um site de gestão de projeto. Descreva o
que essa ferramenta faz. Você acha que uma ferramenta como essa descrita por você
pode melhorar com eficácia as comunicações de projeto?
ESTUDO DE CASO Nº 1 Comunicação no Escritório
Cathy Buford é a líder de design de uma equipe de projeto técnico grande e complexo de
um cliente muito exigente. Joe Jackson é o engenheiro designado para a equipe de Cathy.
São quase 9h30 quando Joe vai até o escritório de Cathy. Ela está com a cabeça baixa
e atarefada.
– E aí, Cathy! Você vai ver o jogo do campeonato hoje à noite? Você sabe, eu fui treina-
dor voluntário este ano, Joe diz a ela.
– Oi, Joe. Estou realmente ocupada, Cathy diz.
Joe, então, senta-se em uma cadeira da sala e diz: – Ouvi dizer que seu filho joga bola
muito bem.
Cathy pega alguns papéis e tenta focar-se no trabalho: – Ah? Acho que sim. Estou tão
atarefada.
– É, eu também, Joe diz. – Tenho de fazer um intervalo para dar uma escapada.
– Aproveitando que está aqui, Cathy diz, estive pensando que talvez você devesse ava-
liar a possibilidade de usar o código de barras ou tecnologia de reconhecimento de carac-
teres ópticos para a entrada de dados. Isso pode...
Joe a interrompe: – Olha as nuvens negras que estão se formando no céu. Espero que
não chova no jogo essa noite.
Cathy continua: – Algumas das vantagens dessas tecnologias são... Continua falando
sobre isso por alguns minutos e pergunta: – Então, o que você acha?
– Ah? Não, elas não funcionam, responde Joe. – Confie em mim. Além disso, o cliente
usa pouca tecnologia e isso aumentaria os custos do projeto.
– Mas se pudermos mostrar ao cliente que isso poderia fazê-lo economizar dinheiro e
reduzir erros de entrada de dados, Cathy insiste, ele provavelmente pagaria os custos adi-
cionais para implementar as tecnologias.
– Economizar dinheiro!, Joe exclama. – Como? Despedindo funcionários? Nós já temos
muito desemprego por redução de cargos de trabalho. E o governo e os políticos não
estão fazendo nada em relação a isso. Não importa em quem você vote. Eles são todos
iguais.
– A propósito, ainda preciso de seus dados para o relatório de progresso, Cathy o lem-
bra. Necessito enviar o relatório para o cliente amanhã. Como você sabe, vou precisar de
cerca de oito a dez páginas. Precisamos entregar um relatório grande para mostrar para o
cliente como estivemos ocupados com o projeto.
– O quê? Ninguém me disse nada, fala Joe.
– Mandei um e-mail para a equipe de concepção já faz algumas semanas dizendo que
precisava dos dados de todos até a última sexta-feira. Você provavelmente poderia usar o
material que preparou para a reunião de análise de status do projeto de amanhã à tarde,
responde Cathy.
– Tenho de fazer uma apresentação na reunião de amanhã? Estou sabendo agora, Joe
lhe diz.
– Estava na pauta distribuída semana passada, diz Cathy.
– Não tenho tempo de atualizar todo o material acumulado na minha mesa, Joe diz
irritado. – Só vou ter que acelerar isso. Vou usar algumas das transparências da minha apre-
sentação de seis meses atrás. Ninguém vai perceber a diferença. Aquelas reuniões são uma
perda de tempo mesmo. Ninguém se interessa por elas. Todo mundo acha que são apenas
a perda de duas horas da semana.
– De qualquer modo, você pode me enviar por e-mail seus dados para o relatório de
progresso até o fim do dia?, Cathy pergunta.
– Hoje tenho que sair mais cedo por causa do jogo.
– Que jogo?
– Você não estava escutando nada do que eu disse? O jogo do Campeonato de Basquete.
– Então, você deveria começar a fazer isso agora, Cathy sugere.
– Só preciso falar com o Jim primeiro sobre o jogo de hoje à noite, diz Joe. – Depois vou
escrever alguns parágrafos. Você pode fazer umas anotações na reunião de amanhã durante
a minha apresentação? Seria o necessário para o seu relatório.
– Não posso esperar até amanhã. O relatório tem que estar no correio amanhã e por isso
vou ficar até tarde da noite preparando.
– Então, você não vai ver o jogo?
– Envie por e-mail os seus dados.
– Não estou sendo pago para ser digitador, argumenta Joe. – Escrevo muito mais rápido
à mão. Você pode pedir para alguém digitar. Você provavelmente vai querer editar tudo
isso mesmo. O último relatório para o cliente ficou totalmente diferente do que eu tinha
preparado. Parecia que você o tinha refeito completamente.
Cathy olha para todo o material sobre sua mesa e tenta continuar trabalhando.
PERGUNTAS
1. Quais são alguns dos problemas de comunicação?

2. O que Cathy deveria fazer? O que você acha que Joe irá fazer?
3. Como Cathy e Joe poderiam ter controlado melhor essa situação?
4. O que poderia ter sido feito para evitar o problema de comunicação entre Cathy e Joe?
ATIVIDADE EM GRUPO
Peça que dois participantes do curso encenem essa situação. Imediatamente depois, faça
um debate com o grupo sobre as quatro questões acima.
ESTUDO DE CASO Nº 2 Comunicação Internacional
– Samuel, é Angelique de novo. Agora são 9 horas de quarta-feira. Preciso falar com
você. Faz tempo que você não me liga e preciso de uma atualização do projeto. Também
quero discutir sobre algumas mudanças na colocação dos equipamentos na construção.
Tentei várias vezes enviar-lhe e-mail nas últimas semanas, mas recebo uma mensagem de
volta dizendo que meus e-mails não podem ser entregues. Você está com algum problema
na sua caixa de e-mail? Por favor, ligue para mim hoje. Tenho de entregar um relatório para
nossa diretoria na segunda-feira e preciso saber o status do projeto.
Angelique desliga o telefone depois de deixar essa mensagem de voz. Ela estava bas-
tante insatisfeita, pois já fazia várias semanas que vinha tentando falar com Samuel. Nesse
dia, ela pensou: – Chega! Se ele não me ligar de volta hoje, a primeira coisa que vou fazer
amanhã é ligar para o chefe dele.
Angelique era a nova gerente de fábrica nomeada para a nova unidade de produção
da ElectroTech Corporation que a Thomson Industries estava projetando e construindo
para a ElectroTech na Irlanda. Ela estava atualmente localizada na sede da ElectroTech em
Boston, mas seria transferida para a Irlanda assim que a construção começasse.
Samuel era o gestor de projetos da Thomson Industries, a principal contratada para a
concepção e construção da nova fábrica. Seu escritório ficava em Dallas. Embora ele tenha
gerenciado vários projetos antes, sempre eram menores e na região de Dallas. Ele conhecia
a maioria das pessoas que trabalhavam nesses projetos com ele. O projeto da ElectroTech
era sem dúvida o maior e mais complexo que já tinha sido designado a ele. Por exemplo,
nele duas das principais empresas terceirizadas que forneceriam equipamentos para a fábri-
ca ficavam na Alemanha e no Japão.
No início do projeto, Samuel fez uma rápida reunião de equipe e com confiança disse a
eles: – Boston e Irlanda não são diferentes de Dallas. E as empresas alemã e japonesa já es-
tão sabendo que minha abordagem será direta. Ou constroem os equipamentos de acordo
com nossas especificações e entregam no prazo combinado ou não serão pagos. Simples
assim. Sem desculpas, sem negociações. O contrato da ElectroTech tem uma cláusula de
bonificação por conclusão adiantada e eu pretendo conseguir isso. Então, temos que jogar
duro com nossos fornecedores e não deixar que qualquer atraso deles atrapalhe nossas
chances de ganhar a bonificação. E outra coisa: precisamos ser bem rigorosos com relação
às mudanças do cliente, para não haver razão para atrasos nem desculpa para que não nos
paguem a bonificação.
– Conseguimos designar pessoas qualificadas para esse projeto, então, temos de ser ca-
pazes de começar rápido. Todos devem saber exatamente o que precisa ser feito e, então,
não devemos perder muito tempo com reuniões para discutir e calcular as coisas. Podemos
focar todo nosso tempo na execução do trabalho em vez de ficar falando sobre ele. Não me
encham de papelada ou e-mails. Terei trabalho suficiente a fazer: acompanhar os orçamen-
tos e os cronogramas, cobrar os fornecedores, impedir que a ElectroTech faça uma série de
mudanças e não deixar que nossa própria diretoria fique na nossa cola.
Quando Samuel voltou para o escritório depois do almoço, Penny, sua assistente admi-
nistrativa, disse: – Verifiquei sua secretária eletrônica e Angelique deixou outra mensagem.
Disse que precisa falar com você, alguma coisa sobre mudanças. Disse também que sua
caixa de e-mail não deve estar funcionando.
Samuel responde: – Mudanças! Eu sabia! É exatamente por isso que eu não quero falar
com ela. Como toda mulher, sempre mudando de idéia sobre uma coisa ou outra. Ainda
bem que os homens não fazem isso, senão não teríamos nada feito. E sobre meus e-mails,
pedi que Larry configure minha caixa de modo que quem me enviar um e-mail vai receber
uma mensagem de volta dizendo que este não pôde ser entregue. Depois de um tempo,
eles vão entender que não estou interessado em receber cópias dos e-mails de todo mundo
cheias de trivialidades e detalhes.
Penny disse a Samuel: – Você deveria checar seus e-mails, pois alguns deles podem ser
muito importantes.
Samuel respondeu bruscamente: – Já gerenciei uma série de projetos de sucesso, todos
sem e-mails. Mais trabalho e menos conversa: esse é o segredo para o sucesso do projeto.
Penny diz: – Talvez seria melhor pedir para Larry reenviar seus e-mails para mim, para
que pelo menos eu pudesse fazer uma triagem.
– Pode fazer isso se quiser, replicou Samuel. – Você só terá muito mais trabalho. Se
alguma coisa realmente for importante, as pessoas vão saber como me encontrar. Como
acha que gerenciávamos antes de existir e-mails? Além disso, como você ouve minhas men-
sagens de voz, posso controlar meu tempo e decidir com quem preciso falar e quando, em
vez de ficar perdido com tantas ligações das pessoas me dizendo por que não podem fazer
tal coisa. De qualquer forma, elas sempre dão um jeito de fazer. Só precisam ter o hábito
de resolver os problemas assim que eles surgem, em vez de correr para o chefe para se
lamentar.
Samuel não respondeu à mensagem de voz de Angelique. Na manhã seguinte, ela ligou
para Michael Jetson, vice-presidente dos projetos da Thomson Industries e chefe de Samuel.
Enraivecida, ela contou que Samuel não respondia a suas ligações telefônicas nem a seus
e-mails. Ameaçou impedir todos os futuros pagamentos das faturas da Thomson se Samuel
não retornasse seus chamados.
Michael foi até o escritório de Samuel no momento em que ele analisava os relatórios
de custos do projeto e disse: – Samuel, recebi uma ligação de Angelique da ElectroTech.
Ela estava bastante nervosa. Disse que você não tem retornado as ligações e que ela precisa
falar com você.
Samuel respondeu: – Está absolutamente certo. E você sabe por que eu não estou retor-
nando as ligações? Porque ela quer fazer uma série de mudanças que atrasariam muito o
projeto e nos impediriam de receber aquela bonificação por conclusão adiantada.
– Disse para ela que você ligaria, Samuel. Então, por favor, ligue ainda hoje. Esse é um
projeto importante para todos nós e eu não quero um cliente insatisfeito, disse Michael.
– Michael, você sabe como as mulheres são. Elas colocam os sentimentos acima das
coisas. Vou ligar para ela e acalmá-la. Teria sido mais apropriado se ela me contasse que
iria te ligar, em vez de fazer tudo pelas costas. Mas não faz mal, é uma mulher para você!,
replicou Samuel.
Depois que Michael saiu do escritório de Samuel, Penny trouxe um fax do fornecedor
do Japão, que dizia: – Analisamos a última revisão das especificações de equipamentos que
nos foi enviada. Verificamos que elas foram alteradas sem o nosso conhecimento. Alguns
dos requisitos de desempenho foram mudados significativamente e lamentamos que eles
não possam ser cumpridos a menos que façamos uma grande mudança em toda a enge-
nharia do projeto. Gostaríamos de nos reunir com você para discutir os custos adicionais
exigidos para que esse trabalho adicional de engenharia permita atender às suas especifi-
cações revisadas.
Samuel diz: – Só pode ser brincadeira. Nós não vamos pagar nem um centavo a mais.
Eles receberam muito dinheiro no contrato de fornecimento para fazer qualquer mudança
que fosse necessária. Não vou negociar com eles sobre mais dinheiro. Eles que percebam
que nos Estados Unidos nós não fazemos negócios desse jeito, ou pelo menos eu não faço.
Penny, escreva uma carta para eles para eu assinar, dizendo que não vemos fundamento em
providenciar capital adicional. Eles sabiam que as especificações iniciais estavam marcadas
como preliminares e deveriam ter previsto que futuras alterações de engenharia seriam exi-
gidas conforme as coisas fossem construídas. Faça uma carta breve e resoluta. Não quero
deixar nenhuma abertura para aqueles tipos de negociações embaraçosas.
– Só mais duas coisas, Penny, diz Samuel. – Agende uma reunião de projeto para ama-
nhã com todos os membros possíveis. Tenho de saber o que está acontecendo com esses
equipamentos. Preciso descobrir se alguém esteve falando com o fornecedor japonês ou
se Angelique não me informou sobre isso. E digo mais, se eu descobrir o que aconteceu,
algumas pessoas terão que dar uma boa explicação. As pessoas não sabem que o trabalho
delas é me manter informado? E uma segunda coisa. Ligue para Angelique e veja se ela
pode vir para Dallas na sexta-feira para uma reunião. Não tenho tempo de ir até lá, pois
tenho uma partida de tênis com um velho amigo na sexta-feira à noite. Já que ela quer tanto
falar comigo, deixe que venha até aqui. Talvez assim ela se acalme. Também faça reservas
para todos nós naquele novo restaurante próximo ao shopping. Depois de conversarmos
calmamente e de bebermos alguns drinques no almoço, vou sugerir a ela que vá ao shop-
ping fazer compras antes de voltar para Boston. Comprar é o que toda mulher precisa para
se livrar do estresse, não é mesmo Penny?
PERGUNTAS
1. Quais são os erros de comunicação de Samuel?

2. O que Angelique deveria fazer quando recebesse a ligação de Penny pedindo a ela que
fosse a Dallas para uma reunião com Samuel?
3. Michael poderia ter dito ou feito algo mais em sua conversa com Samuel sobre a ligação
de Angelique? Penny deveria fazer alguma coisa com relação ao estilo de comunicação
e aos comentários infelizes de Samuel?
4. Quais seriam os elementos de um bom plano de comunicação para gerenciar um pro-
jeto multinacional como esse?
ATIVIDADE EM GRUPO
Divida os participantes do curso em grupos de três ou quatro pessoas para elaborar as res-
postas para as perguntas anteriores. Cada grupo deve indicar um orador para apresentar
as respostas para toda a turma.
Capítulo TIPOS DE ORGANIZAÇÃO DE PROJETO
13 Organização Funcional
Organização por Projetos
Organização Matricial
Estudo de Caso no 1 Multi
Projects
Perguntas
Vantagens e Desvantagens
Estrutura Organizacional Atividade em Grupo
Funcional Estudo de Caso no 2 Divisões
Estrutura Organizacional por de Fabricação
Projetos Perguntas
Estrutura Organizacional Matricial Atividade em Grupo
Resumo
Perguntas
378
Ca pítulo Tre ze
Diretrizes Simples para Grandes Líderes
Um líder eficaz compromete as pessoas a agir, transforma membros de equipes em líderes
e atua como um agente de mudança. Joni Daniels, fundador e diretor da Daniels & Associa-
tes, grupo de consultoria especializado em desenvolvimento pessoal e profissional, oferece
essas Diretrizes para os Grandes Líderes:
Prenda-se à missão e à visão – Assegure-se de que a equipe entende como o projeto
se encaixa dentro da organização (missão) e como ele vai ajudar a organização a chegar a
um estágio futuro desejado (visão). Pergunte aos membros da equipe se suas ações e deci-
sões se encaixam dentro de sua missão.
Comportamento inaceitável é inaceitável – Não permita que as pessoas demonstrem
mau comportamento sem sofrer as conseqüências.
Os líderes não podem controlar os sentimentos das pessoas, mas podem deixar claras
as expectativas em relação ao comportamento de cada uma delas – Defenda o bom com-
portamento e não ignore o mau comportamento.
Interesse mútuo em vez de interesse próprio – Transforme o trabalho em equipe em
critério para obter um bom desempenho dos membros da equipe.
O medo não controla o comportamento da equipe – Em vez de deixar as pessoas te-
merosas, concentre-se em incentivar o bom comportamento e produzir ações positivas.
“Panelinhas” não controlam a dinâmica da equipe – Afirme claramente no início do
projeto que você espera que as pessoas cooperem umas com as outras.
Gerencie e resolva os conflitos – O conflito é uma ocorrência natural que motiva as
pessoas a trabalhar em maior cooperação após sua resolução. A gestão e resolução de con-
flitos ensina a cada membro que eles são capazes de lidar com os problemas juntos. O
conflito é necessário para que os membros da equipe aprendam a confiar uns nos outros.
Ignorar conflitos seria um erro.
Para um resultado bem-sucedido do projeto, não negligencie nem apresse os proces-
sos – As pessoas esquecem-se de todas as normas e metodologias de equipe quando estão
sob pressão. Em vez disso, elas farão tudo o que for necessário para terminar o trabalho.
Revise os processos de equipe ao final de cada reunião para que a equipe possa refletir
sobre suas ações.
Daniels, J. The Collaborative Experience. Industrial Management, maio/junho de 2004, p. 27-30.
379
Embora existam várias formas com as quais as pessoas podem se organizar para traba-
lhar em projetos, os tipos mais comuns de estrutura organizacional são: funcional, por
projetos e matricial. Os exemplos aqui se referem a empresas manufatureiras; contudo,
os conceitos aplicam-se a outros setores, como prestadoras de serviços e organizações
não-governamentais (por exemplo, instituições educacionais e hospitais). Você irá se
familiarizar com:
• as características dos três tipos de estruturas organizacionais;
• as vantagens e desvantagens de cada tipo de estrutura.
ORGANIZAÇÃO FUNCIONAL
A Figura 13.1 representa uma estrutura organizacional funcional para uma empresa
manufatureira que vende produtos eletrônicos-padrão. As estruturas organizacionais do
tipo funcional são tipicamente usadas em empresas que vendem e fabricam principalmen-
te produtos-padrão e raramente conduzem projetos externos. Por exemplo, uma empresa
que fabrica e vende aparelhos de gravação e reprodução de vídeo pode ter uma estrutura
organizacional funcional. Nesse tipo de organização, os grupos são compostos por pessoas
FIGURA 13.1 Estrutura Organizacional Funcional
Acme Electronics
Products, Inc.
Presidente
Vice-Presidente de
Recursos Humanos
Vice-Presidente Vice-Presidente
de Marketing de Engenharia
Gerente de Gerente de Gerente de Gerente de Gerente de

Engenharia Engenharia Engenharia Engenharia Documentação
de Sistemas Eletrônica de Software Mecânica Técnica
Gerente de Gerente de
Gerente de
Atendimento Vendas
Vendas
ao Internacionais
Nacionais
Consumidor
Capítulo 13 Tipos de Organização de Projeto 381
que realizam a mesma função, como engenharia ou fabricação, ou têm experiência ou ha-
bilidades idênticas, como engenharia eletrônica ou testes. Cada grupo funcional, ou área,
concentra-se em realizar as próprias atividades dentro da missão comercial da empresa. O
foco está na excelência técnica e na competitividade de preços dos produtos da empresa,
assim como na importância da contribuição da experiência de cada área funcional aos pro-
dutos da empresa.

1. A organização funcional enfatiza a
importância da contribuição da _______
________ de cada área funcional para os
produtos da empresa.
Uma empresa com uma estrutura funcional pode desenvolver projetos de tempos em
tempos, mas estes costumam ser internos, em vez de projetos para clientes externos. Os
projetos em organizações do tipo funcional podem envolver o desenvolvimento de novos
Vice-Presidente
Financeiro e
Administrativo
de Suprimentos
de Fabricação e Contratos
Gerente de
Gerente
Recebimento
de Compras
e Inspeção
Gerente de
Gerente de Gerente de Gerente de Gerente de
Programação
Produção Montagem Testes Expedição
de Produção
produtos, a concepção de um sistema de informação corporativo, um novo projeto para o

leiaute do escritório ou a atualização da política ou do manual de procedimentos da em-
presa. Para tais projetos, uma equipe de projeto ou força-tarefa multifuncional é formada,
com pessoas selecionadas pela gerência da empresa a partir das subfunções apropriadas
de marketing, engenharia, fabricação e compras. Os membros da equipe podem ser de-
signados para o projeto em meio período ou período integral, para uma parte do projeto
ou durante toda a sua duração. Na maioria dos casos, contudo, as pessoas continuam a
realizar suas funções regulares enquanto fazem parte da força-tarefa para o projeto em meio
período. Um dos membros da equipe – ou possivelmente um dos vice-presidentes funcio-
nais – é designado como líder ou gestor.

2. Verdadeiro ou falso: em uma
organização funcional, as pessoas
continuam a realizar seu trabalho
funcional regular, enquanto atuam
em uma força-tarefa de um projeto
em período parcial.
Em uma organização do tipo funcional, o gestor do projeto não tem autoridade total
sobre a equipe, já que, do ponto de vista administrativo, os membros ainda trabalham para
seus respectivos gerentes funcionais. Como enxergam sua contribuição para o projeto em
termos de sua experiência técnica, continuam subordinados a seus gerentes funcionais. Se
houver conflito entre os membros da equipe, isso costuma percorrer toda a hierarquia da
organização até ser resolvido, desacelerando os trabalhos do projeto. No entanto, se o pre-
sidente da empresa conceder ao gerente de projeto a autoridade de tomar decisões quando
houver desacordo entre os membros da equipe, as decisões podem refletir os interesses da
área funcional do próprio gestor do projeto, e não os melhores interesses do projeto como
um todo. Por exemplo, imagine uma situação na qual há desacordo sobre a concepção
de um novo produto e o gestor do projeto, que é da função de engenharia, toma a deci-
são de reduzir o custo de concepção de engenharia do produto, mas aumenta o custo de
fabricação. Ao relatar o progresso do projeto para o presidente da empresa, o gestor faz
alguns comentários tendenciosos em relação aos pontos de vista dos membros da equipe
de outras áreas funcionais, do gênero: “Se a fabricação estivesse mais disposta a conside-
rar outros métodos de produção, eles poderiam fazer o produto a um custo mais baixo. A
engenharia já reduziu seus custos com concepção”. Uma situação dessa natureza poderia
exigir que o presidente da empresa se envolvesse na resolução do conflito.
A estrutura organizacional do tipo funcional pode ser apropriada para projetos inter-
nos de uma empresa. Contudo, como os projetos não são parte da rotina da empresa, é
necessário estabelecer um entendimento claro do papel e das responsabilidades de cada
pessoa designada para a força-tarefa. Se o gestor não tem autoridade total para as decisões,
deve contar com as habilidades de liderança e persuasão para chegar a um consenso, lidar
com conflitos e unir os membros da força-tarefa para atingir o objetivo do projeto. O gestor
também precisa reservar um tempo para informar os outros gerentes funcionais da empresa
regularmente sobre o status do projeto e agradecê-los pelo apoio das pessoas designadas
para a força-tarefa.
Pode haver situações nas quais uma força-tarefa é designada para trabalhar em um
projeto que seja estritamente em uma área funcional em particular. Por exemplo, o gerente
de documentação técnica pode formar uma força-tarefa de editores e especialistas em do-
cumentação com a finalidade de desenvolver padrões comuns para todos os documentos
técnicos. Nesse caso, o gerente funcional em particular tem autoridade total sobre o projeto,
e os conflitos podem ser resolvidos mais rapidamente do que se surgissem dentro de uma
equipe de projeto multifuncional.
As empresas com estruturas organizacionais funcionais raramente conduzem projetos
envolvendo clientes externos, já que esse tipo de organização não possui gestores designa-
dos para gerenciar projetos financiados pelo cliente. Em vez disso, as organizações do tipo
funcional se concentram em produzir seus produtos e vendê-los a vários clientes.

3. Uma empresa com uma estrutura
funcional pode periodicamente formar
forças-tarefa para trabalhar em projetos
_________________, mas raramente irá
conduzir projetos que envolvam clientes
_________________.
ORGANIZAÇÃO POR PROJETOS

A Figura 13.2 ilustra uma estrutura organizacional por projetos para uma empresa que
vende projetos de trânsito expresso para cidades e municípios. Os projetos médios envol-
vem milhões de dólares e têm duração de vários anos, incluindo engenharia, fabricação e
instalação. Essa empresa trabalha no ramo de projetos; não fabrica produtos-padrão, mas
sim executa vários projetos ao mesmo tempo, em diferentes estágios. À medida que os
projetos avançam e são concluídos, a empresa espera obter contratos para outros novos. As
pessoas são contratadas para trabalhar em um projeto específico; elas podem ser realocadas
de um outro recém-concluído se tiverem a experiência adequada. Cada equipe dedica-se
a apenas um projeto. Quando ele é concluído, seus membros podem ser designados para
outro; do contrário, eles são dispensados.

4. Em uma organização por projetos,
todos os recursos são designados em
________________ para trabalhar em
um projeto particular.
O gestor do projeto tem autoridade
________________ e ________________
total sobre a equipe de projeto.
Na organização por projetos, cada projeto é tratado como uma microempresa. Todos os
recursos necessários para realizar cada projeto são designados para trabalho em período
integral. Um gestor em tempo integral tem total autoridade administrativa e de projeto sobre
sua equipe (na organização funcional, o gestor pode ter autoridade sobre o projeto, mas o
gerente funcional detém a autoridade técnica e administrativa sobre as pessoas designadas
para sua equipe). A organização por projetos é estruturada para ficar altamente focada no
objetivo do projeto e nas necessidades do cliente, já que cada equipe se dedica exclusiva-
mente a apenas um projeto.
Uma organização por projetos pode não ter uma boa relação custo–benefício tanto para
projetos individuais como para a empresa. Cada projeto deve pagar os salários da equipe
FIGURA 13.2 Estrutura Organizacional por Projetos
Ajax Rapid Transit

Project, Inc.
Presidente
de Marketing de
Recursos Humanos
Vice-Presidente
Vice-Presidente
Financeiro e
Jurídico
Administrativo
Gestor do Gestor do
Projeto A Projeto B
Gerente de Gerente de Gerente de

Fabricação Suprimentos Subcontratados
Engenharia
e Contratos
Fabricação Sistemas Subcontratados X

Montagem Hardware Subcontratados Y
Testes Software Instalação
Treinamento
Gerente de
Consultores Suprimentos
Engenharia Fabricação
e Contratos
Sistemas Análise Crítica de Concepção Técnica Montagem

Elétrica Treinamento Testes
Mecânica
Software
dedicada a ele, mesmo durante os estágios nos quais alguns de seus membros não estão
envolvidos. Por exemplo, se um atraso em uma parte do projeto deixa algumas pessoas
sem trabalho por várias semanas, os fundos do projeto precisam cobrir esses custos. Se a
quantidade de tempo ocioso se tornar excessiva, o projeto pode deixar de dar lucro e pas-
sar a absorver os lucros de outros projetos. Do ponto de vista corporativo, uma organização
por projetos pode não ter um bom custo–benefício em função da duplicação de recursos
ou tarefas em vários projetos simultâneos. Como não são compartilhados, os recursos não
podem ser desviados para um projeto simultâneo semelhante quando não estão ocupados
nem sendo usados para o projeto ao qual foram designados. Da mesma forma, são poucas
as oportunidades para membros de diferentes equipes compartilharem conhecimento ou
experiência técnica, já que cada equipe tende a ficar isolada e concentrada unicamente em
seu próprio projeto. Contudo, podem haver algumas funções de suporte dentro da empre-
sa que atendem a todos os projetos. A Figura 13.2 mostra, por exemplo, que a função de
recursos humanos atende a todos os projetos, já que não faz sentido cada projeto contratar
a própria equipe de recursos humanos. Por ter uma área de recursos humanos comum, a
empresa provavelmente terá políticas de recursos humanos e benefícios consistentes para
seus trabalhadores.

5. Uma organização por projetos pode
ter _______________.
Em uma organização por projetos, são necessários um planejamento detalhado e preci-

so e um sistema de controle eficaz, a fim de garantir a utilização máxima dos recursos na
conclusão bem-sucedida do projeto dentro do orçamento.
Estruturas organizacionais por projetos são encontradas principalmente em empresas
envolvidas em projetos muito grandes, que podem ter um orçamento alto (milhões de
dólares) e ser bastante longos (vários anos). Estruturas organizacionais por projetos predo-
minam nos setores de construção civil pesada e aeroespacial. Elas também são usadas no
ambiente não corporativo, como em uma campanha de arrecadação de fundos gerenciada
por voluntários, festivais municipais, reuniões de turma de colégio ou em um show de
variedades.

6. Estruturas organizacionais
por projetos são encontradas
principalmente em empresas que estão
envolvidas em projetos muito _________
_________.
ORGANIZAÇÃO MATRICIAL
A Figura 13.3 mostra uma estrutura organizacional matricial para uma empresa que
comercializa sistemas customizados de automação baseados em computador. Cada cliente
encomenda um sistema exclusivo. Alguns sistemas são vendidos por apenas US$ 50 mil e
levam de quatro a seis meses para serem projetados e fabricados, enquanto outros custam
vários milhões de dólares e levam até três anos para serem concluídos. Assim como a Ajax
Rapid Transit Project, Inc. (na Figura 13.2), a Specialized Computer Systems, Inc. atua no
ramo de projetos; contudo, seus negócios envolvem um número maior de projetos de
menor porte. A empresa trabalha em vários projetos ao mesmo tempo, os quais podem
variar em termos de tamanho e complexidade. Nessa empresa, os projetos são concluídos
e iniciados o tempo todo.
A organização matricial é meio híbrida – uma mistura das estruturas organizacionais fun-
cional e por projetos. Ela mantém o foco no cliente e no projeto, que são característicos da
estrutura por projetos, mas é capaz de reter a experiência funcional da estrutura funcional.
Cada um dos projetos e áreas funcionais da estrutura matricial tem sua responsabilidade de
contribuir para o sucesso conjunto de cada projeto e da empresa. O gestor é responsável
pelos resultados do projeto, enquanto os gerentes funcionais são responsáveis por fornecer
os recursos necessários para atingir os resultados.

7. A estrutura organizacional do tipo
matricial fornece o foco no cliente e
no projeto da estrutura ___________,
mas retém a experiência funcional da
estrutura ____________.
FIGURA 13.3 Estrutura Organizacional Matricial
Specialized
Computer Systems, Inc.
Presidente
Vice-Presidente
de Marketing
de Projetos de Engenharia
Gerente de Gerente de Gerente de Gerente de Gerente de Gerente de

Administração Engenharia Engenharia Engenharia Engenharia Documentação
de Projetos de Sistemas Eletrônica de Software Mecânica Técnica
Cliente do Gestor do
Jack Jim Julie Cathy Rose
Projeto A Projeto A
Equipe do
Projeto A
Cliente do Gestor do
Beth Jeff Maggie Jen Paul Steve
Projeto B Projeto B
Equipe do
Projeto B
Cliente do Gestor do Jack Rose

Joe Cathy
Projeto C Projeto C
Equipe do
Projeto C
Outros Projetos
A organização matricial oferece uma utilização eficaz dos recursos da empresa. As áreas
funcionais (engenharia de sistemas, testes, e assim por diante), que detêm as equipes técni-
cas, oferecem uma gama de competências para colaborar em projetos em andamento.

8. Em uma organização matricial, as
áreas _________________ fornecem um
agregado de _______________ para dar
suporte a projetos em andamento.
Vice-Presidente
Financeiro
Vice-Presidente
de
Recursos Humanos
de Fabricação de Serviços
de Campo
Gerente de Gerente de Gerente de
Programação Treinamento
Montagem Testes Instalação
da Produção
Dennis Chr is Sharon T yler
Jessica Chr is Alex Gerri Wendy
Alex Hannah
Os gestores ficam subordinados à área de projetos da organização. Quando a empresa

recebe uma encomenda por um novo sistema, o vice-presidente de projetos designa um
gestor para o projeto. Um projeto pequeno pode ser designado para um gestor que já esteja
gerenciando vários outros projetos pequenos. Um grande projeto pode ser designado para
um gestor em período integral.
O gestor, em seguida, reúne-se com os gerentes funcionais apropriados para negociar a
alocação de várias pessoas das áreas funcionais para trabalhar no projeto. Elas são designa-
das para o projeto pelo prazo de tempo em que forem necessárias. Algumas pessoas podem
ser designadas para o projeto em período integral, enquanto outras podem ser alocadas
apenas meio período. Algumas podem ser designadas para um projeto durante toda a sua
duração; outras podem trabalhar apenas em uma parte, ou mesmo entrar e sair seguidamen-
te no decorrer do projeto, dependendo de quando seus conhecimentos são necessários e
com quantas horas do seu salário o orçamento pode arcar. Em uma organização matricial,
não é raro que uma pessoa de uma área funcional seja alocada meio período para vários
projetos simultâneos. A Figura 13.3 mostra, por exemplo, que Jack, Cathy, Rose, Chris e
Alex estão trabalhando meio período em dois projetos. Alguns projetos não exigem certos
tipos de conhecimento. Por exemplo, os projetos A e C não exigem nenhuma atividade de
engenharia mecânica, e o A não inclui nenhum treinamento. Assim, dividir o tempo das
pessoas entre vários projetos resulta na utilização eficaz de recursos e minimiza os custos
globais para cada projeto e para toda a empresa.

9. A estrutura organizacional do tipo
matricial resulta na utilização eficaz dos
___________ e minimiza os ___________
gerais, já que permite que as pessoas
___________ seu tempo entre vários
_____________.
À medida que os projetos ou tarefas específicas são concluídos, as pessoas disponíveis

são designadas para novos projetos. O objetivo é maximizar o número de horas das pessoas
e das áreas funcionais designadas para trabalhar (dentro das limitações dos orçamentos dos
projetos individuais), bem como minimizar o tempo ocioso (já que os custos dos salários
por tempo não utilizado têm de ser absorvidos pela empresa, o que reduz sua rentabilidade
geral). Evidentemente, deve-se prever tempo ocioso para férias, feriados, doenças, ativida-
des de treinamento, além do trabalho em propostas para novos projetos.
É importante observar que, se a quantidade total de tempo ocioso da equipe funcional
for grande, a empresa pode não ter lucro, mesmo que cada projeto seja concluído dentro
das horas orçadas. Isso acontecerá se a companhia não estiver trabalhando em projetos
suficientes para utilizar as pessoas de algumas das áreas funcionais. A empresa sempre
precisa ter novos projetos entrando à medida que outros são concluídos, a fim de manter
um alto índice de tempo utilizado para a equipe funcional. Se a quantidade de tempo
ocioso for excessiva, pode ser necessário demitir pessoas. A empresa precisa estar sempre
buscando oportunidades de desenvolver novos projetos para clientes novos ou antigos,
ou desenvolver propostas em resposta a chamadas de propostas, conforme discutido no
Capítulo 3.
A organização matricial oferece oportunidades para as pessoas das áreas funcionais bus-
carem o desenvolvimento de suas carreiras por meio de sua alocação para vários projetos. À
medida que ampliam sua experiência, elas se tornam mais valiosas para os projetos futuros
e aumentam suas chances de serem promovidas para cargos mais altos dentro da empresa.
Conforme cada pessoa de uma determinada área funcional desenvolve uma ampla base
de experiência, o gerente funcional ganha mais flexibilidade para alocá-las para diferentes
tipos de projetos.
Todas as pessoas alocadas para um determinado projeto formam a equipe de projeto,
sob a liderança de um gestor que integra e unifica os trabalhos. As pessoas alocadas para
vários projetos pequenos serão membros de várias equipes diferentes. Cada participante de
uma equipe de projeto tem uma dualidade de relações hierárquicas; de certa forma, cada
membro tem dois gerentes – um gestor de projeto (temporário) e um gerente funcional
(permanente). Para uma pessoa designada para vários projetos concomitantes, a mudança
nas prioridades de trabalho pode causar conflito e ansiedade.

10. Em uma organização do tipo
matricial, cada membro de uma
_____________ tem uma dualidade de
relação hierárquica para com o gestor
___________ temporário e com o gerente
_____________ permanente.
É fundamental especificar para quem o membro da equipe se reporta e por quais respon-
sabilidades ou tarefas. Portanto, é importante que as responsabilidades pela gestão do projeto
e pela gestão funcional sejam delineadas em uma organização matricial.
Na estrutura organizacional do tipo matricial, o gestor do projeto é o intermediário entre
a empresa e o cliente. Ele define o que precisa ser feito (escopo do trabalho), até quando
(cronograma) e por quanto (orçamento) para atingir o objetivo do projeto e satisfazer o
cliente. Também é responsável por liderar o desenvolvimento do plano, estabelecer o cro-
nograma e o orçamento para o projeto e alocar tarefas e orçamentos específicos para as
várias áreas funcionais da organização da empresa. Ao longo do projeto, o gestor é respon-
sável tanto por controlar o desempenho do trabalho dentro do cronograma e do orçamento
quanto por relatar o progresso do projeto para o cliente e para a alta gerência da empresa.
Um administrador pode ser designado para cada projeto, a fim de dar suporte ao gestor e
à equipe em termos de planejamento, controle e prestações de contas.

11. Em uma organização matricial,
o gestor do projeto define ____________
tem que ser feito, até ______________,
por quanto _______________, a fim de
cumprir com o _________________ do
projeto e satisfazer o cliente.
Cada gerente funcional em uma estrutura organizacional matricial é responsável pelo

modo como as tarefas de trabalho distribuídas serão realizadas e quem (qual pessoa específi-
ca) executará cada tarefa. O gerente funcional de cada área funcional da organização oferece
orientação técnica e liderança às pessoas designadas para os projetos. Ele também é respon-
sável por garantir que todas as tarefas designadas para aquela área funcional sejam concluídas
de acordo com as exigências técnicas do projeto, dentro do orçamento e do prazo.

12. Em uma organização matricial, cada
gerente funcional é responsável por
_______________ o trabalho será feito e
_______________ realizará cada tarefa.
Em um ambiente de múltiplos projetos, cada gerente funcional pode ter várias pessoas
designadas para segmentos de vários projetos simultâneos, principalmente se os projetos
forem pequenos demais para alocar pessoas em período integral ou caso precisem de um
conhecimento específico por apenas um curto período de tempo. O gerente funcional deve
continuamente monitorar as tarefas das pessoas em sua área funcional e fazer quaisquer
realocações necessárias em resposta a mudanças nas condições dos vários projetos, como
atrasos no cronograma ou mudanças solicitadas pelo cliente. Por exemplo, se um projeto
estiver atrasado porque o cliente está demorando mais que o previsto para revisar e aprovar
desenhos de engenharia ou porque a remessa de um equipamento por parte de um for-
necedor está tardando mais que o estimado, as pessoas designadas para o projeto podem
ser temporariamente realocadas para outros projetos, se possível. Em uma situação na qual
um projeto está atrasado e correndo o risco de não ser concluído até a data exigida pelo
cliente, o gerente funcional pode temporariamente alocar pessoas de outros projetos que
não estejam em risco.
A organização matricial oferece um ambiente de “verificações e equilíbrio”. O fato de que
problemas em potencial podem ser identificados tanto por meio de sua estrutura de projeto
quanto de sua estrutura funcional reduz a probabilidade de os problemas serem ignorados
até o ponto em que não podem mais ser corrigidos sem pôr em risco o sucesso do projeto.
A estrutura organizacional matricial permite respostas rápidas mediante a identificação de
um problema, pois tem tanto um caminho horizontal (projeto) quanto um caminho vertical
(funcional) para o fluxo de informações.

13. A estrutura organizacional matricial
permite respostas rápidas mediante a
identificação de problemas porque tem
tanto um caminho _________________
quanto um ______________ para o fluxo
de ____________________.
O vice-presidente de projetos, a quem os gestores de projetos se reportam, tem um

papel importante na estrutura matricial (veja a Figura 13.3). Ele pode resolver conflitos de
prioridade entre dois ou mais projetos dentro da organização. Por exemplo, se dois projetos
estiverem competindo pelo uso de um recurso específico (um especialista técnico, talvez,
ou um equipamento de teste), o vice-presidente de projetos pode decidir a prioridade em
termos do menor risco global para a empresa e para as relações com o cliente (principal-
mente se a empresa tiver outros projetos atuais ou propostos para um determinado cliente).
Por meio da função de administração de projetos, o vice-presidente pode estabelecer pro-
cedimentos consistentes para a gestão de projetos, como planejamento e orçamento, coleta
de dados, uso de sistemas de informação e relatórios.

14. Relacione três tipos comuns de
estruturas que podem ser usadas para
organizar as pessoas para trabalhar em
projetos.
VANTAGENS E DESVANTAGENS
As seções anteriores discutiram as características das organizações dos tipos funcional, por
projetos e matricial. A Tabela 13.1 relaciona algumas das vantagens e desvantagens mais
significativas específicas de cada uma das três estruturas organizacionais.
Estrutura Organizacional Funcional

Ao reunir especialistas da mesma área na unidade organizacional, uma organização funcio-
nal reduz a duplicação e a sobreposição de atividades. Ela oferece os benefícios associados
à especialização: um ambiente no qual as pessoas podem compartilhar e atualizar seus
conhecimentos e sua competência sobre um assunto em particular. Por exemplo, todas as
pessoas de uma unidade de engenharia de computação podem compartilhar softwares e
discutir abordagens para o desenvolvimento de sistemas computacionais.
No entanto, as organizações funcionais podem ser compartimentadas, com cada área
funcional preocupada apenas com o próprio desempenho. O trabalho em equipe com ou-
tras funções não é enfatizado, e há pouca fertilização cruzada de idéias entre as funções.
O foco do projeto também não é enfatizado, e as decisões podem atender a interesses de
grupos, e não aos melhores interesses do projeto como um todo. A estrutura hierárquica
leva a comunicação, a resolução de problemas e a tomada de decisões a serem lentas.

15. Quais são algumas vantagens
e desvantagens da estrutura
organizacional funcional?
Imagine um exemplo no qual há um problema de defeitos em produtos. A engenharia

opina que a fabricação não está fazendo o produto adequadamente. A fabricação reclama
que a engenharia não fez a concepção do produto corretamente ou houve erros nos dese-
nhos de engenharia fornecidos para a fabricação. Um problema assim poderia ir de um lado
TABELA 13.1 Vantagens e Desvantagens das Estruturas Organizacionais
Vantagens Desvantagens
Estrutura Funcional • Ausência de duplicação • Compartimentação
de atividades • Resposta lenta
• Excelência funcional • Falta de foco no cliente
Estrutura por Projetos • Controle dos recursos • Ineficiência de custos
• Sensibilidade aos clientes • Baixo nível de transferência
de conhecimento entre
projetos
Estrutura Matricial • Utilização eficiente dos • Dualidade de relações
recursos hierárquicas
• Experiência funcional • Necessidade de equilíbrio
disponível para todos os de poder
projetos
• Maior aprendizado
e transferência de
conhecimento
• Melhor comunicação
• Foco no cliente
Chicago Police Department
O Departamento de Polícia de Chicago (CPD – Chicago Police Department) está usando
uma tecnologia de informação avançada para transformar seus processos comerciais e pro-
teger melhor três milhões de cidadãos dentro de um limite de 590 quilômetros quadrados.
Sua mais recente ferramenta de combate ao crime, o Sistema de Relatório e Análise de
Cumprimento da Lei (CLEAR – Citizen Law Enforcement Analysis and Reporting System),
oferece rápido acesso a informações compartilhadas sobre crimes. Depois de três anos e
US$ 40 milhões, cerca de metade das funções planejadas do CLEAR já foram desenvolvidas
e estão em uso. O sistema inclui 2 mil notebooks sem fio para policiais em rodovias, com 3
mil desktops, todos usados para acessar uma base de dados Oracle protegida, que contém
informações valiosas sobre crimes. O CPD processa cerca de 700 prisões por dia nos limites
da cidade de Chicago. Todos os dados são registrados e armazenados no CLEAR, que forne-
ce um repositório central de dados localizáveis para o CPD e outros departamentos de po-
lícia do Estado de Illinois. Um dia, o CLEAR vai incluir funções que permitam aos cidadãos
de Chicago se comunicarem com o CPD.
Desde a introdução do CLEAR, o índice de solução de crimes por parte do departa-
mento aumentou. Em apenas um ano após sua implementação, em 2001, o índice de solu-
ção de crimes do CPD aumentou de 21%, em 2001, para 26%, em 2002. A média nacional
de crimes resolvidos pelo departamento de polícia norte-americano foi de 17% em 2002.
Ron Huberman, líder do projeto, e sua equipe de TI, com 142 membros, desenvolveram
esse sistema para atender à missão do CPD de servir e proteger os cidadãos de Chicago.
Huberman começou sua carreira no CPD como policial, trabalhando nas ruas da cidade. Ele
usou as próprias experiências para projetar o CLEAR, de modo que suas funções refletissem
os processos tradicionais usados no CPD, tornando ao mesmo tempo a coleta de dados e
informações mais eficientes.
O CPD é a segunda maior força policial dos Estados Unidos, com 13.600 policiais e
3 mil funcionários civis. Antes da implementação do CLEAR, muitos de seus funcionários
não tinham muita experiência em interagir com a informática. Como o CPD implementou
o CLEAR com sucesso? O grande porte da organização e a possibilidade de resistência às
mudanças por parte dos funcionários poderiam ter resultado em um desastre na imple-
mentação do novo sistema. Contudo, o projeto CLEAR é considerado um sucesso para o
CPD. Os fatores que levaram ao sucesso se concentram no usuário. Inúmeras opiniões de
usuários foram coletadas para a concepção e o planejamento do sistema durante sessões
conjuntas de desenvolvimento do aplicativo (JAD – Joint Application Development). Da
mesma forma, O CLEAR foi desenvolvido com interfaces amigáveis ao usuário, para que
ficasse parecido com formulários de papel existentes. Para ajudar a aumentar ainda mais
a aceitação por parte dos usuários, alguns funcionários treinaram outros sobre como usar
o novo sistema. O CPD ganhou o Prêmio de Empreendedorismo em 2004 pelo sucesso na
implementação do CLEAR. Com seu novo sistema, o CPD transformou suas práticas lentas
e desconectadas em processos altamente eficientes para o compartilhamento de informa-
ções críticas.
Por meio da integração de tecnologia e do uso eficiente de princípios de gestão de
projetos, a cidade está se tornando um lugar mais seguro para se viver e trabalhar!
Pastore, R. Taking IT to the Street: How the Chicago Police Department Used Technology to Fight Crime and Become the First
Grand CIO Enterprise Value Award Winner, CIO Magazine, 15 de fevereiro de 2004.
para o outro dentro da hierarquia de decisão, e sua resolução poderia acabar no presidente
da empresa. A organização funcional carece de foco no cliente. Há uma lealdade maior para
com a função que para com o projeto ou o cliente.
Estrutura Organizacional por Projetos

Em uma organização por projetos, todas as pessoas da equipe trabalham para o gestor.
Portanto, ele tem o controle total sobre os recursos, incluindo a autoridade sobre como o
trabalho é feito e por quem. Não há conflito com os outros projetos em relação a priorida-
des e recursos porque todos os recursos para um projeto estão totalmente dedicados a ele.
A organização por projetos é altamente sensível ao cliente. Por exemplo, se o cliente faz
mudanças no escopo de trabalho do projeto, o gestor tem autoridade para realocar recursos
e acomodar as mudanças imediatamente.
A estrutura organizacional por projetos pode ser ineficiente em termos de custos, em
função da subutilização de recursos. Com pessoas alocadas em tempo integral para o proje-
to, pode haver ocasiões em que as coisas desacelerem e os membros da equipe não estejam
trabalhando em um alto nível de produtividade. Quando as coisas ficam lentas, as pessoas
têm tendência a esticar seu trabalho para cobrir todo o tempo disponível. Se não houver
nada mais a fazer, uma tarefa de uma semana pode se estender por duas ou três sema-
nas, aumentando os custos do projeto. Da mesma forma, se algumas pessoas não tiverem
nenhuma tarefa para fazer por períodos temporários, seu tempo ocioso ainda representa
gastos para a empresa, além de corroer os lucros. Outro fator que aumenta a ineficiência
de custos é o potencial de duplicação de atividades em vários projetos simultâneos. Por
exemplo, se as equipes de projeto encomendassem seus materiais e suprimentos em con-
junto, em vez de independentemente, provavelmente conseguiriam preços melhores dos
fornecedores.

organizacional por projetos?
Na estrutura organizacional por projetos, há um baixo nível de transferência de conhe-

cimento entre os projetos. As pessoas dedicam-se a trabalhar em um único projeto e não
têm um “endereço” funcional que seja uma fonte de experiência e conhecimento funcional
compartilhado. Da mesma forma, ao final de um projeto, as pessoas podem ser dispensadas
se não houver um novo projeto no qual possam ser úteis. Nesses casos, o que elas apren-
deram com o projeto se perde dentro da empresa. Em uma organização por projetos, os
membros da equipe sofrem uma grande ansiedade em relação ao futuro à medida que o
projeto se aproxima do fim, principalmente porque eles não têm um “endereço” funcional
para onde possam voltar.
Estrutura Organizacional Matricial

A estrutura organizacional matricial tenta tirar proveito das vantagens tanto da estrutura fun-
cional quanto por projetos, ao mesmo tempo que supera suas desvantagens. A estrutura
matricial permite a utilização eficiente de recursos ao ter pessoas de várias funções desig-
nadas para trabalhar em meio período, se necessário, em projetos específicos, ou designá-
los por apenas um período limitado de tempo para determinados projetos. Além do mais,
não é raro que as pessoas de uma função específica estejam trabalhando em dois ou mais
projetos simultaneamente. Como têm um “endereço” funcional, podem ser movimentadas
entre projetos conforme a necessidade para acomodar quaisquer mudanças. Por exemplo,
se um projeto ficar atrasado, o gerente funcional pode empregar alguns membros de sua
equipe para outros projetos, em vez de permitir que o tempo ocioso aumente os gastos da
empresa.
A estrutura matricial fornece um núcleo de experiência funcional que fica disponível
para todos os projetos e, dessa forma, a experiência é mais bem utilizada. As pessoas de
uma área funcional têm muito em comum e podem colaborar e aprender umas com as
outras. A área funcional fornece um “endereço” para as pessoas ao final de um projeto,
• Em uma organização matricial, é importante delinear as responsabilidades do ges-

tor do projeto e as responsabilidades da gerência funcional.
• Ao implementar-se uma estrutura organizacional matricial, deve-se estabelecer di-
retrizes operacionais a fim de se garantir um equilíbrio adequado de poder entre os
gestores do projeto e os gerentes funcionais.
enquanto esperam ser alocadas para outros projetos. Seu conhecimento fica dentro da em-
presa, pronto para ser usado em projetos futuros. À medida que as pessoas trabalham
em mais projetos, e mais variados, passam por um aprendizado e crescimento maior; seu
conhecimento e habilidades são transferidos de projeto em projeto.
A estrutura matricial também facilita melhor comunicação, permitindo a identificação de
problemas e a resolução de conflitos mais oportunas.
Os membros da equipe de projeto têm dois canais pelos quais podem enviar uma adver-
tência sobre um problema em potencial – o gestor e o gerente funcional. Esse duplo cami-
nho de comunicação aumenta a probabilidade de que problemas sejam identificados, em
vez de suprimidos.
Por fim, a organização matricial é focada no cliente. O gestor é designado como ponto
focal para a comunicação com o cliente, enquanto as unidades funcionais estão preparadas
para oferecer o suporte aos projetos.

organizacional matricial?
Os membros de uma equipe em uma estrutura organizacional matricial têm uma dua-
lidade de relação hierárquica: temporariamente, eles se reportam a um gestor de projeto,
enquanto, do ponto de vista administrativo, ainda se reportam ao seu gerente funcional. Se
uma pessoa é designada para trabalhar em vários projetos, pode ter vários gerentes. Isso
pode gerar ansiedade e conflitos sobre as prioridades do trabalho. Essas pessoas têm uma
lealdade permanente para com seu endereço funcional, que fica prejudicada em função
de sua dedicação necessária para com a equipe de projeto. Uma empresa que utiliza uma
estrutura organizacional matricial deve estabelecer diretrizes operacionais, a fim de garantir
um equilíbrio adequado de poder entre os gestores de projeto e os gerentes funcionais.
Conflitos surgirão entre os gestores e os gerentes em relação a prioridades, à alocação de
pessoas específicas para os projetos, abordagens técnicas para o trabalho e mudanças. Se
houver uma falta de equilíbrio de poder, esses conflitos podem não ser resolvidos de forma
que atendam aos melhores interesses tanto do cliente quanto da empresa.
RESUMO
As três estruturas mais comuns usadas para organizar as pessoas para trabalhar em projetos
são funcional, por projetos e matricial. Essas estruturas são aplicáveis à grande maioria das
empresas e às organizações não-governamentais.
A estrutura organizacional funcional é tipicamente usada em empresas que basicamente

vendem e fabricam produtos padrão e quase nunca conduzem projetos externos. O foco
está na excelência técnica e na competitividade de custos dos produtos da empresa, assim
como na importância da contribuição da experiência de cada área funcional para seus
produtos. Para os projetos, forma-se uma equipe ou força-tarefa multifuncional, com mem-
bros selecionados a partir das subfunções apropriadas. Nessa estrutura, o gestor não tem
autoridade total sobre a equipe, já que, do ponto de vista administrativo, os membros ainda
trabalham para seus respectivos gerentes funcionais. Se houver conflito entre os membros
da equipe, isso normalmente passa por toda a hierarquia da organização até ser resolvido.
Uma empresa com uma estrutura organizacional funcional pode periodicamente formar
forças-tarefas para trabalhar em projetos internos, mas raramente conduzirá projetos que
envolvam clientes externos.
A estrutura organizacional por projetos é usada por empresas que estejam trabalhando
em múltiplos projetos o tempo todo e que não fabriquem produtos-padrão. As pessoas
são contratadas para trabalhar em um projeto específico, e cada equipe se dedica a apenas
um projeto. Quando o projeto é concluído, os membros da equipe podem ser designados
para outro projeto, se tiverem a experiência adequada. Um gestor em tempo integral tem
total autoridade de projeto e administrativa sobre a equipe. Uma organização por projetos
é estruturada para ser altamente sensível ao objetivo do projeto e às necessidades do clien-
te, já que cada equipe fica estritamente dedicada a apenas um projeto. Do ponto de vista
global da empresa, uma organização por projetos pode apresentar ineficiência de custos,
em função da duplicação de recursos ou tarefas em vários projetos simultâneos. Da mesma
forma, há poucas oportunidades para os membros de diferentes equipes compartilharem
conhecimento ou experiência técnica. As estruturas organizacionais por projetos são encon-
tradas principalmente em empresas envolvidas em projetos muito grandes, de alto valor e
duração extensa.
A organização matricial é meio híbrida – uma mistura das estruturas organizacionais
funcional e por projetos. É adequada para empresas que estão trabalhando em projetos
múltiplos o tempo todo e para projetos que variam em termos de tamanho e complexida-
de. Ela fornece o foco no projeto e no cliente da estrutura por projetos, enquanto retém a
experiência funcional da estrutura funcional. Os projetos e as áreas funcionais da estrutura
matricial têm cada um suas responsabilidades de contribuírem para o sucesso conjunto de
cada projeto e da empresa. Além disso, a organização matricial proporciona o uso eficaz
dos recursos da empresa. A divisão do tempo das pessoas entre vários projetos resulta na
utilização eficaz de recursos e minimiza os custos globais para cada um deles e para toda a
empresa. Todas as pessoas designadas para um determinado projeto formam a equipe, sob
a liderança de um gestor que integra e unifica seu trabalho.
Na estrutura matricial, o gestor é o intermediário entre a empresa e o cliente. Ele define
o que tem de ser feito, até quando e por quanto, a fim de atingir o objetivo do projeto e
satisfazer o cliente. O gestor é responsável por liderar o desenvolvimento do plano de pro-
jeto, estabelecer o cronograma e o orçamento e alocar tarefas e orçamentos específicos para
várias áreas funcionais da organização da empresa. Cada gerente funcional é responsável
por como as tarefas atribuídas serão realizadas e por quem irá executar cada uma.
As vantagens de uma estrutura organizacional funcional são a ausência de duplicação
de atividades e a excelência funcional. As desvantagens incluem compartimentação, res-
postas lentas e falta de foco no cliente. A estrutura organizacional por projetos tem controle
sobre os recursos e sensibilidade às necessidades do cliente como vantagens. A ineficiên-
cia de custos e o baixo nível de transferência de conhecimento entre os projetos são suas
desvantagens. As vantagens de uma estrutura organizacional matricial incluem a utilização
eficaz de recursos, a disponibilidade de experiência funcional para todos os projetos, maior

aprendizado e transferência de conhecimento e foco no cliente. Suas desvantagens são a
dualidade de relações hierárquicas e a necessidade de equilíbrio de poder.
PERGUNTAS
1. Descreva uma organização funcional. Não se esqueça de discutir as vantagens e desvan-

tagens desse tipo de estrutura.
2. Descreva uma organização por projetos. Não se esqueça de discutir as vantagens e des-
vantagens desse tipo de estrutura.
3. Descreva uma organização matricial. Não se esqueça de discutir as vantagens e desvan-
tagens desse tipo de estrutura.
4. Que tipo de estrutura organizacional costuma ser usado por empresas que fabricam
produtos-padrão? Por quê?
5. Discuta alguns dos problemas que podem ser encontrados quando uma organização
funcional desenvolve novos produtos.
6. Por que as organizações por projetos são consideradas um conjunto de microempresas?
7. Por que as organizações por projetos são às vezes consideradas caras?
8. Qual é a estrutura organizacional considerada híbrida? Por quê?
9. Como uma organização matricial proporciona o desenvolvimento de carreiras?
10. Quais são as responsabilidades do gestor de projeto em uma organização matricial?
11. Quais são as responsabilidades do gerente funcional em uma organização matricial?
12. Quais são as responsabilidades do vice-presidente de projetos em uma organização do
tipo matricial?
~clements.
1. Procure na Internet estruturas organizacionais funcionais. Resuma pelo menos um
dos sites e compare-o ao que foi apresentado neste capítulo. Que novas perspectivas
você obteve com esse site?
2. Busque na web organizações matriciais. Resuma pelo menos um dos sites e compare-
o ao que foi apresentado neste capítulo. Que novas perspectivas você obteve com
esse site?
3. Visite o site http://www.pmi.org. Entre no link de futuras conferências. Onde elas
serão realizadas? O que será discutido? Há descontos para estudantes?
4. Acesse o site http://www.pmi.org e entre no link de padrões profissionais. O PMI
escreveu um Guia para a Base de Conhecimentos sobre Gestão de Projetos (o Guia
PMBOK®), que define os padrões de prática profissional aprovados pelo ANSI (Ins-
tituto Americano de Padrões Nacionais) para a gestão de projetos. Por que é impor-
tante o estabelecimento desses padrões?
5. Visite o site http://www.pmi.org. Entre no link Publications e veja o link PM Network
Online. Imprima e resuma um dos artigos.
ESTUDO DE CASO Nº 1 Multi Projects

A Multi Projects, Inc. é uma sólida firma de consultoria com 400 funcionários que desen-
volve vários projetos ao mesmo tempo para diferentes clientes. A firma tem boa reputação
e aproximadamente 30% de seus negócios são de clientes antigos. Ela busca empresas em
crescimento para futuros negócios e tem tido sucesso nessa área também. Em função do cres-
cimento, as coisas têm sido bastante agitadas, com os funcionários tentando se manter em dia
com o trabalho, manter os antigos clientes satisfeitos e se virando em mil para acomodar
novos clientes. A empresa está contratando novos funcionários – na verdade, ela passou de
300 para 400 funcionários nos últimos dois anos.
A Multi Projects tem uma estrutura organizacional matricial. À medida que entram novos
projetos, um gestor é designado. Ele pode ser designado para vários projetos ao mesmo
tempo, dependendo do porte deles. Os projetos normalmente custam de US$ 20 mil a US$ 1
milhão e podem durar de um mês a dois anos. A maioria dura cerca de seis meses e custa
entre US$ 60 e US$ 80 mil. A firma realiza uma grande variedade de serviços de consultoria,
incluindo pesquisa de mercado, concepção de sistema de fabricação e seleção de execu-
tivos. Seus clientes são empresas de médio e grande portes e incluem bancos, empresas
manufatureiras e órgãos governamentais.
A empresa acabou de receber uma ligação da Growin Corporation, que quer dar conti-
nuidade a um projeto proposto pela Multi Projects há cerca de seis meses. Os parceiros da
Multi Projects estão surpresos com a boa notícia, pois achavam que o projeto estava morto.
Eles também estão bastante interessados em realizar um primeiro projeto para a Growin
Corporation porque esta é uma empresa em rápido crescimento. A Multi Projects vê uma
oportunidade de realizar vários projetos com a Growin Corporation no futuro.
Jeff Armstrong foi designado como gestor para o projeto da Growin Corporation. Ele
trabalha na Multi Projects há cerca de um ano e está ansioso para ter um projeto desafiador
para gerenciar. Ele também atuou na proposta para o projeto da Growin.
Tyler Bonilla é engenheiro sênior de sistemas. Ele trabalha na Multi Projects há oito anos
e tem uma reputação excelente; os clientes anteriores com os quais trabalhou normalmente
pedem que ele seja designado para seus projetos. Ele gosta do seu trabalho, embora esteja
sempre bastante ocupado. Atualmente está trabalhando em período integral em um projeto
para a Goodold Company, uma antiga cliente que disse que uma das razões pelas quais tra-
balha com a Multi Projects, e não com outra firma de consultoria, é pelo excelente trabalho
que Tyler faz em seus projetos.
Jennifer Fernandez é gerente de engenharia de sistemas e trabalha na Multi Projects há
cerca de 15 anos. Tyler se reporta a Jennifer, mas, por causa da pesada carga de trabalho e
das viagens, ele não a vê muito, apenas nas reuniões mensais.
Julie Capriolo é gestora do projeto da Goodold Company. Ela trabalha na Multi Projects
há cerca de dois anos. Tyler a designou para o projeto em período integral. O projeto tem
um cronograma apertado, e todos estão fazendo horas extras. Julie está se sentindo bastante
pressionada, mas tem uma boa equipe de projeto e confia bastante em Tyler. Ela ouviu de
um amigo que trabalhava com Jeff que ele é muito ambicioso e capaz de fazer qualquer
coisa para preservar sua boa imagem. Isso nunca preocupou Julie, porque ela e Jeff têm
projetos separados e não se cruzam com muita freqüência.
No dia em que Jeff é designado para ser o gestor do projeto da Growin Corporation, ele
encontra Tyler no corredor. – Ficamos com o projeto da Growin, ele diz a Tyler.
– Ótimo, responde Tyler.
Jeff continua: – Sabe, um dos principais motivos para eles darem o projeto para nós e
não para outra firma de consultoria é porque prometemos que você seria o engenheiro de
sistemas líder do projeto, Tyler. Eles ficaram impressionados com você quando nos reuni-
mos com eles para apresentar a nossa proposta. Quando você acha que pode começar a
trabalhar no projeto?
– Infelizmente, não posso. Estou amarrado com o projeto da Goodold e as coisas estão
bastante agitadas. Ficarei nesse projeto por mais uns quatro meses, diz Tyler.
– De jeito nenhum!, exclama Jeff. – Esse projeto da Growin é importante demais para
mim – quero dizer, para nós. Cuidarei disso.
– É melhor você falar com Jennifer, Tyler diz.
Jeff vai até a sala de Jennifer. Ela está ocupada, mas ele a interrompe. – Preciso de Tyler
Bonilla no meu projeto da Growin. Ele quer trabalhar nele, mas disse que eu precisava con-
versar com você antes.
– Impossível, diz Jennifer. – Ele está designado para o projeto Goodold, de Julie Capriolo,
nos próximos quatro meses.
– Julie? Quem é ela? Não importa. Vou encontrá-la e resolver isso. Vocês provavelmente
têm outra pessoa que podem designar para o projeto, responde Jeff, saindo rapidamente da
sala dela em busca de Julie.
– Essa decisão é minha, não é sua e nem da Julie!, Jennifer grita. Mas, a essa altura, Jeff
já foi, sem sequer ouvir o que ela disse.
Julie está em uma reunião com sua equipe de projeto na sala de conferências. Jeff bate
na porta e abre. – Tem alguma Julie aqui? ele pergunta.
– Eu sou Julie, ela responde.
– Preciso falar com você o mais breve possível. É importante. Ah, aliás, desculpe por
interromper. Olhando para Tyler, que está na reunião, Jeff diz: – Ei, Tyler, vejo você mais
tarde, amigão, depois que falar com Julie. Em seguida, Jeff fecha a porta e volta à sua sala.
Julie fica visivelmente perturbada com a interrupção.
Após a reunião, Julie liga para Jeff. – Aqui é Julie. O que você queria falar comigo de
tão importante?
– Sobre realocar Jeff para meu projeto. Ele está interessado e já conversei com Jennifer
sobre isso, Jeff responde.
– Impossível, diz Julie. – Ele é fundamental para o projeto da Goodold.
– Sinto muito – diz Jeff – mas, se o projeto Growin for bem-sucedido, teremos mais tra-
balho deles do que jamais tivemos com a Goodold Company.
– Já passam das 18 horas, e preciso me ausentar da cidade por uma semana, mas discu-
tirei isso com Jennifer assim que voltar, Julie responde rispidamente.
– Bom, é você quem sabe, responde Jeff.
No dia seguinte, Jeff convoca uma reunião com Jennifer e Tyler. Ele começa dizendo a
eles: – Convoquei essa reunião para saber quando Tyler pode começar a trabalhar no pro-
jeto da Growin e como você [olhando para Jennifer] vai conseguir alguém para substituí-lo
naquele projeto sei-lá-o-quê.
– Acho que Julie deveria participar desta discussão, afirma Jennifer.
– Ela não pôde vir. Aparentemente, vai ficar fora da cidade por uma semana e precisa-
mos dar andamento ao projeto da Growin, Jeff diz a ela. – Precisamos nos preparar para
uma reunião com eles na próxima semana. Além do mais, é de Tyler que estamos falando
e ele prefere trabalhar no projeto da Growin. Certo, Tyler?
– Ah, bem, agora que você perguntou, estou ficando cansado de trabalhar nos projetos
da Goodold, responde Tyler. Não estou aprendendo nada de novo. Quer dizer, tudo bem,
mas eu gostaria de uma mudança.
Jennifer está atônita. – Você nunca me disse nada disso, Tyler.
Jeff interrompe: – Bem, acho que ficou tudo acertado. Jennifer, você designa para o projeto
Goodold uma outra pessoa que se sinta um pouco mais desafiada e diga isso a Julie, quan-
do ela voltar. Nesse meio tempo, eu e meu amigo Tyler temos muito trabalho a fazer para
nos apresentarmos bem em nossa reunião com o pessoal da Growin na semana que vem.
PERGUNTAS
1. Por que Jeff está tão ansioso para começar no projeto Growin?
2. O que há de errado com a abordagem de Jeff para lidar com essa situação?
3. O que Jennifer deveria fazer para resolver essa situação?

4. Quais vantagens e desvantagens da organização matricial ficam evidentes nessa histó-
ria?
ATIVIDADE EM GRUPO
Conduza uma discussão entre os participantes do curso em relação às seguintes perguntas:
• O que Jennifer deve fazer agora?
• O que Tyler deve fazer?
• Como cada uma dessas quatro pessoas poderia ter lidado melhor com a situação?
ESTUDO DE CASO Nº 2 Divisões Industriais

A Stevens Corporation é uma empresa industrial de múltiplas divisões com produtos di-
versificados, que atende aos mercados aeroespacial, automotivo e médico. Sua Divisão de
Instrumentos Médicos está localizada no Centro-Oeste e tem uma fábrica com mais de mil
funcionários que vende vários instrumentos, como analisadores, equipamentos de monito-
ramento e instrumentos de teste para hospitais e laboratórios médicos. A empresa é líder no
mercado e seus negócios têm sido estáveis. Ela goza de muito boa reputação e pratica pre-
ços premium para seus produtos. Contudo, os negócios não estão crescendo na mesma ve-
locidade que o restante das divisões da Stevens, nem tão rápido quanto a diretoria gostaria.
Eles sentem que a gerência da divisão se tornou complacente. Há vários novos concorrentes
entrando no mercado com produtos que oferecem mais recursos e preços mais baixos. No
ano passado, o executivo-chefe disse a Kareem, gerente geral da Divisão de Instrumentos
Médicos, que ele tinha de começar a desenvolver produtos novos e com mais recursos para
não perder mercado para os concorrentes que estavam surgindo.
Kareem passou toda a sua carreira – 20 anos, no total – na divisão. É engenheiro eletrô-
nico e trabalhou em muitos dos produtos atuais. Ele acredita que os produtos ainda são de
qualidade e que seu Departamento de Marketing precisa trabalhar mais para convencer os
clientes de que os produtos da Stevens ainda oferecem o melhor valor quando comparados
aos produtos dos concorrentes, que ainda não foram testados e aprovados. Kareem também
acredita que seu Departamento de Produção pode reduzir custos mediante negociações
mais duras com os fornecedores e melhorias nos processos.
Ele crê que a reputação da Stevens acabará tirando os produtos dos novos concorrentes
do mercado. Portanto, está relutante em alocar mais recursos para o desenvolvimento de
produtos do que o necessário para acalmar a presidência e a diretoria. Ele quer manter a
margem de lucro da divisão, que é usada para determinar sua bonificação de final de ano.
A abordagem de Kareem foi estabelecer quatro equipes de desenvolvimento de produto.
A cada equipe foi designado um produto diferente que estava sendo ameaçado por produ-
tos concorrentes, com o objetivo de desenvolver melhorias que se igualem ou superem os
produtos concorrentes. Ele simplesmente designou cada um dos seus quatro gerentes de
departamento para liderar as quatro equipes de desenvolvimento de produto. Julgou que
isso criaria uma rivalidade amistosa. Os quatro gerentes de departamento são:
1. Tanya – Gerente de Marketing
2. Khalid – Gerente de Engenharia Eletrônica
3. Lee – Gerente de Engenharia de Sistemas de Informática
4. Tony – Gerente de Produção
Kareem está recebendo questionamentos mais freqüentes da presidência sobre o status
dos desenvolvimentos dos produtos. Sabe que o progresso tem sido lento e que ele não
colocou prioridade nisso porque acredita que Stevens simplesmente sobreviverá a seus
concorrentes, que ele acredita estarem perdendo dinheiro com seus produtos de preços
mais baixos.
Kareem passou por suas sessões anuais de análise de desempenho com seus gerentes
de departamento na semana passada e perguntou-lhes sobre os projetos de desenvolvi-
mento de produtos. Aqui está o que cada um lhe disse:
Tanya, gerente de marketing, disse que nenhum dos gerentes, incluindo Kareem, está
dando prioridade aos projetos de desenvolvimento de produtos porque estão ocupados de-
mais com suas tarefas rotineiras. Ela falou que os esforços de desenvolvimento de produto
deveriam ser voltados ao mercado, e não à engenharia. As outras equipes de desenvolvi-
mento de produto, lideradas por Khalid e Lee, não estão interessadas em receber nenhum
feedback do Departamento de Marketing; eles apenas querem desenvolver produtos sofis-
ticados, com o máximo de engenharia, mas complicados demais para os clientes usarem.
Ela também disse que Tony somente está interessado em tornar quaisquer novos produtos
mais baratos, não necessariamente melhores, porque ele acredita que um custo mais baixo
por unidade é o objetivo final. Tanya sugeriu que Kareem aprove um novo cargo de gerente
de desenvolvimento de produto, que se reportasse diretamente a ela e teria responsabilidade
integral por todos os projetos de desenvolvimento de produto.
Ela disse a Kareem que várias pessoas-chave de cada um dos outros departamentos
deveriam ser permanentemente realocadas, para que o gerente de desenvolvimento de
produto trabalhasse apenas em projetos de desenvolvimento de produto. Também falou
que os outros três gerentes de departamento parecem estar se unindo contra ela pelo fato
de ser mulher e trabalhar na divisão há pouco tempo. Ela os acusou de serem um bando de
“velhos amigos” que nunca saíram da fábrica para falar com clientes nos mais de 20 anos
em que trabalham lá. Ela disse a Kareem que, se ele não aprovar a contratação de um
gerente de desenvolvimento de produto que se reporte a ela, iria reconsiderar seriamente
seu interesse em permanecer na Stevens Corporation. Tanya tem uma excelente reputação
no setor; várias outras empresas a acolheriam. Kareem sabe que ele levou um tempo para
preencher o cargo de gerente de marketing e que teve de pagar a ela um salário mais alto
do que desejava para trazê-la à Stevens.
Khalid, gerente de engenharia eletrônica, disse a Kareem que os gerentes de desenvol-
vimento de produto não estão progredindo porque o Departamento de Engenharia de Sis-
temas de Informática está sempre discutindo para decidir se as características dos produtos
deveriam ser feitas com hardware ou software. Ele disse que Lee já anunciou que pretende
se aposentar no final do ano. Khalid falou a Kareem que, quando Lee se aposentar, ele não
precisaria ser substituído; em vez disso, o Departamento de Engenharia de Sistemas de In-
formática deveria ser fundido com o departamento de Khalid. Reiterou que assim teria mais
controle sobre os projetos de desenvolvimento de produto, que deveriam ser liderados pela
engenharia de qualquer forma, porque todas as melhorias de produto exigem experiência
em engenharia e concepção. Ele não vê necessidade de envolvimento por parte do Marke-
ting ou da Produção. Disse ainda que o trabalho do Marketing deveria ser vender os produ-
tos desenvolvidos pela Engenharia e que é função da Produção fazer os produtos da forma
como a Engenharia os projeta. Ele também disse que, ao não substituir Lee, Kareem poderia
economizar um pouco de dinheiro para pagar a “supervalorizada” gerente de marketing.
Lee, gerente de Engenharia de Sistemas de Informática, disse a Kareem que ele avaliou
os produtos dos concorrentes e a grande diferença é que seus produtos são baseados em
software, enquanto os produtos da Stevens são baseados em eletrônica, como há muitos
anos. Lee lembrou a Kareem que fazia vários anos que os dois tinham projetado aqueles
produtos eletrônicos. Mas hoje o mercado é diferente, com novas tecnologias e abordagens,
e a Stevens tem de redesenhar seus produtos para serem baseados em software. Ele sugeriu
que, quando se aposentar, no final do ano, Kareem nomeasse Nicole como a nova gerente
do Departamento de Engenharia de Sistemas de Informática. Lee falou que ela é jovem,
inteligente, conhece a concepção de softwares melhor do que ninguém em seu departa-
mento e que poderia fazer um ótimo trabalho na liderança de projetos de desenvolvimento

de produtos. Ela tem mestrado em engenharia da computação e MBA. Nicole está interes-
sada em fazer com que os produtos da Stevens atendam às necessidades dos clientes. Ela
costuma ter discussões freqüentes com Tanya sobre marketing, clientes e concorrentes. Lee
disse a Kareem que se Nicole não fosse promovida ela provavelmente deixaria a Stevens e
iria para outra empresa, talvez até um de seus concorrentes, onde seu talento poderia ser
mais bem aproveitado.
Tony, gerente de produção, disse a Kareem que ele (Kareem) precisa se envolver mais
nos projetos de desenvolvimento de produto e que eles necessitam “unir suas forças”. Falou
que o Marketing, Khalid e Lee estão tentando fazer muitas mudanças nos produtos e que
isso apenas aumentará o preço ou reduzirá as margens de lucro. Ele disse que ambos não
estão preocupados com os custos ou com quaisquer mudanças nos processos de produção
que teriam de ser feitas. Tony sugeriu que Kareem começasse a realizar reuniões regulares
de status de desenvolvimento de produto para descobrir o que está “realmente” aconte-
cendo e ver todas as “políticas”. Observou que todos os gerentes de departamento só se
importaram com a boa imagem do próprio departamento e que não estavam dispostos a
compartilhar informações ou cooperar com as outras equipes. Como resultado, todas as
equipes de desenvolvimento de produto estavam padecendo, e isso só iria piorar a cada
dia. Também falou que o que havia começado como uma rivalidade amistosa entre as equi-
pes havia se tornado uma competição feroz e declarada. Mais uma vez, advertiu Kareem
a fazer alguma coisa antes que a presidência acabe com o emprego de todos eles ou até
mesmo recomende a venda da divisão a um concorrente, se isso começar a prejudicar os
lucros globais da corporação.
Por fim, o presidente chama Kareem para uma reunião e diz que o último relatório de
marketing mostra que a Divisão de Instrumentos Médicos perdeu mercado pelo segundo
trimestre consecutivo e quer saber por que Kareem ainda não tem nenhuma nova melhoria
de produto no mercado. Kareem admitiu que não tem se esforçado ao máximo com o de-
senvolvimento de produtos e que não tem dado a isso a prioridade que deveria. Ele achou
que os concorrentes fossem quebrar. Kareem discutiu sua abordagem para o estabelecimen-
to de equipes de desenvolvimento de produto e o feedback que havia acabado de receber
de seus gerentes de departamento. O presidente não estava satisfeito e disse a Kareem que
ele estava confiando demais em fazer as coisas do mesmo jeito de sempre, e que era melhor
procurar novas idéias e abordagens, ou seu cargo estaria em risco.
O presidente falou a Kareem que a situação é crítica e que a diretoria está perdendo a
paciência. Quando a diretoria o contratou, no ano passado, eles esperavam mudar a Ste-
vens de uma grande empresa nacional para uma excelente empresa global, e que todas
as outras divisões estão caminhando nessa direção, enquanto a Divisão de Instrumentos
Médicos permanece estagnada, apesar do aumento do mercado global para seus produtos.
Também falou a Kareem que iria contratar um consultor de gestão para avaliar o que está
acontecendo em sua divisão e fazer recomendações sobre como organizar os esforços de
desenvolvimento de produto, e de forma acelerada.
PERGUNTAS
Você é o consultor de gestão contratado pelo presidente.
1. Como iniciaria seu contato com Kareem e os gerentes de departamento?
2 . Desenvolva uma lista de perguntas que gostaria de fazer.
3. Supondo que os gerentes de departamento digam a você as mesmas coisas que disse-
ram a Kareem, que recomendações faria ao presidente, incluindo quaisquer mudanças
na estrutura organizacional, para melhorar a gestão de projetos de desenvolvimento de
produto?
4. Que diretrizes você recomendaria sobre como os departamentos ou novos cargos deve-
riam trabalhar em conjunto em projetos de desenvolvimento de produto?
ATIVIDADE EM GRUPO
Divida os participantes do curso em grupos de três ou quatro membros para desenvolver
respostas às perguntas referentes ao caso. Cada grupo deve eleger um porta-voz para apre-
sentar suas respostas para a turma toda.
APÊNDICE A
Softwares de gestão de projetos existem praticamente desde a criação dos computadores.

Antigamente, no entanto, funcionavam apenas em computadores de grande porte e eram
usados somente para grandes projetos. Esses sistemas antigos possuíam capacidade limitada
e, segundo os padrões atuais, eram bastante difíceis de se utilizar.
Hoje existem muitos pacotes de software de gestão de projetos baseados em computa-
dores pessoais (PC), os quais estão presentes em quase todo tipo de negócios. Tais sistemas
– que geralmente apresentam uma interface gráfica de usuário fácil de ser utilizada – são
capazes de planejar atividades, estabelecer cronogramas para trabalhos a serem executa-
dos, visualizar relações entre as tarefas, administrar recursos e monitorar o progresso de
um projeto.
Este apêndice fornece:
• uma discussão sobre os recursos comuns disponíveis na maioria dos pacotes de soft-
ware de gestão de projetos;
• critérios para a seleção de um software de gestão de projetos;
• comentários sobre as vantagens de se utilizar um software de gestão de projetos;
• comentários sobre as desvantagens de se utilizar um software de gestão de projetos
• informações sobre os fornecedores de softwares de gestão de projetos.
RECURSOS DO SOFTWARE DE GESTÃO DE PROJETOS

A lista a seguir, que contém os recursos oferecidos pela maioria dos softwares de gestão de
projetos atuais, embora incompleta, oferece uma visão geral dos tipos de recursos disponí-
veis. No entanto, deve-se salientar que diferentes pacotes de softwares de gestão de proje-
tos apresentam características distintas e que alguns dos recursos presentes na lista não são
encontrados em todos os pacotes. Além disso, alguns produtos realizam um trabalho muito
mais satisfatório em comparação a outros em termos de suporte a alguns desses recursos.
1. Controle de orçamento e custo. Na maioria dos sistemas de gestão de projetos, é
possível relacionar as informações sobre custo com todas as atividades e recursos
de um projeto. Os pagamentos geralmente podem ser definidos por hora, hora extra
ou preço fechado. Datas para pagamentos também podem ser especificadas. Para
materiais, custos únicos ou contínuos podem ser definidos. Pode-se estabelecer có-
digos de orçamento e contabilidade associados a cada tipo de material. Além disso,
fórmulas definidas pelo usuário podem ser desenvolvidas para controlar funções de
custo. A maioria dos softwares utiliza essas informações para calcular os custos esti-
mados e monitorar os custos reais durante o projeto. A qualquer momento, os custos
reais podem ser comparados aos custos orçados para recursos individuais, grupos de
recursos e para todo o projeto. Essas informações podem ser utilizadas não apenas
para fins de planejamento, mas também para relatórios. A maioria dos softwares per-
403
404 Apêndice A Softwares de Gestão de Projetos
mite a visualização e a impressão dos custos para cada tarefa, para qualquer recurso
(pessoa, máquina etc.) ou para o projeto todo, a qualquer momento durante a exe-
cução do projeto.
2. Calendários. Calendários-padrão geralmente podem ser utilizados na definição de
dias e horas de trabalho para cada recurso individual ou grupo de recursos em
um projeto. Esses calendários servem para calcular o cronograma de um projeto. A
maioria dos sistemas apresenta um padrão para o período usual de trabalho, como
de segunda a sexta-feira, das 8 às 17 horas, com uma hora de almoço. Esses calen-
dários podem ser alterados para cada recurso individual ou grupo de recursos. Por
exemplo, pode-se modificar o horário de trabalho, incluir feriados como dias de folga
e introduzir vários turnos (diurno, noturno), bem como períodos de férias e até es-
calas variáveis (hora, dia, semana). Os calendários podem ser utilizados para fins de
relatório e, normalmente, são impressos por dia, semana ou mês para cada recurso
individual, ou em tamanho maior, completos, para colar na parede.
3. Recursos de Internet. Vários pacotes de softwares de gestão de projetos permitem
que as informações sobre o projeto sejam diretamente enviadas para um site na In-
ternet a fim de facilitar a comunicação com os membros da equipe e o cliente. Além
disso, a maioria dos softwares permite o envio das informações sobre o projeto por
e-mail, em vez de serem enviadas para a tela ou para uma impressora. Os membros
da equipe de projeto podem ser informados sobre alterações importantes, como a
atualização dos planos ou do cronograma do projeto ou sobre a sua situação atual.
Gráficos e prazos por vencer também podem ser enviados por e-mail.
4. Gráficos. Para projetos que envolvem grande quantidade de atividades, tentar elabo-
rar manualmente um gráfico de Gantt ou um diagrama de rede é uma tarefa tediosa
e sujeita a erros, assim como incluir quaisquer alterações no gráfico feito à mão.
Um dos mais importantes recursos dos modernos softwares de gestão de projetos é
a capacidade de criar, de maneira rápida e fácil, uma ampla variedade de gráficos,
entre os quais o de Gantt e diagramas de rede, baseados em dados atuais. Depois
que o plano-base é criado, quaisquer alterações podem ser introduzidas no sistema,
já que os gráficos refletirão automaticamente essas alterações. Os softwares de gestão
de projetos permitem que tarefas no gráfico de Gantt sejam associadas umas às outras
para que as atividades precedentes possam ser exibidas. Normalmente, o usuário pode
mudar da visualização do gráfico de Gantt para a visualização do diagrama de rede com
uso de um único comando. Além disso, recursos ilustrativos e de geração de gráficos
geralmente permitem ao usuário:
• realizar alterações interativas de tarefas e relações, como mudar relações de prece-
dência por meio da associação gráfica de tarefas ou alterar a duração das ativida-
des (estendendo a exibição de duração da atividade);
• personalizar formatos, como tamanho de colunas, cabeçalhos, cores, fontes e ali-
nhamento do texto;
• exibir gráficos básicos versus gráficos reais para tarefas e custos;
• realçar o caminho crítico e mostrar a folga de todas as atividades;
• reduzir ou ampliar as exibições utilizando o controle zoom.
5. Importar/Exportar dados. Muitos softwares de gestão possibilitam que o usuário traga
informações de outros aplicativos, como processadores de textos, planilhas e base
de dados. Introduzir informações no software de gestão de projetos denomina-se
importação. Por exemplo, em vez de digitar novamente informações ligadas a custo
de pessoas ou máquinas no software – e possivelmente inserir dados incorretos ou
conflitantes –, você pode simplesmente importá-las quando necessário. Do mesmo
modo, normalmente é possível enviar informações de seu software de gestão de pro-
jetos para esses aplicativos. Esse processo denomina-se exportação. Por exemplo, um
Apêndice A Softwares de Gestão de Projetos 405
relatório de cronograma para um subcontratado específico pode ser exportado para

um processador de texto na forma de memorando.
A maioria dos softwares de gestão de projetos permite a transferência de informa-
ções em texto ASCII padrão, do Windows, para bases de dados SQL, Lotus, Excel,
Microsoft Project Exchange, OLE cliente/servidor, DDE cliente/servidor e vários ou-
tros sistemas.
6. Controle de projetos múltiplos e subprojetos. Alguns projetos são tão extensos que
precisam ser divididos em subconjuntos menores de tarefas ou em subprojetos. Em
outras circunstâncias, gerentes de projeto experientes supervisionam vários projetos
simultaneamente ou membros da equipe realizam mais de um projeto ao mesmo
tempo, dividindo seu tempo entre esses projetos. A maioria dos softwares de gestão
de projetos oferece suporte para essas situações. Eles geralmente são capazes de
armazenar projetos múltiplos em arquivos separados com links de conexão entre os
arquivos, armazenar projetos múltiplos em um mesmo arquivo, lidar com centenas
e até milhares de projetos ao mesmo tempo e criar gráficos de Gantt e diagramas de
rede para projetos múltiplos.
7. Geração de relatórios. Quando os primeiros pacotes de software de gestão de pro-
jetos foram lançados, eles normalmente possuíam apenas um pequeno conjunto de
relatórios, geralmente organizados em tabelas, contendo o resumo do cronograma,
dos recursos ou do orçamento. A maioria dos pacotes de software modernos possui
mais recursos para a criação de relatórios. Entre os relatórios que podem ser gerados
estão:
• relatórios sobre o projeto como um todo;
• relatórios sobre as etapas (marcos) principais de um projeto;
• relatórios que fornecem uma variedade de informações referentes a um intervalo
de tempo, como tarefas concluídas, tarefas em andamento e tarefas ainda por co-
meçar dentro desse intervalo de tempo;
• relatórios financeiros que apresentam uma ampla gama de informações, incluindo
orçamentos para todas as tarefas, bem como para todo o projeto, tarefas e recursos
que estão acima do orçamento, custos orçados acumulados, custos reais e custos
comprometidos;
• relatórios de Critério de Sistema para Controle do Cronograma/Custo (C/SCSC),
geralmente exigidos pelo U.S. Department of Defense para projetos relacionados
à defesa;
• relatórios de alocação de recursos para cada recurso ou grupo de recursos envol-
vidos em um projeto;
• relatórios-padrão customizáveis, tabelas cruzadas e relatórios de variação entre o
plano-base e os dados reais.
A maioria dos sistemas ajusta automaticamente o tamanho do relatório para que este
caiba na página, permitindo o usuário visualizá-la página (page preview) antes de
imprimi-la.
8. Gestão de recursos. Os softwares de gestão de projetos modernos são capazes de
manter uma lista de recursos contendo os nomes dos recursos, a quantidade má-
xima de recursos de tempo disponíveis, os valores-padrão e de horas extras para
os recursos, os métodos de acréscimo e as descrições textuais desses recursos. Um
código poderá ser atribuído a cada recurso, bem como um calendário individual e
personalizado. Limitações também podem ser estabelecidas a cada recurso, como o
número de horas e vezes que estiverem disponíveis. Os usuários também têm a opção
de atribuir recursos a uma porcentagem de uma tarefa, determinar níveis de prioridade
para a atribuição de recursos, atribuir mais de um recurso para uma mesma tarefa e
manter memorandos ou anotações para cada recurso. O sistema vai destacar e aju-
dar a corrigir quaisquer alocações, além de executar o nivelamento dos recursos. A
maioria dos softwares de gestão de projetos permite que o usuário lide com milhares
de recursos em um projeto.
9. Planejamento. Todos os pacotes de softwares de gestão de projetos permitem que
o usuário defina as atividades que devem ser executadas. Assim como normalmente
possibilita a manutenção de uma lista de recursos, o software também possibilita a
manutenção de uma lista de tarefas ou atividades. O usuário pode atribuir, para cada
tarefa, um título, datas de início e término, comentários e durações previstas (inclu-
sive estimativas otimistas, mais prováveis e pessimistas em várias escalas de tempo),
além de poder especificar quaisquer relações de precedência com outras tarefas ou
com a pessoa responsável. Normalmente, o software de gestão de projetos permite
que milhares de tarefas sejam associadas a um projeto. A maioria dos softwares per-
mite também a criação de uma estrutura analítica de projeto (WBS) – veja o Capítulo
5 – para auxiliar no processo de planejamento.
10. Monitoramento e rastreamento do projeto. Rastrear o progresso, os custos e recursos
reais é um componente fundamental da gestão de projetos. A maioria dos pacotes
de software de gestão de projetos permite que o usuário defina um plano-base e o
compare com os custos e progresso reais do projeto. A maioria pode rastrear as ta-
refas em andamento, as concluídas, os custos relacionados, o tempo gasto, as datas
de início e término, o dinheiro real envolvido ou gasto e os recursos utilizados, bem
como durações, recursos e gastos restantes. Há diversos formatos de relatórios asso-
ciados às funções de monitoramento e rastreamento.
11. Cronograma. Projetos reais são geralmente muito extensos. Fazer o cronograma das
atividades manualmente pode ser um processo bastante complexo. Os pacotes de
software de gestão de projetos fornecem um vasto, e muitas vezes automático, supor-
te técnico para isso. A maioria dos sistemas constrói gráficos de Gantt e diagramas de
rede com base nas listas de recursos e tarefas e em todas as informações associadas
a essas listas. Qualquer alteração nessas listas será automaticamente refletida no cro-
nograma. Os usuários podem também planejar o cronograma de tarefas recorrentes,
estabelecer prioridades para as tarefas programadas, executar um cronograma rever-
so (da data final à data de início), definir turnos de trabalho, fazer um cronograma
do tempo decorrido e determinar que tarefas comecem o mais tarde ou o mais cedo
possível, além de especificar prazos do tipo: “deve começar/terminar no dia”, “não
pode começar/terminar antes/depois de”.
12. Segurança. Trata-se de um recurso relativamente novo dos softwares de gestão de
projetos. Alguns sistemas oferecem opção de acesso por senha para o próprio pro-
grama de gestão de projetos, para arquivos individuais do projeto ou para dados
específicos de um arquivo (como valores de pagamento, por exemplo).
13. Classificação e filtração. O ato de classificar permite que o usuário visualize informa-
ções na ordem desejada, como valores de pagamento, do mais baixo ao mais alto;
títulos de recursos ou de tarefas em ordem alfabética. A maioria dos programas per-
mite níveis múltiplos de classificação (por exemplo, pelo último nome, pelo primeiro
nome). O processo de filtração possibilita ao usuário a seleção de apenas dados de-
terminados que satisfazem critérios específicos. Por exemplo, se o usuário necessita
de uma informação apenas sobre as tarefas que requerem determinado recurso, um
simples comando permite que o software ignore tarefas que não utilizam tal recurso
e mostre somente tarefas que o utilizam.
14. Análises de hipóteses (“What-if analysis”). Um recurso muito útil dos softwares de
gestão de projetos é a capacidade de analisar hipóteses. Tal recurso permite ao usuá-
rio examinar os efeitos de várias situações. Em algum momento do projeto, o usuário
pode perguntar ao sistema: “E se ____________ apresentar uma semana de atraso?”.
As conseqüências do atraso para todo o projeto seriam automaticamente calculadas,
e os resultados, apresentados. Por exemplo, para examinar o que acontece se os pre-
ços da madeira aumentarem 1,5% durante o andamento do projeto, um empreiteiro
pode inserir essa informação de mudança no computador, possibilitando a projeção

de todos os custos associados. Pode-se testar quase todas as variáveis (pessoas, va-
lores de pagamento, custos) em um projeto para que os resultados de determinadas
ocorrências sejam avaliados. Esse tipo de análise possibilita ao gerente controlar
melhor todos os riscos relacionados ao projeto.
CRITÉRIOS PARA A SELEÇÃO DO SOFTWARE

DE GESTÃO DE PROJETOS
A seguir, apresentamos uma série de fatores a serem considerados antes da compra de um
pacote de software de gestão de projetos. De acordo com as necessidades individuais do
usuário, os fatores podem ter maior ou menor relevância.
1. Capacidade. A principal preocupação, neste caso, está em saber se o sistema pode
ou não administrar o número de tarefas a serem cumpridas, o número de recursos
necessários e o número de projetos a serem simultaneamente administrados.
2. Documentação e recursos de ajuda “on-line”. A quantidade da documentação e dos
recursos de ajuda on-line variam muito nos pacotes de software de gestão de projetos.
Deve-se considerar a inteligibilidade do manual do usuário, a apresentação lógica das
idéias contidas nele, seu grau de detalhamento e da ajuda on-line, a quantidade e
qualidade dos exemplos, bem como o nível de discussão de recursos avançados.
3. Facilidade de utilização. Trata-se de um fator importante na escolha de qualquer tipo
de pacote de software. Deve-se considerar a apresentação/aparência do sistema; as
estruturas do menu; as teclas de atalho disponíveis; os modos de exibição de cores;
a quantidade de informação que pode ser exibida na tela; a facilidade para inserir
informações, modificar dados e gerar relatórios; a quantidade de dados impressos; a
consistência das telas e o total de aprendizado exigido para se tornar proficiente no
sistema.
4. Recursos disponíveis. Deve-se analisar se o sistema possui os recursos necessários
para a organização do projeto. Por exemplo, o pacote inclui estruturas analíticas de
projeto (WBS), gráficos de Gantt e diagramas de rede? Os algoritmos de nivelamento
de recursos são bons o suficiente? O sistema pode classificar e filtrar informações,
controlar o orçamento, produzir calendários personalizados e ajudar nos processos
de rastreamento e controle? Ele é capaz de conferir alocações de recursos ou ajudar
a analisá-los?
5. Integração com outros sistemas. No mundo digital moderno, observamos uma con-
vergência cada vez maior de vários sistemas eletrônicos. Se estiver trabalhando em
um ambiente no qual dados relevantes são armazenados em vários lugares, como
base de dados ou planilhas, dê atenção especial aos recursos de integração do software
de gestão de projetos. Alguns sistemas permitem apenas a integração básica com al-
guns softwares populares, enquanto outros proporcionam integração sofisticada com
bases de dados distribuídas ou até mesmo orientadas por objeto. Além disso, sua
capacidade de exportar informações para programas de gráficos e processadores de
textos e enviá-las por e-mail pode afetar sua decisão.
6. Requisitos para instalação. Neste tópico, deve-se considerar os softwares e hardwares
necessários para rodar o software de gestão de projetos: memória, capacidade de arma-
zenamento do disco rígido, velocidade de processamento, consumo de energia, tipo de
visualização gráfica, modo de impressão e exigências do sistema operacional.
7. Recursos de geração de relatórios. Os sistemas de gestão de projetos atuais variam em
relação ao número e aos tipos de relatórios que podem gerar. Alguns suportam ape-
nas o modelo básico de planejamento, cronograma e relatório de custos; outros apre-
sentam recursos sofisticados para gerar relatórios sobre tarefas individuais, recursos,
custos reais, custos comprometidos, progresso etc. Além disso, alguns sistemas são
mais fáceis de ser personalizados que outros. Os recursos de geração de relatórios

devem receber atenção especial, pois a capacidade de produzir relatórios detalhados
e eficientes é uma função muito valorizada entre os usuários.
8. Recursos da Internet. Muitos pacotes de software de gestão de projetos permitem que
informações sobre o projeto sejam exibidas diretamente na Internet. Muitos pacotes,
inclusive, possibilitam que diversas tarefas sejam comunicadas por e-mail. Depen-
dendo do tipo de projeto realizado, a importância de tais funções é muito grande.
9. Segurança. Alguns pacotes de software de projeto apresentam um nível de segurança
maior do que outros. Caso a segurança seja um aspecto importante, deve-se prestar
atenção especial aos métodos de restrição de acesso ao software de gestão de proje-
tos em si, a todos os arquivos do projeto e aos dados de cada arquivo.
10. Suporte de vendas. Deve-se levar em conta se o fornecedor que vende o software ofe-
rece suporte técnico, qual é o preço desse suporte e também a reputação da empresa.
VANTAGENS DE SE UTILIZAR UM SOFTWARE

Existem muitas vantagens em se utilizar o software de gestão de projetos. A seguir, apre-
sentam-se algumas delas:
1. Precisão. Um dos maiores benefícios de se utilizar um software de gestão de projetos
é o grande aumento na precisão. Para grandes projetos, a execução manual de tarefas
como elaborar diagramas de rede, calcular o tempo de início e término do projeto
e monitorar o uso de recursos é um processo muito difícil. Os pacotes de software
de gestão de projetos apresentam algoritmos precisos para o cálculo de informações
sobre o projeto, bem como várias rotinas para a verificação de erros dos usuários.
2. Preços acessíveis. Excelentes softwares de gestão de projetos podem ser adquiridos
por menos de 500 dólares, o que pode parecer um preço elevado para uma pessoa,
mas que, para a maioria das empresas, é um investimento válido.
3. Facilidade de utilização. Nos últimos anos, os pacotes de software de gestão de
projetos têm ficado cada mais fáceis de usar. Normalmente, com um treinamento
mínimo, os usuários já conseguem dominar o sistema. Isso, além dos preços mais
acessíveis, tem levado a um aumento do número de usuários de softwares de gestão
de projetos.
4. Capacidade de administrar projetos complexos. É evidente que os softwares conse-
guem administrar determinados aspectos (especialmente numéricos) de projetos de
grande escala melhor do que uma pessoa faria manualmente. Para trabalhos que
apresentam poucas atividades e têm curta duração, o processo manual pode ser efi-
caz. Entretanto, no caso de projetos que envolvem milhares de atividades e recursos
e têm duração de alguns anos, o software de gestão de projetos é indispensável,
conforme o nível de complexidade.
5. Manutenção e modificação. Com sistemas manuais, normalmente é difícil manter
ou modificar informações sobre o projeto. Por exemplo, se dado projeto está sendo
gerenciado sem o auxílio de um computador, os diagramas de rede devem ser ma-
nualmente elaborados e os custos, calculados novamente toda vez que houver uma
alteração. Com a utilização do software de gestão de projetos, qualquer alteração nos
dados será automaticamente refletida nos documentos do projeto, como nos diagra-
mas, nas tabelas de custos e nos gráficos de alocação de recursos. Essa característica
é muito útil, pois é provável que algo se altere no meio do projeto (pelo menos um
pouco), mesmo que tenha sido muito bem planejado.
6. Manutenção de registro. Uma das maiores vantagens do software de gestão de pro-
jetos é sua capacidade de manter registros. Por exemplo, é possível armazenar infor-
mações sobre cronogramas individuais dos membros da equipe, tarefas, custos e os
recursos. Essas informações podem ser utilizadas para a produção de relatórios de

alta qualidade e o planejamento de futuros projetos. Entretanto, as vantagens da ma-
nutenção de registros existirão apenas se o usuário fizer uma atualização constante
dos arquivos.
7. Velocidade. Um software pode realizar, com rapidez, praticamente qualquer tipo
de cálculo, depois que os dados são coletados e inseridos. Criar ou revisar planos,
cronogramas e orçamentos manualmente pode levar horas, dias ou semanas. No
entanto, nos sistemas de hoje, podem-se realizar revisões em questão de minutos ou
segundos. A economia de tempo geralmente é suficiente para cobrir os gastos com a
compra do software.
8. Análise de hipóteses (“What-if analysis”). Outra vantajosa função do software de
gestão de projetos é sua capacidade de analisar hipóteses. A análise de hipóteses,
conforme discutido anteriormente, possibilita ao usuário antever as conseqüências
de várias situações em um projeto. Essas diferentes situações podem ser executadas
no software, e suas conseqüências podem ser avaliadas, o que permite ao gerente do
projeto estar preparado para certas eventualidades, bem como avaliar seus efeitos.
Realizar uma análise de hipóteses sem o uso de um software não é nem um pouco
fácil; muitas vezes, é impossível.
PREOCUPAÇÕES EM RELAÇÃO AO USO DE UM SOFTWARE

Embora o uso de softwares de gestão de projetos apresente muitos benefícios, há diversas
preocupações a serem consideradas e armadilhas que devem ser evitadas, quando possível.
1. Ficar distraído pelo software. Para alguns gerentes de projeto, o software pode ser
um fator de distração. O gerente pode passar muito tempo dedicando-se ao software
ou brincando com ele, com todos os seus relatórios e recursos, esquecendo-se do
mais importante em um projeto: as pessoas.
2. Uma falsa sensação de segurança. O software pode muitas vezes proporcionar ao
gerente de projeto uma falsa sensação de segurança. Em primeiro lugar, o gerente de
projeto pode acreditar que, por ter um software potente, ele é capaz de administrar
e conquistar mais do que é, de fato, possível. Em segundo lugar, ele pode acreditar
que, embora o projeto esteja saindo dos trilhos, o software encontrará um meio de
recuperá-lo. Em terceiro lugar, se o software não for utilizado de maneira apropriada,
poderá registrar que o andamento do projeto está ótimo, quando na realidade não
está. O fato de o software indicar que tudo vai bem não significa que essa afirmação
é verdadeira.
3. Sobrecarga de informação. Os pacotes de software de gestão de projetos apresentam
grande quantidade de recursos e um vasto leque de informações. Às vezes, isso pode
ser assustador. Apenas os recursos necessários devem ser utilizados. Os gerentes de
projeto devem resistir à tentação de utilizar recursos que produzem mais relatórios ou
mais dados, sem que estes contribuam para a conclusão bem-sucedida do projeto.
4. A curva de aprendizado. Leva-se certo tempo para se tornar proficiente no uso dos
softwares de gestão de projetos. A quantidade de tempo varia conforme o grau de co-
nhecimento anterior da pessoa. Para os que normalmente não utilizam computadores
ou softwares corporativos, a curva de aprendizado poderá ser significativa. Entretanto,
o tempo de treinamento normalmente exigido para o domínio do software tem dimi-
nuído nos últimos anos, já que os softwares têm ficado cada vez mais fáceis de usar.
5. Confiança excessiva no software. Como os softwares de gestão de projetos estão
ficando cada vez mais fáceis (e divertidos) de se usar, com muitos recursos atraen-
tes, os gerentes de projeto começaram a confiar excessivamente neles. Pessoas com
pouco ou nenhum conhecimento sobre os princípios de gestão de projetos às vezes
usam o software sem saber exatamente o que estão fazendo. Se os conceitos básicos
de gestão de projetos não forem apreendidos, o software será de pouca valia. De
modo claro e objetivo, pode-se dizer que o software é apenas uma ferramenta que
irá ajudá-lo a realizar seu trabalho de modo mais eficiente; o software em si não é
capaz de administrar um projeto. Você deve administrá-lo, contando essencialmente
com as próprias habilidades e as dos membros de sua equipe.
FORNECEDORES DE SOFTWARE DE GESTÃO DE PROJETOS

Existem vários pacotes de software que oferecem suporte ao processo de gestão de proje-
tos. Quase todos os fornecedores desse tipo de software têm sites na Internet, e vários deles
possibilitam uma demonstração online de seus produtos ou uma versão de avaliação grátis
que você pode baixar para seu computador.
O site do Project Management Institute (www.pmi.org) apresenta uma lista de consul-
tores e fornecedores de softwares de gestão de projetos. É um excelente site, com links para
a página de cada fornecedor.
Outro site que apresenta muitos detalhes e links para softwares de gestão de projetos
é: www.infogoal.com/pmc/pmcswr.htm (ou www.infogoal.com/pmc/pmchome.
htm), do Project Management Center. Também é possível encontrar outros sites fazendo
uma pesquisa por “software de gestão de projetos” no buscador www.google.com.
RESUMO
Este apêndice discute vários recursos que são normalmente encontrados em um software
de gestão de projetos. Entre os mais comuns, estão controle de custos e orçamentos, calen-
dários, recursos de Internet, gráficos, importação e exportação de dados, execução de pro-
jetos múltiplos e de subprojetos, geração de relatórios, gestão de recursos, planejamento,
monitoramento e rastreamento de projeto, criação de cronogramas, segurança, classificação
e filtro e análises de hipóteses.
Alguns critérios para a seleção de um pacote de software de gestão de projetos são:
capacidade, recursos de documentação e de assistência on-line, facilidade de uso, recursos
disponíveis, integração com outros sistemas, requisitos para instalação, recursos de relató-
rios, recursos de Internet, segurança e suporte do fornecedor. Alguns softwares de gestão
de projetos são analisados, e uma lista de fornecedores é apresentada.
Por fim, comentamos uma lista das vantagens dos softwares de gestão de projetos, e as
principais preocupações relacionadas a seu uso. Os benefícios incluem precisão, preços
acessíveis, facilidade de uso, capacidade de administrar projetos complexos, manutenção e
modificação, manutenção de registros, velocidade e análise de hipóteses. As preocupações
envolvem distração pelo software, falsa sensação de segurança, sobrecarga de informações,
curva de aprendizado e confiança excessiva no software.
PERGUNTAS
1. Relacione pelo menos dez recursos comuns dos softwares de gestão de projetos. Em
sua opinião, quais desses recursos são os mais importantes?
2. Comente os critérios que devem ser considerados ao se comprar um software de gestão
de projetos. Se tivesse de classificá-los em ordem de importância, como você os classi-
ficaria?
3. Quais são algumas das vantagens de se utilizar um software de gestão de projetos?
4. Quais são algumas das preocupações relacionadas ao uso de softwares de gestão de

projetos? As vantagens superam essas preocupações? Explique sua resposta.
1. Visite o site do Project Management Institute (www.pmi.org) e consulte a lista de for-

necedores de softwares de gestão de projetos. Comente sua opinião.
2. Por e-mail ou telefone, entre em contato com algumas das empresas que você encon-
trou no exercício anterior e verifique se eles podem lhe enviar um software de demons-
tração grátis.
3. Pesquise e visite o site de pelo menos três outros fornecedores de softwares de gestão
de projetos. Forneça os endereços desses sites e comente sobre seus produtos.
APÊNDICE B
Organizações de Gestão de Projetos
Association Francophone de Management Project Management Benchmarking

de Projet (AFITEP) Network
www.afitep.fr www.pmbn.org
3, rue Française 4606 FM 1960 West
75001 Paris, França Suite 250
Tel.: +33 42 36 36 37 Houston, TX 77069
Fax: +33 42 36 36 35 Tel.: 281-440-5044
Fax: 281-440-6677
Association for Project Management (APM)
www.apm.org.uk Project Management Institute (PMI)
150 West Wycombe Road www.pmi.org
High Wycombe Four Campus Boulevard
Buckinghamshire Newtown Square, Pensilvânia
HP12 3AE 19073-3299 EUA
Reino Unido Tel.: 610-356-4600
Tel. (Reino Unido): 0845 458 1944 Fax: 610-356-4647
Tel. (Internacional): +44 1494 440090 E-mail: pmihq@pmi.org
Fax: +44 (0)1494 528937
E-mail: info@apm.org.uk Swedish Project Management Society
http://www.projforum.se/english.shtml
Australian Institute of Project Management Svenskt ProjektForum
www.aipm.com.au c/o Ekonomibalans
Level 9, 139 Macquarie Street Sydney NSW Box 555 29
2000 102 04 Estocolmo
Tel.: +61 2 9252 7277 Tel.: 08-661 23 93 (vardagar 9-12)
Fax: +61 2 9252 7077 Fax: 08-661 48 98
E-mail: medlemsadm@projforum.se
International Project Management
Association (IPMA)
http://ipma.kingsquare.nl
IPMA, PO Box 1167, 3860 BD NIJKERK,
Holanda
Tel.: +31 33 247 34 30
Fax: +31 33 246 04 70
E-mail: info@ipma.ch
* No Brasil, consultar o site do PMI (Project Management Institute) em www.pmisp.org.br. (NRT)

412
APÊNDICE C
Sites de Gestão de Projetos na Internet
Sites de Gestão de Projetos na Internet

A seguir, há uma lista de alguns sites excelentes sobre gestão de projetos. Se tiver dificulda-
de para acessar algum dos sites, eles podem ser encontrados (com endereços atualizados)
em nosso endereço: www.towson.edu/~clements.
Department of Defense (DOD) Software Program Managers Network

www.spmn.com
International Project Management Association (IPMA)

www.ipma.chhttp://ipma.kingsquare.nl/
MIT Information Systems Project Management Resources and Exploration

http://web.mit.edu/ist/about/resources/projectmgmt/index.html
New Grange Center for Project Management

www.newgrange.org
One Hundred Rules for Project Managers

http://web.mit.edu/ist/about/resources/projectmgmt/index.html
Project Management Boulevard

www.pmboulevard.com
Project Management Center

www.infogoal.com/pmc/pmchome.htm
Project Management Forum

www.pmforum.org
Project Management Insight

www.opmi.pminsight.org.uk
Project Management Institute

www.pmi.org
Project Management Knowledge Base

www.4pm.com
Project Management WWW Site

www.projectmanagement.com/main.htm
413
414 Apêndice C Sites de Gestão de Projetos na Internet
Project Manager
www.projectmanager.com
Project Manager’s Home Page

www.allpm.com
Project Net
www.projectnet.co.uk
Project Smart
http://projectsmart.co.uk
Research on Temporary Organizations and Project Management

www.hh.umu.se/fek/irnop/umea.html
WWW Guide to Project Management Research Sites

www.hh.umu.se/fek/irnop/projweb.html
Links de Gestão de Projetos na WEB
PMI – Project Management Institute

Capítulo do PMI em Brasília – http://www.pmidf.org
Capítulo do PMI em Goiás – http://www.pmigo.org.br
Capítulo do PMI em Minas Gerais – http://www.pmimg.org.br/
Capítulo do PMI em Pernambuco – http://www.pmipe.org.br
Capítulo do PMI em Santa Catarina – http://www.pmisc.org.br
Capítulo do PMI em São Paulo – http://www.pmisp.org.br
Capítulo do PMI na Bahia – http://www.pmiba.org.br
Capítulo do PMI no Amazonas – http://www.pmiam.org
Capítulo do PMI no Ceará – http://www.pmice.org.br
Capítulo do PMI no Espírito Santo – http://www.pmies.org.br
Capítulo do PMI no Paraná – http://www.pmipr.org
Capítulo do PMI no Rio de Janeiro – http://www.pmirio.org.br
Capítulo do PMI no Rio Grande do Sul – http://www.pmirs.org.br
ABGP – Associação Brasileira de Gerenciamento de Projetos – http://www.abgp.org.br
AGESC – Associação Brasileira dos Gestores e Coordenadores de Projetos – http://www.

agesc.org.br
Manuais de Escopo de Contratação de Projetos e Serviços para a Indústria Imobiliária

– http://www.manuaisdeescopo.com.br/
APÊNDICE D
Abreviaturas (entre parênteses, a denominação correspondente em inglês)
CEC Custo estimado na conclusão (FCAC IDC Índice de desempenho de custo (CPI
– Forecasted cost at completion) – Cost performance index)
COC Custo orçado acumulado (CBC – Cumu- IG Informação de gestão (MIS – Manage-
lative budgeted cost) ment information)
COT Custo orçado total (TBC – Total bud- IT Início mais tarde (LS – Latest start time)
geted cost) MCP Mais cedo possível (ASAP – As soon
CP Chamada de propostas (RFP – Request as possible)
for proposal) MOF Melhor oferta final (BAFO – Best and
CPM Método do caminho crítico (CPM – Cri- final offer)
tical path method) MTP Mais tarde possível (ALAP – As late as
CRA Custo real acumulado (CAC – Cumula- possible)
tive actual cost) PERT Técnica de avaliação e análise de pro-
CVDS Ciclo de vida de desenvolvimento de gramas (PERT – Program evaluation and
sistemas (SDLC – Systems development review technique)
life cycle) SI Sistema de informação (IS – Information
DA Diagrama de atividades (AIB – Activity system)
in the box) TC Término mais cedo (EF – Earliest finish
DS Diagrama de setas (AOA – Activity on time)
the arrow) TR Tempo real de término (AF – Actual fi-
DT Declaração de trabalho (SOW – State- nish time)
ment of work) TT Término mais tarde (LF – Latest finish
EAP Estrutura analítica do projeto (WBS – time)
Work breakdown structure) VA Valor agregado (EV – Earned value)
FL Folga livre (FS – Free slack) VAA Valor agregado acumulado (CEV –
FT Folga total (TS – Total slack) Cumulative earned value)
IC Início mais cedo (ES – Earliest start time) VC Variação de custo (CV – Cost variance)
415
REFERÊNCIAS BIBLIOGRÁFICAS
CAPÍTULO 1 completed on time and within budget, but

there are some methodologies available to
ASSESSING project management maturity.
reduce exposure. Wireless Week, v. 9, n. 11,
Project Management Journal, 8756-9728,
p. 34(2), 15 maio 2003.
v. 31, n. 1, p. 32(13), mar. 2000.
FURST, S. et al. Managing the life cycle of SPECIAL Libraries Association. What is not
virtual teams. (High quality, low-cost solu- a project? Information Outlook, v. 6, n. 2,
tions to complex organizational problems). p. 13(3), fev. 2002.
The Academy of Management Executive, URLI, B.; URLI, B. Project management in
v. 18, n. 2, p. 6(15), maio 2004. North America, stability of the concepts.
GARRETT, G. Global project management: Project Management Journal, 8756-9728,
best practices; As projects are becoming v. 31, n. 3, p. 33(11), set. 2000.
increasingly complex, professional project ZIMMERMAN, E. Preventing scope creep.
management is vital to achieving successful Manage, v. 51, n. 3, p. 18, fev. 2000.
results in both the public and private busi-
ness sectors. Contract Management, v. 44, CAPÍTULO 2
n. 4, p. 8(8), abr. 2004.
BUDHWANI, K. Analyze this. CMA Manage-
GLASER, J. Back to basics managing IT pro-
ment, v. 76, n. 5, p. 44(2), jul.-ago. 2002.
jects. Healthcare Financial Management,
v. 58, n. 7, p. 34(5), jul. 2004. CONKLIN, J. Smart project selection. (Using
HOFFMAN, T. IT Departments face a lack outlier techniques). Quality Progress, v. 36,
of project management know-how. Compu- n. 3, p. 81(3), mar. 2003.
terworld, v. 37, n. 32, p. 16(1), 11 ago. 2003. DANIEL, H. et al. Project selection: A pro-
. Pulling the plug; war stories cess analysis. Industrial Marketing Manage-
– and lessons learned – from IT leaders fa- ment, v. 32, n. 1, p. 39(16), jan. 2003.
ced with products that didn’t work as adver- KEEN, K. Don’t ignore the intangibles; even
tised. Computerworld, v. 38, n. 15, p. 1(3), benefits that are hard to quantify can be an
12 abr. 2004. important part of a successful business case.
KENDRA, K.; TAPLIN, L. Project success: CIO, v. 16, n. 22, p. 40(2), 1º set. 2003.
a cultural framework. Project Management . Evidence rules: successful bu-
Journal, v. 35, n. 1, p. 30(16), abr. 2004. siness cases have strong supporting data ba-
MORGAN, B. Bringing a method to the mad- cking them up. Here are some tips for effec-
ness: few software development projects are tive evidence building (Real Value: Practical
417
418 Referências Bibliográficas
Counsel for Capturing IT Value). CIO, v. 17, & Economics, v. 18, n. 4, p. 457(10), jun.
n. 3, p. 54(3), 1º nov. 2003. 2000.
. Tough decisions: IT project se- ZALL, M. Protect yourself. Strategic Finance,
lections have many pitfalls. Get it wrong and v. 85, n. 8, p. 47(3), fev. 2004.
your IT portfolio can become a nightmare.
Here are some warning signs and solutions
to help you improve your process. CIO, v. CAPÍTULO 4
16, n. 15, p. 54(2), 15 maio 2003. BERINATO, S. Playing with fire: IT is late to
MULDOON, K. Details, details: writing an embrace risk analysis, but without it, pro-
RFP. Direct, v. 14, n. 1, p. 49(1), jan. 2002. ject portfolio management is nothing more
than a fad. CIO, v. 16, n. 18, p. 60(7), 1º jul.
ROBERTSON, S. Understanding project
2003.
sociology by modeling stakeholders.
Ian Alexander. IEEE Software, v. 21, n. 1, BROWN, K.; NANCY, L. Whole-brain thinking
p. 23(27), jan.-fev. 2004. for project management. Business Horizons,
v. 46, n. 3, p. 47(11), maio-jun. 2003.
ROBLEWSKY, P. The successful RFP: a
bidder’s perspective. Contract Management, FITHEN, R. IT project closure. Risk Manage-
v. 44, n. 5, p. 4(2), maio 2004. ment, v. 50, n. 10, p. 22(4), out. 2003.
ULFELDER, S. In plain English. Compu- GLEN, P. Getting to done (benefits of clear-
terworld, v. 38, n. 26, p. 34(2), 28 jun. 2004. ly planning the end of a project). Compu-
terworld, v. 38, n. 23, p. 52(1), 7 jun. 2004.
CAPÍTULO 3
MIDDLEMISS, J. The challenge (setting prio-
ABBOTT, G. Proposal evaluations. Govern- rities in information technology projects).
ment Procurement, v. 11, n. 6, p. 52(2), dez. Wall Street & Technology, v. 22, n. 1, p. 46(2),
2003. jan. 2004.
LIN, C. T.; CHEN, Y. T. Bid/no-bid decision- PERKINS-MUNN, T.; CHEN, Y. Streamli-
making – a fuzzy linguistic approach. Inter- ning project management through onli-
national Journal of Project Management, ne solutions. Journal of Business Strategy,
v. 22, n. 7, p. 585(9), out. 2004. v. 25, n. 1, p. 45(4), jan.-feb. 2004
PERKINS, B. Risk/reward contracts: laying 7 STEPS to rescue runaway projects. Wall
the foundations. Computerworld, v. 38, n.19, Street & Technology, v. 21, n. 6, p. 50(2),
p. 37(1), 10 maio 2004. jun. 2003.
PIPER, D. Fixed-Price Contracting – RISKY WESTERVELD, E. The Project Excellence
Business? Contract Management Magazine, Model®: linking success criteria and criti-
v. 43, n. 3, p. 42(3), mar. 2003. cal success factors. International Journal of
POTTER, R. Winning an RFP. The CPA Jour- Project Management, v. 21, n. 6, p. 411(8),
nal, v. 74, n. 4, p. 12(1), abr. 2004. ago. 2003.
REYNOLDS, W. Performance-based contrac- WHY IT projects fail: there’s a difference
ting: The usaid experience. Contract Mana- between managing risk and preventing fai-
gement Magazine, v. 42, n. 12, p. 40(8), dez. lure. Computerworld, v. 37, n. 34, p. 44(1),
2002. 25 ago. 2003.
SAM, T. How to write a winning proposal. WILLIAMS, T. Learning from projects. Jour-
Electric Perspectives, v. 26, n. 4, p. 30(6), nal of the Operational Research Society,
jul.-ago. 2001. v. 54, n. 5, p. 443(9), maio 2003.
WANOUS, M. et al. A neural network bid/no YOKE, C. Planning for chaos; Learning to
bid model: the case for contractors in Syria. expect the unexpected helps bring order
Construction Management & Economics, to project management. Network World,
v. 21, n. 7, p. 737(8), out. 2003. p. 57, 6 out. 2003.
. To bid or not to bid: a para- ZUCCHERO, J. False start: 5 things that can
metric solution. Construction Management derail an IT project before it gets going.
Wall Street & Technology, v. 21, n. 10, FUNCTIONAL estimation of activity critica-
p. 48(2), out. 2003. lity indices and sensitivity analysis of ex-
pected project completion time. Journal of
CAPÍTULO 5 the Operational Research Society, v. 55, n. 8,
BAAR, J.; JACOBSON, S. M. The Keys to Fo- p. 850(10), ago. 2004.
recasting – #2 Work Breakdown Structure. GHOMI, S. et al. Path critical and activity
Cost Engineering, v. 46, n. 3, p. 12(3), mar. critical index in PERT networks. European
2004. Journal of Operational Research, v. 141,
HOBB, L.; SHEAFER, B. Developing a work n. 1, p. 147(6), 16 ago. 2002.
breakdown structure as the unifying foun- HAMERI, A.-P.; HEIKKILA, J. Improving
dation for project controls system develop- efficiency: time-critical interfacing of project
ment. Cost Engineering, v. 45, n. 6, p. 17(5), tasks. International Journal of Project Ma-
jun. 2003. nagement, v. 20, n. 2, p. 143(11), fev. 2002.
LEEMANN, T. Managing the chaos of chan-
LASLO, Z. Activity time-cost tradeoffs under
ge. Journal of Business Strategy, v. 23, n. 5,
time and cost chance constraints. Compu-
p. 11(5), set.-out. 2002.
ters & Industrial Engineering, v. 44, n. 3,
PIGHETTI, D. 6 steps to mission accom- p. 365(20), mar. 2003.
plish: avoid over-budget and incomplete IT
projects by starting out with a focused list of ROSCHE, J. Basics in scheduling: it is im-
business requirements. Best’s Review, v. 105, portant to have a baseline schedule against
n. 2, p. 103(3), jun. 2004. which to measure project progress. Unders-
tanding the basics of scheduling is impor-
PLAN your web project milestones. Compu- tant to everyone involved. Contract Mana-
ter Weekly, p. 24, 1º jun. 2004. gement, v. 44, n. 4, p. 18(2), abr. 2004.
PLANNING. Transactions of AACE Interna- ZHANG, H. et al. Simulation-based metho-
tional, p. 1(68), 2002. dology for project scheduling. Construc-
PREMACHANDRA, I. M. An approximation tion Management & Economics, v. 20, n. 8,
of the activity duration distribution in PERT. p. 667(12), nov.-dez. 2002.
Computers & Operations Research, v. 28, ZHAO,T.; TSENG, C.-L. A note on activity
n. 5, p. 443(10), abr. 2001. floats in activity-on-arrow networks. Journal
RAD, P.; CIOFFI, D. Work and resource bre- of the Operational Research Society, v. 54,
akdown structures for formalized bottom- n. 12, p. 1296(4), dez. 2003.
up estimating. Cost Engineering, v. 46 n. 2,
p. 31(7), fev. 2004. CAPÍTULO 7
RIELEY, J. Practical planning tools that can BAAR, J. The keys to forecasting – #3 Chan-
help get your project off to a good start. ge control. Cost Engineering, v. 46 n. 4,
Journal of Organizational Excellence, v. 22, p. 9(4), abr. 2004.
n. 3, p. 53(12), verão 2003.
BUNTROCK, A. Progress and performance
THOMAS, D.; HUNT, A. Nurturing require- measurement. Cost Engineering, v. 45 n. 11,
ments. IEEE Software, v. 21, n. 2, p. 13(15), p. 26(3), nov. 2003.
mar.-abr. 2004.
COHEN, I. et al. Multi-Project Scheduling
CAPÍTULO 6 and Control: a process-based comparati-
ve study of the critical chain methodology
A COMMENT on solving project-scheduling and some alternatives. Project Management
problems with a heuristic learning algo- Journal, v. 35, n. 2, p. 39(12), jun. 2004.
rithm. Journal of the Operational Research
Society, v. 54, n. 6, p. 666(5), jun. 2003. DOHERTY, S. Change control. Network Com-
puting, v. 15, n. 8, p. 27(2), 29 abr. 2004.
DUBOIS, D. On latest starting times and flats in
activity networks with ill-known durations. DOUGLAS III, E. Project trends and change
European Journal of Operational Research, control. Transactions of AACE Internatio-
v. 147, n. 2, p. 266(15), 6 jan. 2003. nal, p. CSC10(5), 2000.
FARRIS, J. Cost/schedule control on disaster RIGER, R. Managing technological change by

recovery projects. Cost Engineering, v. 43, leveraging your human resources. Legal In-
n. 1, p. 24(5), jan. 2001. formation Alert, v. 22, n. 2, p. 1(5), fev. 2003.
LONGWORTH, S. Evolving project control RIVERA, F.; DURAN, A. Critical clouds and
practices. Transactions of AACE Internatio- critical sets in resource-constrained projects.
nal, p. 04.1(9), 2002. International Journal of Project Manage-
ment, v. 22, n. 6, p. 489(9), ago. 2004.
MEARIAN, L. Killing time on IT projects: IT
projects are notorious for coming in late. ZHANG, G. Some results on resource cons-
Here are some of the worst time-killers that trained scheduling. IIE Transactions, v. 36,
project managers can stumble into – and n. 1, p. 1(9), jan. 2004.
how to avoid them. Computerworld, v. 38,
n. 22, p. 36(1), 31 maio 2004. CAPÍTULO 9
THE NECESSITY of project schedule upda- AL-JIBOURI, S. Monitoring systems and their
ting/monitoring/statusing. Cost Engineering, effectiveness for project cost control in cons-
v. 45, n. 7, p. 8(7), jul. 2003. truction. International Journal of Project Ma-
nagement, v. 21, n. 2, p. 145(10), fev. 2003.
NOSBISCH, M. Project controls: Getting back
to basics. Transactions of AACE Internatio- BLANCO, V. Earned value management ... a
nal, p. 31(1), 2002. predictive analysis tool. Navy Supply Corps
Newsletter, v. 66, n. 2, p. 17(3), mar.-abr.
CAPÍTULO 8 2003.
AL-JIBOURI, S. Effects of resource manage- BRANDEL, M. Budgetary black holes: 10
ment regimes on project schedule. Interna- mistakes that can suck the funds out of your
tional Journal of Project Management, v. 20, IT project budget – and how to avoid them.
n. 4, p. 271(7), maio 2002. Computer-world, v. 38, n. 33, p. 29(2), 16
DECKRO, R.; HEBERT, J. Modeling dimi- ago. 2004.
nishing returns in project resource planning. FELDMAN, J. The seven deadly sins of pro-
Computers & Industrial Engineering, v. 44, ject estimating. Information Strategy: The
n. 1, p. 19(15), jan. 2003. Executive’s Journal, v. 18, n. 1, p. 30(7), ou-
FLESZAR, K.; HINDI, K. Solving the resour- tono 2001.
ce-constrained project scheduling problem FLEMING, Q.; Koppelman, J. What’s your
by a variable neighbourhood search. Eu- project’s real price tag? Harvard Business
ropean Journal of Operational Research, Review, v. 81, n. 9, p. 20, set. 2003.
v. 155, n. 2, p. 402(12), jun. 2004.
KEE, J. Wanted: metric skeptics. (Real Value:
GHOMI, S. et al. A simulation model for Practical Counsel for Capturing IT Value).
multiproject resource allocation. Internatio- CIO, v. 17, n. 1, p. 50(2), 1º out. 2003.
nal Journal of Project Management, v. 20,
n. 2, p. 127, fev. 2002. KING, J. Budgets: when your primary job is
to ferret out liabilities in IT projects – and
HOFFMAN, T. What’s wrong here? Com- minimize them – timing is everything. Com-
puter-World, v. 37, n. 47, p. 5(3), 24 nov. puterworld, v. 38, n. 1, p. 24(2), 5 jan. 2004.
2003.
LEACH, L. Schedule and cost buffer sizing:
LEUS, R.; HERROELEN, W. Stability and re- how to account for the bias between pro-
source allocation in project planning. IIE ject performance and your model. Project
Transactions, v. 36, n. 7, p. 667(16), jul. Management Journal, v. 34, n. 2, p. 34(14),
2004. jun. 2003.
LOH, T. C.; KOH, S. C. L. Critical elements
VERZUH, E. Project status reporting using
for a successful enterprise resource planning
earned value analysis. CHIPS, v. 22, n. 2,
implementation in small-and medium-sized
p. 31, primavera 2004.
enterprises. International Journal of Pro-
duction Research, v. 42, n. 17, p. 3433(23), WANG, C.-H.; HUANG, Y.-C. A new ap-
1º set. 2004. proach to calculating project cost variance.
International Journal of Project Manage- CAUDRON, S. Keeping Team Conflict Alive.

ment, v. 18, n. 2, p. 131(8), abr. 2000. Public Management, v. 82, n. 2, p. 5(5), fev.
2000.
CAPÍTULO 10 BOCK, W. Some rules for virtual teams. The
HAUSCHILDT, J. et al. Realistic criteria for Journal for Quality and Participation, v. 26,
project manager selection and development. n. 3, p. 43(1), outono 2003.
Project Management Journal, v. 31, n. 3, HACKLEY, C. How divergent beliefs cause
p. 23(10), set. 2000. account team conflict. International Journal
STRONG personal skills and certification are of Advertising, v. 22, n. 3, p. 313(19), 2003.
key to becoming a successful project leader. LAWFORD, G. Beyond success: achieving
Computer Weekly, p. 36, 1º jun. 2004. synergy in teamwork. The Journal for Qua-
TOMCZYK, C. Time to get back to basics. lity and Participation, v. 26, n. 3, p. 23(5),
Computerworld, v. 38, n. 22, p. 41(1), 31 outono 2003.
maio 2004. MACKAY, H. Teamwork works on moun-
SEVEN habits of effective IT project leaders. tains, in business. Providence Business News,
Computer Weekly, p. 24, 25 maio 2004. v.16, n. 1, p. 23, 23 abr. 2001.
HOFFMAN, T. Balancing act: businesses that MELYMUKA, K. How to pick a project team;
move at light speed want projects done fast tech skills are only the beginning. Compu-
too. Here’s how project managers deal with terworld, v. 38, n. 15, p. 36(1), 12 abr. 2004.
the pressure and hold the line on quality. MOONEY, A.; SONNENFELD, J. Exploring
Computerworld, v. 38, n. 7, p. 36(2), 18 fev. antecedents to top management team con-
2004. flict: The importance of behavioral integra-
MICHAEL, S. Do your project managers tion. Academy of Management Proceedings,
measure up? Agencies tired of wishful thinking p. 11(6), 2001.
may require management staff to be certified. THOMAS, M. Building and managing a win-
Computer Week, v. 17, n. 38, p. 28(4), 3 nov. ning project team. Manage, v. 52, n. 1, p. 4,
2003. ago. 2000.
KOLBASUK, M. McDonald’s adds to IT USING a total quality approach to measu-
menu – apprentices in project manage- rably improving team relationships. Journal
ment are part of federally funded effort for for Quality & Participation, v. 7, n. 2, p. 50,
I.T. skills development. Information Week, verão 2004.
p. 71, 23 jun. 2003.
CAPÍTULO 12
THAMHAIN, H. Linkages of project environ-
ment to performance: lessons for team lea- BIGGS, M. Technology won’t end project
dership. International Journal of Project Ma- failures; communication is key. InfoWorld,
nagement, v. 22 n. 7, p. 533(12), out. 2004. v. 22, 31 jan. 2000.
THAMHAIN, H. Leading technology-based GILLARD, S.; JOHANSEN, J. Project manage-

project teams. Engineering Management ment communication: a systems approach.
Journal, v. 16, n. 2, p. 35(8), jun. 2004. Journal of Information Science, v. 30, n. 1,
p. 23(7), jan-fev. 2004.
LEE-KELLEY, LIZ; LEONG, L. Turner’s five-
functions of project-based management and GIFFIN, S. A taxonomy of internet applica-
situational leadership in IT services projects. tions for project management communica-
International Journal of Project Manage- tion. Project Management Journal, v. 33, n. 4,
ment, v. 21, n. 8, p. 583(9), nov. 2003. p. 39(9), dez. 2002.
LISTENING may not be as easy as you think.
CAPÍTULO 11 Dispute Resolution Journal, v. 59, n. 2, p. 88,
ALPER, S. et al. Conflict management, effi- maio-jul. 2004.
cacy, and performance in organizational LEWIS, T.; GRAHAM, G. 7 tips for effective
teams. Personnel Psychology, v. 53, n. 3, listening. Internal Auditor, v. 60, n. 4, p. 23,
p. 625(18), outono 2000. ago. 2003.
BURLEY-ALLEN, M. Listen up. HR Magazine, SY, T.; CÔTÉ, S. Emotional intelligence: a

v. 46, n. 11, p. 115, nov. 2001. key ability to succeed in the matrix orga-
nization. Journal of Management Develop-
FRACARO, K. Two ears and one mouth. Su-
ment, v. 23, n. 5, p. 437(19), 2004.
pervision, v. 62, n. 2, p. 3, fev. 2001.
KIM, Y.-S. Learning one’s way to implemen-
MESSMER, M. Conducting effective mee-
ting learning teams in Korea: the relationship
tings. Strategic Finance, v. 82, n. 12, p. 8,
between team learning and power in orga-
jun. 2001.
nizations. Advances in Developing Human
DOHERTY, S. Change control. Network Com- Resources, v. 5, n. 1, p. 64 (20), fev. 2003.
puting, v. 15, n. 8, p. 27, 29 abr. 2004.
KUPRENAS, J. Implementation and perfor-
BIGGIN, B.; LAMOND, B. Program change mance of a matrix organization structure.
control. Internal Auditor, v. 59, n. 3, p. 25, International Journal of Project Manage-
jun. 2002. ment, v. 21, n. 1, p. 51(12), jan. 2003.
ORGANIZATIONAL Communication and in- HARRIS, M.; RAVIV, A. Organization design.
formation systems conference paper abs- Management Science, v. 48, n. 7, p. 852(14),
tracts. Academy of Management Proceedings, jul. 2002.
p. 1 (34), p. 1, 2004.
APÊNDICE A
CAPÍTULO 13
ANTHES, G. Keeping tabs on IT Projects.
VAALAND, T.; HAKANSSON, H. Exploring Computerworld, v. 36, n. 12, p. 48(1), 18
interorganizational conflict in complex pro- mar. 2002.
jects. (Interactions, Relationships and Net-
works in a Changing World). Industrial KING, N. Get on trak. PC Magazine, v. 19,
Marketing Management, v. 32, n. 2, p. 127- n. 7, p. 504, abr. 2000.
138, fev. 2003. COFFEE, P. Project 2003 built for real world.
DEFILLIPPI, R. Organizational models for eWeek, v. 20, n. 45, p. 68(1), 10 nov. 2003
collaboration in the new economy. Human CRAIG, H. Use Web software for projects,
Resource Planning, v. 25, n. 4, p. 7(12), dez. or die. Contractor Magazine, v. 47, n. 9,
2002. p. 68, set. 2000.
PINTO, J.; ROUHIAINEN, P. Building custo- PROJECT meets portal. InfoWorld, v. 22, n. 5,
mer-based project organizations. Chichester, p. 62(5), 31 jan. 2000.
UK: John Wiley & Sons, 2001. 220 p.
MACVITTIE, L. Web services to sleep on.
CLEGG, S.; COURPASSON, D. Political hy- Network Computing, v. 15, n. 6, p. 28(2),
brids: Tocquevillean views on project orga- 1º abr. 2004.
nizations. Journal of Management Studies,
v. 41, n. 4, p. 525(23), jun. 2004. KING, N. Handle projects with the web’s
help. PC Magazine, v. 21, n. 18, p. 28(4),
TURNER, J.; KEEGAN, A. Mechanisms of go-
15 out. 2002.
vernance in the project-based organization:
roles of the Broker and Steward. European GOTTESMAN, B. Z. et al. Getting organized.
Management Journal, v. 19, n. 3, p. 254(14), PC Magazine, v. 21, n. 16, p. 94(3), 17 set.
jun. 2001. 2002.
HOBDAY, M. The project-based organiza- GORDON, P. Track projects on the Web.
tion: an ideal form for managing complex InformationWeek, n. 787, p. 88(2), 22 maio
products and systems? Research Policy, 2000.
v. 29, n. 7/8, p. 871(23), ago. 2000.
RESPOSTAS PARA A SEÇÃO
CAPÍTULO UM
1. Quais são alguns dos atributos de um projeto?
• Um objetivo bem definido
• Tarefas interdependentes
• Utilização de vários recursos
• Um esquema de tempo específico
• Um esforço único ou de uma única vez
• Um cliente
• Um certo grau de incerteza
2. Identifique cinco projetos nos quais você esteve envolvido durante toda a sua vida.
As respostas serão variáveis.
3. Mencione quatro fatores que limitam o cumprimento do objetivo de um projeto.
• Escopo
• Custo
• Cronograma
• Satisfação do cliente
4. Relacione as fases do ciclo de vida de um projeto, na coluna de cima, com as descrições,
na coluna de baixo:
C Primeira fase A. Desenvolvimento e proposição de uma solução
A Segunda fase B. Implementação da solução proposta
B Terceira fase C. Identificação da necessidade ou problema
D Quarta fase D. Conclusão do projeto
5. O objetivo do projeto deve ser acordado entre o cliente e a pessoa ou organização que
irá realizar o projeto.
6. O esforço inicial da gestão de um projeto envolve o estabelecimento de um plano-
base.
7. A implementação do plano-base de um projeto envolve a realização do trabalho de
acordo com o plano e o controle do trabalho, para que o escopo do projeto seja atingido
dentro do orçamento e do cronograma, obtendo a satisfação do cliente.
423
424 Respostas para a Seção Reforce seu Aprendizado
CAPÍTULO DOIS
1. A fase inicial do ciclo de vida do projeto é a identificação de necessidades, que começa
com o reconhecimento de uma necessidade ou oportunidade e termina com a emissão
de uma chamada de propostas.
2. A seleção de projeto envolve a avaliação de várias necessidades ou oportunidades e
uma posterior decisão sobre quais destas deveriam evoluir para um projeto.
3. Os benefícios e as conseqüências podem ser tanto quantitativos e tangíveis quanto qua-
litativos e intangíveis.
4. Quais são as quatro etapas do processo de seleção de projeto?
• Desenvolvimento de um conjunto de critérios de avaliação
• Relação de suposições para cada oportunidade
• Reunião de dados e informações sobre cada oportunidade
• Avaliação de cada oportunidade segundo os critérios
5. Qual é o objetivo de uma chamada de propostas?
Declarar, de forma abrangente e em detalhes, o que é necessário, do ponto de vista do
cliente, para se atender à necessidade identificada.
6. Quais são alguns dos elementos que devem ser incluídos em uma chamada de propostas?
• Especificação de serviço
• Requisitos do cliente
• Produtos a serem entregues (Deliverables)
• Itens fornecidos pelo cliente
• Aprovações necessárias
• Tipo de contrato
• Condições de pagamento
• Cronograma necessário
• Instruções sobre o formato e conteúdo das propostas dos fornecedores
• Data de entrega
• Critérios de avaliação de propostas
• Recursos disponíveis para o projeto
7. Deve-se tomar cuidado para não fornecer informações a apenas alguns fornecedores e não
para todos os interessados, já que isso daria a eles uma vantagem competitiva injusta.
CAPÍTULO TRÊS
1. Os fornecedores precisam estabelecer relações com clientes em potencial antes de pre-
parar uma CP.
2. Qual é o resultado de um esforço de marketing pré-CP/proposta bem-sucedido?
O resultado é ganhar um contrato do cliente para conduzir o projeto.
3. Quais são alguns fatores que o fornecedor deve levar em consideração ao decidir sobre
participar ou não de uma CP?
• Concorrência
• Risco
• Consistência com a missão de negócios
• Oportunidade de aumentar e melhorar sua capacidade
• Reputação com o cliente
• Disponibilidade de fundos do cliente
• Disponibilidade de recursos para preparar uma proposta de qualidade
• Disponibilidade de recursos para realizar o projeto
4. Os fornecedores precisam ser realistas sobre sua capacidade de preparar propostas e

sobre a probabilidade de ganhar o contrato.
5. O processo de proposta é um processo competitivo. Uma proposta é um documento de
venda.
6. Em uma proposta, o fornecedor deve ressaltar os fatores singulares que o diferenciam
das propostas de concorrentes.
7. Uma proposta deve abordar três tópicos ou conter três seções. Quais são elas?
• Seção técnica
• Seção de gestão
• Seção de custos
8. Qual é o objetivo da seção técnica de uma proposta?
O objetivo é convencer o cliente de que o fornecedor entende a necessidade ou proble-
ma e é capaz de oferecer a solução menos arriscada e de maior benefício.
9. Qual é o objetivo da seção de gestão de uma proposta?
O objetivo é convencer o cliente de que o fornecedor é capaz de executar o trabalho
proposto (o projeto) e atingir os resultados esperados.
10. Qual é o objetivo da seção de custos de uma proposta?
O objetivo é convencer o cliente de que o preço do fornecedor para o projeto proposto
é realista e razoável.
11. Quais elementos cada uma dessas três seções pode conter?
Seção técnica
• Entendimento do problema
• Abordagem ou solução proposta
• Benefícios para o cliente
Seção de gestão
• Descrição das atividades
• Deliverables
• Cronograma do projeto
• Organização do projeto
• Experiência relacionada
• Equipamentos e instalações
Seção de custos
• Mão-de-obra
• Materiais
• Subcontratados e consultores
• Equipamentos e aluguel de espaços
• Viagens
• Documentação
• Overhead (custos indiretos)
• Aumento de custos
• Contingência ou reserva de gerenciamento
• Taxa ou lucro
12. Quais são alguns itens que o fornecedor deve levar em consideração ao determinar um
preço para um projeto proposto?
• Confiabilidade das estimativas de custo
• Risco
• Valor do projeto para o fornecedor
• Orçamento do cliente
• Concorrência
13. Os fornecedores devem continuar a ser proativos mesmo depois do envio da proposta.
14. Um fornecedor concorrendo para um contrato de preço global deve desenvolver estima-
tivas de custo completas e exatas e incluir custos de contingência suficientes.
15. Escreva as palavras “baixo” e “alto” em cada caixa, dependendo do grau de risco para o
cliente e para o fornecedor associado a cada tipo de contrato.
Cliente Fornecedor
Preço global Baixo Alto
Por administração Alto Baixo
CAPÍTULO QUATRO
1. Quais são as duas partes da fase de projeto do ciclo de vida?
As duas partes são planejamento e posterior implementação do plano para cumprir com
o objetivo do projeto.
2. A primeira parte da fase de projeto do ciclo de vida envolve o estabelecimento de um
plano-base.
3. O planejamento determina: o que precisa ser feito, quem irá fazê-lo, quanto tempo irá
levar e quanto irá custar.
4. A gestão de riscos envolve identificar, avaliar e responder aos riscos do projeto, a fim
de minimizar a probabilidade e o impacto das conseqüências de eventos adversos sobre
o cumprimento do objetivo do projeto.
5. O planejamento de resposta a riscos envolve o desenvolvimento de um plano de ação
para reduzir o impacto ou a probabilidade de cada risco, o estabelecimento de um ponto
de desencadeamento para saber quando implementar as ações e a atribuição de respon-
sabilidades para as pessoas poderem implementar cada plano de resposta.
6. Um plano de contingência é um conjunto predefinido de ações que seriam implemen-
tadas mediante a ocorrência do evento de risco.
7. Quais são os dois tipos de dados ou informações que precisam ser coletados durante
cada período de relatório?
• Dados de desempenho real
• Informações sobre qualquer mudança no orçamento, no cronograma e no escopo do
projeto
8. Além de estabelecer um plano-base, também é necessário controlar o projeto de forma
proativa, a fim de garantir que seu objetivo seja atingido e que o cliente fique satisfeito.
9. Qual é o objetivo de uma conclusão adequada para o projeto?
O objetivo é aprender com a experiência, a fim de melhorar o desempenho em projetos
futuros.
10. Quais são os dois tipos de reunião de avaliação pós-projeto interna que o gestor deve
realizar?
• Uma reunião individual com cada membro da equipe
• Uma reunião em grupo com toda a equipe do projeto
11. Relacione três motivos para a realização de uma reunião de avaliação pós-projeto com
o cliente.
• Determinar se o projeto forneceu ao cliente os benefícios esperados
• Avaliar o nível de satisfação do cliente
• Obter feedback
12. Para um fornecedor, quais são as duas possíveis conseqüências da conclusão precoce
de um projeto em função de insatisfação do cliente?
• O fornecedor pode ter prejuízo financeiro

• A reputação do fornecedor ficará manchada
CAPÍTULO CINCO
1. Para um projeto, o objetivo costuma ser definido em termos de escopo, cronograma e
custo.
2. Descreva o objetivo de um projeto no qual você esteja trabalhando atualmente (ou tenha
trabalhado recentemente).
3. O que é uma estrutura analítica de projeto?
A estrutura analítica de projeto é uma árvore hierárquica de itens finais que serão atin-
gidos ou produzidos pela equipe durante a execução do projeto.
4. O item de trabalho no nível mais baixo de qualquer ramificação da estrutura analítica de
projeto é chamado de pacote de trabalho.
5. Uma matriz de responsabilidades mostra qual pessoa é responsável por realizar cada
item de trabalho na estrutura analítica do projeto.
6. Identifique dois formatos para a elaboração de um diagrama de rede.
• Diagrama de atividades
• Diagrama de setas
7. As atividades são relacionadas em uma ordem de precedência para mostrar quais ativi-
dades devem ser concluídas antes que outras possam começar.
8. No formato de diagrama de setas para a elaboração de um diagrama de rede, as ativida-
des são ligadas por círculos chamados de eventos.
9. Atividades fictícias são usadas apenas quando o formato de diagrama de setas é usado
na elaboração de um diagrama de rede. Atividades fictícias são mostradas por meio de
uma seta pontilhada.
a. Quando “Preparar Etiquetas para Mala Direta” e “Imprimir Questionário” forem con-
cluídas, qual atividade pode ser iniciada?
“Enviar Questionário e Receber Respostas”
b. Para começar “Inserir Dados de Respostas”, quais atividades devem ser concluídas
imediatamente antes?
“Enviar Questionário e Receber Respostas” e “Testar Software”
a. Para começar “Testar Software”, quais atividades devem ser concluídas imediatamente
antes?
“Desenvolver Software de Análise de Dados” e “Desenvolver Dados para Teste de
Software”
b. Verdadeiro ou falso: depois que “Imprimir Questionário” estiver concluída, “Enviar
Questionário e Receber Respostas” pode começar imediatamente. Falso: “Preparar
Etiquetas para Mala Direta” também precisa ser concluída para que “Enviar Questio-
nário” possa começar.
CAPÍTULO SEIS
1. Verdadeiro ou falso: a estimativa de duração para uma atividade deve incluir o tempo
exigido para se realizar o trabalho mais qualquer tempo de espera associado.
Verdadeiro.
2. O intervalo global de tempo no qual um projeto deve ser concluído é definido por sua
data de início estimada e sua data de conclusão exigida.
3. Qual é a equação para o cálculo da data de término mais cedo de uma atividade?
TC = IC + Duração Estimada
4. As datas de início e término mais cedo para atividades são determinadas calculando-se
de forma progressiva no diagrama de rede.
5. Consulte as Figuras 6.6 e 6.7. Quais são as datas de início e término mais cedo para
“Questionário Teste Piloto”?
IC = Dia 13, TC = Dia 33
6. O que determina a data de início mais cedo de uma atividade? Ela é determinada por meio
da data mais tardia de todas as datas de término mais cedo de todas as atividades que
apontam diretamente para essa atividade em particular.
7. Qual é a equação para o cálculo de data de início mais tarde de uma atividade?
IT = TT – Duração Estimada
8. As datas de início e término mais tarde são determinadas calculando-se de forma regres-
siva no diagrama de rede.
9. Consulte as Figuras 6.10 e 6.11. Quais são as datas de início e término mais tarde para
“Inserir Dados de Respostas”?
TT = Dia 12, IT = Dia 105
10. O que determina a data de término de uma atividade em particular?
Ela é determinada pela data mais cedo entre as datas de início mais tarde de todas as
atividades que partem diretamente daquela atividade em particular.
11 Quando um projeto tem uma folga total positiva, algumas atividades podem ser adiadas
sem comprometer a conclusão do projeto até a data exigida. Quando um projeto tem
uma folga total negativa, algumas atividades precisam ser aceleradas, para que o projeto
seja concluído até a data exigida.
12. Folga total é a diferença entre as datas mais tarde e as datas mais cedo.
13. O caminho mais longo de atividades do início ao fim de um projeto é chamado de ca-
minho crítico.
14. Consulte as Figuras 6.13 e 6.14. Das duas atividades que caminham em direção à ativida-
de 11, “Inserir Dados de Respostas”, qual atividade tem folga livre? Qual é o seu valor?
Atividade 10, “Testar Software”; 50 – (–8) = 58 dias
15. Calcule a duração esperada para uma atividade que tenha as seguintes estimativas de
tempo: to = 8, tm = 12 e tp = 22.
8 + 4(12) + 22
te = = 13
6
16. Calcule a duração esperada (te ) e a variância (σ 2) para a distribuição beta de probabili-
dades a seguir.
5 + 4(8) + 23
te = = 10
6
⎛ 23 − 5 ⎞⎟
σ = ⎜⎜
2
2 = 9
⎜⎝ 6 ⎠⎟⎟
17. Qual porcentagem da área sob essa curva normal está sombreada?
34%.
18. Se 95% da área sob a curva normal a seguir estiver entre os dois pontos indicados, qual
é o desvio padrão? Qual é a variância?
Como há um total de quatro desvios padrão (+2 e –2) entre 12 e 31, 4σ = 32 – 12 = 20,
e, portanto, 1σ = 5. Variância = σ2 = (5)2 = 25.
CAPÍTULO SETE
1. Quais são os dois tipos de dados ou informações que precisam ser coletados durante
cada período de relatório?
• Dados sobre desempenho real
• Informações sobre quaisquer mudanças no escopo, cronograma ou orçamento do
projeto
2. Verdadeiro ou falso: em geral, é melhor que o período de relatório seja curto durante
um projeto.
Verdadeiro.
3. Além de estabelecer um plano-base sólido, também é necessário controlar o projeto de
forma proativa depois que ele for iniciado, a fim de se garantir que o objetivo do projeto
seja alcançado.
4. Quais os três tipos de valores que serão afetados pelas datas de término real de ativida-
des concluídas?
As datas de término real afetarão as datas de início mais cedo e as datas de término mais
cedo das atividades restantes, e a folga total.
5. Quais três elementos podem ser afetados por mudanças em projetos?
As mudanças no projeto podem afetar seu escopo, orçamento e cronograma.
6. Ao analisar o cronograma de um projeto, é importante identificar todos os caminhos de
atividades que têm uma folga negativa.
7. Ao analisar um caminho de atividades que tenha uma folga negativa, quais os dois tipos
de atividades que devem ser observados com cuidado?
• Atividades que estão em andamento ou prestes a serem iniciadas
• Atividades que tenham estimativas de duração longas
8. Relacione quatro abordagens para reduzir as durações estimadas de atividades.
• Aplicar mais recursos
• Designar uma pessoa com maior habilidade ou mais experiência
• Reduzir o escopo ou os requisitos
• Aumentar a produtividade por meio de métodos ou tecnologias mais eficazes
9. Quais são os tempos normais e de processamento mínimo para as atividades B, C e D
na Figura 7.7?
Tempo Custo Tempo de Custo de
Normal Normal Compressão Compressão
Atividade B 9 semanas U$ 80.000 6 semanas U$ 110.000
Atividade C 10 semanas U$ 40.000 9 semanas U$ 45.000
Atividade D 8 semanas U$ 30.000 6 semanas U$ 42.000
10. Quais são os custos semanais para se acelerar as atividades B, C e D na Figura 7.7?
B, US$ 10.000 por semana; C, US$ 5.000 por semana; D, US$ 6.000 por semana.
11. Se todas as atividades da Figura 7.7 fossem realizadas em seu tempo de processamento
mínimo, qual seria o custo total do projeto?
US$ 259.000.
CAPÍTULO OITO
1. No mínimo, os diagramas de rede ilustram as limitações técnicas entre as atividades.
No entanto, quando os recursos disponíveis são limitados, o diagrama de rede pode ser
elaborado para refletir também as limitações de recursos.
2. O nivelamento de recursos procura estabelecer uma programação na qual o uso de re-
cursos é feito do modo mais nivelado possível sem estender o projeto além do tempo
de conclusão exigido.
3. A programação com limitação de recursos desenvolve o cronograma mais curto quando
a quantidade de recursos disponíveis é fixa. Esse método estende o tempo de conclusão
do projeto se necessário, a fim de manter o projeto dentro dos limites.
CAPÍTULO NOVE
1. Faça uma lista dos itens cujos custos devem ser estimados.
• Mão-de-obra
• Materiais
• Subfornecedores e consultores
• Equipamentos e aluguel de instalações
• Viagens
2. A primeira etapa do processo de orçamento do projeto consiste em alocar os custos
totais do projeto para cada pacote de trabalho na estrutura analítica, estabelecendo-se,
assim, um custo de orçamento total para cada pacote de trabalho.
3. Depois que um custo orçado total foi estabelecido para cada pacote de trabalho, a
segunda etapa no processo de orçamento do projeto é distribuir cada COT durante o
pacote de trabalho em questão.
4. O custo orçado acumulado é o valor orçado para a execução do trabalho a ser desem-
penhado até o momento em questão.
5. Consulte as Figuras 9.4 e 9.6. Quais os valores em dólares dos pacotes de trabalho “Con-
cepção da máquina” e “Construção da máquina” que contribuem para o custo excedente
de US$ 4.000 ao final da semana 8?
Quantidade Custos excedentes ou redução de custos
Concepção U$ 2.000 redução de custos
Construção U$ 6.000 custos excedentes
6. Calcula-se o valor agregado acumulado determinando-se primeiro o percentual reali-
zado de cada pacote de trabalho e, em seguida, multiplicando-se esse valor pelo custo
orçado total do pacote de trabalho.
7. Faça uma lista das medidas relativas ao custo utilizadas na análise do desempenho de
custo do projeto.
• COT (custo orçado total)
• COC (custo orçado acumulado)
• CRC (custo real acumulado)
• VAC (valor agregado acumulado)
8. Qual é o índice de desempenho de custo do pacote de trabalho Concepção, no final da
semana 5, para o projeto máquina de embalagem?
U$ 24.000
IDC = = 1, 091
U$ 22.000
9. Qual é a variação de custo do pacote de trabalho “Concepção da máquina”, ao final da

semana 8, para o projeto máquina de embalagem?
VC = U$ 30.000 – U$ 46.000 = –U$ 16.000
10. Usando o primeiro método de estimativa descrito, calcule o custo estimado na conclusão
do pacote de trabalho “Construção da máquina” no projeto máquina de embalagem.
⎛ ⎞
CEC =
U$ 60.000
= $ 92.300 ⎜⎜Obs.: IDC = U$ 30.000 = 0, 65⎟⎟
⎜⎝ ⎟
0, 65 U$ 46.000 ⎠⎟
11. Usando o segundo método de estimativa descrito, calcule o custo estimado na conclusão
do pacote de trabalho “Construção da máquina” no projeto máquina de embalagem.
CEC = U$ 46.000 + (U$ 60.000 – U$ 30.000) = U$ 76.000
12. Ao analisar o desempenho de custo, é importante identificar todos os pacotes de traba-
lho que possuem uma variação de custo negativo ou um índice de desempenho de custo
inferior a 1,0.
13. Ao avaliar pacotes de trabalho que possuem uma variação de custo negativa, você deve
se concentrar no emprego de ações corretivas para reduzir os custos das atividades que
serão realizadas em curto prazo e naquelas cujas estimativas de custo são grandes.
14. O segredo para administrar o fluxo de caixa está em assegurar que a entrada de capital
se dê mais rapidamente que a saída.
15. Se não há recursos suficientes para cobrir os gastos, o fornecedor provavelmente preci-
sará emprestar dinheiro. Isso será somado ao custo do projeto, pois o fornecedor deve
pagar juros também.
CAPÍTULO DEZ
1. Quais os dois benefícios que o gestor de projetos consegue ao envolver a equipe na
elaboração do plano?
O gestor do projeto garante um plano mais abrangente e ganha o compromisso da equi-
pe para realizar o plano.
2. O gestor de projetos deve garantir os recursos apropriados para a realização do traba-
lho, atribuir responsabilidades e delegar autoridade a pessoas específicas para as mais
diversas tarefas.
3. Quais são as duas funções do sistema de informação para a gestão do projeto que é
implementado pelo gestor de projetos?
As duas funções são rastrear o progresso real e compará-lo com o progresso planejado.
4. Quais são as três funções de gestão de projetos que o gestor tem responsabilidade de
liderar?
• Planejamento
• Organização
• Controle
5. A liderança de um projeto implica inspirar as pessoas designadas para o projeto a tra-
balharem como uma equipe para implementar o plano e alcançar o objetivo do projeto
com sucesso.
6. A liderança de um projeto exige envolvimento e autonomia da equipe do projeto.
7. O gestor de projetos competente sabe o que motiva os membros da equipe e cria um
ambiente incentivador, no qual as pessoas trabalham como parte de uma equipe de alto
desempenho.
8. As pessoas querem sentir que estão dando uma contribuição para o projeto e precisam
ser reconhecidas.
9. Um gestor de projetos dá o tom à equipe do projeto, estabelecendo um ambiente de con-
fiança, de altas expectativas e de satisfação.
10. As pessoas que trabalham nos projetos procuram por associação e socialização – elas
não querem trabalhar isoladas.
11. A liderança exige que o gestor de projetos esteja altamente motivado e que dê um exem-
plo positivo para a equipe do projeto.
12. Um bom gestor de projetos acredita que todas as pessoas são valiosas para a organiza-
ção e que elas podem dar contribuições cada vez maiores por meio de um aprendizado
contínuo.
13. Em vez de criar medo do fracasso, o gestor de projetos reconhece que os erros fazem
parte do aprendizado e da experiência de crescimento.
14. Um bom gestor de projetos valoriza e espera um autodesenvolvimento contínuo.
15. Faça uma lista de cinco razões pelas quais é importante que o gestor de projetos tenha
comunicação freqüente.
• Manter o projeto em progresso
• Identificar problemas em potencial
• Solicitar sugestões para melhorar o desempenho do projeto
• Manter a satisfação do cliente
• Evitar surpresas
16. Um alto nível de comunicação é importante principalmente no início do projeto para
construir uma boa relação de trabalho com a equipe do projeto e para estabelecer ex-
pectativas claras para o cliente.
17. Quais são as três maneiras de um gestor de projetos se comunicar?
• Reuniões
• Conversas informais
• Relatórios escritos
18. Os bons gestores de projetos passam mais tempo ouvindo do que falando.
19. Dê três razões pelas quais o gestor de projetos deve estabelecer uma comunicação con-
tínua com o cliente.
• Manter o cliente informado
• Determinar se houve quaisquer mudanças nas expectativas
• Manter o nível de satisfação do cliente
20. Por que a comunicação feita pelos gestores de projetos precisa ser pontual, honesta e
sem ambigüidades?
Porque essa comunicação estabelece credibilidade, constrói confiança e evita boatos.
21. O gestor de projetos deve ter uma conversa informal com cada pessoa da equipe do
projeto e com cada pessoa-chave da organização do cliente.
22. O gestor de projetos deve fazer perguntas abertas e ouvir muito.
23. O gestor de projetos precisa ter um bom senso de humor e precisa estar fisicamente em
forma.
24. Ao solucionar problemas, o gestor de projetos precisa ser capaz de ver a situação como
um todo e como as soluções em potencial podem afetar outras partes do projeto.
25. Quais são as habilidades que um gestor de projetos eficaz tem?
• Capacidade de liderança
• Capacidade de desenvolver pessoas
• Habilidades de comunicação
• Habilidades interpessoais
• Capacidade de lidar com o estresse
• Capacidade de resolver problemas
• Capacidade de gerir o tempo
26. a. Identifique uma habilidade que você queira desenvolver.
b. Identifique três coisas que você pode fazer para desenvolver essa habilidade.
c. Selecione uma das três coisas relacionadas acima e escolha uma data até a qual você
terá feito isso.
27. A delegação envolve capacitar a equipe para alcançar o objetivo do projeto e capacitar
cada membro para atingir os resultados esperados de sua área de responsabilidade.
28. Os gestores de projetos não devem dizer às pessoas como fazer as tarefas a elas atribuídas.
29. Ao designar pessoas para tarefas específicas, o gestor de projetos precisa levar em con-
sideração a capacidade, o potencial e a carga de trabalho da pessoa.
30. Uma delegação eficaz exige que o gestor de projetos tenha confiança em cada membro
da equipe do projeto.
31. A delegação exige que as pessoas sejam responsáveis por alcançar os resultados espe-
rados.
32. As mudanças podem ser iniciadas pelo cliente ou pela equipe de projeto ou podem ser
causadas por imprevistos durante a realização do projeto.
33. O trabalho do gestor de projetos é gerenciar e controlar as mudanças para minimizar
qualquer impacto negativo sobre a realização com sucesso do objetivo do projeto.
34. No início do projeto, o gestor de projetos deve estabelecer procedimentos referentes à
maneira de como as mudanças serão documentadas e autorizadas.
CAPÍTULO ONZE
1. Uma equipe é um grupo de pessoas que trabalham interdependentemente para alcançar
um objetivo comum.
2. Trabalho de equipe é um esforço cooperativo por parte dos membros de uma equipe
para alcançar um objetivo comum.
3. Durante o estágio de formação, pouco trabalho real é realizado devido ao alto nível de
ansiedade das pessoas.
4. No estágio de formação, as pessoas fazem muitos questionamentos.
5. Durante o estágio de formação, o gestor do projeto precisa dar orientação e estrutura à
equipe do projeto.
6. Durante o estágio de agitação, os conflitos aparecem e a tensão aumenta.
7. Durante o estágio de agitação, os membros da equipe querem saber quanto de controle
e autoridade eles têm.
8. Durante o estágio de agitação, o gestor de projetos precisa dar orientação e favorecer a
resolução de conflitos.
9. No estágio de normalização, os conflitos e as insatisfações diminuem, a coesão começa
a se desenvolver e surge um sentido de equipe.
10. Durante o estágio de normalização, um sentimento de confiança começa a se desenvol-

ver. Há uma troca maior de informação, idéias e sentimentos; a cooperação aumenta.
11. No estágio de normalização, o desempenho do trabalho acelera e a produtividade au-
menta.
12. Durante o estágio de execução, há um alto grau de interdependência – os membros
colaboram e ajudam uns aos outros freqüentemente e têm disposição para realizar além
de suas próprias tarefas.
13. Durante o estágio de execução, o gestor do projeto delega totalmente responsabilidade
e autoridade, e, assim, dá poderes à equipe do projeto.
14. Quais são os quatro estágios de desenvolvimento e crescimento de equipe?
• Formação
• Agitação
• Normalização
• Execução
15. Uma equipe de projeto eficaz tem um claro entendimento do objetivo do projeto e claras
expectativas sobre o papel e as responsabilidades de cada pessoa.
16. As equipes de projeto eficazes têm uma orientação a resultados; cada pessoa da equipe
tem um forte comprometimento em alcançar o objetivo do projeto. Há um alto grau de
cooperação e colaboração.
17. As equipes de projeto eficazes têm um nível alto de confiança. Elas são capazes de
resolver conflitos por meio de um feedback construtivo e oportuno e uma confrontação
positiva das questões.
18. O gestor do projeto precisa articular o objetivo do projeto com freqüência. Nas reuniões
periódicas, ele sempre deve perguntar se alguém tem alguma questão sobre o que deve
ser cumprido.
19. O gestor de projetos deve conversar em particular com cada membro da equipe do pro-
jeto para explicar por que ele foi selecionado para o projeto e descrever os papéis e as
responsabilidades esperados.
20. O gestor do projeto precisa estabelecer procedimentos de operação preliminares no início
do projeto, mas estar aberto a sugestões para eliminar e modernizar os procedimentos
quando eles não contribuem mais para o desempenho eficiente e eficaz do projeto.
21. O gestor do projeto deve tentar determinar o que motiva cada pessoa e, em seguida,
criar um ambiente de projeto onde haja esses motivadores.
22. É importante que o gestor do projeto faça reuniões de revisão de status do projeto com
regularidade, com publicação de uma pauta. A participação e perguntas devem ser in-
centivadas durante a reunião.
23. Um gestor de projetos deve solicitar periodicamente sugestões das outras pessoas, a fim
de melhorar suas habilidades de liderança.
24. Uma equipe de projeto formada por um pequeno número de pessoas com atribuições
de longo prazo será mais eficaz do que uma equipe composta de um grande número de
pessoas com atribuições de curto prazo.
25. Quais são algumas das barreiras para a eficácia de uma equipe?
• Metas pouco definidas
• Definição pouco clara do papel e das responsabilidades
• Falta de estrutura de projeto
• Falta de comprometimento
• Má comunicação
• Má liderança
• Rotatividade dos membros da equipe do projeto
• Comportamento disfuncional
26. Os membros eficazes de uma equipe planejam, controlam e sentem-se responsáveis por
seus próprios esforços de trabalho. Eles têm expectativas elevadas sobre eles mesmos.
27. Os membros eficazes de uma equipe participam e comunicam-se. Eles não são apenas
identificadores de problemas, mas também solucionadores.
28. Pense em projetos nos quais você trabalhou. Quais são algumas das características pes-
soais dos membros dessas equipes que lhes permitiram dar contribuições eficazes?
29. A construção de equipe é uma responsabilidade tanto do gestor do projeto como da
equipe do projeto.
30. A socialização entre os membros da equipe favorece a construção da equipe. Os mem-
bros precisam se comunicar uns com os outros com freqüência.
31. Existem duas ações que uma organização de projeto pode tomar para ajudar a prevenir
uma má conduta: apresentar uma política escrita sobre comportamento ético e provi-
denciar um treinamento sobre ética no trabalho.
32. Quais são as fontes comuns de conflitos em projetos?
• Escopo do trabalho
• Atribuições de recursos
• Cronograma
• Custo
• Prioridades
• Questões organizacionais
• Diferenças pessoais
33. Se for tratado propriamente, um conflito pode ser benéfico.
34. Quais são as cinco abordagens para lidar com conflitos?
• Evitar ou concordar
• Competir ou coagir
• Acomodar ou conciliar-se
• Fazer concessões
• Colaborar, confrontar e resolver problemas
35. Quais são as nove etapas envolvidas na resolução de problemas?
• Desenvolver uma declaração do problema
• Identificar possíveis causas para o problema
• Reunir dados e verificar as causas mais prováveis
• Identificar possíveis soluções
• Avaliar as soluções alternativas
• Determinar a melhor solução
• Revisar o plano do projeto
• Implementar a solução
• Determinar se o problema foi resolvido
36. Em uma sessão de brainstorming, a quantidade de idéias geradas é mais importante do
que a qualidade das idéias.
37. Quais são algumas das coisas que você pode fazer para administrar o tempo com eficácia?
• Identificar metas semanais
• Elaborar uma lista de coisas a fazer a cada dia
• Concentrar-se em realizar a lista de coisas a fazer
• Controlar interrupções
• Aprender a dizer “não”
• Fazer bom uso do tempo de espera
• Lidar com a papelada de uma vez só
• Recompensar-se
CAPÍTULO DOZE
1. Identifique dois tipos de comunicação oral pessoal.
• Comunicação frente a frente
• Conversas telefônicas
2. A linguagem corporal pode ser usada não só pela pessoa que fala, mas também pelo
ouvinte, como uma maneira de dar um feedback para a pessoa que fala.
3. Na comunicação pessoal, as pessoas precisam ser sensíveis à linguagem corporal que
reflete a diversidade cultural dos participantes.
4. Os membros da equipe do projeto precisam ser proativos para iniciar uma comunicação
oportuna, a fim de obter e dar informações.
5. Identifique dois métodos que você pode usar para dar feedback durante a comunicação
oral.
• Peça à outra pessoa para lhe explicar o que ela entendeu da sua fala
• Parafraseie o que você acha que a outra pessoa disse
6. Quais são as duas formas de comunicação escrita pessoal?
• Memorandos internos
• Cartas externas
7. A falta da capacidade de ouvir pode causar uma ruptura na comunicação entre as pessoas.
8. Faça uma lista das barreiras mais comuns para a capacidade de ouvir com eficácia.
• Fingir que está escutando
• Distrações
• Idéias preconcebidas e mente fechada
• Impaciência
• Tirar conclusões precipitadas
9. Quais são algumas das coisas que você pode fazer para melhorar sua habilidade de ouvir?
• Focar-se na pessoa que fala
• Empenhar-se em ouvir ativamente
• Fazer perguntas
• Não interromper
10. Quais são os principais propósitos de uma reunião de análise de status?
• Informar
• Identificar problemas
• Identificar tarefas
11. Verdadeiro ou falso: quando os membros da equipe do projeto identificam problemas
ou problemas em potencial, eles devem esperar até a próxima reunião de análise de
status para colocá-los em discussão.
Falso: eles devem iniciar uma reunião de resolução de problemas imediatamente, com
os membros da equipe apropriados.
12. Para projetos técnicos, normalmente existem duas reuniões de análise crítica de concep-
ção: uma reunião de análise crítica de concepção preliminar e uma reunião de análise
crítica de concepção final.
13. Para assegurar que uma reunião seja eficaz, quais são alguns dos passos que a pessoa
que convoca ou conduz a reunião deve tomar antes da reunião?
• Determinar se a reunião é realmente necessária
• Determinar o propósito da reunião
• Determinar quem precisa participar
• Distribuir uma pauta
• Preparar recursos visuais ou materiais a serem distribuídos
• Organizar uma sala de reunião
14. Verdadeiro ou falso: é sempre uma boa idéia esperar que todos os participantes che-
guem para depois começar a reunião, mesmo se passar da hora de início marcada.
Falso: se o líder da reunião espera pelos participantes atrasados, as pessoas irão adquirir
o costume de chegarem atrasadas porque sabem que a reunião não começará na hora
certa de qualquer forma.
15. Quais são as coisas importantes que se deve fazer ao se preparar uma apresentação?
• Determinar o propósito da apresentação
• Conhecer o público
• Fazer um esboço
• Usar uma linguagem simples
• Preparar anotações
• Ensaiar
• Preparar recursos visuais
• Fazer cópias dos materiais que serão distribuídos
• Solicitar equipamentos audiovisuais
• Entrar na sala de reunião e familiarizar-se com o ambiente
16. Quais são as coisas importantes que se deve ter em mente ao se fazer uma apresentação?
• Esperar um pouco de nervosismo
• Saber as primeiras duas ou três linhas da apresentação
• Usar a abordagem dos 3 C
• Falar com o público, não para ele
• Falar claramente e com confiança
• Usar animações apropriadas
• Não ficar na frente de seus recursos visuais
• Causar interesse por sua apresentação
• Não desviar do assunto
• Explicar para o público por que os pontos principais são importantes
• Resumir cada ponto antes de passar para o próximo tópico
• Saber as palavras de encerramento
• Separar um tempo para perguntas do público
• Ser sincero, imparcial e confiante ao responder às perguntas
17. Os relatórios de projeto devem ser escritos para tratar do que é de interesse dos leitores
e não do que é de interesse da pessoa que escreve o relatório.
18. O propósito principal dos relatórios de projeto é informar as realizações do projeto e
não quais atividades a equipe do projeto realizou.
19. Verdadeiro ou falso: um relatório final de projeto é um acúmulo dos relatórios de pro-
gresso preparados durante o projeto.
Falso: é um resumo do projeto.
20. Quais são algumas das diretrizes importantes que se deve ter em mente ao preparar um
relatório?
• Fazer um relatório conciso
• Escrever como você falaria
• Colocar primeiro os pontos mais importantes

• Usar representações gráficas
• Fazer o relatório em um formato atraente e fácil de ler
21. As revisões de documentos do projeto podem resultar de mudanças iniciadas pelo clien-
te ou pela equipe de projeto.
22. No início do projeto, deve ser feito um acordo com relação às maneiras como as mu-
danças serão documentadas e autorizadas.
CAPÍTULO TREZE
1. A organização funcional enfatiza a importância da contribuição da experiência de cada
área funcional para os produtos da empresa.
2. Verdadeiro ou falso: em uma organização funcional, as pessoas continuam a realizar
seu trabalho funcional regular, enquanto atuam em uma força-tarefa de um projeto em
período parcial.
Verdadeiro.
3. Uma empresa com uma estrutura funcional pode periodicamente formar forças-tarefa
para trabalhar em projetos internos, mas raramente irá conduzir projetos que envolvam
clientes externos.
4. Em uma organização do tipo por projetos, todos os recursos são designados em período
integral para trabalhar em um projeto particular. O gestor do projeto tem autoridade de
projeto e administrativa total sobre a equipe de projeto.
5. Uma organização do tipo por projetos pode ter ineficiência de custos.
6. Estruturas organizacionais do tipo por projetos são encontradas principalmente em em-
presas que estão envolvidas em projetos muito grandes.
7. A estrutura organizacional do tipo matricial fornece o foco no cliente e no projeto da
estrutura por projetos, mas retém a experiência funcional da estrutura funcional.
8. Em uma organização do tipo matricial, as áreas funcionais fornecem um agregado de
experiência para dar suporte a projetos em andamento.
9. A estrutura organizacional do tipo matricial resulta na utilização eficaz dos recursos e
minimiza os custos gerais, já que permite que as pessoas dividam seu tempo entre vários
projetos.
10. Em uma organização do tipo matricial, cada membro de uma equipe de projeto tem uma
dualidade de relação hierárquica para com o gestor de projeto temporário e com o ge-
rente funcional permanente.
11. Em uma organização do tipo matricial, o gestor do projeto define o que tem que ser
feito, até quando e por quanto dinheiro, a fim de cumprir com o objetivo do projeto e
satisfazer o cliente.
12. Em uma organização do tipo matricial, cada gerente funcional é responsável por como
o trabalho será feito e quem realizará cada tarefa.
13. A estrutura organizacional matricial permite respostas rápidas mediante a identificação
de problemas porque tem tanto um caminho horizontal quanto um vertical para o fluxo de
informações.
14. Relacione três tipos comuns de estruturas que podem ser usadas para organizar as pes-
soas para trabalhar em projetos:
• Funcional
• Por projetos
• Matricial
15. Quais são algumas vantagens e desvantagens da estrutura organizacional funcional?

Vantagens:
• Ausência de duplicação de atividades
• Excelência funcional
Desvantagens:
• Compartimentação
• Tempo lento de resposta
• Falta de foco no cliente
16. Quais são algumas vantagens e desvantagens da estrutura organizacional por projetos?
Vantagens:
• Controle sobre recursos
• Sensibilidade às necessidades do cliente
Desvantagens:
• Ineficiência de custos
• Baixo nível de transferência de conhecimento entre projetos
17. Quais são algumas vantagens e desvantagens da estrutura organizacional matricial?
Vantagens:
• Utilização eficiente de recursos
• Experiência funcional disponível para todos os projetos
• Maior aprendizado e transferência de conhecimento
• Sensibilidade às necessidades do cliente
• Foco no cliente
Desvantagens:
• Dualidade de relações hierárquicas
• Necessidade de equilíbrio de poder
GLOSSÁRIO
A blema ou oportunidade; desenvolvimen-

to de uma solução proposta; implemen-
Atividade Porção de trabalho definida que tação da solução proposta; e conclusão
consome tempo; tarefa. do projeto.
Atividade fictícia ou fantasma Tipo especial Cliente Entidade que fornece os fundos ne-
de atividade, usado no diagrama de rede cessários para se realizar um projeto. O
do tipo diagrama de setas, que não con- cliente pode ser uma pessoa, uma orga-
some tempo. As atividades fictícias são re- nização ou um grupo de pessoas ou or-
presentadas por uma seta pontilhada. ganizações.
Contingência Quantia que um fornecedor
C
pode incluir em uma proposta para co-
Caminho crítico Em um diagrama de rede, brir gastos inesperados que podem surgir
qualquer caminho de atividades com fol- durante um projeto; reserva de gerencia-
ga total negativa ou zero. Veja também mento.
caminho mais crítico. Contrato Acordo entre um fornecedor, que
Caminho mais crítico Em um diagrama de concorda em fornecer um produto ou ser-
rede, o caminho mais demorado das ativi- viço (deliverables), e um cliente, que con-
dades; o caminho de atividades que tem corda em pagar ao fornecedor um deter-
o menor valor – seja o menos positivo ou minado valor em dinheiro em troca.
o mais negativo – para a folga total. Contrato de preço global Contrato no qual
Chamada de propostas (CP) Documento, um cliente e um fornecedor acordam um
normalmente elaborado pelo cliente, que preço, fixo e total, que não poderá variar,
define uma necessidade ou problema, independentemente de quanto o projeto
exigências e expectativas. custe para o fornecedor.
Ciclo de vida de desenvolvimento de sis- Contrato por administração (ou a preço
temas (CVDS ou SDLC) Ferramenta de de custo) Contrato no qual um cliente
planejamento de gestão de projetos com- concorda em pagar ao fornecedor todos
posta por um conjunto de fases ou etapas os custos reais incorridos durante um
a serem concluídas ao longo do desenvol- projeto, acrescidos de um lucro previa-
vimento de um sistema de informação. mente acordado (que cobre os custos de
Ciclo de vida do projeto As quatro fases administração do projeto).
pelas quais um projeto se movimenta: Controle de projeto Coleta regular de da-
identificação de uma necessidade, pro- dos sobre o desempenho real do projeto,
440
Glossário 441
comparando o desempenho real com o Custo real acumulado (CRC ou CAC) Va-
desempenho planejado, e adotando me- lor que foi de fato gasto para completar
didas corretivas caso o desempenho real todo o trabalho realizado até um ponto
esteja aquém do desempenho planejado. de tempo específico.
Critérios de avaliação Parâmetros, especi- Custo real Valor que foi de fato gasto.
ficados em um CP, que o cliente irá usar Custos indiretos Veja Overhead.
para avaliar propostas de fornecedores
concorrentes. D
Cronograma Definição de datas no plane- Data de entrega Data, especificada em uma
jamento do projeto. CP, na qual um cliente espera que os
Cronograma “mais cedo possível” (MCP fornecedores em potencial enviem suas
ou ASAP) Cronograma baseado no início propostas.
mais cedo possível de cada atividade do Data de início estimada Data esperada
projeto. para o começo de um projeto.
Cronograma “mais tarde possível” (MTP Decisão de participar/não participar da
ou ALAP) Cronograma baseado no início concorrência Avaliação de um fornece-
mais tardio possível de cada atividade do dor sobre prosseguir ou não com a ela-
projeto. boração de uma proposta em resposta a
Cronograma limitado por recursos Méto- uma CP de um cliente.
do para desenvolver o cronograma mais Deliverables Itens, produtos ou serviços
curto quando o número ou a quantidade tangíveis que o cliente espera que o for-
de recursos disponíveis é limitado. Esse necedor ou contratado entregue durante
método estende o tempo de conclusão o projeto.
do projeto, se necessário, para mantê-lo Desvio padrão Medida da dispersão, ou
dentro dos limites de recursos. propagação, de uma distribuição em rela-
Custo Valor que o cliente concordou em pa- ção ao seu valor esperado; raiz quadrada
gar por produtos ou serviços integrantes da variância.
do projeto. Diagrama de atividades (DA ou AIB)
Custo comprometido Fundos que não es- Forma de diagrama de rede na qual as
tão disponíveis para serem gastos em ne- atividades são representadas em caixas,
nhum outro lugar, pois serão necessários ligadas por setas que indicam as prece-
no futuro para pagar por um item solici- dências.
tado, por exemplo, um material; compro- Diagrama de rede Visualização gráfica das
misso; custo onerado. atividades a serem conduzidas para atin-
Custo de processamento mínimo (Crash gir o escopo de trabalho total do projeto,
Cost) Custo estimado para concluir uma mostrando sua seqüência e interdepen-
atividade no menor tempo possível (o dências. Usualmente, representa-se nas
tempo de processamento mínimo). formas de diagrama de atividades ou de
Custo estimado na conclusão (CEC ou diagrama de setas.
FCAC) Custo total projetado de todo o Diagrama de setas (DS ou AOA) Forma de
trabalho necessário para concluir um diagrama de rede na qual as atividades
projeto. são representadas por setas. Também
Custo normal Custo estimado para concluir denominado diagrama de eventos ou
uma atividade sob condições normais, de rede de eventos.
acordo com o planejamento. Distribuição beta de probabilidades Dis-
Custo orçado acumulado (COC ou CBC) tribuição comumente usada para calcular
Valor orçado para realizar todo o traba- a duração esperada e a variância de uma
lho programado até um ponto de tempo atividade com base nas estimativas de
específico. prazo pessimistas, mais prováveis e oti-
Custo orçado total (COT ou TBC) Parce- mistas para aquela atividade.
la do orçamento total do projeto alocada Distribuição normal de probabilidades
para concluir todas as atividades e traba- Distribuição em forma de sino de valo-
lhos associados a um pacote de trabalho res simetricamente ao redor de seu valor
em particular. médio.
442 Glossário
Duração esperada (te) Também chama- as mesmas habilidades ou competências,

da de duração média. Duração espera- como engenharia eletrônica ou testes.
da para uma atividade, calculada para Estrutura organizacional do tipo matri-
a estimativa de tempo pessimista, mais cial Combinação das estruturas organiza-
provável e otimista para a atividade, da cionais funcionais e por projetos, na qual
seguinte forma: os recursos de componentes funcionais
apropriados de uma empresa são tempo-
to + 4(tm ) + t p
te = rariamente atribuídos a projetos em par-
6 ticular.
Estrutura organizacional do tipo por
E projetos Estrutura organizacional na qual
Escopo de trabalho Veja Escopo do projeto. cada projeto tem seu próprio gerente de
Escopo do projeto Todo o trabalho que projeto e equipe de projeto, e todos os
deve ser feito para atingir o objetivo do recursos necessários para realizar um pro-
projeto e obter a satisfação do cliente; es- jeto individual são designados em tempo
copo do projeto; escopo de trabalho. integral para aquele projeto.
Especificação de serviço (ES ou SOW) Evento antecessor Evento no início de uma
Documento que descreve as tarefas, ou atividade (antes da seta) no diagrama de
elementos de trabalho, que o cliente de- rede do tipo diagrama de setas; evento
seja que o fornecedor realize. inicial.
Estimativa de custo Estimativa do custo to- Evento sucessor Evento no final de uma
tal de uma atividade com base nos tipos atividade (depois da seta) no diagrama
e quantidades de recursos necessários de rede do tipo diagrama de setas; even-
para aquela atividade. to final.
Estimativa de duração Tempo total estima- Eventos Pontos interconectados que ligam
do de duração de uma atividade do início as atividades na forma de diagramas de
ao fim, incluindo o tempo de espera as- setas do diagrama de rede. Um evento é
sociado; estimativa de tempo. representado por um círculo.
Estimativa de tempo Veja Estimativa de Exceção Variação em relação às exigências
duração. especificadas pelo cliente, mencionadas
Estimativa de tempo mais provável (tm) pelo fornecedor em sua proposta.
Tempo no qual uma atividade pode ser
F
concluída com mais freqüência sob con-
dições normais. Flutuação Veja Folga total.
Estimativa de tempo otimista (to) Tempo Folga livre ou folga adiantada (FL ou FS)
no qual uma atividade pode ser concluída Período de tempo pelo qual uma ativida-
se tudo correr perfeitamente bem e não de pode ser adiada sem que haja atraso
houver complicações. na data de início mais cedo das atividades
Estimativa de tempo pessimista (tp) Tem- imediatamente posteriores a ela; diferen-
po no qual uma atividade pode ser con- ça relativa entre os períodos de folga total
cluída sob condições adversas, como na para atividades que entram nessa mesma
presença de complicações incomuns ou atividade. Sempre é um valor positivo.
imprevistas. Folga total ou folga de um caminho (FT
Estrutura analítica do projeto (EAP ou ou TS) Se for um valor positivo, período
WBS) Árvore hierárquica de elementos de tempo pelo qual as atividades de um
ou itens de trabalho que serão realizados caminho em particular podem ser adia-
ou produzidos pela equipe de projeto das sem pôr em risco o término do proje-
durante o projeto. to no tempo de conclusão exigido. Se for
Estrutura organizacional do tipo funcio- um valor negativo, é o período de tempo
nal Estrutura organizacional na qual os no qual as atividades de um caminho em
grupos são compostos por pessoas que particular devem ser aceleradas, a fim de
realizam a mesma função, como enge- encerrar o projeto no tempo de conclu-
nharia ou fabricação, ou que possuem são exigido.
Glossário 443
G Método do caminho crítico (CPM) Técnica

de planejamento de rede de atividades.
Gerenciamento de riscos Identificação,
Método do diagrama de precedência
avaliação e resposta aos riscos do pro-
(PDM) Tipo de técnica de planejamento
jeto, a fim de minimizar a probabilidade
de rede.
e o impacto das conseqüências de even-
tos adversos na realização do objetivo do N
projeto.
Gráfico de barras Veja Gráfico de Gantt. Nivelamento de recursos Método para de-
Gráfico de Gantt Ferramenta de planeja- senvolvimento de um cronograma que
mento e programação que exibe as ati- tenta minimizar as flutuações na neces-
vidades de um projeto ao longo de uma sidade de recursos sem estender o cro-
escala de tempo; gráfico de barras. nograma do projeto além do tempo de
conclusão exigido.
I
O
Índice de desempenho de custo (IDC ou
CPI) Medida da eficiência de custo com Objetivo Resultado ou produto esperado de
a qual o projeto está sendo conduzido; um projeto, normalmente definido em
valor agregado acumulado dividido pelo termos de escopo, cronograma e custo.
custo real acumulado. Overhead Porcentagem dos custos diretos
Início mais cedo (IC ou ES) Data de início de um projeto em particular, acrescida da
mais cedo para uma atividade em particu- proposta de um fornecedor para cobrir os
lar; data estimada para início do projeto custos da execução do negócio, como se-
mais a duração estimada das atividades guros, depreciação, gerenciamento geral e
precedentes. recursos humanos; custos indiretos.
Início mais tarde (IT ou LS) Data mais tar-
dia na qual uma atividade em particular
P
deve ser iniciada, para que todo o projeto Pacote de trabalho Item no nível mais bai-
termine na data exigida; data de término xo de qualquer ramificação de uma es-
mais tarde da atividade menos a duração trutura analítica de projeto.
estimada da atividade. Percentual realizado Estimativa na forma
Itens de trabalho Porções individuais de de porcentagem da proporção de traba-
um projeto em uma estrutura analítica lho envolvida em um determinado paco-
de projeto. te de trabalho que foi concluído.
Período de análise Intervalo de tempo no
L qual o desempenho real do projeto será
comparado com o desempenho plane-
Laddering Método para mostrar a relação jado.
de precedência lógica de um conjunto de Planejamento Disposição sistemática de
atividades repetido várias vezes consecu- tarefas para atingir um objetivo, determi-
tivamente. nando o que precisa ser feito, quem irá
fazer, quanto tempo irá levar e quanto
M irá custar.
Matriz de responsabilidades Tabela que Plano-base Plano original, ou esquema, esta-
relaciona as pessoas ou unidades organi- belecendo como o escopo do projeto será
zacionais responsáveis por realizar cada atingido dentro do prazo e do orçamento.
item de trabalho em uma estrutura analí- Plano de contingência Conjunto predefi-
tica organizacional. nido de ações a serem implementadas se
Melhor Oferta Final (MOF ou BAFO) Preço eventos de risco ocorrerem.
final para um projeto, apresentado por um Processo de controle de projeto Veja Con-
fornecedor por solicitação de um cliente trole de projeto.
que está analisando propostas de vários Projeto Esforço para atingir um objetivo es-
concorrentes para o mesmo projeto. pecífico por meio de um conjunto único
444 Glossário
de tarefas inter-relacionadas e a utiliza- Técnica de avaliação e análise gráfica

ção eficaz de recursos. (GERT) Tipo de técnica de planejamento
Proposta Documento, normalmente ela- de rede.
borado por um fornecedor, que esboça Tempo de conclusão exigido Período de
uma solução para se atender a uma ne- tempo ou data na qual um projeto deve
cessidade ou resolver um problema para ser concluído.
um cliente em potencial. Tempo de processamento mínimo (Crash
Time) Menor intervalo de tempo estima-
R do no qual uma atividade pode ser con-
Relação de precedência Ordem na qual as cluída.
atividades devem ser concluídas antes que Tempo normal Duração estimada de tem-
outras atividades possam ser iniciadas. po necessária para realizar uma atividade
Requisitos do cliente Especificações para sob condições normais, de acordo com o
um projeto e/ou atributos de um produ- planejamento.
to ou serviço especificados pelo cliente Tempo real de término (TR ou AF) Tem-
em uma CP. As exigências podem incluir po no qual uma atividade específica é de
tamanho, quantidade, cor, velocidade e fato concluída.
outros parâmetros físicos ou operacionais Término mais cedo (TC ou EF) Data de
que a solução proposta pelo fornecedor término mais cedo para uma atividade
deve conter. em particular; data de início mais cedo
Reserva de gerenciamento Veja Contin- de uma atividade mais a duração estima-
gência. da da atividade.
Risco Possibilidade de que uma circunstân- Término mais tarde (TT ou LF) Data mais
cia indesejada ocorra, podendo resultar tardia na qual uma atividade em particu-
em algum prejuízo. lar deve ser concluída, para que todo o
projeto termine na data exigida.
S
Seleção de projetos Avaliação de neces- V
sidades e oportunidades variadas para Valor agregado (VA ou EV) Valor do traba-
então decidir quais destas devem seguir lho de fato realizado.
adiante como um projeto a ser imple- Valor agregado acumulado (VAC ou CEV)
mentado. Valor do trabalho de fato realizado até um
Sistema de informação (SI ou IS) Sistema ponto de tempo específico; custo orçado
baseado em computador que aceita da- total multiplicado pela porcentagem de
dos como entrada, processa os dados e trabalho estimada para estar concluída.
produz informações para os usuários. Variação de custo (VC ou CV) Indicador
do desempenho de custo; valor agregado
T
acumulado menos o custo real acumulado.
Técnica de avaliação e análise de progra- Variância Medida da dispersão, ou propa-
mas (PERT) Técnica de planejamento de gação, de uma distribuição em relação a
rede. seu valor esperado.

Gestão de Projetos

Загружено:

Сведения о документе

Авторское право

Доступные форматы

Поделиться этим документом

Поделиться или встроить документ

Параметры публикации

Этот документ был вам полезен?

Это неприемлемый материал?

Авторское право:

Доступные форматы

Gestão de Projetos

Загружено:

Авторское право:

Доступные форматы

COPYRIGHT 2007 Cengage Learning Edições Ltda.

, COPYRIGHT 2006 de South-Western, parte da Cengage Learning

Título original: Successful project

1. Administração de projetos I. Clements,

Índices para catálogo sistemático:

Para suas soluções de curso e aprendizado, visite

Para Beth, Tyler, Hannah, Maggie e Grace,

Parte 1 A VIDA DE UM PROJETO 1

1 Conceitos de Gestão de Projetos 2

Decisão de Participar/Não Participar da Concorrência 48

Parte 2 PLANEJAMENTO E CONTROLE DO PROJETO 97

Preparando o Diagrama de Rede 114

7 Controle do Cronograma 190

8 Considerações sobre Recursos 220

9 Planejamento e Desempenho de Custos 240

Parte 3 AS PESSOAS: O SEGREDO PARA O SUCESSO DE UM

12 Comunicação e Documentação do Projeto 346

Comunicação Oral 348

13 Tipos de Organização de Projeto 378

Apêndice A Software de Gestão de Projetos 403

Recursos do Software de Gestão de Projetos 403

Apêndice B Organizações de Gestão de Projetos 412

Apêndice C Sites de Gestão de Projetos na Internet 413

Apêndice D Abreviaturas 415

Referências Bibliográficas 417

Respostas para a Seção Reforce seu Aprendizado 423

No Capítulo 8, Considerações sobre Recursos, discutem-se as limitações dos recursos quan-

Brian M. Kleiner Joseph A. Phillips

Gostaríamos de agradecer a todos com quem trabalhamos e àqueles que participaram

Existem pessoas que fazem acontecer,

Jack Gido é diretor de Desenvolvimento Econômico e de Força de Trabalho

James P. Clements é vice-presidente de Superação Econômica e Comunitária

Os capítulos da Parte 1 introduzem os conceitos de gestão de projetos e de ciclo de vida

• Um projeto tem um objetivo bem definido – um resultado ou produto esperado.

atualizar o sistema de informação de sua gerência, o termo cliente passa a assumir

REFORCE SEU APRENDIZADO

A seguir, estão relacionados alguns exemplos de projetos:

A montagem de uma peça de teatro.

REFORCE SEU APRENDIZADO

O cumprimento bem-sucedido do objetivo do projeto normalmente é limitado por qua-

FIGURA 1.1 Fatores que Limitam o Sucesso do Projeto

Fonte: Cortesia de Dynamics Graphics, Inc.

REFORCE SEU APRENDIZADO

Na realização do projeto, algumas circunstâncias imprevistas podem pôr em risco o cum-

O desafio do gestor de projetos é evitar, prever ou superar essas circunstâncias, a fim de

CICLO DE VIDA DO PROJETO

FIGURA 1.2 Etapas do Ciclo de Vida do Projeto

Identificar Desenvolver Executar o Concluir o

REFORCE SEU APRENDIZADO

O PROCESSO DE GESTÃO DE PROJETOS

2. Divida e subdivida o escopo do projeto em “frações” significativas, ou pacotes de

FIGURA 1.3 Estrutura Analítica de Projeto

Lynn Beth Steve Pat

1.1 1.2 1.3 3.1 3.2 3.3 4.1 4.2

Lynn Keith Andrea Jim Steve Jeff P at Neil

4. Ilustre graficamente as atividades na forma de um diagrama de rede. Esse diagrama

Entretenimento Alimentação Serviços

Jeff Bill Jack

5.1 5.2 6.1 6.2 7.1 7.2 7.3 7.4

Artistas Arquibancada Alimentação Instalações Estacionamento Limpeza Banheiros Segurança

Jeff Jim Bill Chris Steve Tyler Jack Rose

5.2.1 5.2.2 5.2.3 7.2.1 7.2.2 7.3.1 7.3.2

6.2.1 6.2.2 6.2.3

7. Calcule um cronograma e um orçamento para determinar se o projeto pode ser con-