Gerência de Projetos-UnisulVirtual

Universidade do Sul de Santa Catarina
Gerência de Projetos
Disciplina na modalidade a distância
Palhoça
UnisulVirtual
2007
book.indb 1 31/5/2007 14:23:18

Créditos
Unisul - Universidade do Sul de Santa Catarina
UnisulVirtual - Educação Superior a Distância
Campus UnisulVirtual Coordenação dos Cursos Design Gráfico Produção Industrial e Suporte
Avenida dos Lagos, 41 Adriano Sérgio da Cunha Cristiano Neri Gonçalves Ribeiro Arthur Emmanuel F. Silveira
Cidade Universitária Pedra Branca Aloísio José Rodrigues (Coordenador) (coordenador)
Palhoça – SC - 88137-100 Ana Luisa Mülbert Adriana Ferreira dos Santos Francisco Asp
Fone/fax: (48) 3279-1242 e Ana Paula Reusing Pacheco Alex Sandro Xavier
3279-1271 Charles Cesconetto Evandro Guedes Machado Relacionamento com o
E-mail: cursovirtual@unisul.br Diva Marília Flemming Fernando Roberto Dias Mercado
Site: www.virtual.unisul.br Fabiano Ceretta Zimmermann
Itamar Pedro Bevilaqua Higor Ghisi Luciano Walter Félix Cardoso Júnior
Reitor Unisul Janete Elza Felisbino Pedro Paulo Alves Teixeira
Jucimara Roesler Rafael Pessi Secretaria de Ensino a
Gerson Luiz Joner da Silveira Distância
Lauro José Ballock Vilson Martins Filho
Lívia da Cruz (Auxiliar) Karine Augusta Zanoni
Vice-Reitor e Pró-Reitor Albuquerque
Acadêmico Luiz Guilherme Buchmann Disciplinas a Distância
Figueiredo (Secretária de ensino)
Sebastião Salésio Heerdt Luiz Otávio Botelho Lento Tade-Ane de Amorim Ana Paula Pereira
Marcelo Cavalcanti Cátia Melissa Rodrigues (Auxiliar) Andréa Luci Mandira
Chefe de Gabinete da Reitoria Maria da Graça Poyer Carla Cristina Sbardella
Fabian Martins de Castro Maria de Fátima Martins Gerência Acadêmica Deise Marcelo Antunes
(Auxiliar) Patrícia Alberton Djeime Sammer Bortolotti
Pró-Reitor Administrativo Mauro Faccioni Filho Franciele da Silva Bruchado
Marcus Vinícius Anátoles da Silva Michelle D. Durieux Lopes Destri Gerência de Ensino Grasiela Martins
Ferreira Moacir Fogaça Ana Paula Reusing Pacheco James Marcel Silva Ribeiro
Moacir Heerdt Jenniffer Camargo
Campus Sul Nélio Herzmann Logística de Encontros Lamuniê Souza
Onei Tadeu Dutra Presenciais Lauana de Lima Bezerra
Diretor: Valter Alves Schmitz Neto Liana Pamplona
Diretora adjunta: Alexandra Patrícia Alberton Márcia Luz de Oliveira
Raulino Jacó Brüning Marcelo José Soares
Orsoni (Coordenadora) Marcos Alcides Medeiros Junior
Rodrigo Nunes Lunardelli Aracelli Araldi
Simone Andréa de Castilho Maria Isabel Aragon
Campus Norte Graciele Marinês Lindenmayr Olavo Lajús
(Auxiliar) José Carlos Teixeira
Diretor: Ailton Nazareno Soares Priscilla Geovana Pagani
Diretora adjunta: Cibele Schuelter Letícia Cristina Barbosa Rosângela Mara Siegel
Criação e Reconhecimento de Kênia Alexandra Costa Hermann
Cursos Silvana Henrique Silva
Campus UnisulVirtual Priscila Santos Alves Vanilda Liordina Heerdt
Diane Dal Mago
Diretor: João Vianney Vanderlei Brasil Vilmar Isaurino Vidal
Núcleo de Formatura e Eventos
Diretora adjunta: Jucimara
Roesler Jackson Schuelter Wiggers Secretária Executiva
Desenho Educacional
Daniela Erani Monteiro Will Viviane Schalata Martins
Logística de Materiais
Equipe UnisulVirtual (Coordenadora) Jeferson Cassiano Almeida da
Carmen Maria Cipriani Pandini Tecnologia
Costa (Coordenador) Osmar de Oliveira Braz Júnior
Administração Carolina Hoeller da Silva Boeing Eduardo Kraus
Dênia Falcão de Bittencourt (Coordenador)
Renato André Luz Flávia Lumi Matuzawa Jefferson Amorin Oliveira
Valmir Venício Inácio Monitoria e Suporte Ricardo Alexandre Bianchini
Karla Leonora Dahse Nunes
Leandro Kingeski Pacheco Rafael da Cunha Lara Rodrigo de Barcelos Martins
Avaliação Institucional Ligia Maria Soufen Tumolo (coordenador)
Dênia Falcão de Bittencourt Márcia Loch Adriana Silveira
Viviane Bastos Andréia Drewes
Biblioteca Viviani Poyer Caroline Mendonça
Cristiano Dalazen
Soraya Arruda Waltrick Dyego Rachadel
Núcleo de Acessibilidade Edison Rodrigo Valim
Capacitação e Apoio Francielle Arruda
Pedagógico à Tutoria Vanessa de Andrade Manoel
Gabriela Malinverni Barbieri
Angelita Marçal Flores Núcleo de Avaliação da Jonatas Collaço de Souza
(Coordenadora) Aprendizagem Josiane Conceição Leal
Caroline Batista Maria Eugênia Ferreira Celeghin
Enzo de Oliveira Moreira Márcia Loch (Coordenadora)
Cristina Klipp de Oliveira Rachel Lopes C. Pinto
Patrícia Meneghel Vinícius Maykot Serafim
Vanessa Francine Corrêa Silvana Denise Guimarães
book.indb 2 31/5/2007 14:23:23

Apresentação
Bem-vindo!
Parabéns, você está recebendo o livro didático da disciplina

Gerência de Projetos.
O processo de ensino e aprendizagem na UnisulVirtual leva

em conta instrumentos que se articulam e se complementam,
portanto, a construção de competências se dá sobre a articulação
de metodologias e por meio das diversas formas de ação/
mediação.
São elementos desse processo:
O livro didático;
O EVA (Espaço UnisulVirtual de Aprendizagem);
Atividades de avaliação (complementares, a distância e
presenciais).
Os materiais didáticos foram construídos especialmente para
este curso, levando em consideração o seu perfil e as necessidades
da sua formação. Como os materiais estarão, a cada nova
versão, recebendo melhorias, pedimos que você encaminhe suas
sugestões sempre que achar oportuno via professor-tutor ou
monitor.
Recomendamos que antes de você começar os seus estudos,

verifique as datas-chave e elabore o seu plano de estudo pessoal,
garantindo assim a boa produtividade no curso. Lembre: você
não está só nos seus estudos. Conte com o Sistema Tutorial
da UnisulVirtual sempre que precisar de ajuda ou alguma
orientação.
Desejamos que você tenha êxito neste curso!
Equipe UnisulVirtual.
book.indb 3 31/5/2007 14:23:23

book.indb 4 31/5/2007 14:23:23
Mauro Faccioni Filho
Livro didático
Design instrucional
Dênia Falcão de Bittencourt
2ª ed. revista e atualizada
Palhoça
UnisulVirtual
2007
book.indb 5 31/5/2007 14:23:23

Copyright © UnisulVirtual 2007
Nenhuma parte desta publicação pode ser reproduzida por qualquer meio sem a prévia autorização desta instituição.
Edição – Livro Didático

Professor Conteudista
Mauro Faccioni Filho
Design Instrucional
Dênia Falcão de Bittencourt
Projeto Gráfico e Capa

Equipe UnisulVirtual
Diagramação
Evandro Guedes Machado
Revisão Ortográfica
B2B
658.404
F12 Faccioni Filho, Mauro
Gerência de projetos : livro didático / Mauro Faccioni Filho; design instrucional
Dênia Falcão de Bittencourt. 2. ed. rev. – Palhoça : UnisulVirtual, 2007.
218 p. : il. ; 28 cm.
Inclui bibliografia.
1. Administração de projetos. I. Bittencourt, Dênia Falcão de.

II. Título.
Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul
book.indb 6 31/5/2007 14:23:23

Sumário
Palavras do professor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .9
Plano de estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
UNIDADE 1 – Introdução aos projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

UNIDADE 2 – Análise do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
UNIDADE 3 – Planejamento e elaboração . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
UNIDADE 4 – a execução do projeto . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
UNIDADE 5 – Análise e conclusão do projeto. . . . . . . . . . . . . . . . . . . . . . . . 183
Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

Referências . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
Sobre o professor conteudista . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Respostas e comentários das atividades de auto-avaliação . . . . . . . . . . . . 213
book.indb 7 31/5/2007 14:23:23

book.indb 8 31/5/2007 14:23:23
Palavras do Professor
Bem vindo!
Os livros dedicados à gestão de projetos dividem-se

basicamente em dois tipos: aqueles que listam uma
série de técnicas práticas de planejamento, e aqueles que
discutem teoricamente a disciplina de gestão.
Os do primeiro tipo acreditam que simplesmente

aplicando alguma metodologia preconcebida de gestão
será possível gerenciar um projeto com eficiência e
eficácia. Baseiam-se em métodos e técnicas - uma série
imensa de planilhas e relatórios - e mais recentemente

dedicam-se a explicar e implantar ferramentas
computacionais.
Os do segundo tipo analisam a gestão como uma

disciplina capaz de apoiar e beneficiar aqueles que se
dedicam ao planejamento e ao desenvolvimento de
projetos, mas carecem de uma real experiência em
diferentes tipos de projetos, os quais envolvem sempre

um agente essencialmente subjetivo: o ser humano.
Este livro didático explora esse assunto de uma outra

forma. Aqui o foco será essencialmente na aprendizagem
e na discussão que gera um tipo de conhecimento que
pode e deve ser útil aos que se interessam pelo tema.
Neste sentido este não é um livro puramente acadêmico,

com unidades e seções que apresentam teorias e exemplos
desvinculados da realidade e de uma visão aplicada aos
negócios e aos trabalhos práticos. Sem dúvida, muitas
questões aqui colocadas vieram de pesquisas e análises
acadêmicas, porém estão sempre focadas em aplicações.
book.indb 9 31/5/2007 14:23:23

A idéia central desta disciplina é discorrer sobre as principais
teorias de gestão de projetos, mas com o olhar voltado às
aplicações e ao nível estratégico.
A palavra “gestão” está intimamente relacionada à função de

“gerência”, como veremos, e a gerência se assemelha a uma
função operacional voltada ao controle. Mas em projetos isso
não funciona. O melhor foco para a gestão de projetos deve estar
colocado no conceito de liderança, pois a liderança submete a
gestão, e não o inverso.
Com essas palavras iniciais gostaria então de convidá-lo a

essa aventura do conhecimento – o estudo dos projetos, sua
organização, planejamento e, acima de tudo, trabalho de redes
sociais participativas e cooperativas. Bom estudo!
Professor Mauro Faccioni Filho.
book.indb 10 31/5/2007 14:23:24

Plano de estudo
O plano de estudo visa orientar você no desenvolvimento

da disciplina. Ele possui elementos que o ajudarão a
conhecer o contexto da disciplina e a organizar o seu
tempo de estudo.
Ementa da disciplina
O processo de gerência. Modelo PMI. Planejamento do
processo de desenvolvimento. Detalhamento das etapas
de gerência de um projeto. Ferramentas para a gerência
de projeto.
Objetivos
Apresentar os conceitos básicos da área de
gerência de projetos;
Fornecer subsídios para a avaliação de riscos
de um projeto, com ênfase nos projetos de base
tecnológica;
Apresentar técnicas de planejamento, execução e
controle de projetos, formação de equipes e seu
gerenciamento em reuniões;
Descrever um modelo para gerência de projetos;
Verificação dos softwares disponíveis para
auxílio no gerenciamento de projetos;
Utilização de software livre para gerência de
projetos.
book.indb 11 31/5/2007 14:23:24

Conteúdo programático/tempo de dedicação
Unidade 1 - INTRODUÇÃO AOS PROJETOS. (12 h/a)

História
Conceitos
Motivação para o projeto
Tipos de projeto
Unidade 2 - ANÁLISE DO PROJETO (12 h/a)

Avaliação inicial
Requisitos do cliente e solução de problemas
Algoritmo do projeto
Prazo
Viabilidade do projeto
Antecipando e administrando riscos
Ferramenta de apoio para análise e planejamento
Unidade 3 - PLANEJAMENTO E ELABORAÇÃO (20 h/a)

Modelagem do fluxo de atividades
Metodologias de planejamento – Gráfico de Gantt
Metodologias de planejamento – PERT/CPM
Estimativa de recursos e custos
Recursos humanos em projetos
Divisão de tarefas
O modelo PMI
12
book.indb 12 31/5/2007 14:23:24

Unidade 4 - A EXECUÇÃO DO PROJETO (8 h/a)
Preparação e início dos trabalhos
Liderança versus gestão
Tomada de decisões
Reuniões
Gerenciando qualidade
Gestão de conflitos
Simulação, testes e validação.
Unidade 5 - ANÁLISE E CONCLUSÃO DO PROJETO (8 h/a)

Fase de finalização
Plano de contingência
Atendendo as expectativas do cliente
Sobre o sucesso (ou fracasso) do projeto
Equipe e documentação
Lições aprendidas e novas idéias
13
book.indb 13 31/5/2007 14:23:24

Agenda de atividades / Cronograma
Verifique com atenção o cronograma no “EVA”, organize-

se para acessar periodicamente o espaço das disciplinas
cursadas. Lembre-se que o sucesso nos seus estudos depende
da priorização do tempo para a leitura, da realização de
análises e sínteses do conteúdo e da interação com os seus
colegas e professor tutor.
Antes de iniciar a realização das atividades de avaliação,

leia com atenção os critérios de avaliação apresentados pelo
professor tutor no plano de ensino da disciplina no “EVA”.
Não perca os prazos das atividades. Registre no espaço

a seguir as datas-chave com base no cronograma
disponibilizado no EVA.
14
book.indb 14 31/5/2007 14:23:24

Atividades obrigatórias
Avaliação a distância (AD)
Avaliação presencial (AP)

Avaliação final (AF)
Demais atividades (registro pessoal)
Tenha por hábito, usar o quadro para agendar e programar as

atividades relativas ao desenvolvimento da disciplina.
15
book.indb 15 31/5/2007 14:23:24

book.indb 16 31/5/2007 14:23:24
1
UNIDADE 1
Introdução aos projetos
Objetivos de aprendizagem
Ao final desta unidade você terá subsídios para:
Entender como os projetos se desenvolveram na história
da humanidade.
Compreender diferenças entre projetos e atividades
rotineiras e contínuas.
Constatar quais são os motivos que levam à realização
de um projeto.
Aprender os principais conceitos sobre projetos
e gerência, bem como tipos de projeto e suas
classificações.
Seções de estudo
A seguir, apresentam-se as seções para você estudar.
Seção 1 História.
Seção 2 Conceitos.
Seção 3 Motivação para o projeto.
Seção 4 Tipos de projeto.
Após a leitura dos conteúdos, realize as atividades

propostas no final da unidade e no EVA.
book.indb 17 31/5/2007 14:23:24

Para início de estudo

Esta disciplina o convida a aprofundar um assunto que, em
minha opinião, é fascinante: PROJETOS. Você concorda
comigo, não é mesmo?
No entanto, saiba que há muitas idéias equivocadas sobre o que

seriam projetos, e para evitar que você não corra o mesmo risco, o
tema desta unidade é compreender teoricamente qual o conceito
moderno de Projetos partindo de suas raízes históricas.
Há várias diferenças entre projetos e tarefas de rotina, assim

como há diversos tipos de projetos. Neste estudo, você conhecerá
a classificação de acordo com modelos hoje aceitos, e também
as principais tendências sobre gerência de projetos, com atenção
especial ao modelo PMI, que será mais bem descrito ao longo do
livro.
Um fator importante é o da motivação para o projeto, que vai

definir o caminho do seu sucesso, bem como a aderência aos
requisitos do cliente e uma classificação do projeto, muito útil
para seu futuro planejamento. São vários desafios de estudo,
então bom trabalho e boa sorte!
SEÇÃO 1 - História
A palavra “projeto” é muito comum e está presente nos diálogos
de todos os dias. Porém, os conceitos que se formaram em sua
volta diferem de uma pessoa para a outra,
e isso acontece porque o uso
convencional dessa palavra
varia de situação a
situação.
Mas antes de você

começar a aprofundar
o conceito de projeto no
âmbito desta disciplina,
é importante conhecer
de onde veio essa forma
18
book.indb 18 31/5/2007 14:23:24

de trabalho e como tal definição vem se modificando ao longo da

história.
Na história da humanidade o trabalho foi se

organizando lentamente.
Tribos nômades andavam pelo planeta há milhares de anos

buscando alimentos e lutando contra as adversidades. Com a
invenção de alguns artefatos e a domesticação dos animais,
o homem passou de nômade a sedentário, tendo começado a
construir habitações e aglomerados de casas, formando aldeias,
vilas e cidades. O arranjo do trabalho se modificou, e não tendo
mais que buscar o alimento por meio da caça, o homem passou
a produzi-lo e estocá-lo. Alguns passaram a deter mais poder
do que outros, começaram a poupar objetos de valor e terras,
ampliando os domínios terrestres e até mesmo o patrimônio
sobre as questões espirituais.
Por essa época, surgem alguns empreendimentos

feitos para marcar a presença dessas pessoas
poderosas para sempre sobre a Terra.
Todos se lembram das pirâmides do Egito, obras
realizadas para sepultar os faraós, considerados
deuses. Com esse propósito específico de
sepultamento, a pirâmide era encomendada pelo
próprio faraó (que iria usá-la após a morte!) e então
“projetistas” e construtores desenvolviam seu desenho
e passavam a executar a obra. O prazo da execução
era aproximadamente o da duração da vida do faraó,
ou preferivelmente menor, obviamente. Milhares de
homens formavam as equipes e literalmente eram
“usados” na construção, quebrando e carregando
pedras até a exaustão.
Unidade 1 19
book.indb 19 31/5/2007 14:23:24

Figura 1.1 - As três pirâmides do Egito, dos Faraós Quéops, Quéfren e

Miquerinos.
Além dos faraós muitos homens ricos encomendavam
suas próprias pirâmides, cada um na medida das
suas riquezas. Muitas não ficavam prontas a tempo,
e vin ham então servir para o sepultamento de
alguma outra pessoa. As pirâmides eram tipicamente
“projetos”.
Uma das mais interessantes e importantes obras já
feitas pelo homem começou a ser construída 685
anos antes da Era Cristã. As Grandes Muralhas da
China tiveram seu início com a pretensão de defesa
de diferentes reinos, naquela época em luta pela
expansão dos seus territórios (Courau, 2004). Não
havia a China como tal como você conhece hoje,
mas sim um conjunto de sete reinos em combate,
todos buscando conquistar e anexar os vizinhos.
Um desses reinos se chamava Qin (origem do nome
atual da China) e foi comandado por Zheng, que por
volta de 240 a 220 AC conseguiu vencer e anexar
os outros reinos, unificando todos eles. E em 220
AC decidiu realizar essa obra gigantesca, ligando os
trechos de muralhas existentes e criando, de fato,
as Grandes Muralhas da China. Com o objetivo de
separar o país dos bárbaros, e internamente definir a
unidade da nação e a civilização, a obra teve um prazo
de aproximadamente 10 anos de construção, uma
extensão de mais de 6.000 quilômetros de muros com
altura de até 16 metros e fortificações para soldados
a cada 60 metros, recursos humanos da ordem de
centenas de milhares de operários em regime de
trabalho forçado e um plano de produção rígido (na
verdade, cruel). Esse é um típico projeto.
Esses são exemplos de grandes projetos da antiguidade que

mudaram a história da humanidade e a maneira dos homens
agirem uns em relação aos outros e em relação à natureza.
20
book.indb 20 31/5/2007 14:23:24

Pessoas envolvidas nesses projetos começaram a perceber algumas

características típicas de um projeto, que eram diferentes, por
exemplo, de uma tarefa rotineira como a manutenção de um
dique, o dia a dia das batalhas, ou as tarefas administrativas de
condução da política imperial romana ou chinesa. Projetos têm
objetivos definidos e prazo de conclusão, e para que isso aconteça
com sucesso é preciso conduzir, coordenar e controlar um projeto
e as pessoas que o integram.
Talvez o primeiro livro sobre o assunto tenha

sido “An Essay on Projects” (“Um ensaio sobre
projetos”), escrito por Daniel Defoe em 1697
(Cleland, 2004).
Um pouco depois, durante o século 19, os governos dos países

mais desenvolvidos começaram a contratar grandes projetos
de infra-estrutura, tais como ferrovias, pontes, embarcações,
etc., demandando enormes esforços das companhias para a
seu execução, com valores financeiros e prazos pré-definidos.
Decisões importantes deviam ser tomadas nos projetos, para que
atendessem às solicitações desses grandes clientes, e tais decisões
eram gerenciais, administrativas. Não era mais possível escravizar
milhares de homens para construir uma estrada, como tantas
vezes na história já tinha acontecido. E também não havia fundos
ilimitados. Além disso, a gerência desses projetos tinha que
seguir algum tipo de planejamento.
Um cientista da administração surge nessa época e começa

a estudar detalhadamente o trabalho, mostrando que a
produtividade pode ser aumentada se o trabalho for dividido em
tarefas pequenas e distintas. Seu nome é Frederick Taylor (1856-
1915), e ele é considerado o pai da ciência da administração
(Sisk, 2004). Com a sua contribuição, a indústria pôde modificar
seu modo produtivo e deslanchar para aquilo que se conhece
hoje: em vez de um trabalhador executar todas as tarefas até
concluir determinado produto, ele se ocupa apenas de uma tarefa,
especializando-se nela. Com isso, a produtividade aumenta e
os produtos são feitos em série. Fundamental para a revolução
industrial em curso, a contribuição de Taylor também teve seu
lado negativo, transformando o trabalhador numa espécie de
máquina, de engrenagem dentro do processo produtivo, que tem
Unidade 1 21
book.indb 21 31/5/2007 14:23:25

sido sempre muito criticada e satirizada, como no filme “Tempos

Modernos” de 1936 de Charlie Chaplin – o Carlitos.
Junto com Taylor trabalhava Henry Gantt (1861-1919), que

estudou em detalhes as operações associadas a um trabalho,
decompondo-as em tarefas. Para ver as diversas tarefas em
seqüência, e como elas vão se sucedendo até o final de um
determinado projeto, Gantt inventou um gráfico constituído de
barras, sendo que cada barra representa uma tarefa e seu tamanho
representa uma duração.
Os gráficos de Gantt ficaram famosíssimos e até

hoje são usados para gerenciar projetos.
Você estudará esses gráficos em detalhe mais à frente nesta

disciplina, e poderá conferir o quanto estes poderão ajudá-lo a
gerenciar seus projetos. Na figura a seguir, veja um exemplo de
gráfico de Gantt.
Figura 1.2 – Exemplo de gráfico de Gantt.
O reconhecimento do campo de conhecimento

denominado Gerência de Projetos.
Durante a Segunda Guerra Mundial, muitos projetos

tecnológicos foram desenvolvidos pelos militares dos países em
luta. Com o fim da guerra, evidenciou-se a existência de um
campo do conhecimento específico da administração de projetos,
que ficou conhecido em inglês por “project management”, e em
22
book.indb 22 31/5/2007 14:23:25

português por gerência de projetos, ou gerência de projetos. A

maior associação mundial de engenheiros eletrônicos e eletricistas
– o IEEE, Institute of Electrical and Electronic Engineers – criou,
em 1954, a revista Transactions on Engineering Management
especialmente para discutir temas relacionados à gerência
de projetos e produção em engenharia, que tem influenciado
consideravelmente a área.
Também nos anos 50 surgem dois métodos ( CPM e PERT )

que se tornaram muito importantes na “gerência de projetos”,
disciplina que passou a fazer parte de todos os currículos de
Administração e Engenharia de Produção desde então (Prado,
1998).
O primeiro surgiu na empresa Du Pont em 1957,

com o título de Método do Caminho Crítico – CPM
(iniciais do título em inglês Critical Path Method). A
empresa buscava melhorar suas técnicas de planejamento
e controle de projetos de engenharia, e o método fez
enorme sucesso desde o início.
Quase simultaneamente a marinha americana lançou
um projeto complexo para a construção de submarinos
atômicos, o projeto Polaris. Devido à complexidade
do projeto, ao relacionamento de diversas empresas
(eram mais de 9.000 empreiteiros!), e à complexidade
tecnológica envolvida, um sistema de planejamento
e controle precisava ser desenvolvido. Esse sistema
foi criado em 1958 e denominado PERT (Program
Evaluation and Review Technique), que significa “técnica
de avaliação e revisão de programas/projetos”.
Na época, uma pesquisa foi realizada nos EUA para verificar
como se comportavam os projetos governamentais e privados
com relação ao que era planejado e ao efetivamente realizado. O
quadro a seguir mostra os desvios encontrados (Prado,1998).
Tabela 1.1 – Desvios no planejamento.

Desvio entre o Planejado e o Realizado
Projeto Desvio de tempo Desvio de custo
Governamental / militar 40 a 50% 100 a 200%
Privado 40% 70%
Unidade 1 23
book.indb 23 31/5/2007 14:23:25

Esses dados foram divulgados e criaram polêmica. Projetos

governamentais podiam superar em até 200% os custos
inicialmente estimados! No entanto, com o uso do PERT, o
projeto Polaris foi realizado com sucesso – dentro do orçamento
e em apenas três anos. A partir daí, os métodos PERT e CPM
acabaram se fundindo e assumindo inclusive o formato de
Diagrama de Precedências, técnica desenvolvida na França em
1964 (Prado,1998). Você irá estudá-lo e exercitá-lo no decorrer
desta disciplina.
A evolução dos sistemas computacionais, na

segunda metade do século XX, é que vai contribuir
para a melhoria dos métodos de gerência de
projetos.
Mesmo porque os próprios sistemas computacionais são

desenvolvidos na forma de projetos, e por isso demandam
técnicas de planejamento e controle específicos.
Algumas normas começaram a ser escritas para a gerência de

projetos, e nos EUA foi criado o “Instituto de Gerência de
Projetos” – PMI (Project Management Institute), o qual tem sido
responsável pelas mais recentes e importantes contribuições nesse
campo, especialmente o livro “Guide to the Project Management
Body of Knowledge”, conhecido como PMBOK (PMBOK,
2004). Você irá estudar o modelo definido por esse instituto nas
próximas unidades.
Figura 1.3 – Logo do instituto PMI e fac-símile da capa da 3ª. Edição do PMBOK.
24
book.indb 24 31/5/2007 14:23:25

Uma alternativa aos métodos normatizados pelo PMBOK

foi apresentada por Eliyahu Goldratt em 1997, com o nome
de CCPM – Critical Chain Project Management, que pode
ser traduzido como “gerência de projetos pelo encadeamento
crítico” (RAZ, 2004). Isso demonstra o quanto ainda está em
desenvolvimento a área da gerência de projetos.
Mas quem pensa que o uso de gráficos de Gantt, Caminho

Crítico, PERT, CCPM e outros métodos resolveram o problema,
infelizmente está enganado. No ano de 1998, The Standish Group
realizou uma pesquisa nos EUA e descobriu que muita coisa
estava fora do lugar. Conforme reportado pela empresa Process
Quality Associates Inc., de acordo com alguns resultados contidos
no quadro abaixo, procure ver o quanto ainda há por fazer.
Tabela 1.2 – Estatísticas apresentando problemas típicos de projetos.
Desafios e sintomas típicos de projetos Média nacional EUA (1998)

Atraso Apenas 44% dos projetos são concluídos no prazo.
Na média os projetos costumam atrasar em até
222% do prazo programado.
Acima do custo estimado. 189%
Não atingem satisfatoriamente os requisitos 70% dos projetos
técnicos planejados.
Cancelados antes do término. 30% dos projetos
A rápida evolução da computação, especialmente da década de

1990 em diante, e também das tecnologias da comunicação e
informação, onde a Internet é o maior símbolo, representa um
novo desafio. É necessário criarmos métodos capazes de auxiliar
a gerência de projetos, de um lado, e fazer com que tais métodos
não sejam, em si mesmos, empecilhos burocráticos à dinâmica do
trabalho.
Uma vez compreendida a história da área gerência de projetos,

a próxima seção abordará o estudo de alguns conceitos
introdutórios relativos à matéria em exame.
Unidade 1 25
book.indb 25 31/5/2007 14:23:26

SEÇÃO 2 - Conceitos
Antes de você começar a interagir e estudar o conceito de
Gerência de Projetos, é importante entender algumas definições,
tentando evitar equívocos ou interpretações errôneas.
2.1. O que é projeto?

A primeira palavra importante a considerar é, obviamente,
“projeto”. No histórico das grandes obras e empreendimentos
humanos que você acompanhou na seção anterior, pôde perceber
alguns elementos em comum: prazos, objetivos, custos, recursos.
Mas a importância desses componentes foi mudando com o
tempo.
Por exemplo, o prazo de construção das pirâmides

deveria ser menor que o tempo de vida do faraó. Mas
como isso não podia ser determinado, muitas vezes
o serviço ultrapassava do prazo. Na construção das
Muralhas da China ninguém se importava com as
equipes de construtores. Morriam trabalhando e eram
substituídos depois de se exaurirem, ou seja, ninguém
se importava com os recursos humanos.
Com o passar das eras e chegando já nos tempos modernos,

pôde-se verificar que os objetivos ficaram mais claros e mais
especializados, os prazos cada vez mais curtos, os custos sempre
maiores, e os recursos cada vez mais escassos.
Conforme Antônio Houaiss, em seu dicionário de língua

portuguesa (Houaiss, 2004), projeto pode ser definido como:
idéia, desejo, intenção de fazer ou realizar (algo), no

futuro; plano; descrição escrita e detalhada de um
empreendimento a ser realizado; delineamento,
esquema.
26
book.indb 26 31/5/2007 14:23:26

Neste livro foi adotada uma visão voltada à gerência de projetos, a

qual está definida pelo Project Management Institute como:
Um projeto é um conjunto de tarefas, arranjado numa

seqüência ou relação definida, que produz um efeito
ou saída pré-definida. Um projeto sempre tem um
começo, meio e um final.
(“A project is a series of tasks, arranged in a defined
sequence or relationship, that produce a pre-defined
output or effect. A project always has a start, middle,
and an end.”)
É importante ainda considerar

que a visão de projeto neste livro
compreende os empreendimentos
voltados às áreas de tecnologia, como
software e engenharia, por exemplo,
e de certa forma isso os diferencia
de outros tipos de projeto, como é o
caso de uma campanha política, ou o
projeto de salvação das baleias, dar a
volta ao mundo numa bicicleta, etc.
Também é importante ressaltar que
o projeto tem um ciclo de vida bem definido, pois “um projeto
sempre tem um começo, meio e um final”.
Qual é a diferença entre projeto e tarefas de rotina

/ atividades contínuas?
Projetos não são empreendimentos de rotina, são

empreendimentos completos e independentes (Keeling, 2002),
com recursos e administração próprios.
Para exemplificar essa questão, veja na tabela a

seguir um determinado campo de trabalho ou área
de atividades humanas relacionado a um tipo de
projeto, bem como a uma atividade rotineira (que não
é projeto).
Unidade 1 27
book.indb 27 31/5/2007 14:23:26

Tabela 1.3 – Exemplos comparativos entre atividades de rotina e projetos.
Área Exemplo de projeto Exemplo de tarefa de rotina ou

atividade contínua
Culinária Lançamento de um restaurante Administração do restaurante temático
temático
Construção civil Desenhar e construir um prédio Manter e operar o sistema elétrico e de
comercial automação do prédio
Eletrônica Desenvolver novo tipo de Construir telefones celulares
condensador eletrônico
Agricultura Pesquisar planta resistente a Plantar e colher as safras
determinado tipo de praga
Software Pesquisar novo sistema de Suporte técnico aos usuários de
reconhecimento de fala determinada plataforma
Pelo quadro se percebe que, enquanto os projetos

têm um objetivo preciso, fácil de medir e um resultado
previsível, as atividades contínuas são planejadas a
longo prazo, o controle pode mudar bastante durante
o tempo, sempre procurando novas oportunidades
e mesmo outros resultados, diferentes daqueles
pensados no início.
Lançar o restaurante, por exemplo, tem apenas um
resultado: a sua inauguração. Porém sua operação
pode trazer resultados tão diferentes quanto a
mudança dos pratos, variações de cardápio conforme
o gosto dos clientes, diminuição ou aumento da
equipe conforme as vendas, mudança de gerentes, e
assim por diante.
2.2. Qual é o conceito de Gerência?

Conforme Houaiss (2004), em seu dicionário de língua
portuguesa, gerência pode ser definida como: “ato ou efeito de
gerir; administração, gerência”
Uma característica de muitas disciplinas dedicadas à gerência

de projetos, e da maioria dos livros sobre o assunto, é que eles
se dedicam a fornecer ao estudioso um conjunto de ferramentas
e metodologias, modelos de planilhas, softwares e outros
28
book.indb 28 31/5/2007 14:23:26

dispositivos, dando a entender que isto é

o que basta para uma boa gerência. No
entanto, disponibilizar e ensinar a usar
ferramentas e métodos de gerência é um
assunto estritamente operacional, e não
estratégico. Compreendo que a simples
gerência de um projeto pode ser feita
com o uso de ferramentas de apoio,
mas o sucesso de um projeto depende
de liderança e cooperação, assuntos que
extrapolam, e muito, o campo operacional.
Desta forma, neste livro, busque olhar a palavra “gerência”

visando ir além da gerência operacional, tentando encontrar as
brechas para um trabalho de liderança e cooperação, sempre
voltadas a uma visão abrangente e estratégica do projeto.
A gerência está associada à idéia de controle, de administração.

Para Page-Jones (1990), a gerência de projetos está associada a
cinco atividades:
planejar o projeto,
organizar todos os recursos,
integrar os diversos elementos durante a execução do
projeto,
medir o andamento das atividades e
revisar o plano para corrigir eventuais discrepâncias,
para alcançar o objetivo do projeto.
A gerência de projetos compreende as funções

de planejamento, organização de recursos,
distribuição e comunicação das tarefas às pessoas
da equipe, com monitoramento constante das
atividades e motivação do grupo para a conquista
do objetivo pré-definido.
Para o estudo desta disciplina, adote uma definição mais

genérica, que engloba essas atividades, pois assim está sendo
compreendida atualmente a função de gerência em projetos.
Unidade 1 29
book.indb 29 31/5/2007 14:23:26

2.3. Qual é a definição de Prazo?

Prazo é a palavra do momento. Há uma preocupação enorme
com prazos, pois os recursos são sempre escassos, e colocar um
produto no mercado antes do que a concorrência pode ser o fator
do sucesso.
E justamente nos prazos é onde acontecem os maiores erros de

previsão. Por quê?
Você irá estudar isso mais adiante. Por enquanto, reflita sobre a
seguinte definição de prazo:
Considerando o objetivo do projeto, prazo

é o tempo disponível para se chegar ao
resultado.
2.4. Como é a definição de recursos na abordagem desta disciplina?

É comum confundir recursos com dinheiro, ou recursos
com custos. Porém, extraia deste estudo uma definição mais
abrangente, pois as condições financeiras possibilitam obter
diversos recursos, mas não todos. Veja o caso em que se precisa
de um determinado especialista, um engenheiro de grandes
estruturas, por exemplo. Mesmo com dinheiro para contratá-lo, é
possível que não exista alguém com disponibilidade.
Uma definição útil é:
Recursos são as condições econômicas, materiais,

equipamentos e pessoal necessário para
desenvolver determinado projeto a contento.
30
book.indb 30 31/5/2007 14:23:26

2.5. E a definição de custos?

Idéias maravilhosas, projetos visionários, nada disso pode ser
concretizado se não houver condições de pagar os custos de
desenvolvimento. Recursos são necessários, os equipamentos
custam dinheiro, materiais de consumo também, cada vez mais
caras são as horas de trabalho das pessoas e dos especialistas, em
particular.
Custos são os gastos financeiros necessários

para que todos os outros recursos sejam
adequadamente distribuídos no projeto, desde o
início até a sua conclusão.
2.6. E a Equipe de trabalho?

O principal elemento de um
projeto, independentemente
de sua dimensão ou
importância, é o conjunto
de pessoas responsáveis pela
sua consecução. Impossível
seria construir as muralhas
da China sem os milhares de
operários que lá estiveram, e no
entanto, eles eram considerados
descartáveis, trabalhavam como
escravos. Com o avanço da civilização isso mudou, e além de
imprescindível num projeto, o homem passou a ter “valor”.
Mas projetos (a não ser os muito pequenos) não são para um

homem só. Precisam constituir grupos, com atividades e
responsabilidades diversas, interagindo todo o tempo e em
busca de um objetivo comum. Com isso chega-se ao trabalho
cooperativo. Em projeto, é imprescindível a presença de grupos
de pessoas trabalhando de forma cooperada. Nesta disciplina,
conceba como conceito de equipe de projeto o seguinte:
Unidade 1 31
book.indb 31 31/5/2007 14:23:26

Grupo de indivíduos dedicados ao projeto, com

funções e responsabilidades bem definidas,
trabalhando em regime de cooperação e focados
no sucesso da empreitada.
SEÇÃO 3 - Como se dá a motivação para o projeto?

Se um projeto tem origem numa idéia, por causa de uma
necessidade social, comercial ou por um novo conhecimento
tecnológico disponível, para que ele possa crescer e chegar à etapa
do desenvolvimento e ir até o final, chegando a um resultado
próximo do esperado, ele precisa de uma motivação que o
alimente.
Diversas são as motivações possíveis, desde o empenho

unicamente pessoal até um contrato abrangente e inviolável.
Você irá estudar nesta disciplina algumas dessas motivações,
sabendo antecipadamente que muitas vezes elas estão mescladas
no dia a dia dos projetos, umas com mais força, outras menos.
São exemplos de motivação:

Alguém em uma pequena empresa teve a “visão”
de um novo produto, que acredita ser capaz de
alterar o futuro de sua empresa. Essa visão passa a
ser então um guia e um objetivo, capaz de motivar
e ajustar cada momento de desenvolvimento do
projeto que é então gerado. Os líderes são muitas
vezes movidos por essas “visões”, que são perseguidas
constantemente até o final, sem descanso. Tal visão
pode surgir na busca de resolver um problema,
pessoal ou empresarial.
Para uma determinada empresa que vem perdendo
posições no mercado, o projeto de um novo produto
pode nascer como a reação ao produto concorrente
que vem se destacando. Essa “reação” comercial
motiva o nascimento e a execução do projeto,
geralmente com forte pressão por resultados e prazos.
É uma motivação reativa.
32
book.indb 32 31/5/2007 14:23:27

Por outro lado, a empresa ativa busca sua ampliação

no mercado não apenas pela reação ao que já
surgiu, mas pela criação de novos produtos. Essa
cultura criativa define as empresas que lideram
o mercado, pois constantemente estão criando
produtos inovadores ou lançando novas formas de se
relacionar com seus clientes, o que acaba mudando
o comportamento geral do mercado e as favorece.
Como não podia deixar de ser, as empresas criativas
são mais raras do que as reativas, e ambas são
motivadas pela competição.
Nos casos anteriores há uma motivação que é o
denominador comum: sucesso da empresa. Esse
motivador movimenta o mundo do capital e está
na base do crescimento econômico. Também há o
motivador que é o sucesso pessoal, perseguido não
pelas empresas, mas pelos indivíduos.
Na base do sucesso pessoal, um dos grandes
motivadores é o ganho financeiro. O prêmio em
dinheiro dá motivação para perseguir o projeto até
o final, mesmo que a pessoa muitas vezes não dê
valor algum ao projeto em si, mas simplesmente à
remuneração.
Fora do campo puramente pessoal ou empresarial, o
progresso social pode ser um grande motivador no
desenvolvimento de projetos. Parece ser esse o caso
dos projetos ecológicos e ambientalistas, onde um
determinado grupo social, interessado em melhorias
locais ou regionais, empreende projetos de caráter
específico. Sindicatos, associações, organizações civis
de interesse público e partes do governo também são
geradores de projetos especiais, voltados ao bem-
estar social.
Unidade 1 33
book.indb 33 31/5/2007 14:23:27

Como se dá o nascimento de projetos de

Tecnologia?
Os projetos das áreas tecnológicas nascem de uma sucessão

de avanços no conhecimento humano. Tais conhecimentos
vão se acumulando, e uns se servem dos outros para avançar
sempre mais, seja questionando-os, seja aprimorando-os e
transformando-os.
Acompanhe a figura a seguir, inspirada no trabalho de Jay Paap

(2004), que mostra um modelo de inovação tecnológica.
Figura 1.4 - Um modelo de inovação tecnológica.

Necessidades que surgem no negócio, ou na vida diária das
pessoas, ou de renovação do mercado, enfim, problemas que
surgem todos os dias, estão constantemente nos desafiando a
buscar novas soluções. Quando alguém aceita esse desafio, e
simultaneamente há conhecimentos científicos e tecnológicos
disponíveis, idéias surgem. Uma criteriosa seleção dessas
idéias pode levar ao desenvolvimento de novos produtos ou
novos processos que, se alcançarem sucesso, serão amplamente
utilizados e difundidos.
A transformação dessas idéias em produtos ou processos é

considerada uma Inovação Tecnológica, e pode ser algo tão
simples como uma nova maneira de assentar tijolos numa
construção, ou tão complexa quanto lançar uma nova linguagem
de programação.
Cada ciclo tecnológico tem origem numa

inovação.
34
book.indb 34 31/5/2007 14:23:31

A inovação tecnológica pode ser

caracterizada como a primeira vez em
que se utiliza um determinado produto,
processo, sistema ou serviço, sejam
novos ou melhorados, introduzidos
num determinado mercado, ou numa
produção. O centro de gravidade da
inovação tecnológica é a empresa.
Os processos inovadores são bastante

complexos, pois estão ligados ao desenvolvimento de projetos nas
áreas de engenharia e tecnologia avançadas, e com isso podem
apresentar as seguintes incertezas:
são irregulares, quando há diferentes etapas de trabalho,

possibilidades de retrocessos, re-análises constantes, etc;
são de alto risco, quando não há certeza de que
corresponderão ao que originalmente foi imaginado;
são excessivamente lentos ou prolongados, com resultados
que demoram para chegar ao mercado, muitas vezes
comprometendo sua receptividade.
Como melhor conduzir os projetos de inovação

tecnológica?
Projetos de inovação tecnológica, nas empresas, podem assumir

a metodologia científica, onde quatro passos críticos estão
colocados para a solução de um problema:
1. Definir o problema, ou seja, caracterizar adequadamente

os seus limites, saber o que se pretende resolver com a
maior exatidão possível.
2. Descrever o problema, determinando onde está inserido

e com que outros fatos o problema está relacionado. A
descrição do problema deve ser feita com o máximo de
detalhamento.
Unidade 1 35
book.indb 35 31/5/2007 14:23:32

3. Formular hipóteses de solução, que possam ser estudadas

e testadas dentro do escopo do trabalho. Nessa etapa será
criado um plano de trabalho.
4. Executar o projeto de pesquisa propriamente dito,

verificando as hipóteses, testando as possibilidades,
confirmando e rejeitando soluções intermediárias, a fim
de obter os resultados esperados.
Uma vez compreendidos alguns conceitos introdutórios ao estudo

da área de Gestão de projetos, na próxima seção conheça quais
são os tipos de projetos.
SEÇÃO 4 - Tipos de projeto?

Os projetos podem ser classificados em diversas categorias, e
essa classificação vai variar conforme os interesses comerciais,
científicos e industriais, ou então conforme os graus de
dificuldade, ou mesmo conforme o ambiente em que se
desenvolvem.
A seqüência de estudo sugere que você conheça algumas dessas

possíveis divisões, e ao final propõe a sistematização dessas
classificações, de modo a facilitar a visão estratégica sobre tipos
de projetos.
Como os projetos podem ser classificados? Quais

são os tipos existentes?
Os projetos podem ser classificados:
De acordo com o que você estudou nas Seções 1 e 2 desta

Unidade, eles podem ser classificados quanto à natureza
científica e tecnológica, e neste sentido podem ser, a
grosso modo, divididos nos seguintes tipos:
a) Projetos de Pesquisa – são os projetos
científicos, que geralmente acontecem em
universidades e centros de pesquisa, e nascem
da idéia de pesquisadores e linhas de pesquisa já
36
book.indb 36 31/5/2007 14:23:32

em andamento; podem ser de pesquisa básica,

quando direcionados a resolver problemas
genéricos e teóricos, sem aplicação prática em
vista, ou de pesquisa aplicada, quando voltados a
usar uma teoria em alguma nova aplicação, não
necessariamente útil de imediato;
b) Desenvolvimento Tecnológico – ao contrário
dos projetos científicos, os projetos de
desenvolvimento tecnológico nascem da idéia de
empresários e engenheiros, e estão orientados
diretamente ao mercado, buscando introduzir
inovação tecnológica, seja em produtos
diretamente para a venda, ou em processos
de produção ou comercialização dentro das
empresas; por serem projetos de inovação, estão
fortemente associados ao conhecimento científico
gerado em pesquisas básicas e/ou aplicadas;
c) Engenharia – são os que se baseiam em
conhecimentos e tecnologias dominadas, e
estão voltados a construir protótipos e produtos
com aplicação bem definida; os projetos de
engenharia mais comuns que conhecemos são os
da construção civil.
Outra forma de dividir os projetos está relacionada à sua origem

institucional. Neste caso, não estamos fazendo distinção entre
ciência, tecnologia ou engenharia, mas sim quanto ao tipo de
instituição que os originou. Uma possível divisão desses projetos
seria a seguinte:
a) Comerciais – são os projetos que nascem dentro das

empresas buscando diferencial competitivo no mercado;
pode ser a idéia de um novo produto, baseada em
estatísticas e pesquisas realizadas junto ao consumidor,
ou a necessidade de modificação de um processo de
venda ou de produção, com foco em melhoria comercial;
lançamentos de novas embalagens, novas versões de
software e novas formas de entrega para o consumidor
são exemplos desse tipo;
Unidade 1 37
book.indb 37 31/5/2007 14:23:32

b) Industriais – muito próximos dos projetos do tipo

“comercial”, também estão objetivando diferencial
competitivo; no entanto são desenvolvidos no interior
da indústria buscando melhorias no processo produtivo
do chão de fábrica, sem um relacionamento direto com
Chamamos de chão de perspectivas comerciais (apesar de estar claro que tais
fábrica o ambiente onde melhorias vão colaborar na qualidade de todo o sistema);
geralmente estão instaladas são projetos que vão desde uma modificação de leiaute
as máquinas da indústria, e
no chão de fábrica, passando por projetos de introdução
onde o processo operacional
de produção acontece; não
de automatismos em máquinas até a criação de novas
inclui, por exemplo, as áreas máquinas-ferramenta;
de administração, vendas,
compras e projetos. c) Governamentais – os governos são grandes geradores
de projetos, e alguns envolvem toda a sociedade e podem
até mesmo mudar os rumos de uma região ou de um
Do inglês lay-out, representa
país; em tese, nascem das necessidades sociais e de visões
um esboço ou modelo estratégicas para buscar suprir tais necessidades, mas o
genérico de disposição de que se vê geralmente são as vaidades políticas e a visão
peças, móveis e equipamentos limitada como geradores de tais projetos, que muitas
num ambiente.
vezes acabam em gastos inúteis do dinheiro público; mas
certamente há também os projetos de sucesso, muitas
vezes polêmicos, que são capazes de modificar todo
Máquina-ferramenta é aquela
que é usada para fabricar
um panorama histórico; e há também os projetos de
outras máquinas, mais pequeno porte, igualmente importantes, que mudam, por
especificamente para dar exemplo, o trânsito de um bairro ou introduzem ali uma
forma a objetos sólidos como área verde e de preservação;
madeira e metal, os quais
serão usados como peças em d) De fomento – projetos de fomento são também, em
outras máquinas.
geral, governamentais, mas se distinguem um pouco
daqueles por estarem voltados a desenvolver algum
aspecto da economia e/ou tecnologia, ou seja, buscam
criar ambientes favoráveis para que a iniciativa privada
se desenvolva; importantíssimos por sua característica de
apoio estrutural, um bom exemplo desse tipo de projeto
é a criação de parques tecnológicos e incubadoras de
empresas, fomentadores de novos negócios e de inúmeros
outros projetos de inovação dentro dessas empresas ou
idéias nascentes (cabe aqui ressaltar que a Unisul criou
e mantém uma incubadora, com o apoio do governo de
Santa Catarina);
38
book.indb 38 31/5/2007 14:23:32

e) Acadêmicos – são os projetos que se desenvolvem

dentro do ambiente das instituições educacionais, tais
como monografias e teses, bem como softwares e outros
produtos, caracterizando-se por uma relativa distância
das aplicações industriais.
É possível fazer uma separação de tipos de projeto também

quanto ao seu impacto no conhecimento ou no mercado,
independente de sua origem ou de sua natureza técnica. Essa
divisão pode ajudá-lo a ver determinado projeto em relação à sua
“ambição”:
a) Impacto tecnológico ou Breakthrough – tipo de projeto

que se caracteriza por resultar em considerável impacto
em uma tecnologia ou em um mercado, modificando
hábitos de consumidores e alterando completamente
a finalidade da tecnologia anterior; é um tipo raro
de projeto, porque intrinsecamente é de risco, não se
sabendo determinar se terá sucesso, o qual muitas vezes
nem era esperado; veja-se o exemplo da introdução dos
compact discs no mercado musical, que praticamente
aboliu o uso de discos de vinil e fitas magnéticas, ou o
caso do uso da transmissão por rádio na telefonia, que
em poucos anos está mudando completamente o cenário
das telecomunicações mundiais;
b) Plataforma ou sistema – projeto que envolve inúmeros

conhecimentos e módulos diferentes, geralmente
composto por uma série de pequenos projetos (os
derivados), que serão depois arranjados num sistema
único e maior; tipicamente é multidisciplinar, envolvendo
conhecimentos diversos e várias áreas; o atual projeto de
desenvolvimento do sistema de televisão digital brasileiro
é um exemplo;
c) Isolados – são aqueles projetos independentes, não

vinculados a um sistema e nem derivados de uma
necessidade de melhoria; basicamente são os projetos
criados por indivíduos (como o desejo de uma casa, por
exemplo) ou de uma pequena empresa para lançar um
novo produto no mercado;
Unidade 1 39
book.indb 39 31/5/2007 14:23:32

d) Projetos Derivados – caracterizam-se por ser projetos

pequenos e de prazo curto, derivados de outros maiores
ou de requisições de melhorias em sistemas já em
funcionamento regular; são exemplos as criações de
novos leiautes de embalagem, um determinado móvel ou
novo dispositivo em uma máquina-ferramenta.
Como definir o tipo de projeto tecnológico?
Recentemente Dov Dvir et al. (2004) desenvolveram e passaram

a aplicar um esquema genérico para definir tipos de projetos.
Esse esquema, ou framework, foi denominado de “Modelo UCP”
(iniciais de Uncertainty, Complexity e Pace, que pode ser traduzido
aqui por Incerteza, Complexidade e Prazo), sobre o qual é
possível classificar os diversos tipos de projetos tecnológicos.
O desenho da figura a seguir mostra esse modelo como uma

configuração de três dimensões, onde cada eixo representa uma
das variáveis, tendo cada projeto uma posição nesse espaço,
conforme sua posição relativa em cada eixo.
Figura 1.5 – Modelo UCP para classificação de projetos (DVIR et al., 2004).
Devido a sua utilidade na definição dos tipos de projeto, a seguir

você irá acompanhar um pouco mais o modelo de Dov Dvir et al,
a descrição dos eixos e suas subdivisões.
40
book.indb 40 31/5/2007 14:23:32

O eixo da Incerteza apresenta os diferentes níveis de

incerteza que um projeto pode assumir, seja quanto ao
tempo necessário para sua execução, quanto aos recursos
e equipe que serão alocados, a tecnologia disponível e
mesmo sobre a qualidade e sucesso do resultado final.
Nesse sentido, os criadores do Modelo UCP dividem os
projetos em quatro tipos:
a) Tipo A – Baixa Tecnologia: são aqueles
projetos baseados em tecnologias existentes
e dominadas, onde não há necessidade de
nenhum desenvolvimento ou conhecimento
adicional, a não ser os já disponíveis; os projetos
de construção civil são típicos deste nível, pois
o grau de incerteza tecnológica é mínimo, e o
mesmo tipo de projeto já foi realizado inúmeras
vezes, não havendo o que inventar; por esse
motivo a gerência deve ser rígida e não permitir
variações no plano original;
b) Tipo B – Média Tecnologia: também são
baseados em tecnologias existentes, porém
podem incorporar alguma novidade no desejo de
criar algum diferencial para o produto resultante;
esse tipo de projeto tem poucas incertezas e
geralmente acontece em indústrias tradicionais
e bem estabelecidas onde o desenvolvimento
tecnológico ocorre lentamente, como é o caso
da indústria automobilística ou de máquinas
pesadas, onde apesar do domínio tecnológico
também é preciso incorporar algum novo
dispositivo ou elemento; devido às poucas
incertezas, a novidade é incorporada rapidamente
ao produto, geralmente depois de um ou dois
ciclos de desenvolvimento do projeto;
c) Tipo C – Alta Tecnologia: são os projetos
onde as tecnologias a serem empregadas são
novas, apesar de já existirem quando o projeto se
inicia; a alta tecnologia se expressa porque tais
tecnologias pela primeira vez estarão integradas
num determinado produto ou processo, e o
desenvolvimento de tal projeto passa a ter uma
Unidade 1 41
book.indb 41 31/5/2007 14:23:32

série de incertezas, caracterizando-se por ter

longos períodos de planejamento, modelagem,
desenvolvimento e revisões, que exigem muitas
vezes retornar ao início do processo, levando a
variações grandes de custos e de modificações
nos prazos originalmente definidos; para que
aconteça uma estabilização da tecnologia são
necessários vários ciclos de projeto e reprojeto,
até a consolidação do produto/processo;
d) Tipo D – Super Alta Tecnologia: esse é o
tipo de projeto mais raro, onde se tem um
objetivo claro, porém ainda não há tecnologias
disponíveis para realizá-lo; somente governos e
empresas muito grandes se lançam nesse tipo de
projeto, onde o grau de incerteza é elevadíssimo,
e que levará a inúmeros outros projetos derivados
para buscar as tecnologias necessárias; o projeto
Genoma pode se caracterizar como sendo
desse tipo, assim como o projeto aeroespacial
Apollo, que pretendia levar o homem até a Lua
e envolveu milhares de pessoas e pesquisadores,
conseguindo finalmente obter o resultado
desejado, e junto a isso gerou uma enorme
variedade de subprodutos e novas tecnologias;
a figura abaixo representa as classificações no
eixo das Incertezas com relação às tecnologias
envolvidas.
Figura 1.6 – Eixo das Incertezas no Modelo UCP (DVIR et al., 2004).
42
book.indb 42 31/5/2007 14:23:33

O eixo da Complexidade relaciona os diferentes projetos

quanto à complexidade do sistema em desenvolvimento,
e dessa forma o nível de gerência necessária. Inúmeros
elementos podem estar relacionados num projeto, e a
forma como eles se relacionam é que define os níveis de
complexidade, conforme os seguintes níveis:
a) Nível 1 – Montagem: são projetos onde
diferentes elementos são arranjados em
composições simples, ou simples montagens,
de tal forma que o resultado se configura num
único produto com funções bem determinadas
como por exemplo, uma máquina; nesse nível
de complexidade os projetos geralmente são
desenvolvidos internamente por uma empresa,
sem relações externas;
b) Nível 2 – Sistemas: os projetos com nível de
complexidade maior, que envolvem inúmeros
elementos e diferentes equipes, de diferentes
empresas e subcontratados, têm maior nível de
complexidade e são chamados nesse modelo de
“Sistemas”; são exemplos desse tipo um novo
projeto de automóvel ou avião, ou a reengenharia
de uma empresa inteira;
c) Nível 3 – Supersistemas: são aqueles formados
por inúmeros outros sistemas, em geral
dispersos entre diferentes empresas e categorias
tecnológicas, que precisam agir em conjunto em
busca dos resultados definidos pelo contratante,
muitas vezes uma instituição governamental ou
consórcio de empresas; a construção do túnel que
liga a Inglaterra à França é um exemplo desse
tipo, assim como a construção do metrô de São
Paulo; a gerência desse tipo de projeto envolve
inúmeros gestores e uma imensa quantidade de
documentos e relatórios, de forma a coordenar
esforços de diferentes organizações e lugares;
o eixo da Complexidade quanto aos sistemas
envolvidos é apresentado na figura a seguir.
Unidade 1 43
book.indb 43 31/5/2007 14:23:33

Figura 1.7 – Eixo da Complexidade no Modelo UCP (DVIR et al., 2004).
O eixo dos Prazos divide os projetos quanto ao tempo

disponível ou necessário para o seu desenvolvimento.
Como você estudou na Unidade 1, os prazos são
ultrapassados na grande maioria dos projetos, gerando
custos não previstos e atrasos na entrega aos clientes, e
por esse motivo são uma fonte enorme de preocupação.
Nesse sentido, os criadores do Modelo UCP identificam
três tipos de projetos quanto aos “prazos”:
a) Regulares: são aqueles projetos onde existe
um prazo definido, mas há razoável tolerância
aos atrasos e modificações de agenda, como
acontece, por exemplo, na construção de edifícios
residenciais e em estradas; perturbações e
modificações de investimento são toleradas e
admissíveis; apesar de não desejáveis, temos
exemplos comuns em projetos de implantação
de sistemas de software gerencial em empresas
(os ERPs), e são tolerados porque se admite
que há fatores não percebidos no começo do
projeto e que o atrasam, e a importância da sua
implantação é preponderante, independente do
prazo;
b) Competitivos: são os projetos mais comuns
no ambiente industrial/empresarial, e estão
endereçados a novas oportunidades de negócios,
posicionamento estratégico ou lançamento
de novas linhas de produtos; nesses casos a
perda do prazo não é fatal para a empresa,
44
book.indb 44 31/5/2007 14:23:33

mas atrasos podem ser o motivo de fracasso

em um lançamento e a perda de liderança em
determinado mercado;
c) Críticos: são os projetos onde o atraso significa o
fracasso total, implicando em falência ou derrota;
projetos desse tipo surgem em fases críticas,
como por exemplo, em guerras, quando projetos
militares precisam ser concluídos no tempo justo;
por esse motivo, a gerência é rigorosa e há pouco
tempo para documentação e outros tipos de
burocracia, levados ao mínimo necessário (veja a
figura a seguir).
Figura 1.8 – Eixo dos Prazos no Modelo UCP (DVIR et al., 2004).
Considerando os eixos apresentados, é possível

posicionar um projeto ou situação de determinado
produto, e buscar então um novo posicionamento
estratégico.
É o que se dá no exemplo do artigo citado de Dvir et al. (2004),

que relata o caso do desenvolvimento de um sistema de controle
e proteção contra incêndios. Na figura a seguir é representada
a atual posição do produto e a posição futura numa disposição
bidimensional.
Unidade 1 45
book.indb 45 31/5/2007 14:23:33

Figura 1.9 – Exemplo de projeto apresentado no artigo de DVIR et al. (2004).
É importante ter uma compreensão de como os projetos se

dividem, sabendo que os diversos esquemas se ajustam aos
projetos conforme o ponto de vista que estamos tomando para
estudá-los ou prepará-los. Com essa compreensão é possível ter
sempre uma visão estratégica na criação e na gerência do projeto.
Agora que você já acompanhou a leitura desta unidade, para

praticar os novos conhecimentos, realize as atividades propostas a
seguir e no EVA.
Atividades de auto-avaliação
Leia com atenção os enunciados e realize as atividades.
1) Considerando que projetos têm “objetivos definidos e prazo de

conclusão”, encontre um exemplo de projeto em sua própria
experiência, ou na história, e descreva o mesmo.
46
book.indb 46 31/5/2007 14:23:33

2) Com respeito à administração dos projetos ao longo da história,

você estudou que houve um momento em que se passou do
trabalho realizado sem planejamento para um início de teorização e
implantação de práticas gerenciais. Em que época isso acontece, e por
que motivos?
3) Na seqüência veja os dois quadros. O primeiro é de um levantamento

realizado em 1958, e o segundo tem dados de 1998. Compare os
índices, analise se houve mudanças nesse período, e a seguir, descreva
suas observações nas linhas em branco.
Quadro 1.1 – Desvios no planejamento (1958).

Desvio entre o Planejado e o Realizado
Projeto Desvio de tempo Desvio de custo
Governamental / militar 40 a 50% 100 a 200%
Privado 40% 70%
Quadro 1.2 – Estatísticas apresentando problemas típicos de projetos (1998)

Desafios e sintomas típicos de projetos Média nacional EUA (1998)
Atraso Apenas 44% dos projetos são concluídos no prazo.
Na média os projetos costumam atrasar em até
222% do prazo programado.
Acima do custo estimado. 189%
Não atingem satisfatoriamente os requisitos 70% dos projetos
técnicos planejados.
Cancelados antes do término. 30% dos projetos
Unidade 1 47
book.indb 47 31/5/2007 14:23:34

4) Considere o quadro a seguir, onde exemplos de projetos são

comparados com exemplo de tarefas de rotina. Escreva no quadro
alguns novos exemplos para as áreas determinadas.
Área Exemplo de projeto Exemplo de tarefa de rotina ou

atividade contínua
Concessionária de energia
elétrica
Software
Indústria Automobilística
Bancos
Governo
5) Veja o diagrama a seguir. Pesquise um produto ou serviço presente

no mercado que tenha sido desenvolvido seguindo esses passos, e
descreva brevemente as diversas etapas.
48
book.indb 48 31/5/2007 14:23:34

6) A figura a seguir apresenta o Modelo UCP de classificação de projetos.
Considere os seguintes casos, classificando-os e marcando no gráfico:

( A ) A construção de uma casa, e classifique esse projeto segundo o
modelo UCP, marcando no desenho com eixos “complexidade x incerteza”
a posição relativa do projeto.
( B ) Faça o mesmo considerando um projeto de desenvolvimento de
software para controle de biblioteca, por exemplo, e faça a marcação.
( C ) Em Santa Catarina está sendo desenvolvido o projeto de um novo
carro, com tecnologia brasileira e tração 4x4. Classifique e marque
também este projeto no desenho.
Comente no final as diferenças que você vê entre os três tipos de projeto.
Unidade 1 49
book.indb 49 31/5/2007 14:23:34

Síntese
Nesta unidade você estudou como os projetos se desenvolveram

na história da humanidade, e como eles se separaram, primeiro
na prática, depois conceitualmente, das atividades rotineiras e
contínuas. Aprendeu os principais conceitos sobre projetos e
gerência, avaliando os motivos que levam à sua realização.
Alguns tipos de classificação de projeto foram apresentados, e

o principal deles, o Modelo UCP, atribui níveis de incerteza,
complexidade e prazo, o que permite ao gestor uma visão ampla
das características do trabalho que o espera.
Com base na motivação do projeto, pode-se passar à fase de

análises de viabilidade e planejamento, assuntos da próxima
unidade. Até lá!
Saiba mais
Para aprofundar os temas abordados na unidade sugere-se:
1. www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=177 - link para

estudo da SOFTEX, Sociedade para Promoção da Excelência
do Software Brasileiro, sobre os mercados de software do Brasil,
China e Índia.
2. http://www.softex.br/cgi/cgilua.exe/sys/start.htm?sid=37 -
nesse link há um conjunto de estudos e artigos sobre a situação do
software no Brasil, constantemente atualizados e que permitem
uma visão ampla das oportunidades de negócio no mercado da
informática.
Links úteis
Alguns links são muito úteis para a comunidade de ciência e

tecnologia. Dê uma olhada nestes abaixo:
1. www.finep.gov.br – este é o sítio da Financiadora de Estudos

e Projetos, do Ministério de Ciência e Tecnologia do Brasil.
Vários editais de financiamento para inovação tecnológica
são colocados ali constantemente, e são dedicados ao fomento
50
book.indb 50 31/5/2007 14:23:34

industrial e empresarial. Há inclusive investimentos em projetos

tecnológicos a fundo perdido, ou seja, não reembolsáveis. No sítio
da Finep você vai saber como está o andamento da maioria dos
grandes projetos tecnológicos do país.
2. www.cnpq.br – o Ministério da Ciência e Tecnologia

também dispõe do Conselho Nacional do Desenvolvimento
Científico e Tecnológico – CNPq – que também financia bolsas
e projetos tecnológicos diversos, com ênfase em pesquisadores e
desenvolvedores cursando graduação ou recém formados. Além
disso, traz uma série de informativos e editais importantes.
3. Veja no seguinte sítio um artigo muito interessante sobre

criatividade no desenvolvimento de novos projetos. Aponta oito
tópicos como importantíssimos para a carreira criativa na área
de desenvolvimento de tecnologia. http://carreiras.empregos.
com.br/carreira/administracao/comportamento/131101-
criatividade_fraley.shtm
4. Veja no Brasil a ANPEI - Associação Nacional de Pesquisa,

Desenvolvimento e Engenharia das Empresas Inovadoras, cujo
sítio é www.anpei.org.br . Vários artigos importantes, estatísticas
e outras informações sobre projetos de pesquisa e inovação
tecnológica, bem como oportunidades de negócios.
Unidade 1 51
book.indb 51 31/5/2007 14:23:34

book.indb 52 31/5/2007 14:23:34
2
UNIDADE 2
Análise do projeto
Compreender a importância da avaliação e análise
prévia em projetos.
Constatar que os requisitos do cliente definem o
planejamento geral do projeto, que deve ser elaborado a
partir de um algoritmo.
Analisar a questão dos prazos, sua influência na
viabilidade de um projeto, e quais os riscos inerentes ao
processo.
Conhecer algumas das ferramentas computacionais que
apóiam o planejamento dos projetos.
Seções de estudo
Seção 1 Avaliação inicial

Seção 2 Requisitos do cliente e solução de problemas
Seção 3 Algoritmo do projeto
Seção 4 Prazo
Seção 5 Viabilidade do projeto
Seção 6 Antecipando e administrando riscos
Seção 7 Ferramenta de apoio para análise e
planejamento
book.indb 53 31/5/2007 14:23:34


Nesta unidade você irá ver que é fundamental, para o sucesso de
um projeto, que seja feita uma análise ampla do problema a ser
resolvido. O cliente, aquele que está solicitando o projeto, muitas
vezes não consegue mostrar todas as nuances do problema, então
uma análise profunda e ampla será necessária.
Junto à definição dos motivos do projeto, está o estabelecimento

de um “caminho bem planejado” para sua execução, que será
traduzido aqui por “algoritmo” do projeto, o qual permite traçar
um caminho preciso de execução. Os métodos de planejamento
partem desse algoritmo para avaliar os recursos necessários e
fazer o planejamento das etapas de desenvolvimento.
Também será analisada a questão do prazo e dos riscos de

um projeto que podem ser previstos e, desta forma, criadas
alternativas para sua administração. Além disso, muitas
ferramentas computacionais têm surgido ultimamente para apoiar
o planejamento dos projetos. Ao longo deste estudo você irá
conhecer algumas delas e saber como utilizá-las para estabelecer
um plano geral.
Ao estudo!
SEÇÃO 1 - Avaliação inicial

Para que os projetos tenham sucesso é preciso ter, antes
de tudo, uma visão clara sobre a sua finalidade
e sobre o resultado final esperado. Em recente
artigo sobre lideranças em equipes de projetos,
Christenson e Walker (2004) definem
esse tipo de atitude, vinculada a uma
comunicação objetiva do projeto, como fatores
essenciais para que toda a equipe tenha real
compromisso com o seu sucesso.
Você viu na unidade anterior que uma série de diferentes

fatores influencia no surgimento de um projeto. Mas para que
ele tome forma e possa evoluir ainda há muito que fazer. Quem
54
book.indb 54 31/5/2007 14:23:34

encomendou o projeto, quem teve a idéia, quem sentiu a sua

necessidade, muitas vezes não sabe exatamente o que quer nem
aonde quer chegar. A primeira pergunta que se deve fazer, nesses
casos, é:
Qual é o problema?
Você irá se surpreender com a resposta, pois o real problema

não aparece, e em seu lugar vêm meias palavras e pedaços de
problemas. Para chegar a sua raiz é preciso argumentar um pouco
mais, na tentativa de clarear a própria idéia do projeto, pois
geralmente o usuário, o fabricante, o empresário, não tem clareza
sobre o problema a ser resolvido.
- preciso melhorar o tempo de produção desta

linha de montagem.
É de fato um “grande” problema, e então seria

necessário contar com um “grande” projeto (sem
saber direito que projeto seria esse).
Talvez o tempo da linha de montagem seja grande
porque, ao finalizar cada etapa da montagem, alguém
pára para contar peças.
- Então, se houvesse um sistema de contagem
automático, esse tempo poderia ser reduzido.
Essa automação poderia ser um contador em
determinados trechos da esteira, o que já existe no
mercado, basta comprar e instalar.
Porém, seria necessário pegar os dados gerados pelo
contador e envia-los para o departamento de estoque,
onde planilhas são construídas.
Bem, esse processo de análise pode ir bem longe, até se chegar de

fato a um problema com uma solução a ser implementada, e para
se ter tal solução um projeto será criado.
Parece simples, mas não é.
Unidade 2 55
book.indb 55 31/5/2007 14:23:34

O primeiro passo, o passo fundamental, é transformar o assunto

no qual está inserido o “problema” em uma definição exata,
pois um trabalho de desenvolvimento só tem sentido quando se
procura uma solução, ou seja, quando se sabe o resultado a ser
obtido, o que só acontece quando há clareza no problema a ser
resolvido.
A isso se denomina escopo do problema.
Clientes têm idéias confusas sobre os seus próprios desejos. E

se nossa tarefa é criar soluções para problemas de tecnologia
complexos, será preciso envolver a associação de conhecimentos:
adquiridos em etapas de pesquisa e desenvolvimento

científico e/ou;
de engenharia e/ou;
empíricos.
Não parece fácil. Quanto maiores a complexidade e incerteza
do projeto a ser trabalhado, maior a necessidade de envolver
diferentes membros na equipe, buscando complementaridades.
Da mesma maneira,
para que se aproxime do problema, é preciso criar

para ele um modelo de representação.
Na tentativa de definir um problema, há duas maneiras de

encará-lo:
Partido geral, ou amplo: definir o problema de maneira

ampla permite criar soluções menos usuais, pois o
universo de análise é maior. Com isso se quer dizer que
ângulos diferentes podem ser analisados, e soluções que
56
book.indb 56 31/5/2007 14:23:35

estavam fora do alcance de visão do cliente ou da equipe,

por exemplo, podem surgir e resolver a questão. Observe
a figura:
Soluções abrangentes e variadas
Visão ampla
Efeitos não Efeitos não

visíveis visíveis
Causas e efeitos
visíveis
Causas não Causas não
visíveis visíveis
REGIÃO DO PROBLEMA
Figura 2.1 – Representação esquemática do problema com abordagem de “visão ampla”.
Na figura, você observou que na região do problema há várias

causas e efeitos que não estão imediatamente visíveis, a não ser
que um partido geral seja tomado, e que uma capacidade de
visão ampla esteja em ação. Com isso, vários aspectos podem ser
analisados, e propostas de soluções abrangentes e variadas podem
ser assumidas.
Partido restrito: Visões restritivas levam a soluções de

pequeno alcance, ao contrário de uma percepção ampla
que pode levar a soluções de maior alcance. Problemas
atacados desde o início de maneira pormenorizada
podem gerar soluções deslocadas, e um gasto excessivo de
tempo e dinheiro. Observe a figura:
Unidade 2 57
book.indb 57 31/5/2007 14:23:35

Solução restrita
Visão restrita
Efeitos não Efeitos não

visíveis visíveis
Causas e efeitos
visíveis
Causas não Causas não
visíveis visíveis
REGIÃO DO PROBLEMA
Figura 2.2 – Representação esquemática do problema com abordagem de “visão restrita”.
Você percebeu na figura, que onde um conjunto de causas

e efeitos não está no campo de visão dado por um partido
restrito. Isso gera uma solução de alcance limitado, que muito
provavelmente não agirá sobre causas e efeitos não percebidos.
Considero essa dualidade de visões, a ampla e a restrita, como

o problema fundamental das áreas de pesquisa, desenvolvimento
e engenharia, seja em setores de software ou de construção, da
indústria ou do serviço, da nossa vida profissional ou da nossa
vida privada. Por esse motivo, vou explorar um pouco mais esses
conceitos com alguns exemplos e estudos de caso (obviamente
com a expectativa de influenciar você a buscar um partido
amplo!). Leia com atenção:
58
book.indb 58 31/5/2007 14:23:35

Caso 1 – implantação de um ERP e a esperança surgiu no coração

de todos. Nesse momento fiz a
Conheci uma empresa que minha primeira análise e relatei
tinha várias filiais espalhadas a todos: o problema está no
por extenso território e mais de sistema, e a rede não vai alterar
mil e quinhentos funcionários. seu comportamento.
Não vou contar aqui a novela e
os dramas que aconteceram na Bem, eu não queria frustrar as
escolha do software ou na sua esperanças de ninguém. Veio
implantação. a nova rede e tudo continuou
como era antes (e minha equipe
Vou iniciar o caso do já tinha apresentado todos os
momento em que uma rede de gráficos de desempenho, antes
comunicação IP foi contratada e depois da existência da rede,
de uma grande empresa de mas ninguém estava disposto a
telecomunicações. Qual era o abandonar suas crenças até que
problema? cada um visse novamente, em
sua própria máquina, que tudo
Antes do contrato dessa grande
continuava igual).
rede IP, todos os usuários
reclamavam de imensos Chegou a vez da segunda
problemas de demora para solução (restrita): se o sistema
resolver qualquer coisa com o não funcionava bem deveria
tal software ERP, que tinha ser problema com o servidor,
vindo para ser “a salvação então a solução seria trocar
do sistema de informações” o servidor (isso foi feito).
dessa empresa. O usuário Acredito que tenha melhorado
evidentemente achava que um por cento (é uma crença
isso seria um novo problema particular, baseada na redução
para ele, tão acostumado em proporcional de reclamações).
preencher papeizinhos.
Fiz as seguintes perguntas: o
Mas cada vez que fazia uso do sistema é lento em todas as
novo sistema, o mesmo não solicitações? Apenas das filiais?
respondia ou demorava demais Poderia haver problemas nas
para dar uma resposta, muitas rotinas implementadas para
vezes “travando”. acesso ao banco de dados?
Então surgiu a primeira Quanto mais as perguntas
solução (restrita) do problema: foram cercando diferentes
era a infra-estrutura de rede aspectos do sistema, cada vez
que não funcionava bem. Foi mais as respostas indicaram
contratada então a nova rede IP que o problema estava na
Unidade 2 59
book.indb 59 31/5/2007 14:23:36

própria construção do sistema. ganhar alguns pontinhos sabia

Bem, se essas perguntas inteligentemente manipular
tivessem sido feitas numa referenciais comparativos (e é
etapa bem anterior, talvez as por isso que os concursos de
coisas tivessem ocorrido de Qualidade não têm valor, a não
modo diverso, mas na vida ser para os ignorantes sobre o
real a empresa deixou por isso assunto).
mesmo e passou a conviver
com o ERP, como se fosse Pois bem, uma das suas
uma espécie de filho defeituoso iniciativas era a de aumentar
vivendo para sempre dentro de a interatividade com os
casa. clientes e melhorar a imagem
junto ao mercado, sendo que
Outro caso que também reformular o site da empresa
destaca a falta da visão ampla: era um dos planos. Já havia um
site em funcionamento, mas
Caso 2 – encomenda de um novo era tão fraco e desestruturado
“site corporativo”
que o número de visitas
Estive em certa companhia era muito baixo, e ainda
onde a cultura tecnológica menor ao de alguns sites
remontava ainda à época da especializados de algumas de
segunda revolução industrial, suas seções industriais, que
ou seja, a cultura tinha tinham feito os seus de forma
conseguido evoluir do ambiente independente. O gerente geral
das máquinas a vapor para as de marketing da empresa, que
máquinas elétricas. Isso não é surpreendentemente também
uma crítica à companhia, pois acumulava a função de gerente
ela estava adequada ao seu técnico geral, resolveu mudar
mercado, que a enxergava como essa situação contratando um
capaz de entregar produtos novo ambiente, de tal forma
tradicionais (e conservadores) e que embutisse os sites das
nisso era razoável. seções, não permitindo assim
que tivessem tal independência
No entanto, o discurso da nova de relacionamento com o
direção era de remodelagem mercado.
dos seus objetivos, e o foco
era estar a par das novas Esse era o clima geral do
tecnologias e dos novos negócio e tal era o problema
processos de qualidade, a resolver: um novo site
tanto é que fazia questão de corporativo com esse conjunto
participar dos concursos de de premissas, sejam de
qualidade regionais, e para marketing, sejam de política.
60
book.indb 60 31/5/2007 14:23:36

Tanto esse gerente como entre empresas de design para

seu diretor, ambos tendo contratar o tal site, e ganhou
conquistado suas posições a que tinha o menor preço.
a partir de negociações Certamente a descrição do
políticas (e não por talento propósito da contratação estava
empreendedor ou por conforme os objetivos desse
conhecimento do mercado), assessor, e as empresas fizeram
desprezavam as novas seus orçamentos praticamente
tecnologias, em um nível tal “no escuro”.
que o primeiro escrevia e-mails
como se fossem ofícios e o Ganhou o menor preço
segundo mal conhecia as regras e então chegou a terceira
do português escrito. Isso não solução (restritíssima) para o
consistia num grande problema problema, que foi a de dar uma
no ambiente em que viviam, “melhorada” no site existente.
mas tornou-se grave quando
Todos os funcionários da
resolveram influenciar nas
empresa, seus gestores,
definições do novo site.
aqueles que formulavam
O gerente geral de marketing suas novas estratégias, bem
assumiu a função de gestor como seus principais clientes
desse projeto e trouxe a e fornecedores, ficaram fora
primeira solução (restrita) para desse processo de análise
o caso: passou a incumbência de definições, e enfim, após
para o assessor de marketing da uns seis meses de atraso, o
empresa. Ele mesmo não tinha novo site foi publicado. Sem
uma visão geral da empresa e interação com as aplicações
sabia disso. informatizadas da empresa,
sem dinamismo e sem
O assessor de marketing tinha capacidade de mostrar as
dois problemas, que todos próprias atividades da empresa,
conheciam: não dominava foi um fracasso (as próprias
tecnologias e não conhecia estatísticas do site mostravam
a cultura da empresa (mas isso).
imaginava que, após ter
lido algumas revistas sobre Para o diretor e para o gerente
publicidade, podia discutir isso não teve importância,
qualquer assunto). afinal já tinham um “novo”
site, e era o que importava
O assessor trouxe então a para os concursos regionais de
segunda solução (restrita) para qualidade (e sua publicidade e
o problema: fez uma licitação política pessoal).
Unidade 2 61
book.indb 61 31/5/2007 14:23:36

Para o assessor de marketing da sua própria sobrevivência no

isso também não tinha futuro.
importância, pois ele cumpriu
seu dever e o emprego estava Começou então a tomar
mantido (tempos depois foi um partido amplo para
promovido!). analisar o problema, e iniciou
um conjunto de ações em
No entanto essa visão restrita (e seqüência, sempre com soluções
neste caso também mesquinha) criativas e tomadas por uma
fez a empresa dar um passo visão de conjunto.
para trás (talvez irreversível).
Em primeiro lugar, não
Eu poderia continuar descrevendo casos e mais casos desse tipo

de visão restrita aplicada à solução de problemas, e infelizmente
parece ser adotada por uma ampla maioria. Temos que lutar
contra isso. Deixem-me dar então apenas um exemplo de visão
ampla que, mesmo fazendo parte da minoria, pode mudar os
rumos de toda uma empresa ou mesmo de um país. Acompanhe:
Caso 3 – uma gigante da mudou completamente de

telefonia celular ramo para não desperdiçar
seu conhecimento técnico em
Assim como nos dois casos eletrônica e sua cultura de
anteriores, verídicos, também fabricação de produtos com
neste não vou revelar o excelência.
nome da empresa onde o
fato ocorreu (apesar de ser Ao mesmo tempo, assumiu
muito fácil adivinhar). E como solução (de ampla visão)
apesar de ter vivido o dia a não competir diretamente com
dia daqueles dois casos, neste empresas orientais que tinham
último, infelizmente, não tive preços baixos em produtos
participação. eletrônicos.
Bem, em meados dos anos Outra solução foi competir
70, a empresa vivia uma crise num mercado nascente e
no seu mercado, sendo que de alto valor agregado, que
os grandes compradores de naquele momento ainda
seus produtos, voltados à área consistia numa promessa: o
elétrica e eletrônica, estavam da telefonia celular. No início
perdendo o poder de compra. dos anos noventa, a empresa
A empresa tinha um grande já detinha um razoável
problema nas mãos, que era o conhecimento na área, e um
62
book.indb 62 31/5/2007 14:23:36

domínio consistente do seu O que aconteceu foi que,

mercado local que, no entanto, em aproximadamente cinco
era de dimensão restrita. anos, essa empresa assumiu a
liderança mundial na venda
Também com uma visão ampla de aparelhos, partindo de uma
e estratégica do mercado simples empresa de eletrônica
mundial, previu que a produção periférica, sendo atualmente
de aparelhos de telefonia copiada pela enxurrada de
celular teria valor agregado novos fabricantes orientais,
quando inserisse qualidade no que para disputar o mercado
software, e não no hardware do insistem numa estratégia de
equipamento. preços reduzidos.
Adotou uma solução (ampla) A série de soluções (amplas)
de pesquisar e desenvolver adotadas pela empresa,
novas interfaces e aplicativos sempre com uma visão geral
voltados à facilidade de sobre o seu mercado e sobre
manuseio por parte do usuário, os costumes, tendências e
muito mais do que desenvolver interesses dos seus clientes
simplesmente a miniaturização finais, fez com que conquistasse
dos aparelhos ou a qualidade e mantivesse a posição de líder.
de baterias, o que considerou
como commodities. Na época, Essa mesma visão é que
um dos líderes mundiais nesse criou um ambiente aberto de commodities – palavra da
mercado era uma empresa discussão com desenvolvedores língua inglesa que indica
que o produto ou sistema
americana, que valorizava a de software de todo o mundo, é de uso ou conhecimento
robustez do aparelho. que continuam colaborando genérico, tendo poucas
para sua expansão e liderança. diferenças de valor,
independente de quem os
fabrica ou fornece.
Unidade 2 63
book.indb 63 31/5/2007 14:23:36

É importante que você observe nesses casos, sejam de sucesso ou

de fracasso, algumas características e traços comuns. Observe:
Um partido amplo de visão não acontece onde as pessoas sentem-se limitadas

no seu relacionamento; a visão centrada em si mesmo naturalmente limita um
olhar descompromissado, capaz de enxergar outras facetas fora do seu mundo
Ambiente de particular.
cooperação
Ambientes onde há uma cultura de cooperação, ou seja, onde as pessoas
gostam de ajudar e de receber ajuda, admitindo que isso não seja uma forma
disfarçada de aproveitamento, permitem liberdade de expressão.
Certamente apenas um ambiente de cooperação não é suficiente, pois em

Conhecimento técnico problemas técnicos é necessário um conhecimento específico.
aliado à visão de Porém, apenas o conhecimento técnico é algo limitante, e deve ser
mercado contrabalançado com uma visão externa, voltada para o mercado e para outras
facetas não técnicas.
Ao mesmo tempo, é difícil ter conhecimento técnico em muitas e variadas

áreas, especialmente na atualidade onde há tantas tecnologias que se
Multidiscipli- desenvolvem tão rapidamente.
naridade Equipes trabalhando em conjunto e com alto grau de cooperação são capazes
de reunir conhecimentos de diferentes disciplinas, capazes de gerar soluções
de ampla visão.
O contrário desse ambiente de cooperação e multidisciplinar acontece onde

impera uma visão medíocre, aquela que não admite relacionamentos e que
acredita que, se alguém dá uma sugestão, é porque está “planejando algo”.
Também faz parte da visão medíocre a confusão que une ciência exata e
crenças, fazendo com que um problema seja analisado sob o ponto de vista do
“achismo”.
Visão medíocre
Muitos técnicos excelentes, engenheiros que conheci e que eram tidos por
gênios na universidade, resolveram ficar alheios ao desenvolvimento dos seus
colegas, supondo que sua imensa capacidade seria o bastante para resolver
os grandes problemas do futuro. Hoje infelizmente muitos deles estão presos
às suas baias, resolvendo mini-problemas sob as ordens de gerentes pouco
espertos, porém politicamente articulados.
A articulação política de caráter pessoal é, necessariamente, a visão restrita.

Centrada no “eu”, torna-se incapaz de um partido abrangente para as soluções,
mesmo que para problemas estritamente pessoais.
Isso se estende para a postura de solução de quaisquer problemas, e quando se
dá no nível empresarial pode ser uma catástrofe.
Política pessoal Nos casos antes citados você viu o que significou na contratação do “web site
corporativo”, apesar de, pessoalmente, os contratantes terem aparentemente
“se dado bem ”.
No entanto, nesse tipo de ambiente, muitos dos que estavam em volta
esperavam ansiosos a queda dos chefes, muitas vezes para substituí-los com as
mesmas práticas (renovadamente restritas).
64
book.indb 64 31/5/2007 14:23:36

Por fim, para completar o estudo desta seção, você deve entender
que as estratégias são definidas e implementadas com uma visão
de partido amplo, e as questões operacionais estão definidas sobre
questões restritas, ou partes de uma estratégia. O momento em
que uma ou outra deve acontecer é que define o tipo de visão a
ser adotada.
SEÇÃO 2 - Requisitos do cliente e solução de problemas

A expressão “requisitos do cliente” é comum entre
os desenvolvedores de software, e para
muitos outros profissionais, de outras
áreas, parece uma expressão nova. O
cliente nesse caso é aquele que precisa
resolver um problema, ou que está
gerando uma demanda específica, e
desse modo tem uma idéia aproximada
daquilo que quer obter. Como
acompanhou anteriormente, esse cliente
conhece talvez alguns dos efeitos de um problema,
mas geralmente não todos. E quando tem um desejo, no
fundo não sabe exatamente como expressá-lo.
Aquele que foi chamado, por algum motivo, para resolver o

problema de um requisitante qualquer, antes de tudo precisará
saber afinal “qual é o problema a resolver” e qual é o resultado
esperado.
O primeiro passo a tomar é coletar o maior

número possível de informações.
A coleta de informações está presente em todas as etapas

do trabalho, desde a primeira reunião com um cliente ou o
nascimento da idéia de um projeto, passando por todas as
etapas do projeto até a chegada do resultado, sendo um precioso
instrumento de aperfeiçoamento e correção contínua. Neste
sentido, cada etapa de um projeto pode ser vista como um novo
Unidade 2 65
book.indb 65 31/5/2007 14:23:36

começo, onde os requisitos das etapas devem ser novamente

levantados e analisados.
Nas etapas iniciais, a coleta vem diretamente do cliente que

solicita a solução de um problema, mas em casos onde há uma
idéia de produto, por exemplo, tais informações podem vir da
literatura e de experiências prévias, seja dos desenvolvedores, seja
de outros envolvidos no projeto.
Quais os procedimentos para levantar os

requisitos básicos do cliente?
Alguns procedimentos para levantar os requisitos básicos do

cliente, ou as informações para o desenvolvimento de um novo
produto ou sistema, e encaminhar uma primeira visão geral do
problema / solução são:
Se o problema a ser resolvido está escrito - devem-se

listar as informações que estão no seu enunciado, na
tentativa de detalhar o melhor possível suas partes;
Se for um defeito a eliminar - descrever todos os efeitos
conhecidos e enumerar todas as possíveis causas;
Se for um novo produto ou processo a desenvolver
- listar o que deve ser determinado pela solução, ou seja,
definir com a maior clareza possível o que está sendo
buscado;
A partir dos dados levantados e do partido amplo
do problema - deve-se criar modelos e esquemas de
representação, permitindo uma melhor visualização do
conjunto; nesse sentido o desenvolvimento de desenhos
esquemáticos, diagramas e fluxogramas, torna-se útil
para a compreensão do todo, mesmo que tais desenhos
não sigam modelos padronizados (isto não importa nesse
momento);
Além das informações listadas - dos desenhos e de
outros dados coletados, é importante verificar as leis
físicas associadas e suas equações, no caso dos problemas
66
book.indb 66 31/5/2007 14:23:37

científicos, mas também outros impeditivos e limitantes,

tais como questões jurídicas, restrições técnicas,
restrições ambientais, etc.;
Tomar proveito de modelos computacionais e
simuladores - como ferramentas de apoio para
compreender o problema, retratá-lo e simular situações,
bem como aprimorar o desenho de diagramas, gráficos
de planejamento, aplicar hipóteses de solução e
desenvolver esquemas gerais e/ou detalhados.
O desenho da figura abaixo reproduz esses passos na forma
de um diagrama de coleta de informações para a solução de
problemas. Como se pode notar, é um diagrama genérico que não
esgota as possibilidades de tipos de problemas ou idéias originais
a serem transformadas em projetos. Mas dá uma clara percepção
da necessidade de coleta do maior número de informações,
inclusive de fontes externas ao problema, para então chegar à fase
de se criar hipóteses de solução.
Problema
definido
ou
Dados Desenho, Hipóteses Objetivos

Defeito a diagrama
eliminar coletados de solução do projeto
ou modelo
ou
Novo Outras
produto informações
Figura 3.3 – Diagrama do nascimento do projeto com coleta de informações e requisitos do cliente.
Com as hipóteses de solução formuladas, é possível traçar

objetivos de chegada considerando as hipóteses que têm maior
chance de sucesso. Esses objetivos serão perseguidos em todo o
projeto, e para isso é preciso definir um caminho de trabalho para
abordar o projeto. Esse caminho está definido no algoritmo do
projeto, apresentado na próxima seção.
Unidade 2 67
book.indb 67 31/5/2007 14:23:37

SEÇÃO 3 - Algoritmo do projeto

O algoritmo é a uma seqüência lógica de passos, que permite
modelar um determinado programa, ou projeto, entendidos e
definidos com exatidão para que o projeto chegue ao resultado
esperado. Tendo um objetivo bem definido, conforme você
estudou na seção anterior, é preciso determinar um fluxograma
genérico de atividades, até o objetivo ser atingido.
O algoritmo apresentado na figura a seguir foi adaptado a partir

de uma proposta de Meillir Page-Jones (1990). O fluxograma se
inicia a partir dos objetivos definidos, e vai ser encerrado quando
os mesmos forem alcançados.
Qual é o conjunto de atividades que determina a

Gerência de Projeto?
Neste algoritmo, pode-se ver o conjunto de atividades que

determina a Gerência do Projeto, as quais são:
planejamento,
definição e organização dos recursos,
acompanhamento da execução,
medição dos resultados obtidos e
revisão, quando então o ciclo reinicia, se necessário.
Acompanhe o desenho a seguir e analise cada uma das etapas,
procurando observar o fluxo das atividades.
68
book.indb 68 31/5/2007 14:23:37

Objetivos do projeto
Planejamento
Ferramentas de apoio
das atividades
Definição dos
recursos
Obtenção dos
recursos
Integração dos
recursos
Execução das Acompanhamento

atividades e medições
Revisão do projeto Os objetivos

NÃO foram alcançados
SIM
Encerramento do projeto
Figura 3.4 – Algoritmo genérico com o fluxograma do desenvolvimento do projeto.
Para compreender o que consiste cada etapa, acompanhe a seguir

uma breve descrição de cada uma delas:
a) Planejamento das atividades – o planejamento consiste

em dividir o objetivo geral do projeto em tarefas,
ou pequeno objetivos, que vão se encadeando numa
seqüência determinada, a fim de atingir o resultado
esperado do projeto.
Também consiste em definir recursos materiais,
financeiros e de pessoal, para cada um desses
pequenos objetivos, com os trabalhos a serem
feitos num determinado prazo pré-estabelecido.
Unidade 2 69
book.indb 69 31/5/2007 14:23:37

b) Definição dos recursos – a definição dos recursos

é uma das tarefas do planejamento, porém coloco à
parte no algoritmo e logo após a fase do planejamento
para destacar a importância dessa etapa. Muitas
vezes a definição dos recursos necessários não é bem
determinada, o que pode acarretar carências na etapa da
execução, que podem então ser fatais.
Definir com a maior exatidão os recursos
necessários, sejam financeiros, materiais,
equipamentos ou pessoal com a qualificação
necessária, contribuirá para completar a fase do
planejamento e para diminuir riscos.
Recursos subestimados levarão a importantes
faltas, enquanto recursos superestimados levarão
a custos altos, inviabilizando o projeto em alguns
casos.
c) Obtenção dos recursos – somente com uma boa
definição de recursos é possível partir para a fase da sua
obtenção, que pode ser uma tarefa bastante difícil no
processo do projeto.
Se for um projeto dentro de uma grande
organização, talvez os recursos já estejam
previamente alocados, mas se o projeto for
empreendido por uma pequena empresa,
eles podem ser escassos. Neste caso, recursos
externos serão necessários, o que tomará um
determinado tempo até serem obtidos. Essa
demora não é favorável, por exemplo, nas áreas
de alta tecnologia.
d) Integração dos recursos – os recursos podem vir de
fontes diferentes, e muitas vezes guardam grandes
diferenças entre si. Nesse momento é que são organizadas
as equipes, distribuídas as tarefas e feitas as discussões
iniciais de repasse de informações.
Pense, por exemplo, num conjunto de pessoas
com diferentes habilidades, e que ainda não
se conhecem. Ou então na utilização de
equipamentos novos, ainda não dominados por
70
book.indb 70 31/5/2007 14:23:37

todos. Nesse sentido é que a integração dos

recursos assume importante papel, determinante
para o progresso do projeto dentro do prazo
estipulado.
Arranjos de lay-out de produção, organização
de máquinas, montagem de laboratório,
treinamento e comunicação do planejamento
completo para todos os envolvidos, são atividades
desta etapa.
e) Execução das atividades – muitos consideram que

o projeto só está de fato em desenvolvimento quando
se inicia a execução das atividades. Isto é um grande
engano, como você já pôde ver pela quantidade e
importância das etapas precedentes, que são etapas
preparatórias e de planejamento. A etapa da execução é
aquela em que os recursos materiais são utilizados pela
equipe, que desenvolve a série de tarefas designadas no
planejamento, tendo em vista atingir os sub-objetivos,
numa ordem tal que permita chegar aos objetivos finais
desejados.
Tome como exemplo algo muito simples
como a construção de uma casa. Depois de
elaborados os projetos e tendo listagens de
materiais e memoriais descritivos, que definem
em detalhe como se construirá a casa (essa é
a etapa do planejamento), passa-se a fazer os
orçamentos, contratar pessoal e reuni-los para
discutir, com um partido amplo, como será a
construção e os prazos a serem cumpridos. A
partir de então começa a execução do projeto,
que provavelmente foi subdivido em fundações,
alvenaria, telhado, rebocos, instalações, etc.
f) Acompanhamento e medições – como a execução
deve seguir o planejamento, certamente deverá haver
o acompanhamento e a verificação do andamento do
projeto, avaliando periodicamente a concordância entre
Unidade 2 71
book.indb 71 31/5/2007 14:23:37

uma coisa e outra. Muitas vezes, é nessa etapa onde se

faz mais visível a presença da gerência, devido ao controle
do planejamento.
Como o objetivo geral deve ter sido subdividido
em pequenos objetivos, com metas e prazos
menores, faz-se necessário verificar o alcance de
tais metas com medições periódicas, ou seja, nos
prazos determinados para cada sub-objetivo.
g) Revisão do projeto – durante o acompanhamento e
medições, caso os objetivos não sejam alcançados, seja
devido ao tempo gasto para chegar até aquele ponto,
seja pela qualidade diferente da esperada, o projeto
deve passar por revisões. Rever o projeto durante o
seu andamento significa reavaliar constantemente o
planejamento, bem como redefinir os objetivos quando
necessário.
Caso a revisão seja feita apenas no final do
projeto, poderão acontecer enormes frustrações
(financeiras ou de expectativa).
A figura a seguir representa esse ciclo de revisão
a cada etapa do projeto, que deve seguir adiante
caso os sub-objetivos, esperados naquela etapa,
tenham sido alcançados.
Replanejamento
Os sub-objetivos
Revisão da etapa
foram alcançados?
NÃO
SIM
Próxima etapa
Figura 3.5 – Fluxograma específico da fase da revisão.
Se não foram alcançados os objetivos, uma

revisão da etapa deve ser feita, indicando
possibilidades de modificação e retificação, que
precisam passar então por um replanejamento
72
book.indb 72 31/5/2007 14:23:37

para seguir adiante. Satisfeita a condição, vai-se

para a próxima etapa até serem alcançados os
objetivos gerais do projeto.
h) Encerramento do projeto – encerrar o projeto significa
atingir seus objetivos. A finalização do projeto não é
simplesmente acabar um produto ou compilar um código.
O encerramento é uma etapa bem definida, na qual toda
a documentação deverá ser organizada e entregue àquele
que o encomendou, com a comunicação mais completa
e abrangente possível sobre o resultado alcançado e os
problemas e soluções encontrados.
Tendo sido bem entendido o algoritmo do projeto, a próxima
seção trata de um tema especial para a Gerência de projetos:
Prazo.
SEÇÃO 4 - Prazo
Projetos são estabelecidos
com prazo determinado.
Como você pode perceber,
se não houver uma
data aproximada para
o empreendimento ser
encerrado, então não haverá
um projeto e sim uma tarefa
de rotina.
A definição do prazo é algo que

nasce a partir dos requisitos do cliente, pois os objetivos por
ele definidos só têm sentido se forem cumpridos até uma
determinada época, na qual então podem ser aplicados.
A discussão sobre prazos deve se dar considerando as

vantagens que o projeto busca, as condições reais da equipe de
desenvolvimento e os recursos disponíveis.
Na opinião de Meillir Page-Jones (1990), há quatro fatores que

fazem os projetos terem prazos irreais. Tais prazos irreais à
primeira vista são exeqüíveis, porém quando o conjunto de fatores
Unidade 2 73
book.indb 73 31/5/2007 14:23:38

que determina o andamento do projeto entra em jogo, o prazo se

perde.
O que leva os projetos a serem assumidos como

prazos irreais?
A seguir analise esses quatro fatores geradores de prazos irreais.
1. Racionalização do desejo - Page-Jones considera que

esse primeiro fator se dá quando alguém, que tem poder
sobre a equipe, imagina um prazo qualquer e, conforme
seu desejo, impõe uma data final aleatória.
Partindo dessa data estabelecida por um desejo, aquele
que vai gerenciar o projeto tenta dividir as tarefas em
prazos menores para adaptar ao prazo global. Ajustando
ao máximo, ele talvez consiga configurar um conjunto
de pequenas tarefas com prazos muito justos, dando a
entender que talvez seja possível cumprir a meta. Após
uma partida acelerada, os membros da equipe terão
que fazer paradas de revisão, talvez correções e ajustes,
e então o prazo começa a ceder e a equipe, cansada,
diminui a capacidade de produção.
Isso pode acontecer, por exemplo, quando um político

define a data para uma inauguração, sem ter a mínima
noção do tempo e das questões legais que envolvem
a contratação e a execução da respectiva obra. Ou
quando o diretor de uma empresa determina que
tal software deva estar funcionado em sua empresa
em determinado momento, sem buscar saber se tal
software sequer existe ou é adaptável.
2. Estimativa prematura - se a estimativa do prazo

total for feita muito no começo da análise do que será o
projeto, tal data pode parecer imutável (para os membros
74
book.indb 74 31/5/2007 14:23:38

da equipe) e muito provavelmente será irreal. Ora,

muitas das particularidades do projeto serão percebidas
conforme se aprofunda a discussão e o planejamento
do projeto, e só então será possível prever com maior
acuidade os prazos das diversas etapas, culminando com
um prazo global mais próximo da realidade de execução.
A estimativa prematura acontece no afã de se ter uma
data final para o projeto ficar pronto, mas devemos
controlar esse desejo. Certamente a estimativa dependerá
em muito do domínio que se tem da tecnologia
empregada no projeto.
3. Compromisso progressivo - Page-Jones atribui
uma conotação bastante negativa para esse fator, por
considerá-lo de procedimento não ético. Consiste em
estabelecer um escopo de projeto reduzido para a equipe,
que então define um prazo para tal escopo. A partir do
início da execução o contratante, ou mesmo o gestor,
vai ampliando o escopo e mostrando sua verdadeira
composição, com constantes incrementos de necessidades
e de compromissos. Não sendo mais possível voltar atrás,
a equipe tenta ajustar as novas necessidades dentro do
planejamento, estressando dessa forma todo o trabalho.
Perdas e danos podem ser irreparáveis, especialmente
pelo sentimento de ter sido enganado, e certamente não
haverá prazo cumprido.
4. Escala de valores - O que Page-Jones chama de escala
de valores está apresentado na figura a seguir. O projeto
tem um determinado custo para ser desenvolvido, que
está representado pela linha tracejada, enquanto os
ganhos a serem auferidos com o projeto finalizado estão
representados pela linha contínua. A definição da melhor
data para entregar o projeto está relacionada com o
melhor valor agregado possível.
Unidade 2 75
book.indb 75 31/5/2007 14:23:38

Figura 3.6 – Representação das vantagens relativas de um projeto considerando o prazo (adaptado de
Page-Jones, 1990).
Parta do princípio segundo o qual tal “primeira data” seja

exeqüível, e que todas as análises levaram a definir essa data
como adequada. Os atrasos que ocorreram farão a data de
entrega escorregar para a direita no gráfico, e o valor adicional
de vantagens vai diminuindo proporcionalmente, até atingir um
ponto onde não há mais valor adicional, e os prejuízos começarão
a aumentar progressivamente.
Então, o que não fazer no momento de definir

prazos de um projeto?
Considerando as implicações estudadas, é importante:
não ceder ao primeiro impulso de se definir uma data

sem antes analisar o máximo possível de dados do
projeto;
perceber quando a data definida não passa de um
“desejo racionalizado”, e então buscar esclarecer o
porquê da data, ou mesmo declinar do projeto para evitar
o fracasso;
76
book.indb 76 31/5/2007 14:23:38

discutir em detalhe todos os objetivos do projeto, para

evitar depois uma série de novos compromissos que não
haviam ficado claros no início;
perceber com a maior clareza possível a escala de
valores do projeto ao longo do tempo, evitando
embarcar em um projeto onde a primeira data de entrega
esteja próxima demais da data “fatal”.
SEÇÃO 5 - Viabilidade do projeto

Você já estudou a origem das idéias de novos projetos, das
motivações, dos requisitos do cliente, da visão geral do projeto e
do conceito de prazo. Porém, resta analisar, antes de começar um
projeto, se de fato ele é viável e quais os riscos envolvidos na sua
execução.
Muitas vezes um projeto é iniciado sem um estudo

de sua viabilidade nem dos seus riscos, o que tem
sido a fonte de inúmeros fracassos.
Mesmo os projetos muito simples precisam

de um estudo de viabilidade, e tal estudo
dará condições de se tomar as melhores
decisões desde o início, minimizando
riscos, despesas extraordinárias e atrasos.
Projetos complexos, que envolvem múltiplas
disciplinas e grandes custos, podem exigir
um estudo de viabilidade, como um
documento preparado por consultoria
externa e análise aprofundada.
Quais fatores analisar ao estudar a viabilidade?
São os seguintes os fatores preponderantes a serem analisados

num estudo de viabilidade: benefícios, recursos, custos e tempo.
Unidade 2 77
book.indb 77 31/5/2007 14:23:38

Esses quatro fatores podem ser vistos como elementos inter-

relacionados, como apresentado na figura a seguir:
custos prazo
recursos benefícios
Figura 3.7 – Fatores fundamentais na viabilidade dos projetos.
Acompanhe a descrição de cada um deles e suas relações. Procu-

re observar que, no estudo de viabilidade, tais fatores ainda não
são estimados com grande nível de detalhamento, mas apenas o
suficiente para se ter uma “visão geral do projeto”.
a) Benefícios - são os resultados positivos esperados do

projeto depois de finalizado. Alguns dos benefícios são
facilmente mensuráveis e outros não. Os mensuráveis
são aqueles que você pode comparar com o que se tinha
antes do projeto ter sido realizado.
Veja a seguinte lista de exemplos:

aumento do patrimônio (construção de máquina-
ferramenta, edificação);
aumento do faturamento (ascensão das vendas,
redução de desistências);
maior lucratividade (diminuição de custos, maior
preço de venda devido ao valor agregado ao
produto);
maior agilidade (na produção, na resposta a
solicitações externas e internas).
78
book.indb 78 31/5/2007 14:23:39

O projeto pode trazer também uma série de benefícios

cuja medição não é tão simples quanto comparar lucros
ou tempo de resposta. Nesse caso, está-se falando de
benefícios intangíveis, que podem ser tão ou mais
importantes que os tangíveis.
Pense nos seguintes itens:

aumento da satisfação dos clientes (apesar de ser
possível medir por meio de pesquisas, este é um
item subjetivo e bastante variável);
fixação de determinada marca como líder de
qualidade;
sensação de “time vencedor”.
b) Recursos - considere os recursos como sendo

materiais (equipamentos, instalações, softwares, etc.) e
humanos (a equipe do projeto). Projetos que envolvem
o desenvolvimento de novas máquinas, por exemplo,
exigirão como parte dos recursos o acesso a laboratórios
de testes. Também é importante ressaltar que os recursos
humanos adequados não são apenas os que detêm
certo tipo de conhecimento técnico, algo que não é o
bastante. É preciso dispor de pessoas com conhecimento
técnico e com capacidade de trabalho cooperativo, base
fundamental de todo projeto.
c) Custos - considerando os recursos materiais e humanos
necessários para o desenvolvimento do projeto, recursos
financeiros serão necessários para custeá-lo, geralmente
considerada a sua parte mais delicada. Ora, é possível
dispor de excelente pessoal, idéias brilhantes, domínio
tecnológico e um mercado potencial, mas as dificuldades
da sobrevivência diária podem impedir o uso de
certo montante de dinheiro em um projeto, mesmo
considerando seu provável sucesso.
Unidade 2 79
book.indb 79 31/5/2007 14:23:39

c) Tempo (Prazo) - lembre-se de que você já estudou

a questão da definição de prazos na seção anterior, e
aqui cabe ressaltar seu papel fundamental na análise
da viabilidade de um projeto. Certamente se os prazos
definidos forem irreais, o projeto será inviável e
fracassará. O estudo de viabilidade deve considerar o
prazo com especial cuidado. Muitas vezes, o projeto
encomendado tem os recursos necessários, pessoal
especializado e com grande domínio da tecnologia, e o
pagamento é bastante bom, mas o prazo exageradamente
curto não pode ser resolvido com a inclusão de mais
pessoas, por exemplo. No desenvolvimento de um
sistema computacional, o acréscimo de membros na
equipe pode, às vezes, significar acréscimo de confusão.
O projeto é viável?
Estudar a viabilidade do projeto é, antes de mais nada, pesar os

possíveis benefícios, os custos, a disponibilidade dos recursos
e do prazo, comparando com os riscos previsíveis capazes de
estragarem tudo.
No quadro a seguir, acompanhe um modelo de questionário /

relatório, bastante simplificado (e subjetivo), para um Estudo de
Viabilidade de Projetos.
80
book.indb 80 31/5/2007 14:23:40

Estudo de viabilidade
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratégias)
Benefícios: Descrição:
- quais são as vantagens mensuráveis que o projeto trará?
- quais são os valores comparativos?
Benefícios:
Descrição:
- que vantagens intangíveis ele trará?
- como se poderá verificar?
Recursos: Descrição:
- quais os recursos materiais necessários para o projeto?
- esses recursos estão disponíveis?
- caso não disponíveis, é possível obtê-los?
Recursos: Descrição:
- quais os recursos humanos necessários para o projeto?
- essas pessoas estão disponíveis para o projeto?
- caso não disponíveis, há outras pessoas para substituí-las?
Custos: Descrição:
- considerando os recursos necessários, quanto dinheiro será necessário para desenvolver o projeto?
- esse montante está disponível?
Custos: Descrição:
- há fontes de financiamento?
Prazo: Descrição:
- qual o prazo pré-definido pelo “cliente” para o projeto?
Prazo: Descrição:
- considerando a experiência da equipe, qual o prazo estimado para o projeto? É igual ao pré-definido?
Conclusões quanto à viabilidade do projeto:
Recomendações:
Anexos
(tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais, etc.)
Quadro 1 – Modelo de relatório para estudo de viabilidade de projetos.
Unidade 2 81
book.indb 81 31/5/2007 14:23:40

Observe que este modelo não esgota todas as possibilidades de

análise, pelo contrário. Mas encaminha uma série de questões
iniciais, com as quais é necessário você se preocupar para tentar
perceber se é viável prosseguir com o desenvolvimento do pro-
jeto e contra quais riscos é preciso se resguardar. Cada projeto,
obviamente, trará questões particulares, que devem ser tratadas
e resumidamente descritas. Posteriormente, no caso do projeto
seguir em desenvolvimento, as estimativas detalhadas de custos,
benefícios e recursos deverão ser tratadas.
SEÇÃO 6 - Antecipando e administrando riscos

Os riscos de um projeto já estão lá antes
mesmo de ele nascer. Você poderá verificar
como prevê-los com a maior antecipação
possível, e então administrar a sua
existência (já que não é possível eliminá-
los completamente). Você tem que encarar
o risco como uma ameaça, que pode levar
o projeto ao erro, às perdas e ao fracasso.
Geralmente não é possível evitar essa
ameaça.
Os riscos podem ser considerados conforme a

probabilidade de ocorrerem e conforme o impacto
que terão sobre o projeto, caso ocorram.
Há riscos de enorme impacto como, por exemplo, a falta de

recursos financeiros bem no meio do projeto – essa falta faz
simplesmente o projeto ser abortado. Você terá então de avaliar se
há de fato a probabilidade de isso ocorrer. Se o recurso financeiro
para custear o projeto não está depositado previamente e depende
de financiamento externo, a probabilidade de falta pode ser
considerável.
Outra questão se refere ao impacto do risco do atraso do projeto

em um benefício esperado. Se for o lançamento de um produto
de área de forte concorrência, o impacto é enorme e deve ser
avaliada a probabilidade de ocorrer. Há outros casos onde a
82
book.indb 82 31/5/2007 14:23:40

probabilidade de ocorrência dos riscos é alta, porém o impacto

deles é mínimo. Durante o período da construção de uma casa,
a probabilidade de chuvas é altíssima e, sendo assim, uma série
de atividades alternativas é programada, fazendo com que esse
risco tenha baixo impacto no projeto. Outra questão importante
se refere à origem dos riscos, que o desenho a seguir apresenta de
modo esquemático:
Risco externo
Área do projeto Risco interno
Figura 3.8 – Riscos internos e externos.

Observe que os riscos em projetos podem basicamente ser de
origem interna e de origem externa. Essa diferença de origem
leva tais riscos a um tratamento diferente quanto à sua previsão,
administração e eliminação. Acompanhe como é identificada
cada origem:
a) Riscos de origem interna - os riscos de origem interna

passam a existir a partir do nascimento do projeto.
Unidade 2 83
book.indb 83 31/5/2007 14:23:40

Podem ser considerados típicos riscos internos dos

projetos:
equipamentos defeituosos;
equipe despreparada para trabalho em grupo;
falta de domínio tecnológico;
gastos excessivos;
estouro de prazo devido a falhas de
desenvolvimento;
estouro de prazo devido a erros no gerenciamento;
necessidades tecnológicas desconsideradas durante
o planejamento das etapas;
a complexidade do sistema, não devidamente
percebida nas etapas iniciais;
alterações no escopo do projeto.
b) Riscos de origem externa - são aqueles que independem

de qualquer atividade ou planejamento do projeto, mas
podem acontecer e afetar seriamente o seu andamento.
Podem ser considerados típicos riscos provocados por

agentes externos aos projetos:
causas/fenômenos naturais;
crises políticas de uma região ou país;
crises econômicas;
doenças;
problemas do financiador do projeto ou do
fornecedor de insumos/recursos;
alterações na legislação;
pressões da organização, da sociedade, do cliente;
alterações no mercado quanto às suas necessidades
ou capacidade de compra.
84
book.indb 84 31/5/2007 14:23:41

Como agir diante dos riscos?
Com essas considerações sobre origem, probabilidade e impacto

dos riscos sobre o projeto, há duas possibilidades de ação:
a) Deixar acontecer e, então, tentar resolver.

b) Antecipar e administrar os riscos.
O processo de administração de riscos deve ser contínuo, desde
o planejamento inicial do projeto até as suas últimas etapas, e
consiste em um ciclo de atividades, conforme você pode ver na
figura a seguir:
Etapa Nova Etapa

Identificar os riscos
Analisar os riscos
Planejar ação
sobre os riscos
Eliminar ou
administrar
os riscos
Figura 3.9 – Antecipando e administrando riscos.
Esse ciclo deve se repetir a cada nova etapa, e os riscos

identificados devem ser comunicados a todos os participantes
do projeto, seja para os de nível inferior, seja para os de nível
superior (mesmo que isso possa desagradar).
Unidade 2 85
book.indb 85 31/5/2007 14:23:41

O ciclo para o tratamento dos riscos é composto do seguinte:
1. Identificação de riscos;
2. análise;
3. planejamento da ação contra esses riscos;
4. controle/eliminação dos riscos;
5. nova etapa do projeto e nova identificação de riscos.
Acompanhe a descrição de cada um deles:
a ) Identificação de riscos - esse é o primeiro passo na

administração dos riscos, e consiste em sua identificação.
O modelo apresentado no quadro abaixo aponta diversas
causas de riscos e proporciona uma visão do projeto
sob a perspectiva de suas ameaças. Essa identificação
deve ser feita reunindo a equipe do projeto, e a sua
experiência será fator chave para perceber proativamente
os riscos possíveis. A partir da sua identificação, devem
ser descritos com clareza, declarando sua origem e a
conseqüência que trarão ao projeto caso aconteçam.
b ) Análise - partindo da identificação e da expressão
clara e objetiva dos riscos do projeto, o segundo passo
consiste em analisá-los, seja quanto à probabilidade,
seja quanto ao impacto. Se o risco tiver probabilidade
de 100%, será uma certeza, e não apenas um risco. Se
o risco tiver probabilidade próxima de zero, poderá ser
desprezado. Quanto ao impacto, se for muito reduzido,
talvez não seja necessário dispender esforços na tentativa
de eliminá-lo, esforços esses que devem ser destinados a
outras atividades. A inexperiência de uma equipe é, em
si, um fator de alto risco num projeto. Claro que uma
equipe iniciante deve ter chance de se responsabilizar
por um projeto, e é necessário que isso aconteça para que
se obtenha experiência. Nesses casos, projetos de baixa
complexidade são os recomendados e, então, um processo
de identificação e análise de riscos, bem elaborado e
estudado, trará conhecimentos importantíssimos para
a carreira (digo isso porque vejo que a maioria dos
envolvidos em projetos NÃO realiza tais estudos, e só
obtém experiência após excessivos erros).
86
book.indb 86 31/5/2007 14:23:41

c ) Planejar ações sobre esses riscos -identificados os

riscos, conhecidas as suas probabilidades e o impacto
que podem causar no projeto, é preciso planejar ações
para evitar ou reduzir tal impacto. O processo de
planejamento passa pelas seguintes perguntas:
Conhecemos o risco?
Podemos conviver com ele, se acontecer?
Como é possível atenuar seu impacto?
O que é possível fazer para evitá-lo?
As respostas a essas perguntas levarão o projeto a um conjunto
de planos de ação. Cada risco detectado merecerá uma discussão
sobre ações preparatórias, e quando os riscos do projeto forem
altos demais, talvez seja melhor não aceitar o projeto.
d ) Controle/eliminação dos riscos -identificados os

riscos, analisados e criados os planos de ação, é hora de
colocar as coisas para andar. As ações devem ter data
para começar, e uma vez colocadas em andamento, os
riscos devem ser monitorados. Se determinada ação teve
sucesso, o risco pode ter sido eliminado. Caso não tenha
sido eliminado e surja no meio do projeto, deve então ser
controlado para determinar o mínimo impacto possível
no projeto. Se havia o risco de um atraso, por exemplo, e
o atraso aconteceu, o plano de contingência de ampliar a
equipe ou terceirizar partes do projeto deve ser colocado
em prática, buscando a todo custo manter a data final de
entrega em garantia. Controlar os riscos é o último passo
do ciclo da administração dos riscos, e basicamente se
divide em:
Controlar os planos de ação preventivos;
monitorar a eclosão dos riscos previstos;
responder à eclosão de tais riscos com ações
corretivas;
monitorar o surgimento de novos riscos, não
previstos;
refazer o planejamento de ações;
Unidade 2 87
book.indb 87 31/5/2007 14:23:42

integrar-se ao processo global da gerência do

projeto.
No quadro 2, Modelo de relatório para estudo de riscos de

projetos, são apresentadas diversas questões importantes para
detecção, análise e ações preparatórias contra os riscos do projeto.
Observe:
Estudo de riscos
<nome do projeto>
Equipe de estudo:
Local e data:
Resumo do projeto (escopo, objetivos, estratégias)
Riscos quanto aos benefícios:

- o cliente tem uma idéia exata do resultado a ser obtido?
Descrição:
- ou tem uma idéia aproximada?
- é possível medir os benefícios?
Riscos quanto aos benefícios:

- qual a probabilidade desse tipo de riscos? Descrição:
- qual o seu impacto?
Riscos quanto aos recursos:

- há equipamentos de reserva?
Descrição:
- há pessoal de reserva?
- a tecnologia empregada é inteiramente dominada?
Riscos quanto aos recursos:

Riscos quanto aos custos:

- o financiamento de todo o projeto está garantido? Descrição:
- há um montante de reserva?
Riscos quanto aos custos:

88
book.indb 88 31/5/2007 14:23:42

Riscos quanto ao prazo:

- há fatores internos ou externos, não considerados, que podem afetar o prazo do Descrição:
projeto?

Descrição:
- a equipe de projeto é experiente?

Lista dos 10 riscos mais importantes:
Podemos conviver com eles?
É possível atenuá-los?
É possível evitá-los?
Conclusões quanto aos riscos do projeto:
Anexos
(tabelas, demonstrativos, estatísticas, reportagens, tendências tecnológicas e comerciais, etc.).
Quadro 2 – Modelo de relatório para estudo de riscos de projetos.
Tal modelo pode e deve ser adaptado para as condições de cada

projeto e cada equipe. Toma tempo inicial da equipe do projeto,
mas garantirá ganhos substanciais no decorrer dos trabalhos, seja
por evitar riscos, seja pelo conhecimento aprofundado que trará a
todos os envolvidos com o trabalho que virá pela frente.
SEÇÃO 7 - Ferramenta de apoio para análise e

planejamento
Existem atualmente várias ferramentas computacionais para
apoio na análise e planejamento de projetos. A seguir, são citadas
algumas dessas ferramentas, que poderão ser utilizadas por você
para a prática de gerência de projetos.
Unidade 2 89
book.indb 89 31/5/2007 14:23:42

Um produto muito interessante de apoio ao

gerenciamento de projetos foi desenvolvido com a
Linguagem Java e está disponível para uso gratuito:
O nome do produto é “Free Project Management

Software”, mais conhecido como jxProject, e está
disponível para download no sítio www.jxproject.
com.
Este software é de uso bastante simples, porém de
grande utilidade, pois cria gráficos de Gantt de grande
qualidade com a inclusão de dependências entre
tarefas (o que você verá em detalhes na próxima
unidade deste livro).
Acompanhe a seguir uma tradução que fiz diretamente do

texto de apresentação do jxProject, que está disponível em
inglês no original, no site mencionado acima.
“Se você está buscando um Software de Gerência de
Projetos Gratuito, então você veio ao lugar certo. Você
pode instalar jxProject em todos os seus computadores
sem nenhum custo. Você também pode compartilhar seus
planejamentos de projetos com qualquer um que tenha
acesso à Internet, pois qualquer pessoa na Internet pode
acessar e instalar jxProject. Plataformas Windows, Linux e
Solaris suportam o jxProject, e muitos usuários de Mac OSX
têm relatado seu grande sucesso usando este software. E
como é possível? O aplicativo é financiado por propaganda,
colocada na parte superior à direita da janela do aplicativo,
e tal propaganda é que financia o desenvolvimento e
manutenção desse sistema.”
“História: fundado em 2001 por Peter Hawkins, com
a missão de colocar uma cópia de jxProject em todos
os computadores. Palavras de Peter Hawkins: ‘Tenho
trabalhado em computação desde que me formei em
Engenharia Mecânica em 1986. De 1986 a 1994, trabalhei
nas áreas de engenharia e manufatura, incluindo processos
de controle de manufatura e sistemas CAD/CAM,
geralmente usando UNIX/C. De 1994 a 2001, trabalhei com
várias tecnologias aplicadas a negócios com TCP/IP, HTTP,
RDBMS, OLAP, Java e Windows em indústrias diversas, como
a de produtos de software, saúde, comunicações sem fio e
comércio eletrônico’”.Em outro trecho do seu depoimento,
90
book.indb 90 31/5/2007 14:23:42

Peter Hawkins comenta: “Existem duas tecnologias que

mudaram fundamentalmente a maneira como softwares
devem ser desenvolvidos. São: Arquitetura Orientada e
Objeto e execução Multi-threaded. Tenho visto companhias
desenvolvendo software do mesmo jeito que elas faziam
nos anos 70, ainda que as tecnologias tenham mudado
completamente. A falha em implementar processos de
trabalho que incorporem essas diferentes tecnologias
contribui significativamente para a falta de eficiência no
desenvolvimento de software, hoje em dia. Parte do que
venho fazendo com o jxProject está aperfeiçoando meus
próprios métodos para incorporar tais novas tecnologias.
Vejo positivamente os escritos de Eliyahu M. Goldratt,
cujos livros ‘Theory of Constraints’ e ‘Critical Chain’ nos dão
uma visão mais completa das forças que agem sobre os
processos de negócios.”
O mais popular software comercial de gerência é o da

Microsoft, e se chama Microsoft Project – MSProject.
O MSProject é uma marca registrada e é o produto de
maior sucesso hoje da Microsoft depois do Office.
Você verá que muitas empresas usam essa ferramenta,

que pode ser adquirida nas revendas autorizadas e
está disponível também em www.microsoft.com/
brasil/office/project/standard.asp.
Acompanhe a seguir algumas informações gerais sobre

esse produto, extraídos do sítio da Microsoft. Certamente
tais informações são de âmbito comercial, e cada usuário
deverá verificar com cautela se o produto se ajusta ou não
às suas necessidades, especialmente em produtos como
esse, que não estão voltados para aplicações específicas,
mas sim pretendem atender a uma gama muito extensa
de atividades. Esse tipo de pretensão em softwares tem a
desvantagem de abrigar um número excessivo de módulos
e acessórios, o que acaba por incluir uma complexidade
desnecessária para o usuário.
Unidade 2 91
book.indb 91 31/5/2007 14:23:42

“O Microsoft Office Project Standard 2003 é utilizado pelos

gerentes de projetos que precisam de uma ferramenta de
área de trabalho para gerenciar seus projetos de maneira
independente, mas que não exigem coordenação rigorosa
com outros gerentes de projeto, nem a capacidade
degerenciar recursos a partir de um repositório central.
O Project Standard 2003 foi projetado para aprimorar a
capacidade de organizar o trabalho e para comunicar de
maneira eficiente e sucinta por ferramentas familiares e
fáceis de serem usadas.”
Segundo a Microsoft, “o Project Standard 2003 ajuda a
organizar e gerenciar melhor o trabalho e pessoas, para
garantir que os projetos sejam entregues na data, e que
estejam dentro do orçamento. Com o Project Standard
2003, é possível:
Organizar seu trabalho de maneira mais eficiente, com
recursos e poder de planejamento poderoso.
Controlar e avaliar os impactos do planejamento e
alterações de recursos em todos os planos do projeto.
Personalizar planos para capturar informações específicas
para seus projetos.
Exibir as informações do projeto que você deseja revisar.
Dar enfoque às informações que precisam de sua atenção
com filtros e grupos.”
Algumas facilidades para quem já usa os pacotes da
Microsoft: “O Project Standard 2003 ajuda a projetar seus
planos de projeto e status de maneira eficiente e sucinta,
permitindo que você:
Aumente seu impacto sobre o trabalho, usando Copiar
Imagem para o Assistente do Office para comunicar e
apresentar idéias e informações do Project Standard 2003
em outros programas do Office System como Microsoft
Office Word 2003, Microsoft Office PowerPoint® 2003 e
Microsoft Office Visio® 2003.
Comunique mais claramente, usando novos
aprimoramentos de impressão para imprimir cópias de
uma página de planejamentos de projeto.
Compartilhar informações do projeto com membros da
equipe, salvando arquivos do Project (MPP) em um site
do Microsoft Windows® SharePointTM Services (WSS).
WSS é um componente do Microsoft Windows Server
2003 que permite que os usuários criem sites para
compartilhamento de informações e colaboração de
documentos.
92
book.indb 92 31/5/2007 14:23:42

Iniciar rapidamente as ferramentas que auxiliam na

metodologia de gerenciamento de projetos, para que
você possa configurar agendas e gerenciar recursos de
maneira mais eficiente.
Acessar ajuda online e treinamento, para obter assistência
e suporte atualizado e relevante.
Baixar um modelo da Galeria de Modelos, ao invés de
iniciar um projeto a partir do rascunho.
Usar ferramentas familiares para fazer um trabalho
mais sofisticado e de impacto, sem a necessidade de
treinamento extensivo.
Economizar tempo movendo informações do projeto
facilmente entre o Project 2003 e outros programas do
Office, como Microsoft Office Excel 2003.
Navegar e aprender o Project Standard 2003, rapidamente,

com uma interface atualizada consistente com os
programas do Microsoft Office 2003.”
Esses são outros softwares de gerência disponíveis no

mercado, mas a introdução de novos produtos comerciais
continua todos os dias. Cada empresa ou gestor deve
escolher o que melhor se adapta ao seu estilo:
Pert Chart Expert
WBS Chart Pro
Mindmanager
Primavera Team Play
PMOffice
Open Project System
Rational Project Manager
PS8
Tassc Estimator Manager
Gantt Project (grátis e disponível em www.
ganttproject.org.)
Unidade 2 93
book.indb 93 31/5/2007 14:23:42

Agora que você já concluiu a leitura desta unidade, pratique os

novos conhecimentos, realizando as atividades propostas a seguir
e no EVA.

1) Considere o seguinte problema, colocado por um cliente:
“Atualmente meu pessoal da área comercial emite propostas de serviços
usando planilhas de cálculo Excel e documentos gerados no Word.
Quando o cliente dá o “aceite” na proposta, muitas vezes vários itens dela
foram modificados, porém isso não é ajustado na planilha. O pessoal de
vendas precisa ajustar a lista de produtos a serem entregues, e faz isso
manualmente, gerando uma nova lista. A nota fiscal é emitida à mão,
e finalmente a reposição do estoque é feita por meio de constantes
verificações nas prateleiras. Eu gostaria de automatizar meu processo de
reposição de estoques”.
Em sua opinião, qual é o escopo do problema, segundo uma avaliação
“restrita”, e “qual seria uma visão ampla” desse mesmo problema?
94
book.indb 94 31/5/2007 14:23:43

2) Quando o cliente descreve o seu problema, ele o faz com a própria

linguagem e com uma visão particular, que muitas vezes indica um
caminho de solução. Você sabe que muitas vezes esse caminho pode
não levar à melhor solução. Veja a figura a seguir, que apresenta um
diagrama com a coleta de informações e requisitos do cliente, visando
o melhor entendimento do problema proposto. Considerando esse
diagrama e sua experiência, liste as principais ações que você deve
tomar para chegar ao melhor entendimento do problema.
Problema
definido
ou
Dados Desenho, Hipóteses Objetivos

Defeito a diagrama
eliminar coletados de solução do projeto
ou modelo
ou
Novo Outras
produto informações
3) Qual a função do algoritmo no planejamento do projeto?
Unidade 2 95
book.indb 95 31/5/2007 14:23:43

4) Como você define a data “fatal” do projeto? (veja a figura a seguir)
96
book.indb 96 31/5/2007 14:23:43

5) Riscos são inerentes a qualquer projeto. Por quê?
Síntese
Nesta unidade, você pôde entender a importância da avaliação

e análise prévia em projetos, e como os requisitos do cliente
definem o planejamento geral do projeto, que deve ser elaborado
a partir de um algoritmo. Esse “algoritmo” do projeto permite
traçar um caminho preciso de execução, e muitas vezes você
terá que utilizar ferramentas computacionais para apoiar o
planejamento dos projetos, estabelecendo e desenhando um plano
geral.
Você estudou também a importância do prazo e como os riscos

podem interferir em um projeto. Se forem antecipados, você
poderá criar formas de administrar tais riscos e até mesmo tirar
vantagem deles.
Na próxima unidade, você irá estudar e praticar alguns métodos

gráficos de planejamento de projetos.
Até lá!
Unidade 2 97
book.indb 97 31/5/2007 14:23:43

Saiba mais
Para aprofundar os temas abordados na unidade, sugere-se:
1. Atualmente é importantíssimo estar atualizado sobre o que

acontece no Project Management Institute (PMI), que edita o
PMBOK e tem mais de 150 mil associados em todo o mundo.
Você deve dar uma olhada em: www.pmi.org. Nesse site, você
encontrará artigos variados, conferências, possibilidade de se
associar, comprar livros e saber o que acontece de novo no mundo
da gerência de projetos.
2. Outro local importante no desenho de métodos e teorias sobre

a gerência de projetos é a Sociedade de Gerência de Engenharia
do IEEE (IEEE Engineering Management Society (EMS). Essa
sociedade está no endereço http://www.ewh.ieee.org/soc/ems/, e
o sítio do IEEE geral é o www.ieee.org.
3. Algumas revistas muito interessantes sobre a área de gerência

de projetos de tecnologia estão hoje disponíveis e abertas na
internet. Um exemplo é a revista http://www.worldscinet.com/
compsci.shtml, específica sobre Gerência de Tecnologia. Nesse
mesmo sítio, você poderá encontrar diversas outras publicações
(em inglês) sobre temas de interesse da computação.
98
book.indb 98 31/5/2007 14:23:43

3
UNIDADE 3
Planejamento e elaboração
Conhecer as técnicas de planejamento de projetos.
Analisar essas diferentes técnicas e métodos de

planejamento, com exercícios e exemplos práticos.
Aprender a incorporar o planejamento, por meio de
ferramentas, às atividades iniciais de um projeto.
Verificar que as estimativas de recursos, custos e prazos
são mais coerentes e consistentes quando embasadas
em um planejamento detalhado.
Aprender a dividir tarefas de projeto entre os membros
da equipe.
Seções de estudo
Seção 1 Modelagem do fluxo de atividades

Seção 2 Metodologias de planejamento – Gráfico de
Gantt
Seção 3 Metodologias de planejamento – PERT/CPM
Seção 4 Estimativa de recursos e custos
Seção 5 Recursos humanos em projetos
Seção 6 Divisão de tarefas
Seção 7 O modelo PMI

book.indb 99 31/5/2007 14:23:43


Nesta unidade você vai aprender técnicas de modelagem e
planejamento de projetos. A primeira delas, e mais antiga, é o
Gráfico de Gantt, que permite colocar em um gráfico de barras
todas as atividades e tarefas, distribuídas ao longo do tempo. A
outra técnica é chamada atualmente de PERT/CPM, e permite
verificar quais atividades representam o “caminho crítico” de
um projeto, ou seja, aquele que estabelece a seqüência crítica de
atividades.
Vocês estudará o papel dos membros da equipe de projeto, e

como dividir a tarefa entre eles, visando um trabalho produtivo e
um ambiente de cooperação, considerando diferentes estruturas.
Saberá ainda como o modelo PMI está presente nas técnicas de
gerência de projetos e sua influência nas técnicas modernas de
gestão.
Bom estudo!
SEÇÃO 1 - Modelagem do fluxo de atividades

Para que um projeto seja desenvolvido e se obtenham os
resultados esperados, é preciso ter uma visão geral que permita
avaliar sua viabilidade, os possíveis riscos e suas necessidades
gerais. Certamente, durante esse processo de visão geral, não é
possível detalhar todos os elementos do projeto. Mas é suficiente
para decidir sobre a sua viabilidade e então dar um passo além: o
desenvolvimento do projeto.
Para detalhar o projeto, o primeiro passo é a

sua modelagem e a definição de um fluxo de
atividades. Um modelo de um objeto é uma
representação, é uma simplificação desse
objeto para que você possa entendê-lo de
forma abrangente.
100
book.indb 100 31/5/2007 14:23:44

Por exemplo, a maquete de um prédio é um modelo

de como será o prédio ao ficar pronto. Ele mostra as
partes do edifício, seu aspecto geral, numa proporção
muito boa para que possamos entendê-lo antes de
ficar pronto. Ele não é o prédio, é apenas o modelo do
prédio. No entanto, a gente pode começar a detalhar
mais e mais o modelo desse prédio, como, por
exemplo, fazendo os projetos de instalações elétricas
e de telecomunicações dele. Os desenhos dessas
instalações são representações, bem detalhadas, de
como serão tais instalações, porém continuam sendo
modelos, pois não são as instalações em si.
Modelar, dessa forma, significa representar um sistema, ou parte

dele, em forma física (a maquete, por exemplo) ou simbólica
(desenho do projeto elétrico, por exemplo), de tal maneira que se
possa predizer ou descrever seu comportamento.
Usa-se os modelos para facilitar a visão do futuro

objeto, e ao mesmo tempo usa-se o modelo para
ajudar a construir tal objeto, ou seja, o modelo pode
lhe ajudar a realizar o projeto e chegar ao resultado
final esperado.
Assim, o modelo de representação é uma idealização do sistema

físico, e ele nos auxilia na análise e na solução dos problemas.
Sem os modelos não teríamos a civilização como a conhecemos.
Algumas das principais características dos modelos, e que fazem

com que tenham grande valor, são:
usando um modelo não é preciso trabalhar diretamente

com o sistema físico real, não é preciso construir o
prédio inteiro para mostrá-lo, basta desenhar um fachada
ou construir uma maquete;
é prático e seguro trabalhar com modelos, pois caso as
coisas não se afigurem tão boas, podemos abandonar
tudo no começo;
Unidade 3 101
book.indb 101 31/5/2007 14:23:44

graus de precisão dependerão do aprimoramento do

modelo, ou seja, conforme a gente queira ter maior
precisão de como será o projeto no final, podemos ir
aprimorando paulatinamente sobre o próprio modelo;
redução de tempo na análise, pois não precisamos ter o
projeto pronto para fazer as primeiras simulações;
o modelo abstrai o problema para o campo de domínio
daquele que o analisa, quer dizer, ao modelar um
problema, cada um o faz no campo que tem domínio;
se é um desenhista, faz o desenho, se é um escultor,
cria a maquete, se é um matemático, coloca na forma de
equações, se é um escritor, coloca na forma de uma ficção
ou poema, e assim por diante;
os modelos não são únicos, ou seja, é possível fazer
diversos tipos diferentes de modelo para uma mesma
coisa; no caso do prédio, podemos representá-lo por meio
de uma maquete de madeira e papelão, ou então por uma
maquete eletrônica, ou pelo desenho artístico da fachada,
etc., sendo que todas terão o seu valor;
como o modelo é apenas uma representação, uma
redução do real, ele contém erros, os quais são inerentes
ao seu caráter de redução.
Com essas características você pode perceber que os modelos têm

inúmeras utilidades, não só para planejar a gestão de projetos,
mas para planejar o próprio projeto.
Basicamente considere como utilidades dos modelos

de representação:
modelos ajudam a PENSAR;
permitem COMUNICAR;
é possível PREVER;
permitem CONTROLAR;
nos ajudam a ENSINAR.
102
book.indb 102 31/5/2007 14:23:44

Os modelos para apoio a projetos de engenharia e tecnologia,

conforme Bazzo (1997) podem ser divididos em quatro tipos:
Modelo ICÔNICO – é o modelo que representa com

alto grau de semelhança o sistema físico, seja em duas
dimensões (como no caso das fotos e mapas) ou em três
dimensões (maquetes, esculturas, protótipos).
Figura 3.1 – Exemplo de representação icônica – mapa urbano.
Modelo DIAGRAMÁTICO – tem pouca semelhança

com o sistema físico, e é apresentado por meio de
símbolos, linhas, diagramas. Facilita a compreensão
do funcionamento de uma máquina, um processo ou
sistema, sem dispersar a atenção em detalhes de outra
ordem, e um bom exemplo disso são os fluxogramas
usados nas empresas, mostrando como se dá o
fluxo de processos, ou então o organograma
dessa mesma empresa, que mostra como
se distribuem os cargos e departamentos.
No entanto, por ser uma representação um
pouco mais especializada, serve para
aqueles que conhecem a convenção
usada no diagrama.
Modelo MATEMÁTICO – é um modelo simbólico
abstrato, que está cada vez mais associado aos problemas
de tecnologia avançada, sendo o de aplicação mais
importante na engenharia. Os modelos matemáticos são
os mais poderosos instrumentos de representação, e têm
permitido modelos computacionais sofisticados, porém
são altamente especializados e exigem conhecimento
avançado dos usuários.
Unidade 3 103
book.indb 103 31/5/2007 14:23:44

Modelo GRÁFICO – é o modelo que representa o

comportamento de fenômenos por meio de curvas,
gráficos, facilitando a sua verificação. Há diversos tipos
de gráficos como, por exemplo, de linhas, com barras,
em forma de pizza, etc. (veja, por exemplo aqueles
disponíveis no Microsoft Excel), sendo que o traçado
se dá a partir de um conjunto de valores previamente
definidos pelo usuário – como você estudará, o Gráfico
de Gantt é um modelo gráfico de representação.
Projetos muito pequenos obviamente não precisam de um
modelo, assim como a construção da casinha do cachorro não
precisa certamente de uma planta dessa casinha. Se, no entanto,
a casinha tiver algum grau de complexidade maior, é melhor
desenhar.
Tendo o modelo em mãos pode-se, então utilizar métodos de

planejamento e criar um detalhamento de como se desenvolverá o
projeto.
Observe na figura 3.2, como se dá o fluxo do conhecimento

durante o desenvolvimento de um projeto tecnológico.
Execução,
Idéias, Preparação, Piloto,
MODELO Engenharia
Tempo
Pesquisa Desenvolvimento
SEQUENCIAL
MODELO
SEQUENCIAL
COM Tempo
SOLAPAMENTO
MODELO
COM Tempo
SOLAPAMENTO
Figura 3.2 – Três modelos de fluxo de conhecimento no desenvolvimento de projetos tecnológicos
Veja que as diferenças entre os três tipos de fluxos definem prazos

diferentes de entrega, mas podem depender de como se deu a
contratação e quais os riscos aceitáveis.
Como lidar com a escolha dos modelos?
104
book.indb 104 31/5/2007 14:23:45

A percepção clara de como se dará o desenvolvimento do projeto

permitirá uma boa divisão e detalhamento das atividades.
Na etapa inicial das idéias, chamada de “pesquisa”, são

adquiridos os conhecimentos e informações necessárias
para dar início ao projeto. Não há passagem para a
próxima etapa, chamada de “desenvolvimento”, sem
que todas as atividades da primeira etapa tenham sido
concluídas.
Na etapa do desenvolvimento ocorrem as primeiras
implementações do projeto, como por exemplo, a escrita
das primeiras versões de um software, a criação do
protótipo, os testes iniciais, as simulações, etc.
No modelo seqüencial a passagem para a etapa de
“engenharia” só ocorrerá quando a etapa anterior estiver
concluída.
Na engenharia se dará a implantação do projeto, a
criação de um piloto e sua colocação efetiva no mercado
como, por exemplo, na finalização e entrega de um
novo produto, o que inclui o início do funcionamento e
suporte, ou a colocação em linha de fabricação de uma
nova máquina.
No modelo seqüencial o conhecimento adquirido em
cada etapa não influencia a etapa anterior, e novas
decisões são tomadas apenas com os conhecimentos já
obtidos. Esse modelo de desenvolvimento de projetos é
bastante conservador, e toma maior tempo de realização
total, pois nenhuma atividade segue seu andamento se a
atividade anterior não tiver sido totalmente concluída. A
Unidade 3 105
book.indb 105 31/5/2007 14:23:45

construção civil usa esse modelo seqüencial como padrão

e isso faz sentido, pois o tipo de projeto pressupõe fases
bem divididas e com requisitos de precedência.
Precedência – em projetos as
atividades podem ter relações
Se, no entanto, as etapas sofrerem um certo grau de
de dependência com outras mesclagem, de tal forma que a etapa seguinte tenha
atividades, anteriores, as quais início, enquanto a etapa anterior ainda está na fase de
são pré-requisitos para o seu encerramento, denomina-se tal modelo de seqüencial
início. com solapamento. Conhecimentos e problemas da etapa
seguinte interferem positivamente na etapa anterior,
obrigando revisões dinâmicas do processo. Projetos de
equipamentos ou softwares são exemplos para esse tipo
de modelagem.
A situação radical de desenvolvimento de projetos
é aquela onde as diferentes etapas estão totalmente
entremeadas, chamada de modelo com solapamento,
e percebe-se que os conhecimentos e problemas de
uma etapa interferem nas soluções de todas as outras
etapas, sejam anteriores ou posteriores. O fluxo de
informações precisa então ser contínuo, e esse tipo de
modelo pressupõe ênfase nos ambientes de comunicação
e integração de equipes.
Nesta seção você interagiu com a modelagem do fluxo das
atividades de um projeto, e como podem ser os diversos modelos
de representação, sejam do fluxo ou mesmo do projeto como um
todo. A modelagem permite uma visão estratégica do projeto.
A partir dessa visão estratégica você poderia dar início a sua
operacionalização, e para isso necessitará contar com métodos e
ferramentas, assunto da próxima seção.
SEÇÃO 2 - Metodologias de planejamento – Gráfico de

Gantt
Para fazer o planejamento do projeto é necessário descer nos
detalhes, ou seja, decompor todo o trabalho em suas menores
partes. Essa decomposição significa dividir em tarefas cada vez
menores as diversas atividades do projeto.
106
book.indb 106 31/5/2007 14:23:46

Há duas maneiras de se decompor um projeto:

na forma de um organograma ou “árvore de
decomposição”, ou na forma de tabelas
(Valeriano, 1998).
Tanto a árvore quanto a tabela trazem as mesmas informações,

sendo que a diferença está na forma de apresentação. Veja as
figuras 3.3 e 3.4 a seguir que mostram uma divisão de tarefas do
projeto fictício denominado “Exemplo”.
Na figura 3.3 você pode ver a tabela com o rascunho da divisão

de etapas e com as diversas tarefas que serão necessárias para
compor cada uma delas. Essa tabela permite que sejam anotadas
as diversas tarefas, e tal ferramenta, muito simples, permite que
se escrevam todas as tarefas componentes.
Projeto EXEMPLO
Etapa 1
• Definições
• Compra materiais
• Organiza equipe
• Documentação
• .....
Etapa 2
• Desenho
• Montagem
• Documentação
• .....
Etapa 3
• Teste 1
• Teste 2
• Documentação
• Encerramento
• .....
Figura 3.3 – Tabela com divisão de tarefas de um projeto “Exemplo”.
Unidade 3 107
book.indb 107 31/5/2007 14:23:46

A árvore da figura 3.4 apresenta as mesmas tarefas e etapas,

porém numa representação espacial, o que para algumas pessoas
facilita a compreensão dos diversos componentes. É uma questão
de escolha.
Projeto EXEMPLO
Etapa 1 Etapa 2
Definições Compra Org. Equipe Documentação Desenho Montagem Documentação
Etapa 3
Teste 1 Teste 2 Documentação Teste 1
Figura 3.4 – O mesmo projeto da figura 3.3 em uma divisão por árvore de decomposição.
Com esse tipo de divisão de tarefas é possível imaginar e localizar

todos os componentes do projeto. A partir dessa divisão você
iniciará a construção do planejamento para execução e gestão do
projeto.
Como planejar o desenvolvimento do projeto?
Para tal, a seguir você estudará três métodos para planejar o

desenvolvimento do projeto:
Gráfico de Gantt,
Diagramas PERT e
Método do Caminho Crítico – CPM.
São métodos que vêm sendo desenvolvidos nos últimos cem
anos, especialmente após a Segunda Guerra Mundial, tendo tido
grande ênfase nos anos recentes com os projetos que envolvem
desenvolvimento de software e sistemas de alta tecnologia.
108
book.indb 108 31/5/2007 14:23:46

a) Gráfico de Gantt - O gráfico de Gantt também é chamado de

gráfico de barras. Foi concebido pelo engenheiro norte-americano
Henry L. Gantt (1861-1919) (Hinojosa, 2003) para tentar
resolver o problema da programação de diferentes atividades
industriais, distribuindo-as no calendário de maneira que o
conjunto de atividades pudesse ser visualizado, com a facilidade
de se perceber, pelo tamanho de uma determinada barra, qual
seria a duração da atividade que tal barra representaria. Ou seja,
o início da barra marcaria a data de começo da

atividade e o final da barra seu término, sendo
que a barra se estende por todo o período
compreendido entre as duas datas.
A figura 3.5 mostra um exemplo de Gráfico de Gantt

desenhado em planilha (neste caso com o auxílio do
MS Excel). Veja que o projeto se estende do dia 14/
março até 17/abril, e é constituído de quatro etapas,
havendo dois projetistas neste trabalho. As barras
pretas mostram os prazos previstos para a execução
de cada Etapa/Tarefa.
Figura 3.5 – Exemplo de Gráfico de Gantt.
Este tipo de gráfico permite desenhar uma barra com

a duração prevista, e junto a ela outra barra que vai
sendo preenchida conforme as tarefas vão sendo
cumpridas, de tal forma que é possível acompanhar
o andamento do projeto e a proporção de atraso ou
quanto se está adiantado em relação ao previsto.
Na figura veja a barra cinza da Etapa 1 mostrando
o andamento do projeto até aquele momento. Se
você estiver com o gráfico nessa posição no dia 21 de
março, então perceberá que o projeto está cumprindo
seu prazo.
Unidade 3 109
book.indb 109 31/5/2007 14:23:46

Como você pode ver nesse exemplo, no eixo horizontal

apresenta-se um calendário com a escala de tempo pertinente
e mais adequada ao projeto (dias, semanas, meses, etc.). No
eixo vertical estão incluídas as atividades que serão executadas,
sendo que a barra de duração da atividade é pintada no eixo
horizontal ocupando o prazo previsto. O formato da barra,
sua cor, grossura da linha, etc., depende apenas de quem a
está construindo e da facilidade de visualização que se requer.
Projetos com equipes muito grandes costumam imprimir tais
gráficos em painéis grandes, para que num único relance se
possa ver as etapas, como vai indo o dia-a-dia do projeto, os
principais responsáveis, datas de início e fim, etc.
O gráfico que Henry Grantt criou tornou-se imensamente

popular e passou a ser utilizado, sem grandes modificações, no
gerenciamento de todos os tipos de projetos em todo o mundo.
Umas das desvantagens apontada era que não interligava uma
atividade à outra, ou seja, não deixava clara a interdependência
entre as diferentes atividades. Versões recentes desse tipo
de gráfico passaram então a utilizar setas de ligação entre
as diferentes barras, para mostrar esse tipo de dependência,
especialmente a partir do uso de softwares como o MS Project.
Porém não é necessário um software para se construir o Gráfico

de Gantt, e justamente por isso é tão popular e essa é uma
das suas grande vantagens: o traçado simples e direto. Com
isso passa a ser muito útil nas etapas iniciais de planejamento
(Hinojosa, 2003), mas quando o projeto passa a se desenvolver
e modificações no planejamento acontecem, o gráfico começa a
se tornar confuso. A replanificação exige que se faça um novo
gráfico. Também uma desvantagem é que o gráfico de Gantt não
apresenta custos das etapas, e dificilmente se adapta a projetos
muito complexos com múltiplas tarefas simultâneas. Nesses casos
se usam outros métodos, como PERT e CPM.
A seguir acompanhe o desenvolvimento de um exemplo simples

para aplicação do Gráfico de Gantt.
110
book.indb 110 31/5/2007 14:23:47

Vamos supor a construção de uma área de lazer

com 30 metros quadrados, churrasqueira, pia e
banheiro. E é um exemplo suficientemente comum
para explorarmos todas as questões relacionadas ao
gerenciamento de um projeto que envolve equipe.
A idéia partiu do cliente, que pretende fazer uma
comemoração, e nos deu o prazo de oito semanas
para entregarmos a obra pronta, sendo que todos os
materiais para a obra são fornecidos por ele.
Vamos começar fazendo a decomposição do projeto
em tarefas, e para isso utilizaremos a decomposição
em tabela. Chamaremos este novo projeto de
“Churrasqueira”. Proponho a seguinte divisão:
Projeto CHURRASQUEIRA
Etapa 1 – Preparação do terreno
• Limpeza do terreno
• Medições e marcações
• Escavações
Etapa 2 – Fundações
• Montagem das madeiras de caixaria
• Montagem das ferragens da fundação
• Concretagem
Etapa 3 – Alvenaria
• Construção das paredes
• Montagem da churrasqueira
• Rebocos
Etapa 4 – Telhado
• Montagem da estrutura de madeira
• Colocação de Telhas
Etapa 5 – Piso
• Concretagem do piso
• Assentamento da Cerâmica do piso
Etapa 6 – Carpintaria
• Colocação de janelas
• Colocação de portas
Etapa 7 – Instalação Hidráulica
• Tubulações de água
• Colocação da caixa dágua
Unidade 3 111
book.indb 111 31/5/2007 14:23:47

• Montagem de torneiras, descargas, acessórios

• Esgoto
Etapa 8 – Instalação Elétrica
• Instalação das Tubulações
• Passagem dos cabos alimentadores
• Montagem das tomadas, luminárias e quadros
Etapa 9 – Pinturas e acabamento
• Pintura externa
• Pintura interna
• Limpeza final e entrega da obra
Figura 3.6 – Tabela com divisão de tarefas do projeto “Churrasqueira”.
Ao analisar a divisão acima percebemos que o projeto

não é tão simples como podia parecer à primeira vista,
pois há inúmeras tarefas, as quais ainda poderiam ser
mais detalhadas.
Por ser um exemplo, ficaremos com o que está definido
acima. Considerando essas nove etapas vamos construir
um gráfico de Gantt simples e útil para nosso projeto.
Vamos começar com uma planilha dividida em nove
barras horizontais, onde anotaremos as etapas, e oito
colunas onde anotaremos as semanas, como o da figura
3.7 abaixo.
Neste desenho incluí algumas divisões para facilitar
nosso trabalho, tais como a divisão das colunas das
semanas nos seus sete dias, com marcação do sábado
(S) e do domingo (D), e nas barras horizontais fiz uma
divisão para marcarmos o prazo previsto (Prev) e outra
divisão para depois podermos anotar o realizado (Real),
conforme o projeto for andando. Além disso, no espaço
reservado para escrever o nome das etapas, há também
um questionamento sobre quem irá realizar aquela
tarefa, ou seja, quem é o responsável por aquela tarefa
específica.
Isso é muito útil para poder distribuir as
responsabilidades, e também é útil para aquele que vai
trabalhar nela, pois pode compreender sua função no
conjunto das atividades bem como o impacto de seu
prazo sobre o restante.
112
book.indb 112 31/5/2007 14:23:47

Figura 3.7 – Planilha para Gráfico de Gantt do projeto “Churrasqueira”.
O prazo de dois meses parece ser bastante enxuto,

então teremos que ser cuidadosos na distribuição
dos prazos para termos sucesso. E vejam que neste
projeto o sucesso significa acabar antes do dia da
comemoração, não sendo admitida outra possibilidade.
A equipe que trabalhará conosco neste projeto será
constituída, além do gestor (você), também de um
mestre de obras, um pedreiro, um servente, um
carpinteiro, um eletricista, um encanador e um pintor.
São oito pessoas, sendo que alguns estarão presentes
apenas em algumas etapas da obra. Fazendo uma
reunião preliminar com todos os membros da equipe
estimamos os seguintes prazos de execução para cada
etapa:
Projeto churrasqueira Prazos estimados pela equipe Dependência

Etapa 1 – Preparação do terreno 2 dias -
Etapa 2 – Fundações e estrutura 1 semana Etapa 1
Etapa 3 – Alvenaria 4 semanas Etapa 2
Etapa 4 – Telhado 1 semana Etapa 2
Etapa 5 – Piso 2 semanas Etapa 4
Etapa 6 – Carpintaria 1 semana -
Etapa 7 – Instalação Hidráulica 1 semana Etapa 4
Etapa 8 – Instalação Elétrica 1 semana Etapa 4
Etapa 9 – Pinturas e acabamento 2 semanas Etapas 2 e 4
Figura 3.8 – Estimando prazos para as etapas do projeto “Churrasqueira”.
Se repararmos nessa estimativa de prazos, chegamos

a 13 semanas e 3 dias, o que supera a data final que
dispomos. Porém, sabemos que algumas atividades
podem ser feitas em paralelo, e nesse sentido é que
Unidade 3 113
book.indb 113 31/5/2007 14:23:47

vamos traçar nosso primeiro esboço de gráfico de

Gantt, que está apresentado na figura 3.9, assumindo as
dependências ainda de forma muito simplificada.
Figura 3.9 – Gráfico de Gantt do projeto “Churrasqueira” – primeiro esboço.
Algo que se nota neste gráfico é que, para adequar o

projeto ao prazo total, necessitamos colocar algumas
atividades em paralelo, e isso é muito natural. O
serviço do telhado começou mais ou menos no meio
das atividades de alvenaria, e o piso está dividido em
duas fases, sendo que a segunda fase aparece apenas
após o encerramento de todo o trabalho da alvenaria.
Da mesma forma as instalações hidráulicas e elétricas
estão divididas em duas etapas. Esse projeto é simples,
então não é difícil perceber essas possibilidades de
trabalho em paralelo para otimizar o tempo e a equipe,
porém se alguém que não conhece o projeto der uma
olhada neste gráfico, não entenderá porque há uma
interrupção na instalação hidráulica em determinado
ponto, e nem porque ela começa na quinta semana e
não apenas na sétima, por exemplo. Uma divisão mais
detalhada facilitaria essa visão externa, e certamente
também facilitaria a própria gestão do projeto. Uma
nova opção de gráfico de Gantt deste mesmo projeto
está apresentada na figura 3.10.
114
book.indb 114 31/5/2007 14:23:48

Figura 3.10 – Gráfico de Gantt do projeto “Churrasqueira”.
Este gráfico detalha melhor algumas fases, que

permite que se veja a dependência entre um serviço
e outro. A dependência não está explícita no gráfico,
porém alguém com mais experiência perceberá que
o serviço de telhados depende da finalização da
construção das paredes, e após o telhado ficar pronto
serão colocadas as tubulações elétricas e hidráulicas.
A concretagem do piso poderá ser feita também
após a conclusão do telhado, e começaremos a
pintura externa após a colocação das janelas e portas.
Depois da conclusão do piso faremos os acabamentos
das instalações elétricas, passando todos os cabos
e instalando tomadas e luminárias, bem como
instalando acessórios da parte hidráulica. Por fim
faremos a pintura externa e limpeza geral da obra.
Este exemplo é obviamente uma suposição de serviço, mas ele

espelha exatamente o que ocorre em todos os projetos. Você pode
ter muitas dúvidas quando o serviço está por começar, e então
é necessário fazer alguns desenhos iniciais e avaliar se será útil
a divisão que inicialmente foi pensada. Caso não seja, ou caso
você perceba que é possível detalhar um pouco mais, então é
importante fazê-lo.
Unidade 3 115
book.indb 115 31/5/2007 14:23:48

No gráfico apresentado foi também preenchido o nome da pessoa

da equipe responsável por cada etapa. Desta forma é possível
definir as atividades de cada um, e assim o trabalho individual
será otimizado. O eletricista, por exemplo, poderá participar de
vários outros projetos, bastando para isso preparar sua agenda
conforme a distribuição de tarefas em cada projeto.
Volte agora ao gráfico da figura 3.10 para analisar outra

característica desse tipo de diagrama. Apesar de você saber que
uma atividade deve começar apenas quando outra terminar (como
por exemplo, o telhado somente após as paredes e estrutura
estarem montadas), isso não está tão evidente no desenho. A
pessoa que não conhece o projeto não perceberá esse tipo de
dependência. Foi preciso avançar na construção desse tipo de
diagramas e introduzir relações de dependência, o que se dá em
todos os modernos softwares de geração de gráficos de Gantt.
Como são as relações de dependência entre as

atividades no gráfico de Gantt?
É possível serem criadas dependências de quatro tipos entre

atividades:
1. Dependência fim-início, quando o início de uma

Atividade B só é possível após o fim da Atividade A;
2. Dependência fim-fim, quando o final da Atividade B

deve, necessariamente, coincidir com o fim da Atividade
A;
3. Dependência início-início, quando o início da Atividade

B deve, necessariamente, coincidir com o início da
Atividade A;
4. Dependência fim-início com folga, quando o início de

uma Atividade B só é possível após o fim da Atividade
A, porém há um tempo de folga para o início da
Atividade B.
116
book.indb 116 31/5/2007 14:23:48

A representação gráfica dessas relações de dependências é feita

com setas interligando as extremidades das atividades, como se vê
nas figuras seguintes.
Atividade A
Atividade B
Figura 3.11 – Dependência Fim-Início num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 3.12 – Dependência Fim-Fim num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
Figura 3.13 – Dependência Início-Início num Gráfico de Gantt, onde B depende de A.
Atividade A
Atividade B
FOLGA
Figura 3.14 – Dependência Fim-Início com folga num Gráfico de Gantt, onde B depende de A.
A introdução das setas que mostram dependências foi um

grande avanço na visualização do planejamento, antes apenas
possível pela distribuição das barras num gráfico com escala de
tempo. Essa introdução permitiu perceber que as setas poderiam
indicar algo mais no gráfico, e daí em diante um novo conjunto
de gráficos e diagramas foi desenvolvido, e chega-se então ao
Método do Caminho Crítico (CPM) e diagramas PERT.
Unidade 3 117
book.indb 117 31/5/2007 14:23:49

SEÇÃO 3 - Metodologias de planejamento – PERT/CPM

Após a Segunda Guerra Mundial, surgiu
um projeto do governo norte-americano
que acabou causando profunda influência
na disciplina de gestão de projetos. Era o
projeto Polaris, da Marinha, para produzir
uma série de submarinos nucleares em cinco
anos.
Esse projeto iria envolver mais de 9000

Figura 3.15. Submarino Polaris – extraída de http://
empreiteiros diferentes, e devia ter o “de
stores.ebay.com/The-Silent-Service-Submarine-
Store
acordo” do Congresso, o que teve um
enorme impacto tal o clima de desconfiança que o projeto gerou,
pois sabia-se que os prazos e custos de projetos militares eram
constantemente estourados (Prado, 1998). Para reverter esse
quadro de desconfiança e ter o projeto aprovado, foi criada uma
equipe especialmente para planejar e fiscalizar o seu andamento
e a construção dos submarinos. Essa equipe foi denominada
Program Evaluation and Review Task Force, gerando a sigla
PERT, que posteriormente viria a denominar a técnica de
representação do planejamento do projeto por eles desenvolvida
– Program Evaluation and Review Technique - PERT.
O projeto Polaris supreendeu e foi desenvolvido em apenas três

anos, o que atraiu grande atenção para a equipe e para a técnica
que eles desenvolveram para a gestão de projetos. Na década de
60 muitas melhorias foram incrementadas à técnica, incluindo
o Critical Path Method – CPM (Método do Caminho Crítico),
e todas as técnicas de representação de projetos por redes de
atividades e dependências acabaram sendo reunidas atualmente,
no que se denomina PERT/CPM.
A idéia dessas técnicas era criar um diagrama que verificasse

os pré-requisitos de cada atividade, de forma que se pudesse
compreender qual seria o conjunto de atividades, com seus prazos
e em seqüência cronológica, de tal maneira que fosse possível
traçar o “caminho crítico” do projeto, ou seja, a seqüência de
atividades que determinariam o menor tempo possível do projeto.
118
book.indb 118 31/5/2007 14:23:50

Aonde se pode aplicar as técnicas PERT/COM?
Entre as várias aplicações das técnicas PERT/CPM pode-se

citar:
definir as atividades de um projeto;

determinar a duração de cada atividade;
com base nos prazos de cada atividade, buscar o prazo
mínimo para o projeto total;
encontrar as ligações temporais entre as diversas
atividades, ou seja, verificar os tempos de folga entre
atividades seqüenciadas;
identificar quais atividades são críticas no projeto, ou
seja, aquelas cujo prazo determina o andamento de todo
o projeto, e que se ocorrer um problema qualquer de
atraso, todo o projeto sofrerá retardo;
determinar qual é a seqüência crítica do projeto
considerando as atividades críticas, ou seja, determinar a
seqüência de atividades críticas que perfazem o “caminho
crítico” do projeto;
verificar os tempos de folga que existem entre as
atividades, de tal modo que se possa trabalhar com esses
prazos durante a execução do projeto sem afetar o prazo
total.
Diferente do Gráfico de Gantt, onde cada

atividade ocupa uma barra do painel, nessas
técnicas de revisão e do caminho crítico são
usadas setas para compor o diagrama.
Observe o desenho da figura a seguir (figura 3.16), onde cada seta

representa uma determinada atividade (atividade A, atividade B,
....) e os círculos representam um evento ou nó, que é a conclusão
de uma ou mais atividades..
Unidade 3 119
book.indb 119 31/5/2007 14:23:51

Figura 3.16 – Diagrama de setas simples com nós, que denotam a conclusão de atividades.
Como você pode ver no diagrama, a duração de cada atividade

não está representada pelo comprimento da seta, pois os
comprimentos dessas não têm escala. O que mais importa aqui
é verificar qual atividade depende de outra, sua precedente. No
caso desse exemplo da figura 3.16 você pode ver que a atividade B
só ocorre depois de A, e D ocorre depois de B. No entanto, para
que a atividade H possa acontecer, necessariamente você precisa
ter concluídas as atividades C e D. Ou seja, o diagrama de setas
define uma lógica para a seqüência de execução.
As diferenças entre os métodos como o Gráfico de Gantt e o as

técnicas PERT/CPM acontecem devido ao tipo de representação
e de escala utilizadas. No Gráfico de Gantt existe uma escala
de tempo bem definida, mas a representação das precedências,
da vinculação entre diferentes atividades e do “caminho crítico”,
nem sempre são evidentes.
Para entender como se dá na prática as técnicas PERT/CPM

primeiramente acompanhe uma comparação gráfica entre os
diferentes métodos, e então evoluirá seu estudo a partir desse
ponto.
Na figura 3.17 há duas representações para projeto

“Churrasqueira”, que você já estudou na seção
anterior. Na parte superior da figura veja o Gráfico
de Gantt, exatamente o mesmo que foi estudado
anteriormente.
120
book.indb 120 31/5/2007 14:23:51

Figura 3.17 – Diagrama de setas com escala e acima o Gráfico de Gantt do projeto “Churrasqueira”.
Na parte inferior da figura está um representação por

diagrama de setas do mesmo projeto, onde as letras
denominam as atividades, conforme a seguinte tabela
de correspondência:
A PREPARAÇÃO DO TERRENO
B FUNDAÇÕES
C ALVENARIA - PAREDES
D ALVENARIA - REBOCO E CERÂMICAS
E TELHADO
F PISO
G CARPINTARIA
H TUBULAÇÃO HIDRÁULICA
I INSTALAÇÃO HIDRÁULICA
J TUBULAÇÃO ELÉTRICA
K INSTALAÇÃO ELÉTRICA
L PINTURA EXTERNA
M PINTURA INTERNA E ACABAMENTO
Figura 3.18 – Tabela com lista de atividades.
O diagrama de setas do projeto “Churrasqueira” da

figura 3.17 está construído dentro da escala de tempo
definida no gráfico de barras que está acima dele, como
você pode ver. Percebam que cada nó está colocado
exatamente na coluna que representa o início ou final
de uma determinada atividade. Repare, por exemplo,
na atividade E – Telhado: o nó onde começa a seta está
no início do dia 7 de abril, e o nó no final da seta está no
dia 13. A seta E então compreende 7 dias. Mesmo para
Unidade 3 121
book.indb 121 31/5/2007 14:23:51

um projeto simples como este o desenho com setas

acaba se tornando razoavelmente complexo, e de fato
não nos mostra muitas coisas.
Da forma como foi apresentado não lhe parece

um modelo diagramático ruim, e que o Gráfico de
Gantt estava bem melhor?
Acontece que a riqueza desse tipo de diagrama não está em

representar na escala temporal o desenvolvimento do projeto, mas
sim nos mostrar os seus pontos críticos de atraso.
Para você entender melhor isto, veja que a seguir são

feitas duas modificações no diagrama de setas do
projeto “Churrasqueira”:
Redesenho do diagrama para que fique mais claro,
retirando a escala de tempo;
Para não perder a referência das atividades quanto
ao seu prazo estimado, sob cada seta é colocado o
número de dias de sua duração.
Figura 3.19 – Diagrama de setas modificado do projeto “Churrasqueira”.
Com essas duas modificações simples se obtem o

diagrama da figura 3.19 (apesar das atividades A, B e C
serem diferentes, estas são reunidas numa seta para
simplificar o diagrama).
122
book.indb 122 31/5/2007 14:23:51

Bem, apesar de ser um desenho limpo, ainda não é

suficientemente claro para ajudar no planejamento do
projeto, não é mesmo?
Que conceitos e símbolos são utilizados nos

diagramas PERT/COM?
Para construir os diagramas PERT/COM mais objetivos e

limpos são utilizados alguns conceitos e símbolos.
Com tais símbolos, apresentados no quadro da figura
a seguir, você poderá então fazer a construção final
do diagrama do projeto “Churrasqueira” e partir para
sua análise como ferramenta de apoio na gestão de
projetos.
Figura 3.20 – Quadro com simbologia e nomenclatura utilizados em diagramas PERT/CPM.
Unidade 3 123
book.indb 123 31/5/2007 14:23:51

Como você pode ver na figura 3.20, alguns novos conceitos estão
apresentados, tais como “data mais cedo e mais tarde”, folgas e
símbolos com informações:
Data mais cedo (dc) - representa a primeira data onde

pode ocorrer o evento.
Data mais tarde (dt) - é a última data em que esse
evento pode ocorrer, sem afetar o prazo do projeto.
A “data mais tarde” existe quando há uma folga no
projeto, e a folga específica da atividade é chamada de
“folga”.
A sequência de atividades que define o prazo crítico
do projeto, ou seja, aquela seqüência onde alterações
implicam alteração do prazo total do projeto, é chamada
de “caminho crítico”.
Saiba que você ainda poderia simplificar um pouco
mais o desenho. Observe que o nó ao final da atividade
D, o nó que dá origem à atividade L e o nó ao final da
atividade G podem ser reunidos em um só, sem alterar a
ordem das atividades. Assim o diagrama passaria a ser:
Figura 3.21 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 1.
Esse diagrama pode ser simplificado mais uma vez. A

seta fantasma que une os nós do final da atividade E e
do início da atividade G pode ser suprimida, juntando
124
book.indb 124 31/5/2007 14:23:52

então esses dois nós. Com um pequeno rearranjo das

setas e dos nós teríamos então, o desenho simplificado do
diagrama, conforme apresentado na figura 3.22.
Repare como o diagrama ficou mais simples e objetivo, e como
foi alterado desde o original. É importante reparar que todo
esse processo de construção foi realizado aqui para demonstrar
a construção do diagrama PERT/CPM, mas na prática você
pode desenhá-lo diretamente, apenas sabendo as atividades, suas
precedências e respectivas durações.
As ferramentas computacionais fazem isso

automaticamente. Acompanhe a figura:
Figura 3.22 – Diagrama PERT/CPM do projeto “Churrasqueira”, simplificação 2.
Tendo agora o diagrama desenhado, o próximo passo

será introduzir os símbolos que permitem colocar as
informações detalhadas do plano.
Em primeiro lugar se coloca os nós e para cada um se
dá um “nome”, neste caso uma dezena para cada nó de
forma que, se precisar posteriormente inserir algum novo
nó, use a numeração intermediária (ver figura 3.23).
Como você pode perceber, todas as datas de início, mais
cedo e mais tarde, estão em branco. Veja que é assumida
a data mais cedo para o nó 10 como sendo “1”, ou seja,
o “primeiro dia” da atividade ABC, e a partir daí conte
as datas em dias (mas não há problema se assumir a data
mais cedo como “0”).
Unidade 3 125
book.indb 125 31/5/2007 14:23:52

Figura 3.23 – Diagrama projeto “Churrasqueira”, detalhamento 1.
Uma vez que você tenha a primeira “data mais cedo”

definida, pode-se ir preenchendo as dc dos outros nós.
A dc do nó 20 será a dc do nó 10 mais a duração da
atividade ABC, ou seja,
dc20 = dc10 + duraçãoABC
E assim, fazendo todas as contas até o último nó, você
obterá a data final do projeto, como apresentado na
Figura 3.24.
Figura 3.24 – Diagrama projeto “Churrasqueira”.
Preenchido completamente o último nó, é possível fazer o

caminho inverso do diagrama preenchendo agora a “data
mais tarde” de início de cada atividade. A data mais tarde
do nó 70, dt70 , será encontrada subtraindo-se a duração
da atividade M, da seguinte forma:
126
book.indb 126 31/5/2007 14:23:52

dt70 = dt80 – duraçãoM

Adotando, assim, o mesmo procedimento para todos os
nós, você obterá como resultado a figura 3.25, a seguir.
Figura 3.25 – Diagrama PERT/CPM final do projeto “Churrasqueira”.
No diagrama veja que o caminho de atividades onde não

há folga define o “caminho crítico” das atividades do
projeto. Sobre esse conjunto de atividades o gestor deve
prestar atenção especial e preparar suas estimativas de
recursos e custos.
Enquanto no Gráfico de Gantt é possível ver

a escala temporal claramente, bem como, a
pessoa responsável por cada atividade e também
acompanhar o andamento do projeto ao longo
do tempo (preenchendo uma barra das tarefas
“executadas”); no diagrama PERT/CPM é possível
determinar a seqüência de atividades com suas
precedências, e perceber claramente quais as
atividades que podem afetar todo o andamento
do projeto.
Nesse sentido é importante ter as duas ferramentas
como instrumentos objetivos de apoio ao gestor.
Uma vez compreendido o estudo das seções iniciais desta

unidade, você concluiu o estudo de ferramentas de apoio para o
planejamento das etapas de um projeto.
Unidade 3 127
book.indb 127 31/5/2007 14:23:52

E uma vez tendo o planejamento realizado e os prazos estimados,

é preciso agora estimar os recursos e custos necessários ao
projeto. Siga em frente!
SEÇÃO 4 - Estimativa de recursos e custos

Tendo um planejamento do projeto, é possível estimar os
recursos necessários para ele. Bem, estimar não é uma ciência
exata. DeMarco (1991), propõe algumas definições um pouco
diferentes, tais como:
Estimativa é a previsão mais otimista que não tem

uma probabilidade zero de tornar-se realidade.
Uma estimativa é uma previsão que tanto pode
estar acima quanto abaixo do resultado real.
Essas definições soam estranhas, mas dizem muito sobre o ato

de estimar: é um “chute” que pode marcar o gol ou apenas passar
mais ou menos perto. Precisamos estimar o melhor possível para
evitar riscos durante o projeto.
Quais são os recursos necessários a um projeto?
Quanto aos recursos necessários a um projeto, basicamente há os

seguintes:
Materiais – são os produtos necessários para

confeccionar o projeto, tais como matérias-primas,
produtos manufaturados, componentes, hardware, etc.;
Equipamentos – são as máquinas e ferramentas
necessárias para poder trabalhar as matérias-primas,
escrever o código de um software, facilitar uma
construção, etc.;
128
book.indb 128 31/5/2007 14:23:52

Pessoal – os recursos humanos aparecem como o

principal requisito em projetos, especialmente em
projetos de tecnologia, na próxima unidade discutiremos
este item;
Financeiros – são os custos do projeto, que advém dos
gastos relativos a materiais, equipamentos, locações,
transportes, pessoal, licenças, fretes, direitos autorais,
etc.; a estimativa de custos é o assunto da próxima seção.
Como você já acompanhou, o planejamento do projeto tem
um foco muito intenso no prazo geral, pois como projetos
são trabalhos com data marcada para acabar, o prazo é algo
determinante. Para realizar o planejamento se faz uma divisão de
tarefas, e essa divisão é o fator que irá permitir estimar recursos,
tarefa por tarefa.
Dessa forma se pode partir da tabela onde as tarefas foram

divididas e incluir colunas específicas para descrever recursos
necessários.
Unidade 3 129
book.indb 129 31/5/2007 14:23:53

A tabela apresentada na figura a seguir é um exemplo

de relatório a ser preenchido no início do projeto. Este
exemplo partiu de tabela anterior.
Projeto CHURRASQUEIRA Recursos necessários

Etapa 1 – Preparação do terreno
• Limpeza do terreno Tratores (dois dias)
• Medições e marcações Topógrafo
• Escavações Tratores (um dias)
Etapa 2 – Fundações
XX dúzias de madeira para caixaria;
• Montagem das madeiras de caixaria
Pessoal para montagem da caixaria;
• Montagem das ferragens da fundação XX barras de ferro;
• Concretagem XX caminhões de concreto
Etapa 3 – Alvenaria
XX milheiros de tijolos;
• Construção das paredes Xx sacos de cimento;
Etc.
• ........ ...........
Figura 3.26 – Divisão de tarefas com estimativa de recursos.
Para cada projeto específico deverá ser construída

uma tabela exclusiva, sendo que a coluna dos recursos
definirá uma lista de necessidades. A próxima etapa é
realizar a estimativa dos custos.
Como realizar a estimativa de custos?
A distribuição de custos do projeto é feita num gráfico chamado

de “cronograma físico-financeiro”.
Aproveita o gráfico de barras que você estudou no Gráfico de

Gantt, sendo que os custos do projeto podem ser distribuídos ao
longo do tempo de duração do projeto. Para cada item, definido
nos recursos estimados para o desenvolvimento do projeto, é
130
book.indb 130 31/5/2007 14:23:53

feita uma estimativa de gastos. O uso do gráfico de barras é

interessante nesse caso, devido à clareza visual de apresentação.
A seguir, acompanhe um exemplo para entender melhor esse tipo

de cronograma.
Na figura 3.27 é apresentado o Gráfico de Gantt de

um projeto hipotético com sete atividades – Tarefas A
até G – cujos trabalhos transcorrem em 16 semanas,
aproximadamente quatro meses. Tendo estimados
os recursos necessários para desenvolver cada
tarefa, os custos podem ser distribuídos por tarefa
e por unidade de tempo, nesse caso por semana.
Sobre o próprio gráfico os valores são anotados,
semanalmente, e se tem aí o Cronograma
Físico-Financeiro.
Figura 3.27 – Estimando custos – cronograma físico-financeiro.
Fazendo a estimativa de custos por atividade e por

unidade de tempo é possível chegar a valores mais
próximos do real.
Quanto maior a divisão das tarefas, melhor. Anotados
todos os valores fazemos a somatória, também por
unidade de tempo.
A cada semana se chega a um valor total, conforme
você pode ver na última linha do gráfico.
Com tais valores se pode estimar o valor total de custos
do projeto, apresentado no canto inferior direito da
figura.
Unidade 3 131
book.indb 131 31/5/2007 14:23:53

Outra visualização dos custos desse mesmo projeto é

apresentada na figura 3.28, a qual decorre dos valores
obtidos na estimativa do gráfico de barras.
Figura 3.28 – Gráfico de linha do cronograma físico-financeiro.
Percebe-se pelo gráfico da figura 3.38 que o projeto

deverá dispor de recursos financeiros bem maiores do
que a média nas semanas 6 e 7. Fazendo essa análise
pode-se retornar ao planejamento do projeto e, caso
necessário, alterar a duração das tarefas que impactam
nesses valores, nesse caso especialmente a Tarefa C. Se
não for possível alterar, então o caixa do projeto deverá
estar preparado para tal fluxo.
Uma vez que você compreendeu como realizar a estimativa

dos cursos, na próxima seção veja como estruturar os recursos
humanos em projetos.
132
book.indb 132 31/5/2007 14:23:53

SEÇÃO 5 - Recursos humanos em projetos

Para entender este tema que tal pensar um campeonato de futebol
como um projeto:
Em um campeonato de futebol, onde cada time

traça seus objetivos, contrata jogadores, treinador,
busca recursos e tem datas definidas para chegar aos
resultados.
Há inúmeros riscos, pois é uma competição com
muitas variáveis. Sabe-se que uma questão muito
importante, sempre discutida pelos comentaristas e
que também é a conversa do início de cada semana
após uma rodada emocionante, trata da formação e
do entrosamento dos jogadores dentro de campo.
Cada jogador tem sua função, sabe-se mais ou menos
sobre suas qualidades, e alguns são reconhecidos por
sua competência. No entanto, em cada partida há um
comportamento diferente, há um jeito diferente de
jogo, e simultaneamente encantamentos e decepções.
Certamente os projetos de pesquisa, de

engenharia, de software, não são assim tão
famosos nem tão visíveis, mas muitas vezes
são bastante emocionantes. E vão depender do
espírito de “time” na equipe. Constituir uma
equipe é relativamente fácil, constituir um time,
não tanto.
A equipe é constituída a partir

da definição de funções, então é
possível determinar as características
necessárias de um indivíduo para
que preencha tal função. Grandes
companhias preparam uma lista
de requisitos mínimos para que
se procurem funcionários para
determinada vaga.
Em algumas, há pessoas trabalhando no recrutamento que

atuam como máquinas de verificação: olham currículos e buscam
Unidade 3 133
book.indb 133 31/5/2007 14:23:53

aquelas que preenchem tais requisitos, depois fazem as entrevistas

e as análises de perfil, e por fim alguém é contratado e passa a
integrar a equipe. Essas companhias enxergam o trabalho como
atividade rotineira, e muitas vezes máquinas e pessoas não
fazem grande diferença (a pessoa nesse caso é um agente que
toma decisões e tem liberdade de ação, ao contrário da máquina).
Atividades rotineiras até podem suportar equipes assim, mas com
certeza projetos não.
Projetos, assim como campeonatos, exigem

pessoas que trabalhem em cooperação e que
gostem, realmente, de chegar aos resultados com
sucesso.
Numa equipe convencional, de rotina, cada um faz a sua

função (não precisaria ser assim!). Num projeto os membros da
equipe trabalham para ajudar os outros, fazendo a sua função e
colaborando para que os outros realizem as suas.
O primeiro conceito importante na formação de uma

equipe é cooperação.
O segundo conceito importante é: objetivo comum.
Formar uma equipe que trabalhe com objetivo comum e de forma

cooperativa é um verdadeiro desafio (basta ver que muitas vezes
os times com os melhores jogadores não ganham o campeonato
– algo ficou faltando!). Isso quer dizer que não basta analisar
as competências pelo currículo. É necessário que, além da
competência, a pessoa que vai fazer parte da equipe de projeto
tenha a cultura da colaboração. Isso não pode ser detectado sem
a convivência. E gerentes de projetos que não sejam líderes,
muitas vezes não conseguirão entender essa característica. Essa
percepção exige experiência e intuição.
Perceba que aqui se sai do campo das ciências exatas e entra no

campo “pantanoso” das relações humanas (nada exatas...).
134
book.indb 134 31/5/2007 14:23:53

Quais são os momentos distintos no processo de

se estruturar uma equipe para um projeto?
Na estruturação da equipe de um projeto, conforme Valeriano

(1998),há quatro momentos distintos:
Formação: quando se reúnem os membros do projeto

e as funções são distribuídas; ainda não há clareza das
atividades a serem realizadas, as pessoas não se conhecem
e o tratamento é formal; por não haver conhecimento há
um ambiente de confusão inicial;
Turbulência: a partir do início das atividades começam
a se formar subgrupos, a partir de afinidades pessoais,
e muitas vezes principiam atritos, especialmente em
equipes grandes com pessoas de variados tipos; a
turbulência é comum em projetos, especialmente quando
os riscos são grandes e iminentes;
Normalização: se os períodos de turbulência são
resolvidos pela liderança, os processos de trabalho
passam a ser bem conhecidos e aceitos por todos. As
atividades tornam-se claras, assim como os objetivos,
estabelecem-se normas internas e o trabalho passa a
andar;
Desempenho: nesse período a equipe entra em
equilíbrio criativo e cooperativo, e o projeto tem alto
rendimento; os membros sentem-se parte do time de
trabalho, reconhecem a liderança e os companheiros
como importantes em seu próprio papel.
Essas quatro fases de estruturação podem acontecer ou não,
sendo que muitos projetos chegam a crescer até a normalização,
sem atingir o ambiente propício do “desempenho”. Sustentar a
fase do desempenho é, além de tudo, uma tarefa difícil que exige
esforço contínuo do gestor. Veja na figura a seguir, o diagrama
esquemático dessa estrutura.
Unidade 3 135
book.indb 135 31/5/2007 14:23:53

Figura 3.29 – Representação esquemática das fases de estruturação da equipe de projeto.
Se o gestor for um líder, poderá conduzir sua equipe para a fase

do “desempenho”. Se não, provavelmente permanecerão na fase
da “normalização”.
E, além da liderança, os perfis das pessoas que virão a fazer

parte de nossas equipes de projeto vão influenciar o ambiente de
cooperação. Keeling (2002), apresenta diversos tipos de perfis
citando outros autores, tais como Margerison e McCann, que
comentam sobre oito diferentes papéis, Belbin, que classifica
nove grupos descritivos, ou Parker, com apenas quatro papéis. Os
quatro papéis de Parker, citados por Keeling (2002) são:
Contribuidor – aquele que contribui com atividades e

resultados, mas não é participativo;
Colaborador – o que participa do desenvolvimento em
conjunto;
Comunicador – capaz de comunicar as atividades e de
integrar grupos por meio da comunicação;
Desafiador – o que sempre apresenta as questões e
participa dos trabalhos num espírito de desafio (o que
pode ser bom ou ruim, dependendo da situação ).
Na composição dos membros de uma equipe uma alternativa
interessante é criar a matriz de qualidades desejáveis e de
funções necessárias em um projeto.
136
book.indb 136 31/5/2007 14:23:53

Imagine que você tenha um grupo de pessoas na

empresa que possa vir a participar do projeto, e
precisa definir suas posições. Ao mesmo tempo, sabe-
se as competências técnicas e comportamentais
necessárias para trabalhar nele. Criar e preencher uma
matriz, como a do exemplo da figura 3.30, ajuda a
perceber os perfis e a maneira de distribuir os papéis.
Perfil e necessidades Conhecer Conhecer Conhecer Dominar Exp. de Exp. de Disp. de Novo na
tecnologia tecnologia tecnologia uso de trabalho trabalho tempo empresa
Membro da equipe “1” “2” “3” “X” em equipe em equipe
Profissional A X X X
Profissional B X X X X
Profissional C X X
Profissional D X X X X
Profissional E X X X X
Profissional F X X X
Olhando para a matriz se tem a tendência a eleger

o “profissional F” como líder da equipe, pois
tem experiência e dispõe de tempo, enquanto o
“profissional D” é novo na empresa, e isso pode gerar
algum desconforto. Em domínio técnico se vê que os
profissionais B e E são capacitados, mas não dispõem
de tempo livre (podem estar engajados em outros
projetos), e a alternativa será discutir com eles as
possibilidades de rearranjo de trabalhos.
Uma vez que você compreendeu como estruturar os recursos

humanos em projetos, na próxima seção aprenda como realizar a
divisão de tarefas.
SEÇÃO 6 - Divisão de tarefas

Num projeto as atividades são divididas
ao máximo, como você acompanhou na
composição de Diagramas de Gantt. A divisão
das atividades é feita para se ter clareza dos
objetivos e para perceber as entregas parciais.
Também no Diagrama de Gantt são atribuídas
Unidade 3 137
book.indb 137 31/5/2007 14:23:54

tarefas para os membros da equipe e, assim, cada um enxerga

suas metas e seus prazos. Atividades diferentes para pessoas
diferentes.
A distribuição de responsabilidades será feita de acordo com

o modelo adotado pela gerência do projeto. Há gestores que
centralizam em excesso as decisões, e outros que delegam. O
equilíbrio dependerá bastante do seu perfil, assim como da
acomodação dos membros da equipe.
Para a gerência do negócio a meta é o resultado

global e a satisfação do cliente, enquanto que para
o desenvolvedor a meta é a entrega conforme a
especificação da sua tarefa.
Segundo Page-Jones (1990), as prioridades são para gerentes, não

para funcionários. Com isso ele quer afirmar a distribuição de
responsabilidades conforme o papel de cada um na equipe.
Este é o Modelo de Equipe definido no “ framework” da

Microsoft (MSF, 1998) quando define papéis em uma equipe.
Assim, para cada um, uma tarefa de cada vez.
Para definir os papéis e comunicá-los à equipe é importante

criar um organograma, definindo as funções e a hierarquia dos
membros.
Há inúmeras possibilidades de estruturar tal organograma, e isso

dependerá da complexidade do projeto, da empresa onde a equipe
de projeto está sendo montada, de como o projeto interfere nas
atividades da empresa, etc.
Quais são as estruturas típicas de grupos de

projetos?
Segundo Keeling (2002), há as seguintes estruturas típicas de

grupos de projetos:
estruturas diferenciadas e exclusivas,
138
book.indb 138 31/5/2007 14:23:54

estruturas híbridas,
estruturas matriciais,
estruturas modulares,
estruturas horizontais.
A seguir, veja em detalhes como se configura cada uma delas,
procure entender como elas podem se adequar aos projetos.
a) Estruturas exclusivas - Projetos de pequeno porte, que

consigam ter seu próprio pessoal e recursos exclusivos e
têm pequena complexidade, podem montar estruturas
organizacionais simples e funcionais. Esse tipo de
estrutura é direta em seus procedimentos e fácil de ser
compreendida pelos membros da equipe.
Pequenas empresas de engenharia da construção,

por exemplo, trabalham desta maneira, onde o gestor
do projeto trabalha com um conjunto de técnicos
e pessoas de apoio administrativo, e ele reporta
diretamente ao cliente final.
Figura 3.31 – Estrutura exclusiva.
b) Estruturas híbridas - Em projetos internos às empresas

maiores, onde vários projetos ocorrem ao mesmo tempo,
as estruturas híbridas passam a ocorrer com maior
freqüência. Veja a figura 3.32, onde um organograma
típico desse modelo de estrutura é apresentado. O gestor
do projeto conta com membros dedicados exclusivamente
Unidade 3 139
book.indb 139 31/5/2007 14:23:54

àquele trabalho, mas precisa paralelamente recorrer a

outras pessoas, que não estarão dedicadas a esse projeto,
mas que são importantes para ele e que simultaneamente
se dedicam a outras áreas dentro da empresa. Se o gestor
do projeto tiver liberdade de trabalho para recrutar tais
pessoas, e dispuser de parte do seu tempo, o projeto terá
sucesso. Empecilhos ocorrem quando essa liberdade
não lhe é permitida, o que levará o projeto a atrasos e
dispersões.
Figura 3.32 – Estrutura híbrida.
c) Estruturas matriciais - Estruturas matriciais são bem

mais complexas e exigem grande maturidade de trabalho,
tanto por parte da empresa como por parte dos membros
das diversas equipes. A figura 3.33 apresenta esse tipo
de estrutura. Veja que diversos projetos ocorrem ao
mesmo tempo. Sendo que os membros fazem parte das
áreas da empresa, e não exclusivamente dos projetos,
ou seja, cada funcionário está inserido em determinado
setor da empresa e executa serviços que atendem ora a
um projeto, ora a outro. Alguém estará responsável pelo
projeto, e será definido como seu gestor, mas mesmo esse
gestor pode estar designado para mais de um projeto,
ou para partes de um projeto, sendo que esse mesmo
gestor faz parte de um determinado setor/departamento
140
book.indb 140 31/5/2007 14:23:54

da empresa. Sem dúvida, a coordenação desse tipo

de estrutura é mais complexa, e exige alto grau de
organização geral da empresa, especialmente em relação
aos planos de produção.
Figura 3.33 – Estrutura matricial.
d) Estruturas modulares - Estruturas modulares ocorrem

quando, dentro da empresa, há grupos com relativa
autonomia e determinada especialização, que realizam
determinado tipo de serviço. O gestor do projeto
emprega esse grupo modular para desenvolver parte do
projeto, e vai distribuindo assim as atividades conforme
as especializações. Internamente o grupo (ou módulo de
desenvolvimento) tem autonomia para gerenciar aquela
etapa, sendo que o gestor geral do projeto percebe a
entrada e a saída do módulo, mas não propriamente o
que acontece em seu interior. Projetos de software, por
exemplo, envolvendo grandes equipes com diferentes
conhecimentos, podem usar esse tipo de estrutura.
Unidade 3 141
book.indb 141 31/5/2007 14:23:55

Figura 3.34 – Estrutura modular.

e) Estruturas horizontais - As estruturas horizontais
geralmente são formadas por poucos membros, onde
há uma grande maturidade no trabalho em conjunto.
As relações se dão em rede, onde todas as pessoas
se relacionam com todas as outras. O líder do grupo
tem a função de acompanhar o andamento das
atividades, e ele mesmo muitas vezes é membro ativo do
desenvolvimento do projeto, como por vezes acontece
em trabalhos de pesquisa e desenvolvimento reunindo
pesquisadores diversos. Projetos que usam esse tipo
de estrutura reúnem especialistas, e por esse motivo o
líder geralmente é também um especialista técnico ou
científico, de tal forma que sua ascendência sobre o grupo
seja inequívoca.
A figura 3.35 mostra exemplo de configuração de uma

estrutura horizontal. O modelo de desenvolvimento
de aplicativos da Microsoft (MSF, 1998) também se
baseia nesse modelo horizontal, definido por “pequena
equipe de pares ou especialistas trabalhando em papéis
multidisciplinares e interdependentes”. A questão da
multidisciplinaridade, que surge aqui, tem especial
interesse em projetos de inovação tecnológica, como no
caso dos aplicativos. O ambiente proporcionado por uma
estrutura horizontal permite os diálogos constantes e a
troca positiva de idéias, nascedouro de soluções criativas.
142
book.indb 142 31/5/2007 14:23:55

Figura 3.35 – Estrutura horizontal de equipe de projeto.
Uma vez compreendidas as principais técnicas para planejamento

de projetos, na seção seguinte conheça em detalhes o modelo do
Project Management Institute (PMI).
SEÇÃO 7 - O modelo PMI

Recentemente os trabalhos do Project
Management Institute (PMI), dos
Estados Unidos, têm sido difundidos
em todo o mundo e têm chamado
especial atenção dos gestores de
projeto. Muitos confundem o PMI
com um novo método, ou nova
técnica, mas esse instituto tem se
dedicado a reunir o conhecimento
sobre gestão de projetos e difundi-lo na forma de Normas. Ficou
famoso o Guia PMBOK (veja as referências bibliográficas ao
final deste livro), que é o “Guia do Conjunto de Conhecimentos
Unidade 3 143
book.indb 143 31/5/2007 14:23:55

em Gerenciamento de Projetos” do PMI e atual Norma Nacional

Americana ANSI/PMI 99-001-2004.
O Project Management Institute (PMI) foi fundado em 1969

e a primeira versão do seu guia foi publicado em 1987 com o
título: “O Conjunto de Conhecimentos em Gerenciamento de
Projetos”. Em 1996 foi lançada nova versão, já com o título Guia
PMBOK®.
Esse conjunto de conhecimentos é preparado e revisado através

de um processo voluntário de desenvolvimento, sendo que a
norma é um consenso de especialistas e interessados nos tópicos
do gerenciamento de projetos. O Instituto administra o processo
de redação e estabelece regras para promover a imparcialidade
dos conceitos a serem publicados.
Como resultado, o PMBOK torna-se uma espécie de grande

manual da área de gerenciamento de projetos, compilando o
conhecimento prático e teórico até o momento atual, servindo de
base para gestores e para novos estudiosos.
São nove as áreas do conhecimento em gerenciamento de

projetos cobertas pela terceira edição, com os seguintes tópicos e
subtópicos (ver PMBOK, 3ª. Edição):
Gerenciamento de integração do projeto

Desenvolver o termo de abertura do projeto
Desenvolver a declaração do escopo preliminar
do projeto
Desenvolver o plano de gerenciamento do
projeto
Orientar e gerenciar a execução do projeto
Monitorar e controlar o trabalho do projeto
Controle integrado de mudanças
Encerrar o projeto
Gerenciamento do escopo do projeto

Planejamento do escopo
144
book.indb 144 31/5/2007 14:23:56

Definição do escopo
Criar EAP (Estrutura Analítica do Projeto)
Verificação do escopo
Controle do escopo
Gerenciamento de tempo do projeto

Definição da atividade
Seqüenciamento de atividades
Estimativa de recursos da atividade
Estimativa de duração da atividade
Desenvolvimento do cronograma
Controle do cronograma
Gerenciamento de custos do projeto

Estimativa de custos
Orçamentação
Controle de custos
Gerenciamento da qualidade do projeto

Planejamento da qualidade
Realizar a garantia da qualidade
Realizar o controle da qualidade
Gerenciamento de recursos humanos do projeto

Planejamento de recursos humanos
Contratar ou mobilizar a equipe do projeto
Desenvolver a equipe do projeto
Gerenciar a equipe do projeto
Unidade 3 145
book.indb 145 31/5/2007 14:23:56

Gerenciamento das comunicações do projeto

Planejamento das comunicações
Distribuição das informações
Relatório de desempenho
Gerenciar as partes interessadas
Gerenciamento de riscos do projeto

Planejamento do gerenciamento de riscos
Identificação de riscos
Análise qualitativa de riscos
Análise quantitativa de riscos
Planejamento de respostas a riscos
Monitoramento e controle de riscos
Gerenciamento de aquisições do projeto
Planejar compras e aquisições
Planejar contratações
Solicitar respostas de fornecedores
Selecionar fornecedores
Administração de contrato
Encerramento do contrato”.
Você reparou que os principais tópicos descritos acima estão
presentes neste livro, e também que foram descritos algumas
das novas tendências em gestão e análises teóricas realizadas
em publicações do IEEE (Institute of Electrical and Electronic
Engineers).
Para conhecer mais sobre este método, veja ainda nas Unidades
deste livro as seções “saiba mais” e as referências bibliográficas no
final.
Antes, para exercitar os novos conhecimento, realiza as atividades

propostas a seguir e no EVA.
146
book.indb 146 31/5/2007 14:23:56

1) Considere o seguinte problema: será implantado um novo sistema

de qualidade na EMPRESA, e uma equipe interna foi designada para
montar o projeto de implantação, o qual não deve superar dois meses,
e que deve ser primeiro implantado no setor administrativo e somente
depois no setor de produção da empresa. O projeto tem as seguintes
atividades: reuniões do grupo do projeto para definir o programa;
redação do programa de qualidade; treinamento do pessoal do
setor administrativo; treinamento do pessoal do setor de produção;
implantação do programa de qualidade no setor Administrativo;
implantação do programa no setor de produção; avaliação dos
resultados e conclusão, com entrega dos relatórios à direção. Faça sua
análise e, com base nela, preencha o quadro a seguir:
Prazos estimados pela

Projeto Qualidade equipe de implantação
A-
B-
C-
D-
E-
F-
G-
Unidade 3 147
book.indb 147 31/5/2007 14:23:56

2) Prepare o Gráfico de Gantt para a planilha de atividades do exercício

anterior – Projeto QUALIDADE, e considere ainda que os treinamentos
podem ser feitos em seqüência, independente do início do trabalho de
implantação no setor de produção.
Projeto QUALIDADE
3) Quais são as quatro fases de estruturação da equipe, e em sua

opinião qual a mais problemática? Por que a fase escolhida é a mais
problemática?
4) Como uma matriz de perfis e competência pode ajudar na estruturação

de uma equipe?
148
book.indb 148 31/5/2007 14:23:57

5) Em sua opinião, qual tipo de estrutura de equipe melhor se ajusta

ao desenvolvimento de software em uma pequena empresa, cujos
projetos são iniciados apenas sob a demanda do cliente?
6) Qual o modelo de estrutura representado na figura abaixo? Qual o seu

grande problema?
Unidade 3 149
book.indb 149 31/5/2007 14:23:58

7) Em que tipo de estrutura é possível uma grande troca de

conhecimentos, sendo que as pessoas trabalham entre pares? Qual
a vantagem desse tipo de estrutura na Gestão de TI e na indústria de
softwares?
150
book.indb 150 31/5/2007 14:23:58

Síntese
Nesta unidade você estudou modelos e métodos importantes

para o gerente de projetos, em especial o gráfico que apresenta
as diversas atividades em forma de barras ao longo do tempo,
desenvolvido por Gantt. A popularidade desse tipo de Gráfico
Gantt deve-se à força de sua clareza visual.Recentemente a
implantação de setas de precedência interligando as barras
aumentou ainda mais a sua qualidade como modelo.
Apesar da imensa utilidade do Gráfico de Gantt, outro

método foi desenvolvido para facilitar o planejamento do
tempo de duração do projeto – trata-se do método do caminho
crítico, denominado genericamente de PERT/CPM. Com
tais ferramentas de planejamento e análise pode-se chegar a
estimativas bastante realistas quanto aos recursos necessários ao
projeto, e quais seus custos. O modelo PMI é uma abordagem
que apresenta uma visão geral dos aspectos de projeto,
considerando a visão particular desse Instituto americano.
Também estudou a questão da formação das equipes de projeto

a partir do planejamento em gráficos. Você viu que os perfis são
muito variados, e também são dinâmicos, ou seja, as pessoas
têm comportamentos diferentes, conforme o meio em que estão.
Para dividir as tarefas e encontrar os perfis corretamente, uma
técnica interessante é preparar uma matriz de competências.
Para organizar o grupo de trabalho em difentes tarefas, foram
estudados cinco modelos estruturais, que dependerão de cada
tipo de projeto a ser trabalhado.
Na próxima unidade você estudará como se dá o dia-a-dia do

projeto durante sua execução, seus problemas de rotina e os
aspectos importantes da liderança no sucesso da empreitada. Até
lá!
Unidade 3 151
book.indb 151 31/5/2007 14:23:58

Saiba mais
Para aprofundar os temas abordados na unidade sugere-se:
1. Nesta unidade, você estudou modelos de representação como

forma de entender um projeto, a partir de uma visão geral.
Para o desenvolvimento de software surgiu uma tecnologia que
busca criar modelos de representação, por meio de diagramas,
que muito se assemelham aos diagramas genéricos que usamos
aqui. Essa tecnologia é chamada “UML – Unified Modelling
Language”, e está baseada na modelagem de diversos tipos
de diagramas, os quais abrangem diferentes visões de um
projeto de software, seja ele simples como o “Hello World
/ Alô Mundo”, que se vê em Java, seja de sistemas das mais
variadas complexidades. A UML é desenvolvida atualmente por
uma organização internacional sem fins lucrativos, e toda sua
documentação pode ser encontrada em www.uml.org. Vários
softwares para desenvolvimento UML estão disponíveis hoje
para download gratuito, como por exemplo, o POSEIDON (veja
em http://www.gentleware.com/index.php ). Veja também o
sítio http://www.cragsystems.co.uk/ITMUML/index.htm para
estudar uma introdução a UML.
2. Veja em www.gestiopolis.com/recursos/documentos/fulldocs/
ger/pertcpm.htm um artigo bastante completo e com exemplos
variados do uso de PERT/CPM, em espanhol. Casos práticos e
exercícios, bem como exemplos de tabelas e relatórios.
3. As idéias da Microsoft para gestão de projetos de software

estão disponíveis no endereço http://www.microsoft.com/
technet/itsolutions/msf/default.mspx. Análises de risco,
estimativas, grupos de trabalhos e diversos outros conceitos
são discutidos no que eles chamaram “Microsoft Solutions
Framework – MSF”.
4. Veja em www.teses.usp.br a dissertação de mestrado

de Leandro Patah, “Alinhamento estratégico de estrutura
organizacional de projetos: uma análise de múltiplos casos”. Este
trabalho foca em diversos tipos de estrutura, especialmente a
matricial, e trará conhecimentos aprofundados sobre o tema.
152
book.indb 152 31/5/2007 14:23:58

5. Entre novamente no sítio da SOFTEX (www.softex.br) e

veja os estudos sobre terceirização de mão-de-obra, bem como
o estudo comparativo entre as indústrias de software no Brasil,
China e Índia. Há exemplos de como a terceirização alavancou
a indústria indiana, por exemplo. Ao mesmo tempo, isso tem
trazido impacto sobre a “formação de equipes de TI” nos Estados
Unidos.
Unidade 3 153
book.indb 153 31/5/2007 14:23:59

book.indb 154 31/5/2007 14:23:59
4
UNIDADE 4
A execução do projeto
Compreender que a preparação correta no início de
um projeto permite a gerência e o controle eficaz da
qualidade.
Perceber que líderes e gestores podem ser tipos bem
diferentes.
Estudar técnicas e práticas para controle de prazos e
recursos, para encontros de trabalho, e para gestão de
conflitos.
Verificar que um projeto de sucesso exige etapas
de simulação, testes e validação dos resultados
intermediários, onde são buscados incrementos de
melhoria.
Seções de estudo
Seção 1 Preparação e início dos trabalhos

Seção 2 Liderança versus gestão
Seção 3 Tomada de decisões
Seção 4 Motivação e comunicação
Seção 5 Reuniões
Seção 6 Acompanhamento e controle
Seção 7 Gerenciando tempo, recursos e qualidade
Seção 8 Gestão de conflitos
Seção 9 Simulação, testes e validação

book.indb 155 31/5/2007 14:23:59


Esta unidade apresenta questões práticas como a partida do
projeto, os possíveis conflitos advindos do choque entre pessoas
da equipe com variados perfis, bem como as características do
gestor do projeto para tratar tais conflitos e dificuldades.
Em especial, é debatido o perfil do gestor quando comparado

com o do líder, assunto que é muito abordado em debates sobre
desenvolvimento tecnológico e inovação. Tais diferenças de perfis
podem afetar positiva ou negativamente o desenvolvimento do
projeto e, até mesmo dificultar a administração de conflitos, por
exemplo.
Também será tema de estudo, nesta unidade, as simulações e

os testes de revisão contínua, facilitando a busca, durante a fase
de desenvolvimento do projeto, de conquistas parciais. Tais
conquistas parciais é que garantem o resultado esperado do
projeto conforme você verá. Então, está preparado? Siga em
frente e bom estudo!
SEÇÃO 1 - Preparação e início dos trabalhos

A produção em projetos é uma
decorrência do planejamento, pois
como você já viu nas demais unidades,
o projeto é um trabalho com data
marcada para acabar, enquanto as
atividades de produção de rotina
não têm tal finalidade, e as
pessoas entram no trabalho de
uma empresa ou indústria, por
exemplo, quando as coisas já
estão acontecendo.
Outro fator importante e por isso aparentemente tanta

preparação, é que num projeto é preciso sempre ter a visão
do conjunto e não apenas das partes. Tendo o planejamento
156
book.indb 156 31/5/2007 14:23:59

realizado, os recursos disponíveis, os objetivos claros e o contrato

estabelecido junto ao cliente, é que se pode iniciar os trabalhos.
O que fazer para começar o projeto?
Para preparar e começar o projeto é importante você considerar

que:
muitas pessoas imaginam que trabalhar em um projeto

é imediatamente começar a programar, ou perfurar, ou
martelar, ou seja, alguma atividade que demande muito
esforço. A energia é despendida logo no começo e, por
não se saber onde chegar, logo tudo esvanece e o projeto
perde o sentido.
Trabalhar num projeto não é desprender um enorme

esforço em direção a um objetivo desconhecido, para
parecer que o suor faz o trabalho, pois projeto exige
reflexão.
Outros pensam que alguém deve dar as ordens e será este

alguém que terá todo o projeto “na cabeça”, basta seguir
seus passos. Provavelmente há um responsável e líder
num projeto (no entanto este responsável certamente não
tem o projeto todo na cabeça).
Não existe um “ser sagrado” que sabe tudo
sobre o trabalho a ser realizado, já que o
responsável depende inteiramente da sua
equipe.
Como o projeto é uma atividade

inerentemente coletiva, é preciso que
haja o espírito do trabalho cooperativo.
Não há como fazer projetos com algum nível de complexidade
sem a participação criativa e positiva de várias pessoas.
Unidade 4 157
book.indb 157 31/5/2007 14:23:59

Um exemplo de ação neste sentido foi divulgada

recentemente, quando um grupo de projetistas
inventou uma espécie de jogo em rede de
computadores, uma espécie de gincana, em que eles
brincavam de colocar partes do projeto num diretório
comum e a vitória era cumprir tal demanda num prazo
cada vez mais curto – tratava-se de uma brincadeira
que fazia do projeto uma diversão em forma de game!
O início de um projeto deve se dar com uma

reunião!
Nesta reunião, o escopo do projeto deve ser exposto com a maior

clareza possível, discutido em detalhes, o plano de produção
deve ser delineado, as tarefas divididas e as responsabilidades
atribuídas.
É neste momento que o fluxograma geral (você lembra do

algoritmo do projeto?) deve ser apresentado, discutido e suas
cópias distribuídas. A comunicação dos procedimentos, já
discutidos, deve ser feita a partir desse contato inicial.
Mas reuniões são muito mal vistas. Você sabe por

quê?
As pessoas pensam que reuniões são chatas, que não dizem nada,
que o chefe senta na extremidade da mesa para mandar. No
entanto,
158
book.indb 158 31/5/2007 14:23:59

as reuniões podem ser interessantes, se:
tiverem uma pauta bem definida;

a pauta não for extensa;
os assuntos são claros e de
conhecimento dos presentes;
o horário de começar e acabar for bem
definido;
forem suficientemente breves;
houver um coordenador, capaz de
distribuir a fala entre os diversos
presentes;
houver um líder, capaz de decidir
quando for necessária uma decisão.
Há empresas que fazem tantas reuniões que

as pessoas acham que trabalhar é participar de
reuniões, enquanto que outras pessoas acham
que a pior coisa do mundo é uma reunião. Nem
uma nem outra está correta. Provavelmente é a
reunião que está mal conduzida.
Passada a fase das reuniões iniciais, o projeto

tem início. Os grupos de trabalho estão com
suas atividades definidas, prazos estabelecidos
e resultados por alcançar. Resta então cumprir
tais etapas, já estabelecidas no Gráfico de Gantt do projeto.
Se o planejamento foi bem feito, há uma divisão bem clara de
objetivos e atividades e possivelmente com sub-etapas de prazos
curtos.
Orientação a
E assim que começam os trabalhos de desenvolvimento, a “zero-defeito” e prazos
mentalidade de “uma entrega a cada dia” é estabelecida entre curtos de entregas
todos os membros da equipe. Com isto, há a sensação comum de intermediárias – a
que os projetos devem “andar” e que devem estar no prazo. Microsoft estabeleceu este
conceito como um objetivo
de desenvolvimento
(MSF, 1998).
Unidade 4 159
book.indb 159 31/5/2007 14:23:59

Na Microsoft, o gerente de projeto Chris Peters

considera que a atividade de um projetista não é
simplesmente colaborar no projeto para que esse
chegue ao resultado final. Ele considera que cada
projetista, ao começar seu trabalho, deve estar
pensando em “entregar”.
Sobre isso, analise o parágrafo seguinte:
Todos [os projetistas]… têm o mesmo trabalho. Eles
têm exatamente a mesma descrição de trabalho. E
esta é entregar (embarcar) produtos. Seu trabalho
não é escrever código. Seu trabalho não é testar.
Seu trabalho não é escrever especificações. Seu
trabalho é entregar produtos. Isto é o que um
grupo de desenvolvimento faz. Seu papel como um
desenvolvedor ou como um testador é secundário.
Não estamos dizendo que não são importantes
– mas são secundários para seu trabalho real, o qual
é entregar um produto. Quando você acorda cedo
de manhã e vem para seu trabalho, você diz, “Qual
é o foco – estamos tentando entregar ou estamos
tentando escrever código?” A resposta é: nós estamos
tentando entregar. Você não está tentando escrever
código. (MSF, 1998).
Observe que esta citação esclarece a atitude do projetista ao

participar de um grupo de trabalho. E com este foco, o trabalho
deve ser iniciado.
160
book.indb 160 31/5/2007 14:23:59

SEÇÃO 2 - Liderança versus gestão

Nossa sociedade está muito mais
acostumada a trabalhar com gestores ou
gerentes, do que com líderes.
A função da gerência tem sido

muitas vezes confundida com uma
espécie de atuação por cobrança
e controle, que coloca os gerentes
numa condição de animosidade
com seu grupo de gerenciados. Ou
seja, aqueles que ficam submetidos ao
gerente se sentem diminuídos e perdem
a motivação do trabalho criativo. Muitas vezes
isso, de fato, acontece. Conheço vários gerentes que se sentem
muito satisfeitos em... mandar.
Mas aqui surge uma dúvida:
Quais são as qualidades esperadas de um gerente

de projetos?
No entendimento de Page-Jones (1990), as qualidades de um

gerente de projetos são as seguintes:
integridade pessoal;
sensibilidade;
capacidade de estabelecer objetivos;
capacidade de cumprir objetivos;
tenacidade;
capacidade de inspirar;
disposição de servir;
coragem de delegar;
competência técnica;
Unidade 4 161
book.indb 161 31/5/2007 14:24:00

capacidade para comunicar a realidade;

capacidade de pensar e ser inovador;
coragem para tomar decisões.
Tais características cabem perfeitamente para os líderes,
especialmente as qualidades de “inspirar, ser inovador e ter
coragem de tomar decisões”. Nem sempre os gerentes são
inspiradores, inovadores e decisores e, mesmo assim, são ótimos
gerentes, pois são capazes de coordenar os prazos e distribuir
tarefas adequadamente, assim como os membros da equipe
confiam nele para conduzir o trabalho até o final.
Quais são os atributos desejáveis em um gerente

de projeto?
Em seu livro sobre gerenciamento de projetos, Valeriano

(1998) cita Denis Donaire, que considera que os atributos
desejáveis em um gerente estão divididos em três grandes áreas:
conhecimentos, habilidades e atitudes. Acompanhe a seguir o
quadro apresentando cada área.
162
book.indb 162 31/5/2007 14:24:00

Quadro 4.1 – Atributos desejáveis para um gerente de projeto
Atributos desejáveis
• o gestor precisa ter conhecimento do sistema administrativo e

financeiro da organização onde trabalha;
• precisa conhecer o funcionamento do sistema de RH – recursos
humanos, e como se dão as relações jurídicas com relação aos
funcionários e terceirizados da empresa;
• práticas, políticas e valores, isto é, percepção clara de como
funciona a organização em suas práticas no dia-a-dia, a política
Conhecimento interna das relações e quais os valores considerados por aqueles
organizacional que trabalham nela;
• consciência do custo e das implicações das decisões técnicas, o
Conhecimentos
que implica em reconhecer as relações entre as ações e o que isso

implica em gastos no projeto e para a empresa;
• produtos, missões e mercados ou clientes da organização,
que significam um conhecimento profundo das atividades
econômicas da organização.
• o gestor precisa conhecer áreas correlatas à especialização de

que trata o projeto, com uma visão geral das competências
tecnológicas;
• também precisa ter competência técnica em pelo menos uma
Conhecimento técnico área de especialização;
• por fim, deve ter domínio de métodos de pesquisa, que
permitam relacionar os diversos membros da equipe em um
desenvolvimento equilibrado e voltado para resultados.
Unidade 4 163
book.indb 163 31/5/2007 14:24:00

• o gestor deve ter a capacidade, e isso deve ser perceptível, de

planejamento, organização e controle das atividades do projeto;
• para comandar sua equipe é desejável que desenvolva sua
capacidade de liderança;
• capacidade de auto-análise, ou seja, constantemente fazer
auto-crítica das suas atitudes, dos seus conhecimentos e das
necessidades de aprimoramento técnico;
De comando • capacidade de alocação de recursos, que advém do conhecimento

dos recursos disponíveis e daqueles que serão necessários buscar
no desenvolvimento do projeto;
• capacidade de gerar confiança no superior; isto se dá pela
integridade e pela segurança ao trabalhar orientado a resultados;
• escolha do estilo de liderança adequado;
Habilidades
• habilidade de tomada de decisões, condição essencial numa

função de comando (o gerente que não toma decisões é
considerado fraco por sua equipe, o que desmotiva o grupo).
• trabalhar em equipe, que está relacionada à capacidade de

cooperar e gerenciar conflitos;
• criatividade, especialmente na solução de problemas inesperados
e distantes daqueles que foram avaliados como riscos inerentes
ao projeto;
• capacidade de redigir com clareza, precisão e concisão, que são
Outras habilidades habilidades relacionadas à capacidade de se comunicar, nev
vcessária para o andamento do projeto de forma coordenada e
racional;
• relacionamento pessoal, habilidade relacionada ao dia-a-dia
do trabalho em equipe, às atitudes de educação na convivência
(infelizmente não é nada irreal o “gerente” que se dirige aos
membros de sua equipe aos berros).
• interesse por questões administrativas;

Posicionamento em • disciplina de trabalho;
relação a aspectos internos
e externos • entrosamento com pessoal externo à organização;
• ambição profissional.
Atitudes
• hábito de começar o ataque ao problema pela revisão da

literatura, pela revisão dos projetos da mesma área que o
antecederam, seja na empresa ou outros locais e, principalmente,
Estratégia de ação a capacidade de exercitar sempre uma visão geral do problema e
do ambiente de negócios onde o projeto está envolvido;
• hábito de leitura sistemática de textos técnicos.
164
book.indb 164 31/5/2007 14:24:00

Stephen Covey (2005) criou uma ilustração que relaciona

diferenças entre liderança e gerência. No quadro a seguir,
apresento uma adaptação de tal tabela de acordo com os conceitos
desenvolvidos neste livro:
Quadro 4.2 - Diferenças entre liderança e gerência
Diferenças Liderança Gerência

Interesse nas pessoas nas coisas
Trabalha na espontaneidade com a estrutura
Idéias liberação e fortalecimento controle delas e das atividades
Presteza eficácia eficiência
Prefere planejar e programar trabalhar sob um programa
Gasto considera como investimento considera como despesa
Trabalho baseado em princípios em técnicas
Procura transformação transação
Poder centrado em princípios utilidade
Procura resolver por discernimento medição
Fazer a coisa certa certas as coisas
Resolve baseado numa direção em rapidez
Pensa em uma linha superior resultados
Tem propósitos métodos
Decide baseado em princípios em práticas
Para o líder a pergunta é: “a Para o gestor o que importa é:
Ponto de vista escada está junto da parede subir rapidamente a escada
certa?”
Fonte: Adaptado de Covey (2005).
Bem, não é necessário fazer um juízo de valor sobre qual o

melhor líder ou gestor, pois os papéis dependerão da atividade, do
tamanho do problema ou do tipo do projeto. De certa forma, os
dois papéis devem estar combinados.
Uma vez dado início ao projeto, tendo um planejamento claro

das atividades e consideradas as funções de liderança e de gestão,
passa-se agora aos detalhes do dia-a-dia do projeto. E um dos
pontos fundamentais de qualquer projeto é a tomada de decisão,
assunto de estudo na próxima seção.
Unidade 4 165
book.indb 165 31/5/2007 14:24:00

Seção 3 - Tomada de decisões

Hoje, uma grande parte dos textos sobre administração
empresarial focaliza o problema da tomada de decisão.
Decidir significa escolher uma opção entre várias

e, com isto, há sempre o risco da escolha não recair
sobre a melhor opção.
Um campeão de xadrez decide o melhor movimento a cada vez e

seu exercício de escolha é renovado
a cada nova jogada. Aquele que
tomar decisões erradas perderá
o jogo. Assim também o goleiro
na hora do pênalti: a decisão do
seu movimento poderá implicar
ou não na defesa do gol. Sabe-
se que os grandes craques de
qualquer esporte, especialmente
os coletivos, aliam as habilidades pessoais e de relacionamento à
capacidade de antever os movimentos do jogo e tomar a decisão
que levará ao gol, ao ponto, ao sucesso, enfim.
Que milagre poderia ser este, capaz de levar a uma

decisão certa no momento certo?
Alguns traços são comuns entre esses “tomadores de decisão”:
experiência anterior;
treino em decidir e executar (as jogadas, os chutes);
o exercício da visão ampla (do jogo);
coragem de, após um erro, calibrar os movimentos para
tentar de novo até acertar.
Você já deve ter assistido em algum desses momentos mágicos no
esporte, quando o atleta resolve arriscar um difícil movimento,
muitas vezes num momento crítico onde a chance da derrota
166
book.indb 166 31/5/2007 14:24:00

é enorme e, cheio de confiança, decidir uma partida. Um jogo

coletivo é como um projeto: há um objetivo a ser atingido, o
prazo está estabelecido e só é possível vencer se a equipe estiver
unida e entusiasmada.
Para Page-Jones (1990), a tomada de decisão durante um projeto

envolve quatro passos:
1. identificar possíveis modos de ação e chegar a um

entendimento comum do que cada opção significa;
2. identificar as ramificações de cada opção, incluindo

vantagens e desvantagens;
3. discutir e avaliar cada uma dessas ramificações;
4. escolher o modo de ação mais vantajoso e partir para ele.
Como você pôde acompanhar, num projeto há a necessidade

da constante avaliação das opções possíveis e disponíveis que,
combinada à experiência prévia do decisor, definirá as próximas
ações.
Seção 4 - Reuniões
Como você já estudou nesta unidade, as
reuniões de projeto são muito importantes,
pois são momentos especiais de comunicação
e decisão. Durante o encaminhamento do
projeto, os planos, as discussões e os rumos
do trabalho são colocados e precisam ser
encarados como ambientes coletivos para o
desenvolvimento do próprio projeto.
Como fazer para que a reunião seja bem sucedida?
Para que uma reunião venha a ser bem sucedida, Page-Jones

(1990) coloca as seguintes sugestões de ação:
Unidade 4 167
book.indb 167 31/5/2007 14:24:01

1) Antes da reunião • o grupo de trabalho ou o gestor/líder deve definir um lugar conveniente para
a reunião;
• os participantes devem ser selecionados conforme o assunto em pauta e não,
simplesmente, reunir todos do grupo;
• antes de marcar uma agenda, é importante verificar se todos podem, de fato,
participar;
• se há consenso sobre uma data e horário, fazer então o aviso com
antecedência;
• a pauta de reunião deve ser bem definida e levada aos participantes com
antecedência;
• o número de itens em pauta deve ser restrito, evitando dispersão e
superficialidade.
2) Durante a reunião • deve ser designado um moderador, capaz de controlar as falas e questões;
• também deve ser designado um secretário, que anote os pontos principais
discutidos, bem como as resoluções adotadas, criando então uma ata;
• o grupo deve prender-se à pauta, evitando entrar em assuntos diversos;
• definir regras de procedimento, conforme o objetivo dos itens de pauta
(planejamento, comunicação, resolução de problemas, decisão).
3) Depois da reunião • todos os itens de ação devem ser anotados e devem ser atribuídas
responsabilidades por cada item de ação;
• distribuir a ata da reunião.
Tenho certeza que você, ao ler estas linhas, pensou em reuniões

em que já tomou parte e que não seguiram tais recomendações.
Aquelas que tiveram alguém capaz de conduzir as conversas,
talvez tenham tido bons resultados, porém a maioria deve ter
sido enfadonha e sem resultados, sem contar a sensação do tempo
perdido.
Se a reunião não tiver pauta, peça uma. Se não

tiver definida a hora de acabar, pergunte qual é.
Para o projeto de desenvolvimento de uma inovação tecnológica,

um software, um novo produto, haverá com certeza várias
reuniões e caberá a cada um de nós interferir no seu bom
andamento.
168
book.indb 168 31/5/2007 14:24:01

Seção 5 - Gerenciando qualidade

Gerenciar a qualidade é buscar a ausência de erros. Muitas vezes
não se presta atenção aos erros e se cria metas de qualidade que
podem ser bem baixas para nossa vida social, apesar de parecerem
excelentes para a vida profissional.
Para contextualizar esta questão do erro,

acompanhe a seguir um texto de Philip Crosby,
citado por Tom DeMarco (1991):
“As pessoas foram condicionadas a acreditar que
o erro é inevitável. Não apenas aceitamos o erro,
nós o prevemos. Quando projetamos circuitos,
programamos um computador, fazemos um
planejamento, soldamos conexões, datilografamos
uma carta, fazemos um orçamento, ou montamos
componentes, não nos preocupamos se cometemos
alguns erros; e a gerência prevê o acontecimento
desses erros. Achamos que os seres humanos
possuem um fator de erro integrado a eles.
Entretanto, não mantemos o mesmo padrão, quando
a coisa passa para o campo da vida pessoal. Se
mantivéssemos, aceitaríamos com naturalidade
receber troco errado (a menos); aceitaríamos que as
enfermeiras deixassem cair no chão um percentual
de recém-nascidos; acharíamos natural entrar na
casa errada de vez em quando. Como indivíduos, não
toleramos esses erros.
Portanto temos dois pesos e duas medidas: um para
nós e um para a empresa. A razão para isso é que a
família cria para nós padrões de desempenho bem
mais altos do que as empresas. Muitas empresas
gastam 10, 15 ou até mesmo 20% do faturamento
de suas vendas com sucata, re-trabalho, garantias,
consertos, testes e inspeções.
Os erros que produzem esse desperdício são causados
diretamente pelo pessoal da empresa, tanto pelos
funcionários como pela administração. Para eliminar
esse desperdício, para melhorar o funcionamento e
aumentar a eficácia, precisamos nos concentrar na
prevenção dos defeitos e dos erros que nos assolam.
O erro que é prevenido não precisa de consertos,
exames ou explicações.
Unidade 4 169
book.indb 169 31/5/2007 14:24:01

O primeiro passo é adotar uma atitude de prevenção

de defeitos. Essa atitude é chamada, simbolicamente,
de Defeito-Zero.”
Como você pode refletir, o controle da qualidade passa antes por

um conceito do que é o defeito e até onde estamos dispostos a
aceitá-lo.
Quais são os momentos críticos do gerenciamento

da qualidade?
Conforme o artigo “Managing project quality” (Kloppeborg

& Petrick, 2004), o gerenciamento da qualidade em projetos
passa por dois momentos críticos: a abertura do trabalho e seu
encerramento. Os pontos fundamentais a serem tratados nesses
dois momentos são:
1) Fase inicial do projeto
identificação dos objetivos do projeto;

alinhamento estratégico com a empresa e com o objetivo
do cliente;
alinhamento operacional com a capacidade de produção
da estrutura disponível;
seleção dos recursos necessários;
contrato detalhado do projeto descrevendo:
o porquê do projeto;
o quê;
quando;
quanto custa;
quais os riscos;
como fazer;
170
book.indb 170 31/5/2007 14:24:01

os fatores críticos do sucesso, o plano de

comunicação, os conhecimentos necessários e os
compromissos.
2) Fase de encerramento
definição e comunicação do benefícios reais entregues

para o cliente;
expressão de reconhecimento aos participantes;
entregar prêmios quando há méritos especiais (evitando
aquele tipo de mediocrização que evita prêmios para não
“magoar” os mais fracos).
De posse de um Diagrama de Gantt com acompanhamento
constante das etapas realizadas, sabemos dos custos envolvidos e
do tempo gasto a cada momento. Fazendo a revisão de cada etapa
é possível replanejar o projeto e avaliar as condições do tempo
restante e recursos disponíveis e ainda necessários.
Seção 6 - Gestão de conflitos

Como não podia deixar de ser, o trabalho em equipe é, quase
sempre, um ambiente de conflitos. Isso acontece devido ao
dinamismo dos pensamentos e sentimentos humanos, em
constante movimento e readequação.
Quais são os tipos de conflitos?
Segundo Valeriano (1998), existem três

tipos de conflitos:
o de ordem intrapessoal, que

ocorre em cada indivíduo, consigo
mesmo;
interpessoal, que ocorre entre
diferentes indivíduos;
Unidade 4 171
book.indb 171 31/5/2007 14:24:01

intergrupos, que se dá entre diferentes grupos.

Esses conflitos estão presentes em todos os ambientes sociais,
sejam de trabalho, familiar ou de comunidades em geral e,
obviamente, estão presentes nas equipes de projeto, as quais
muitas vezes estão reunidas por um pequeno período de tempo e
de forma muito intensa, a potencializar estas relações.
Esses três tipos de conflito, intrapessoal, interpessoal e

intergrupos então presentes no decorrer dos projetos segundo as
seguintes causas potenciais (KEELING, 2002):
na definição de cronogramas;
na definição das prioridades;
na composição dos recursos humanos para trabalhar no
projeto;
opiniões técnicas e de desempenho;
procedimentos administrativos;
custos;
conflitos de personalidade.
No quadro 4.3 a seguir, você poderá observar quais são os
conflitos em projetos como os oriundos de diferenças entre os
indivíduos e as organizações devido aos seus diferentes objetivos.
Quadro 4.3 - Fontes de conflitos
Diferenças de objetivos como fonte de conflitos

Indivíduo / profissional Organização / gerência
Busca a inovação tecnológica. Busca o lucro.
Quer autonomia de ação. Quer integrar os profissionais na organização.
Quer livrar-se de regras e procedimentos. Estabelece as regras e procedimentos.
Quer autoridade baseada em mérito. Autoridade baseada em hierarquia.
Quer ser recompensado com base em seu Recompensa conforme o interesse da
desempenho. organização.
Quer ampla comunicação entre pares. Bloqueia a comunicação interna.
Busca otimização do próprio trabalho. Busca cumprimento de cronogramas e custos.
Fonte: Adaptada de Valeriano (1998).
172
book.indb 172 31/5/2007 14:24:02

Você percebeu como são interesses e objetivos

diferentes: indivíduo e organização!
Observe que as pessoas têm diversas necessidades e intenções,

que muitas vezes não combinam ou se ajustam às das
organizações, mesmo que tais organizações, paradoxalmente,
tenham sido construídas por indivíduos.
Num projeto, isto pode ser a fonte de um grande fracasso e o

gestor do projeto deverá saber criar suficiente blindagem entre os
objetivos mais gerais da organização e os específicos do projeto,
que devem refletir os indivíduos que o compõem.
Há organizações que trabalham orientadas para projetos,

porém com a mentalidade de organização tradicional. Não será
possível vencer a contradição, se não houver um repensar de seus
princípios.
Organizações envelhecidas, nascidas ainda com a mentalidade

dos princípios da revolução industrial, por exemplo, buscam
renovação adotando práticas de reengenharia e gestão por
projetos e fracassam logo em seguida sem saber o porquê. A
orientação a projetos é uma orientação às pessoas, eis a resposta.
No entanto, não estaremos livres de conflitos em um projeto,

então será necessário administrá-los.
Como realizar a administração dos conflitos?
Para Valeriano (1998), há as seguintes possibilidades de se

administrar conflitos num projeto, por:
Confronto ou solução de problemas, quando as partes

envolvidas encaram o problema e buscam juntas
alternativas de solução;
Unidade 4 173
book.indb 173 31/5/2007 14:24:02

Comprometimento, que é a busca de soluções

alternativas, por parte do gerente do projeto, dando
algum grau de satisfação às partes envolvidas;
Acomodação, são enfatizadas as áreas onde há acordo e
esquecidas ou desprezadas as áreas conflitantes; haverá
perda para o projeto se as áreas de atrito eram, de alguma
forma, importantes para seu prosseguimento;
Prevalência, que é quando uma das partes prevalece
sobre a outra, numa relação ganha-perde;
Retirada, quando o conflito é deixado de lado, sem
solução, o que pode trazer o aprofundamento da
crise; muitas vezes a retirada é usada como modo
de administrar a crise, considerando a retomada do
problema algum tempo depois, quando houve tempo
para melhor reflexão.
Considerando tais possibilidades, será função do gestor escolher
a maneira de tratar o conflito. Com certeza, a melhor forma de
administrar os conflitos se dá quando são percebidos o mais cedo
possível. Como muitas doenças, se o conflito for detectado no
início, é mais fácil de curar e, se muito tarde, pode ser impossível.
Uma vez compreendido como administrar os conflitos durante a

gestão dos projetos, na próxima seção acompanhe como realizar o
teste e a validação do projeto.
Seção 7 - Simulação, testes e validação

Projetos podem ter resultados melhores se forem testados em
etapas, com resultados parciais e não aguardar até o final para ver
o que deu certo e o que deu errado. Neste sentido, é importante,
para cada etapa e subdivisão do projeto, buscar conseguir um
resultado palpável.
174
book.indb 174 31/5/2007 14:24:02

No caso da construção civil, por exemplo, a finalização

da etapa das fundações tem como resultado as
próprias fundações, que podem ser testadas quanto às
características necessárias de resistência e dimensões.
Qualquer problema aí detectado pode ser resolvido
imediatamente, não sendo necessário aguardar até
o final da obra para perceber que os alicerces não
suportaram o peso da construção – seria um desastre!
Em projetos de software há a possibilidade de dividir o sistema

em pequenos módulos, de tal forma que cada módulo tenha
características específicas, definidas inicialmente e atingi-las é o
objetivo a ser alcançado no final da etapa.
Quanto maior a divisão de etapas e, desta

forma, de objetivos intermediários, mais fácil
será detectar possíveis problemas e corrigi-los a
tempo.
Um exemplo de divisão em etapas desse tipo está

definido nos “pacotes diários” e nos “protótipos de
prova” do Microsoft Solutions Framework (MSF, 1998).
O objetivo é chegar ao final de cada dia com um
protótipo sendo que este deva estar testável. Esse
protótipo é compilado e deve funcionar. Passa-se para
a etapa seguinte se o pacote diário anterior alcançou
o sucesso.
Uma outra alternativa, é o uso de simuladores em
projetos mais complexos. Nesses casos, uma boa
forma de testes prévios é o uso de simulações
computacionais, que permitem uma visão do produto,
possibilitando fazer testes variados em um ambiente
computacional.
Um ótimo exemplo dessa situação são os softwares de
apoio a projeto (CAD), que em mecânica e arquitetura
permitem visualizar e testar peças, máquinas e
ambientes. A detecção de falhas durante a simulação
permite enormes economias de tempo e dinheiro.
Unidade 4 175
book.indb 175 31/5/2007 14:24:02

A validação do projeto é feita então por etapas e

por simulações, sendo que no final de cada etapa
e mesmo durante cada uma delas, um processo de
revisão contínua é a melhor solução de qualidade de
um projeto de sucesso.
Segundo Page-Jones (1990), há várias revisões a serem feitas

no decorrer do projeto, com testes contínuos e validação a cada
etapa.
Quais são as revisões e testes que necessitam ser

realizados?
Especificamente sobre projetos, as revisões e testes, deve-se

realizar as seguintes ações:
revisão do escopo do
projeto, que analisa
constantemente se o projeto
está adequado às intenções
e necessidades dos usuários/
clientes;
revisão de análise, que
verifica se os problemas
anunciados no escopo estão sendo cuidados;
revisão do projeto, que verifica se preenche as
especificações, os padrões de qualidade e se tem
condições de ser implementado;
revisão da programação e do sistema, que verifica se os
resultados dos testes do protótipo estão adequados;
revisão da aceitação, que verifica se, após os testes do
protótipo, já é possível colocar o resultado do projeto em
produção;
revisão de produção, que verifica se o sistema de
produção está adequado e se há oportunidades de
melhoria no produto;
176
book.indb 176 31/5/2007 14:24:02

revisão dos aspectos técnicos do projeto;

revisão dos aspectos comerciais;
revisão pós-projeto, que busca aprender com os
resultados finais do projeto.
Simulações, revisões e testes são atividades do dia-a-dia do
projeto e, como visto, interferem inclusive no seu final e podem se
estender à produção, atividade que já não pertencerá ao escopo do
projeto em si, mas à rotina.
Agora que você finalizou a leitura desta unidade realize as

atividades propostas a seguir e no EVA.
1) O que é importante fazer para iniciar um projeto? Explique porque

é importante a fase preparação para o início do projeto. Procure
comentar com um exemplo que você já vivenciou.
Unidade 4 177
book.indb 177 31/5/2007 14:24:03

2) Como você descreve os quatro passos da decisão? Dê um exemplo

prático, a partir da sua experiência.
3) Descreva as principais fontes de conflito entre os indivíduos e as

instituições, dando exemplos de sua própria experiência.
178
book.indb 178 31/5/2007 14:24:03

4) Quais as formas de administrar um conflito e qual delas melhor se

adapta ao seu estilo de gestão? Por que esta forma de atuar e não as
outras? Faça um comparativo e publique na “Exposição”.
5) Qual a importância do uso de simuladores no desenvolvimento de

projetos?
Unidade 4 179
book.indb 179 31/5/2007 14:24:03

Síntese
Nesta unidade, você viu como os preparativos iniciais do projeto

devem ocorrer e quais atividades são importantes para que a
produção tenha início acompanhando o planejamento definido
previamente.
Você pôde aprender que o início do projeto pode definir também

o padrão de qualidade que será buscado em toda a fase de
desenvolvimento, especialmente se for implantada uma cultura de
“defeito-zero”.
Também foi analisada a comparação entre as características do

gestor e as do líder. A figura do líder aqui definida é a do sujeito
capaz de criar ambientes de cooperação e de trabalho criativo.
Para isto, muitas vezes é necessário administrar conflitos, mostrar
caminhos produtivos e tomar decisões que definam rumos para o
projeto. Sem dúvida, uma das características fundamentais nessas
atividades é a de motivar e inspirar.
Por fim, tomando por base a necessidade de, durante a fase de

planejamento, segmentar o projeto em pequenas tarefas e etapas,
a fase de desenvolvimento pressupõe um conjunto de revisões e
testes, que podem ser bem sucedidos se o projeto tiver resultados
claros a serem atingidos em cada uma de tais etapas.
Na próxima unidade, você estudará as atividades de encerramento

do projeto, o processo de documentação dos trabalhos e também
da dissolução da equipe e das análises finais, para verificar se os
objetivos foram alcançados. Até lá!
Saiba mais
1. As reuniões geralmente são esperadas como atividades não

muito proveitosas. Isso acontece porque não existe uma boa
preparação para elas. Uma reunião bem preparada conduz a
180
book.indb 180 31/5/2007 14:24:03

decisões importantes e realizações. Acesse o link a seguir e

conheça algumas sugestões e práticas para uma boa reunião
citadas no artigo intitulado A boa geometria da reunião, de
Carlos Cardoso Aveline. http://www.terra.com.br/planetanaweb/
flash/reconectando/ambiente/334/reuniao.htm
2. O uso de simuladores pode ser importante para verificar

protótipos de produtos, antes mesmo de eles serem construídos.
No caso do desenvolvimento eletrônico, por exemplo, há um
interessante conjunto de simuladores, desenvolvidos com Java,
que podem ser vistos no link: http://www.amanogawa.com/index.
html . O exemplo é o seguinte: no projeto de uma antena, o
projetista tem como variar as características do produto, e testar
seus resultados. Se for construir um circuito eletrônico, poderá
fazer simulações específicas. Você quer fazer um projeto de
um novo modelo de “pipa/papagaio/maranhão”? (cada região
usa um nome diferente). Veja o simulador computacional da
NASA que está no site http://www.grc.nasa.gov/WWW/K-12/
airplane/kiteprog.html. Este é mais um ótimo exemplo de como
simuladores apóiam o trabalho de novos projetos.
Unidade 4 181
book.indb 181 31/5/2007 14:24:03

book.indb 182 31/5/2007 14:24:03
5
UNIDADE 5
Análise e conclusão do projeto
Compreender aspectos relativos à finalização do projeto,
à dissolução das equipes e aos registros documentais do
trabalho.
Verificar que o sucesso do projeto ou o fracasso, está
intimamente ligado às expectativas do cliente, por um
lado, e à capacidade de liderança do gestor, por outro.
Perceber que todo trabalho de projeto é uma fonte de
aprendizagem, mas para que o aprendizado ocorra será
necessário extrair lições e refletir sobre elas.
Constatar que um projeto pode ser a origem de muitos
outros, mas para isto os membros da equipe precisam
estar atentos às oportunidades.
Seções de estudo
Seção 1 Fase de finalização

Seção 2 Plano de contingência
Seção 3 Atendendo as expectativas do cliente
Seção 4 Sobre o sucesso (ou fracasso) do projeto
Seção 5 Equipe e documentação
Seção 6 Lições aprendidas e novas idéias

book.indb 183 31/5/2007 14:24:03

Para início de conversa

As atividades de encerramento do projeto são o objeto de estudo
nesta unidade, as quais consideram aspectos diversos como o
processo de documentação dos trabalhos e também da dissolução
da equipe e das análises finais, quando se verificará o grau de
sucesso ou fracasso, alcançado pelo trabalho.
O sucesso estará ligado à demanda original, vinda do cliente,

seja este cliente um contratante externo ou você mesmo. Se a
expectativa for atendida, a sensação de missão cumprida estará
no ar. Se não, será a frustração do fracasso. Mas com o fracasso,
principalmente, se aprende muito, é de onde se pode tirar lições
para aproveitar no desenvolvimento dos novos projetos.
Bom estudo!
Seção 1 - Fase de finalização

A finalização do projeto pode acontecer por dois motivos:
(a) as coisas deram certas e o resultado esperado está sendo

atingido;
(b) as coisas deram erradas e é melhor finalizar antes que piore.
Primeiro considere a opção “a” e deixe a opção “b” para a próxima

seção.
A avaliação de que o resultado está sendo atingido

é obtida por medições que devem ser feitas a
cada etapa do trabalho. Você viu isto quando
estudou o algoritmo do projeto e foram
tratados o acompanhamento e as medições
em cada atividade. Atingir o grau satisfatório
em cada uma dessas medições faz o projeto
caminhar rumo ao objetivo final.
184
book.indb 184 31/5/2007 14:24:03

Uma das marcas principais do encerramento do

projeto é a data limite ou prazo final.
Muitas vezes não teremos como discutir contra uma data, não
haverá prorrogações. Então deveremos trabalhar tendo em
vista tal data. O controle disso se dará no preenchimento e na
atualização constante do Gráfico de Gantt, preenchendo-se as
atividades “realizadas” e comparando-se com o “previsto”, assim
como avaliando-se a cada passo o “caminho crítico” do projeto
no diagrama PERT/CPM.
Fechado o projeto, será importante avaliar as estatísticas sobre

o tempo gasto, recursos utilizados, os riscos previstos que
aconteceram e os que não aconteceram, se os custos previstos
foram suficientes e todos os demais dados que possam ajudar a
compreender melhor a gestão dos próximos projetos.
Encerrar o projeto não será apenas concluir os

trabalhos e fechar a porta. Este será o momento
de avaliar se as expectativas do cliente foram
atingidas e, se foram, avaliar o grau de sucesso do
trabalho.
Será o momento de reunir toda a documentação

(obrigatoriamente) gerada, para que a história do trabalho seja
preservada, permitindo a introdução do resultado do projeto
num ciclo de vida de produção, bem como, permitir avançar
em melhorias e mesmo em novos projetos, a partir das lições
aprendidas. Será também o momento de desfazer a equipe, que
nos casos de sucesso se transforma num momento triste e, nos de
fracasso, uma libertação.
Nas próximas seções você estudará com maior profundidade esses

tópicos.
Unidade 5 185
book.indb 185 31/5/2007 14:24:04

Seção 2 - Plano de contingência

Na seção anterior, lembre-se que você interagiu com duas
opções, “a” e “b”. Você já estudou a primeira opção e agora
chegou a hora de estudar a segunda. Você já viu que em todo
filme ou brincadeira, caso as coisas saiam erradas, diz-se que:
Vamos ativar o plano “B”!
Ora, esse plano “B” é o plano de contingência. O plano de

contingência, infelizmente, não é uma “carta na manga” que
facilmente é lançada sobre a mesa e muda todo o jogo.
Geralmente é um conjunto de ações, tomadas sob pressão,

geradoras de conflitos e de crises, pois o plano de contingência é
um plano de solução de crises. A percepção do erro geralmente
é postergada ao máximo e isto ocorre de forma inconsciente.
Ninguém gosta de errar.
Para isso, tem-se as ferramentas de planejamento,

acompanhamento e controle do projeto (você acompanhou várias
neste livro), que devem fazer parte de cada momento de revisão
para que se possa perceber se estamos de acordo ou não com o
planejado.
Tais ferramentas apontam os erros, basta fazer as marcações e

ler os indicadores. E tendo visto os erros, não é certo trabalhar
com desculpas, pois este é outro defeito do ser humano, aceitável
apenas em questões sentimentais (e não de trabalho).
Realizando as revisões e percebendo erros capazes de afetar

seriamente o projeto, um plano de contingência deve ser aplicado.
Várias ações devem ser tomadas quando um projeto sai dos
trilhos rumo ao fracasso.
Quais são as ações corretivas?
186
book.indb 186 31/5/2007 14:24:04

Conforme o trabalho de Iacovou e Dexter (2004), são definidas

as seguintes ações corretivas, tentando remediar a situação:
desenvolver um plano de recuperação;

redefinir e gerenciar o propósito do projeto, ou seja,
avaliar novamente o escopo do projeto e o que, de fato, se
quer atingir;
reavaliar o negócio e considerar o cancelamento do
projeto, quando de fato não há solução de continuidade;
replanejar o projeto usando métodos de estimativa
apropriados e comprovados;
gerenciar as expectativas dos clientes, pois eles
perceberão rapidamente que “as coisas não estão indo
bem”;
formular um plano de comunicação objetivo e
aberto, tanto para os membros da equipe, como para
fornecedores e clientes – isso trará confiança;
dividir o restante do projeto em pequenas partes
ou atividades, facilitando o controle, a percepção
de objetivos menores e mais próximos, bem como a
capacidade de acreditar no sucesso;
tratar as dificuldades pessoais da equipe do projeto,
especialmente quando esta equipe se sentiu culpada pela
aproximação do insucesso;
incorporar práticas corretivas no processo de
desenvolvimento do restante do projeto;
por fim, reavaliar a liderança, verificando se ela é capaz
de alinhar as diversas forças componentes do projeto
rumo ao seu objetivo.
O ponto principal de um plano de contingência,

desta forma, é a tomada de decisão.
Unidade 5 187
book.indb 187 31/5/2007 14:24:04

Tomar decisões é a tarefa dos líderes empenhados no sucesso.

Por esse motivo, ao perceber que um projeto não vai bem, é
importante verificar se o líder vai bem.
Seção 3 - Atendendo as expectativas do cliente

Toda propaganda hoje diz o seguinte:
Fazemos de tudo para atender as expectativas do

cliente.
Sabemos que isto é apenas propaganda e que ninguém atende

exatamente as expectativas do cliente. Provavelmente porque tais
expectativas não são bem conhecidas. Nem mesmo pelos clientes.
Quando um de nós diz: “vou comprar um quilo

de açúcar” é muito fácil atender tal expectativa.
No entanto, se dizemos: “queria um software para
gerenciar a venda em balcão”, a expectativa é muito
mais complexa do que está expressa nesta simples
frase.
Não é fácil compreender como o cliente deseja que o

software seja, o tempo de resposta, a interface, quanto
está disposto a gastar e muitas outras questões desse
tipo.
Não há uma regra sobre como avaliar todos esses

requisitos, mas uma série de procedimentos foi
apresentada neste livro ao discutir sobre os requisitos
do cliente. A análise aprofundada de tais requisitos
e a comunicação clara do que se entendeu como
escopo do problema, tanto para o próprio cliente como para os
membros da equipe de projeto, é condição básica para atender
expectativas. E digo expectativas no plural, por entender que há
188
book.indb 188 31/5/2007 14:24:04

aquelas específicas do cliente e aquelas da equipe e ambas devem

ser atendidas para que haja sucesso.
Além disso, não acredito em empresas que vivem alardeando que

“fazem tudo pelo cliente”. As empresas fazem antes algo por si
mesmas, depois pelo cliente. E nisto não há um juízo de certo
ou errado, mas simplesmente o fato de que, para sobreviver, a
empresa precisa olhar para si mesma.
Não se trata também de ultrapassar limites de ética ou avançar

em atitudes oportunistas, mas, sim, de ser realista quanto às
finalidades de cada sujeito neste jogo. Assim,
a expectativa do cliente deve ser tratada como

algo objetivo e deve ficar claro para ambas as
partes o que é possível realizar e o que não é.
Chegar ao fim do projeto é, então, contemplar a expectativa

desse cliente, seja ele um contratante externo, uma demanda
da empresa ou um desejo de você mesmo. Ao confrontar tal
contemplação, tem-se uma medida do sucesso do trabalho.
Seção 4 - Sobre o sucesso (ou fracasso) do projeto

O projeto foi entregue no prazo, gastou-se menos do que
o previsto, o produto alcançou ou até mesmo superou as
expectativas, os benefícios mensuráveis pelo seu resultado são
enormes... bem, temos um projeto de sucesso.
A equipe será condecorada, haverá prêmios para os responsáveis,

a empresa passará a vender mais ou conquistar um nicho que
antes não detinha. Inovações serão incorporadas pela indústria
e pelo mercado e, dependendo do grau, poderão até mesmo
revolucionar um setor ou um hábito.
Para seqüência deste estudo, imagine, porém, a situação inversa:

o fracasso. Todos queremos evitá-lo e, mesmo quando houver
um fracasso, precisamos aprender com ele para crescer. Não há
vitorioso que não tenha fracassado alguma(s) vez(es).
Unidade 5 189
book.indb 189 31/5/2007 14:24:04

Como você pode se prevenir dos fracassos em

projetos?
Para Keeling (2002), existe fracasso em projetos quando:
objetivos não são alcançados no prazo;

custos vão além dos limites aceitáveis;
resultados têm nível de qualidade comprometido.
Nesses três itens resumem-se os fatores que definem um projeto:
prazo, custos, recursos e benefícios. Se algum deles não for
atendido, tem-se indícios de fracassos.
No entanto, você pode fazer uma análise mais sutil. Há casos de

projetos que foram concluídos com custo excessivo, muito além
do orçamento original e acima do prazo estipulado.
São exemplos desse tipo a Ópera de Sydney, na

Austrália e o Eurotúnel, que liga a Inglaterra e
França.
No entanto, quem ousaria hoje dizer que são fracassos? Do

ponto de vista dos custos e dos prazos, foram. Mas os benefícios
aparentemente superam em muito essas falhas.
Estes são casos de projetos estratégicos e visionários, que são

considerados no início como equivocados ou previamente
fracassados. Com o passar do tempo, percebe-se o quanto foram
importantes para os desdobramentos futuros. Isso se deve à
visão poderosa, à intuição e à persistência de lideranças e não aos
cálculos e estudos de burocratas anônimos.
190
book.indb 190 31/5/2007 14:24:05

Figura 5.1. Ópera de Sydney, na Austrália, projetada em 1957 pelo dinamarquês Jorn Utzon, que hoje
é Patrimônio Nacional da Austrália.
Atualmente, muitos projetos na área de software têm sido

vítimas da síndrome do fracasso. Por este motivo, boa parte
dos estudos recentes sobre gestão de projetos tem se voltado
a analisar tais casos e o interesse sobre os trabalhos do PMI
(Project Management Institute) é sintomático de uma realidade de
mercado.
Segundo Page-Jones (1990), embora todo projeto de

Processamento de Dados enfrente dificuldades técnicas, elas não
são a causa principal de fracassos. Os desastres verdadeiramente
impressionantes são devidos a gerenciamento inadequado ou
inepto de projetos.
Esse autor ataca exatamente o ponto: os problemas relativos a

projetos não estão nas questões técnicas e tampouco em atrasos
ou gastos, pois, estes são conseqüências de um problema maior: o
fracasso da gestão.
Como evitar o fracasso da gestão?
Unidade 5 191
book.indb 191 31/5/2007 14:24:05

Pode-se evitar fracassos, conforme Keeling (2002), com:
melhor avaliação de viabilidade;

análise de riscos criteriosa;
uso de métodos de planejamento;
uso de sistemas de controle.
Porém, isto não é suficiente, apesar de necessário. Um grupo
de trabalho pode se reunir e fazer várias avaliações, considerar
inúmeros riscos e gerar grandes relatórios, preencher planilhas
e usar softwares de planejamento de projetos. Mas tudo isso é
inócuo se não houver o poder da decisão e o poder da decisão é
uma atividade humana. Com isto, quero dizer que é preciso ter
liderança para que um projeto aspire ao sucesso.
Para encerrar esta seção, acompanhe um caso famoso de fracasso,

motivo de estudos e pesquisas dos interessados em administração
sobre o projeto de construção de uma embarcação de guerra, no
século XVII.
192
book.indb 192 31/5/2007 14:24:06

Estudo de Caso:
VASA – um projeto fracassado do século XVII.

O caso da embarcação “Vasa” foi apresentado no
artigo de Kessler et al. (2004), do qual retirei a história
seguinte.
Figura 5.2. Representação em escala reduzida, Museu do VASA (Fairley e

Willshire, 2003).
No começo do século XVII, a Suécia estava engajada
numa série de batalhas navais contra a Dinamarca,
Rússia e Polônia. Em 1625, dez embarcações de guerra
suecas foram abatidas quando estavam patrulhando
a Baía de Riga. Por este motivo, foram aceleradas as
atividades de construção de uma das maiores naves
de guerra daquele tempo: Vasa.
Por ter descoberto que a Dinamarca planejava
construir um barco ainda maior que o Vasa, o rei
da Suécia, Gustavus Adolphus, ordenou alterações
na especificação do navio para introduzir um
segundo nível de canhões e mais canhões do que
originalmente planejado. Com tais modificações o
Vasa excedeu em muito o que poderia ser suportado
pelo lastro original.
Unidade 5 193
book.indb 193 31/5/2007 14:24:06

Além disso, o mestre construtor, Henrik Hybertson,

faleceu, deixando a construção nas mãos de um
gerente inexperiente e mais fraco nas decisões e
controle dos operários.
No verão de 1628, um teste de estabilidade foi
conduzido pelo Almirante Klas Fleming e pelo Capitão
Sofring Hansson. Trinta homens correram de um
lado ao outro do navio. Depois da terceira corrida
o navio inclinava tão violentamente que o teste
foi interrompido. No entanto, Fleming decidiu não
postergar o lançamento do navio, alegando que o
mestre construtor já tinha feito navios antes e não havia
com o quê se preocupar.
Menos de um mês depois, em 10 de agosto de 1968,
o Vasa foi levado ao mar. Para mostrar o poder dos
armamentos da embarcação, o Capitão Hansson
velejou com as portas dos canhões abertas, o que não
era usual. Depois de navegar pouco mais de mil metros
em mar calmo, o Vasa entornou e naufragou, levando
consigo cinqüenta marinheiros para o fundo do porto
de Estocolmo. Era uma embarcação magnífica, que
tinha custado cerca de 5% do tesouro sueco, com 64
canhões pesados e para 300 marinheiros, feito para
simbolizar a força e a beleza da Suécia e para meter
medo no coração dos seus inimigos.
Muita discussão foi feita para descobrir os culpados
pelo desastre, mas ninguém foi formalmente acusado.
O rei foi parcialmente culpado por ter demandas
pouco realistas, Hybertson pelo desenho medíocre do
projeto, Fleming por não ter dado atenção aos testes
realizados e Hansson pela inabilidade no comando da
embarcação.
Os erros, porém, foram bem mais graves do que esses e
pode-se considerar os seguintes detalhes:
1. os construtores tentaram imitar o projeto da
embarcação dinamarquesa Sancta Sophia, no entanto
não tinham conhecimento técnico nem capacidade de
desenvolver procedimentos construtivos para tanto;
2. ênfase na elegância e no poder de fogo e pouca
importância à estabilidade e navegabilidade;
3. excesso de pressa na construção do barco e pouca
atenção a sua qualidade, especialmente se considerar a
sua dimensão e a quantidade de novas tecnologias que
estavam incorporadas, o que atribuía ao projeto uma
série de riscos e incertezas;
194
book.indb 194 31/5/2007 14:24:07

4. os testes durante a fase de desenvolvimento eram

incompletos, houve desprezo pelos resultados de
tais testes e excesso de otimismo com o resultado do
projeto, desconsiderando os sinais em contrário;
5. três pessoas diferentes fizeram especificações e
definições para o projeto, de forma independente,
modificando o conjunto (o Rei, Hybertson e o último
mestre);
6. o projetista principal, Hybertson, faleceu um ano antes
de o navio ser concluído e não deixou documentação
ou memória, ou seja, não houve transferência
tecnológica;
7. o rei não tinha conhecimentos técnicos para o
problema proposto e, mesmo assim, interferiu no
projeto como seu chefe supremo.
Este conjunto de fatores gerou esse fracasso exemplar.
Seção 5 - Equipe e documentação

Equipes de projeto podem criar tal afinidade e desfazê-las não
é fácil. Ficam as afinidades e o entusiasmo, especialmente se
há sucesso. O encerramento das atividades deve passar por uma
avaliação de finalização. Uma discussão franca sobre erros e
acertos, especialmente no que se refere ao modelo de gestão
adotado, bem como ao dia-a-dia da equipe, trará benefícios e
crescimento a todos.
Reconhecimento dos méritos: eis uma obrigação.
Há muitos casos de projetistas que empenham

horas de esforço e imaginação num projeto
e sabemos que não são apenas aquelas horas
que estão escritas lá na planilha. Estas horas
são doações espontâneas daqueles que gostam
de desafios e almejam sempre a qualidade e
a realização. O reconhecimento disto deve
Unidade 5 195
book.indb 195 31/5/2007 14:24:08

ser manifestado claramente e, quando houver oportunidade e

condições, deve ser premiado.
Receber um prêmio, mesmo que seja uma simples palavra de

agradecimento sincero, é algo honroso. Conheço gestores que
não sabem premiar e consideram que realizar o trabalho é a
obrigação de cada um. Tomara que você não encontre um desses
pela frente!
Documentação é um ponto falho em quase todos

os projetos.
Quando Joãozinho e Mariazinha entraram pelo caminho

desconhecido na floresta, a trilha de pedras que ele deixou foi seu
documento principal, o documento que permitiu que ele voltasse
para casa. Este era o “caminho das pedras”. No entanto, quando
o único material que ele tinha para documentar o caminho, na
segunda vez que entrou pela floresta, eram pedaços de miolo de
pão, os pássaros comeram sua marcação e ele se perdeu. Esta
documentação era efêmera.
A memória é uma documentação efêmera.
A documentação não é adequada se não for clara,

estiver arquivada, acessível e possível de ser
entendida por outros.
Você acompanhou desde a primeira unidade que o planejamento

está baseado em análises, avaliações, relatórios, depois planilhas e
diagramas. Muitos desses documentos serão usad os ao longo do
projeto para revisões, serão realizadas reuniões que deverão gerar
atas e assim por diante.
Além disso, o trabalho técnico será baseado em desenhos,

rascunhos, anotações, resultados de testes e muitos outros
documentos de variados tipos.
196
book.indb 196 31/5/2007 14:24:08

Nenhum projeto poderá ser considerado

encerrado se a documentação não estiver
adequadamente preservada e organizada.
É uma obrigação dos responsáveis de cada etapa do projeto

e do gestor finalmente, organizar, arquivar e preservar a
documentação do projeto, que deve ser parte do resultado final do
trabalho.
Seção 6 - Lições aprendidas e novas idéias

Cada projeto é uma oportunidade de
aprendizagem e, geralmente, aprendemos
com os erros.
A constante revisão do projeto, em cada

uma das suas etapas, será um exercício
de análise e, para isso, contamos com
diversos instrumentos, tais como relatórios
preenchidos lá no começo e que devem ser
analisados em comparação com o realizado,
passo a passo. Muitas críticas e idéias surgirão nesses momentos e
é importante avançar sobre isto. Como dito na seção anterior,
a documentação gerada será uma fonte de

recursos de aprendizado.
A leitura do caso “Vasa” também é uma oportunidade de

aprendizagem, pois você poderá estudar erros e acertos em
projetos de outros para avaliar caminhos. O estudo de casos
proporciona, em contraste com nossa própria experiência, uma
fonte rica de aprendizagem. Considere novamente o caso “Vasa”
e compare com projetos na área de software. Foi exatamente
isso que fizeram Fairley e Willshire (2003) em seu artigo sobre
problemas em projetos de software, buscando antídotos para
Unidade 5 197
book.indb 197 31/5/2007 14:24:08

tais problemas numa série de sugestões, cujas principais estão

apresentadas no quadro 5.1.
Quadro 5.1. Problemas em projetos de software e seus antídotos, adaptado de (Fairley & Willshire, 2003).
PROBLEMA ANTÍDOTOS
• estimativas objetivas de prazo
Pressão excessiva de prazos
• mais e melhores recursos priorizações
• estimativas objetivas de prazo
Pressão excessiva de prazos
• mais e melhores recursos priorizações
Mudanças no escopo e nas • desenvolvimento iterativo

necessidades • modificar gestão de controle e planejamento
• desenvolvimento de especificações prévias
Falta de especificações
técnicas • atualização das especificações com base em eventos
indicação de um arquiteto de software
• desenvolvimento de planejamento prévio
Falta de documentação de
planejamento • atualizações periódicas e baseadas em eventos indicação de
um gestor de projetos
Inovações excessivas ou • maior controle sobre a linha de trabalho

secundárias • análise de impactos gestão contínua dos riscos
• uso de protótipos
Falta de métodos científicos • desenvolvimento incremental uso de métricas de medição
da performance técnica
Ignorando o óbvio • assimilar as lições aprendidas anteriormente
• cultura de trabalho baseada em ética nos relacionamentos

Comportamento anti-ético uso e aderência a códigos de ética formais
Aparentemente, um projeto de embarcação nada tem a ver com o

desenvolvimento de software, mas não é bem isto que nos sugere
este conjunto de “problemas e seus antídotos”.
Analisando o quadro 5.1 você pode perceber que as lições tiradas

do episódio são muitas e algumas das mais importantes dizem
respeito ao uso de métricas de performance, ao desenvolvimento
incremental, à divisão do projeto em pequenas etapas, ao controle
constante do desenvolvimento e a uma cultura baseada em ética e
bom relacionamento.
198
book.indb 198 31/5/2007 14:24:09

Você poderia ainda listar mais algumas lições!
Tais como:
não se deve imitar projetos sem o suficiente

conhecimento técnico;
buscar concisão e usabilidade;
não se submeter à pressa e dar atenção especial à
qualidade;
realização constante e contínua de testes, durante todas
as etapas;
reduzir os cargos de responsabilidade, para evitar o
“empurra-empurra” da decisão;
gerar documentação sempre e não apenas no final;
aqueles que não têm conhecimento técnico não devem
interferir em assuntos que não são de sua competência.
Se você retornar à unidade 1 deste livro, poderá ver que os
projetos foram se modificando no decorrer do tempo e as lições
aprendidas foram sendo incorporadas pouco a pouco. No início,
houve desperdício imenso de recursos financeiros e mesmo de
vidas humanas. Um esforço enorme de melhoria se deu na época
da revolução industrial e logo depois, chegando ao começo do
século XX com teorias e ferramentas específicas. Hoje, temos um
número muito maior de ferramentas, sistemas computacionais
especiais e disputas teóricas em revistas especializadas. Porém,
ao mesmo tempo, os resultados não são tão animadores. Basta
conferir nos quadros apresentados na unidade 1 que comparam
o passado e o presente. Espero que você se dedique firmemente
para não colocar seus próprios projetos naquela estatística.
Bem, você estudou questões sobre aprendizagem e sobre o

processo de tirar lições dos fatos, das dificuldades e soluções que
irá encontrar no decorrer do trabalho de desenvolvimento do
projeto. Porém, acredite,
Unidade 5 199
book.indb 199 31/5/2007 14:24:09

tais lições só serão percebidas e aprendidas por

pessoas e equipes especiais.
Para pessoas e equipes cheias de idéias e criatividade, encerrar

um projeto geralmente serve de pretexto para dar origem a
um novo projeto, pois todas as idéias que foram surgindo no
meio do caminho são sementes para novos trabalhos. Empresas
buscam pessoas assim, para que sobrevivam no mercado criando
oportunidades de novos negócios.
Anotações feitas durante o trajeto de desenvolvimento serão

geradoras de oportunidades em ambos os sentidos. Por um lado,
vários apontamentos indicarão a necessidade de acrescentar
melhorias incrementais, as quais não caberiam no decorrer do
projeto já que atrasariam o trabalho ou determinariam custos
impossíveis de cumprir.
Por outro lado, idéias completamente novas poderão surgir,

apontando para soluções radicalmente diferentes.
É importante também perceber que o fracasso

de um projeto não é, necessariamente, o
encerramento das oportunidades. Os fracassos
ou os graves problemas de um projeto chamam
a atenção para novas oportunidades de
desenvolvimento.
Mas para renascer é preciso ter o espírito e a convicção dos

líderes. Inúmeras oportunidades estão a sua frente. Ou seja, é a
hora de começar um novo projeto. Boa sorte!
200
book.indb 200 31/5/2007 14:24:09

1) Quais são os passos para implantar um plano de recuperação num

projeto em crise? Exemplifique com projetos de sua experiência.
2) Que grandes dificuldades existem no atendimento das expectativas do

cliente?
Unidade 5 201
book.indb 201 31/5/2007 14:24:09

3) Como se pode prevenir um projeto do fracasso? Que atitudes você

pode tomar nesse sentido?
4) Quais lições você tira do fracasso do projeto VASA para seus próprios
projetos?
202
book.indb 202 31/5/2007 14:24:09

Síntese
Nesta unidade, você viu que é importante uma análise criteriosa

de todos os passos dados durante o projeto e documentá-los.
Assim, será possível dar continuidade às melhorias que o projeto
exigir, permitir o suporte ao produto, aprender com os erros e
acertos do processo e também gerar novas idéias de projetos.
Outra questão importante refere-se ao reconhecimento dos

membros da equipe como os verdadeiros responsáveis pelas
conquistas obtidas. Evidenciar tais méritos é uma obrigação,
pois a partir do momento que o projeto se encerra as pessoas se
voltarão para outros trabalhos e funções, e lembrando-se desses
momentos de desafio, sentirão satisfação por saber que foram
reconhecidos.
Haverá os casos de fracassos, que devem ser analisados com ainda

maior rigor, permitindo nosso crescimento pessoal e também a
propagação da experiência para todos os interessados. Estudos
de casos famosos são, também, importantes objetos de pesquisa e
análise.
Oportunidades de novos projetos estão a nossa disposição. A

última seção fala justamente disto e, de certa forma, nos liga ao
início deste livro, que discute a origem dos projetos. Que seja
aqui o ponto de ligação para o eterno recomeçar, seja dos estudos,
seja dos projetos, seja dos novos empreendimentos de sucesso. Até
mais!
Unidade 5 203
book.indb 203 31/5/2007 14:24:09

Saiba mais
1 – Visite o site http://www.arcweb.com/ e veja inúmeros

estudos e oportunidades de novos projetos na área empresarial e
industrial. Veja também estudos de casos e análises de mercado.
2 - O IEEE – Institute of Electric and Electronic Engineers

– mantém uma Sociedade voltada à gestão de engenharia
e projetos, de âmbito mundial. É a IEEE Engineering
Management Society. Visite o site http://www.ewh.ieee.org/soc/
ems/ e veja inúmeras oportunidades de trabalho, estudo, artigos,
revistas, etc. Estudantes de graduação de qualquer área podem se
associar com valores de taxas anuais especiais.
204
book.indb 204 31/5/2007 14:24:09

Para concluir o estudo
Com este livro, você fez uma revisão geral da disciplina

de Gerência de Projetos. Foram trabalhados os principais
tópicos da matéria, desde o início da idéia de um projeto,
passando por seu planejamento, técnicas de modelagem,
métodos de controle durante a fase de execução,
procedimentos para encerramento e documentação,
chegando à entrega ao cliente ou solicitante.
O assunto da “gerência de projetos” é essencialmente

moderno, apesar dos projetos fazerem parte da história
do homem. É moderno porque, atualmente, os ciclos de
evolução tecnológica se sucedem muito rapidamente e
as empresas precisam se renovar continuamente para se
manterem vivas. Esta renovação, na maioria das vezes, se
dá pela criação de novos produtos e processos através de
projetos.
Espero ter colocado elementos úteis para o estudante

e leitor, que possibilitem a abertura de novas idéias e a
revisão dos conceitos existentes. É um assunto vivo e, por
isto, sujeito a críticas e novas propostas. Ficarei grato por
todos os comentários e críticas que você, leitor atento,
possa fazer.
Sucesso a todos!
Prof. Mauro Faccioni Filho
book.indb 205 31/5/2007 14:24:09

book.indb 206 31/5/2007 14:24:10
Referências
BAZZO, Walter Antônio, PEREIRA, Luiz Teixeira do Vale.

Introdução à Engenharia, 5.ed. Florianópolis, Editora da UFSC,
1997.
CHRISTENSON, Dale; WALKER, Derek H. T. Understanding the
role of “vision”in project success. IEEE Engineering Management
Review, vol 32, no. 4, 2004. pp 57-73.
CLELAND, David. The evolution of project management. IEEE
Transactions on Engineering Management, v.51, no. 4, 2004, pp.
396-397.
COURAU, Christophe. Muralhas que dividiram os homens,
História Viva, edição 13, novembro de 2004. http://www2.uol.
com.br/historiaviva/home.html (acessado em 18/02/2005)
COVEY, Stephen. O 8º. Hábito: da eficácia à grandeza. Rio de
Janeiro: Elsevier, 2005. 413 p.
DeMARCO, Tom. Controle de projetos de software. Editora
Campus, Rio de Janeiro, 1991. 304 pp.
DVIR, Dov, SHENHAR, Aaron., ALKAHER, Shlomo. From a single
discipline product to a multidisciplinary system: adapting the right
style to the right project. IEEE Engineering Management Review,
vol 32, no. 1, 2004. pp 12-23.
FACCIONI Filho, Mauro. Especificação e solução de problemas
de engenharia. (Apostila) curso de Especialização “Automação
e Computação Industrial”, fevereiro de 2004, CTAI/Senai/SC,
Florianópolis.
FACCIONI Filho, Mauro. Gestão de Projetos e de Equipes.
Palhoça: Unisul Virtual, 2005. 300p.
FAIRLEY, Richard E., WILLSHIRE, Mary Jane. Why the Vasa Sank: 10
Problems and Some Antidotes for Software Projects. IEEE Software.
March/April, 2003. pp 18-25 (disponível em http://computer.org/
software )
FERNANDES, Jorge Monteiro. Gestão da Tecnologia como parte
da estratégia competitiva das empresas. Brasília: IPDE, 2003.
275 p.
book.indb 207 31/5/2007 14:24:10

GOOCH, Tom. Object Oriented Analysis and Design Team. Kennesaw
State University, 2000. (disponível em http://pigseye.kennesaw.edu/
~dbraun/csis4650/A&D/index.htm. Acesso em: 24/Abril/2005).
GREEFF, Gerhard. Staying in sync. ISA Intech/Industrial Computing, vol 52,
no. 6, June 2005. pp. 51-55. (www.isa.org/intech)
HINOJOSA, María Alejandra. DIAGRAMA DE GANTT. 2003. Disponível em
www.gestiopolis.com, acessado em 24/04/2005.
HOUAISS, Antônio. Dicionário Houaiss da Língua Portuguesa. Editora
Objetiva / Instituto Antônio Houaiss. Rio da Janeiro, 2004. 2922 pp.
IACOVOU, Charalambos, DEXTER, Albert. Turning around runaway
information technology projects. IEEE Engineering Management Review, vol
32, no. 4, 2004. pp 97-112.
KEELING, Ralph. Gestão de projetos, uma abordagem global. Editora
Saraiva, 2002, 294 pp.
KESSLER, Eric H., BIERLY, Paul, GOPALAKRISHNAN, Shanthi. VASA Syndrome:
insights from a 17th-Century new-product disaster. IEEE Engineering
Management Review, vol 32, no. 1, 2004. pp 38-48.
KLOPPENBORG, Timothy; PETRICK, Joseph. Managing Project Quality. IEEE
Engineering Management Review, vol 32, no. 4, 2004. pp 86-790.
MSF – Microsoft Solutions Framework, 1998. Disponível em www.
microsoft.com/technet/itsolutions/msf/default.mspx
PAAP, Jay, KATZ, Ralph. Anticipating disruptive innovation. IEEE Engineering
Management Review, vol 32, no. 2, 2004. pp 74-85.
PAGE-JONES, Meillir. Gerenciamento de projetos: guia prático para
restauração da qualidade em projetos e sistemas de processamento
de dados. São Paulo: McGraw-Hill, 1990. 328 pp.
PQA - History of Project Management, www.pqa.net, acessado em
15/02/2004. Process Quality Associates Inc.
PMBOK, Guide to the Project Management Body of Knowledge, Project
Management Institute, 2004, 3a. edição, 388 pp.
PRADO, Darci Santos do. PERT/COM – Série Gerência de Projetos,
volume 4. 1998. Belo Horizonte. Editora DG.
RAZ, Tzvi, BARNES, Robert, DVIR, Dov. A critical look at Critical Chain
Project Management. IEEE Engineering Management Review, vol 32, no. 2,
2004. pp 35-44.
SÁENZ, Tirso W., CAPOTE, Emilio G. Ciência, Inovação e Gestão
Tecnológica, IEL/SENAI, Brasília, 2002.
book.indb 208 31/5/2007 14:24:10

SISK, Toney. The History of Project Management. http://officeupdate.
microsoft.com/downloadDetails/projhistory.htm. Acesso em 20/Fev/2005)
VALERIANO, Dalton L. Gerência em projetos – pesquisa,
desenvolvimento e engenharia. São Paulo: Makron Books, 1998. 438 pp.
book.indb 209 31/5/2007 14:24:10

book.indb 210 31/5/2007 14:24:11
Sobre o professor conteudista
Mauro Faccioni Filho nasceu em Maringá, PR, em 29

de outubro de 1962. Formou-se em Engenharia Elétrica
pela Universidade Federal de Santa Catarina (UFSC)
no começo do ano de 1985 e nesse mesmo ano fundou
a empresa Creare Engenharia (www.creare.com.br),
junto com dois colegas da universidade. Posteriormente,
concluiu, também na UFSC, Mestrado (1997) e
Doutorado (2001) em Engenharia Elétrica, com estudos
sobre representações tridimensionais e modelagem
numérica computacional.
Nos anos 2002 a 2004, atuou como diretor do Centro

de Tecnologia em Automação e Informática – CTAI,
em Florianópolis, tendo participado da criação de cursos
superiores e de pré-incubadora empresarial tecnológica,
além de ter editado revista técnica em automação e
informática.
Desde 2002 está na UNISUL como professor. Participou

do desenvolvimento em 2004 do projeto do Curso
Superior de Tecnologia em Web Design e Programação,
do qual é atualmente coordenador e onde atua também
como tutor.
Em 2006, fundou a empresa FAZION Sistemas,

dedicada à “inteligência em redes móveis”, onde sua
equipe desenvolve softwares para “web móvel” (www.
fazion.com.br) .
Com vários artigos técnicos e científicos publicados,

lançou ainda três livros de poemas. Seu currículo
completo está disponível para consulta online no banco de
dados do CNPq, no endereço http://buscatextual.cnpq.
br/buscatextual/index.jsp.
book.indb 211 31/5/2007 14:24:11

book.indb Sec1:212 31/5/2007 14:24:11
Respostas e comentários das
atividades de auto-avaliação
A seguir, acompanhe as respostas sobre as atividades de auto-
avaliação apresentadas ao longo de cada uma das unidades
desta disciplina. Para o melhor aproveitamento do seu estudo,
confira suas respostas somente depois de realizar as atividades
propostas.
UNIDADE 1
1) Resposta: o exemplo descrito deve claramente identificar um

objetivo e um prazo determinado de execução
2) Resposta: durante a revolução industrial há maior interesse
em desenvolver métodos de gerência, para evitar gastos
desnecessários, perdas de tempos, atrasos, etc. Um cientista
da administração surge nessa época e começa a estudar
detalhadamente o trabalho, mostrando que a produtividade
pode ser aumentada se o trabalho for dividido em pequenas
tarefas separadas. Seu nome é Frederick Taylor (1856-1915) e ele
é considerado o pai da ciência da administração (SISK, 2004).
3) Resposta: na prática não houve mudanças e os índices são
muito próximos e até piores, apesar da implementação de
variadas técnicas para controle de produção introduzidas
durante o século XX. Isto indica que as empresas não estão
utilizando tais técnicas e continuam realizando seus trabalhos
sem gerenciamento.
book.indb Sec1:213 31/5/2007 14:24:11

4) Respostas:
Exemplo de tarefa de rotina

Área Exemplo de projeto ou atividade contínua
Concessionária de (projeto de nova hidrelétrica) (operação da hidrelétrica)

energia elétrica
Software (nova plataforma de e-commerce) ( manutenção de aplicativo)
Indústria (desenho de novo lançamento) (linha de montagem)

Automobilística
(criar nova linha de financiamento e
Bancos (operar carteiras de crédito)
lançar no mercado)
(desenvolver sistema de eleição
Governo (emissão de títulos eleitorais)
eletrônica)
5) Resposta - exemplo:
- necessidade: um sistema de marcação do tempo que fosse portátil
-conhecimentos: tecnologia mecânica dominada
- idéias: relógio de pulso, de bolso
- seleção: de pulso
- desenvolvimento: artesãos suíços
- uso de difusão: relógios de quartzo, com ponteiros e com visor digital,
etc)
6) Resposta: veja o desenho a seguir.
carro 4x4
casa software
214
book.indb Sec1:214 31/5/2007 14:24:11

Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF
UNIDADE 2
1) Resposta exemplo: Visão restrita: instalar um software de controle de

estoque, que relaciona os produtos em prateleira e dá a baixa a partir da
emissão da nota fiscal de venda, com controle feito por um “responsável”
pelo estoque;
Visão ampla: sistema integrado que verifica o estoque durante o processo
de emissão de propostas, ele deve ser atualizado a cada modificação
solicitada pelo cliente, sendo que quando este dá o aceite, imediatamente
o estoque recebe o aviso da baixa e a reposição é requisitada
automaticamente.
2) Resposta exemplo::
listar as informações que estão no enunciado, na tentativa de
detalhar o melhor possível suas partes;
descrever todos os efeitos conhecidos do produto, quando for o
caso, e enumerar todas as possíveis causas;
listar o que deve ser determinado pela solução, ou seja, definir
com a maior clareza possível o que está sendo buscado;
criar modelos e esquemas de representação, permitindo uma
melhor visualização do conjunto;
desenvolver desenhos esquemáticos, diagramas e fluxogramas;
verificar as leis físicas associadas e também outros impeditivos
e limitantes, tais como questões jurídicas, restrições técnicas,
restrições ambientais, etc;
usar simuladores como ferramentas de apoio.
3) Resposta: o algoritmo permite modelar o planejamento do projeto

de maneira a entendermos e definirmos todos os passos que devem ser
seguidos na execução do projeto, para que o mesmo chegue ao resultado
esperado.
4) Resposta: a partir de certo prazo o projeto perde o sentido. Isto não
significa apenas que ele dá prejuízo, mas simplesmente não há mais
possibilidade de se obter sucesso, como por exemplo, no lançamento de
um produto específico para uma data, ou quando há uma concorrência,
ou devido a um fenômeno natural, etc.
5) Resposta: porque projetos são trabalhos que envolvem variáveis muito
diversas e como há um prazo determinado para seu encerramento, fatores
como custos e recursos tendem a variar conforme a complexidade do
problema e por isto é difícil manter todas as previsões.
215
book.indb Sec1:215 31/5/2007 14:24:11

UNIDADE 3
1) Resposta: porque projetos são trabalhos que envolvem variáveis muito

diversas e como há um prazo determinado para seu encerramento, fatores
como custos e recursos tendem a variar conforme a complexidade do
problema e por isto é difícil manter todas as previsões.
Prazos estimados pela

Projeto Qualidade equipe de implantação
A - reuniões do grupo do projeto para definir o programa 1 semana, 7 dias
B - redação do programa de qualidade 2 semanas, 14 dias
C - treinamento do pessoal do setor administrativo 3 dias
D - implantação do programa de qualidade no setor administrativo; 2 semanas, 14 dias
E - treinamento do pessoal do setor de produção 3 dias
F - implantação do programa no setor de produção; 2 semanas, 14 dias
G - avaliação dos resultados e conclusão 3 dias
2) Resposta:
4) Resposta: a matriz ajuda a definir as necessidades de um projeto

e alinhar aos recursos humanos disponíveis para o trabalho. Não
havendo recursos humanos na empresa ou grupo, pode-se buscar por
recrutamento externo. Da mesma forma, a matriz ajuda a definir os
investimentos financeiros do projeto, pois é possível definir os gastos
com a equipe de acordo com os custos de hora-homem dos membros
escolhidos.
216
book.indb Sec1:216 31/5/2007 14:24:11

Sistemas Informatizados Corporativos no Âmbito da Administração Pública: SIAFI, SIAFEM e SIGEF
5) Resposta: Geralmente a estrutura exclusiva, com um organograma bem

definido, é o que melhor se adapta nessas condições. Nesse modelo, os
membros do projeto são dedicados a um projeto apenas.
6) Resposta: esta é a estrutura matricial e seu grande problema é a
complexidade, que exige maturidade da empresa e das equipes de
projeto para poderem trabalhar em vários projetos simultaneamente, com
equipes alterando-se conforme o cronograma e o setor/atividade.
7) Resposta: na estrutura do tipo horizontal, pois os membros da equipe
se reconhecem como pares, mesmo quando os domínios e os interesses
técnicos são muito diferentes. Esse tipo de estrutura é tipicamente
multidisciplinar, com grande número de idéias e soluções criativas, o que
favorece o desenvolvimento de aplicativos de software.
UNIDADE 4
1) Resposta: antes de começar um projeto é necessário uma etapa de

reflexão para elaborar a etapa de início do projeto. A etapa de início de um
projeto deve se dar por conta de uma reunião. Nesta reunião, os planos
serão discutidos em detalhes, o plano de produção deve ser delineado,
as tarefas divididas e as responsabilidades atribuídas. O fluxograma geral
deve ser apresentado, discutido e suas cópias distribuídas. A comunicação
dos procedimentos, já discutidos, deve ser feita a partir desse contato
inicial.
2) Resposta: os quatros passos são: (1) identificar possíveis modos de ação,
(2) verificar vantagens e desvantagens; (3) discutir e avaliar; (4) escolher o
modo de ação mais vantajoso e partir para ele.
3) Resposta: resposta subjetiva, baseada no seguinte quadro:
Diferenças
Indivíduo / profissional Organização / gerência
Busca a inovação tecnológica Busca o lucro
Quer autonomia de ação Quer integrar os profissionais na organização
Quer livrar-se de regras e procedimentos Estabelece as regras e procedimentos
Quer autoridade baseada em mérito Autoridade baseada em hierarquia
Quer ser recompensado com base em seu desempenho Recompensa conforme o interesse da organização
Quer ampla comunicação entre pares Bloqueia a comunicação interna
Busca otimização do próprio trabalho Busca cumprimento de cronogramas e custos
4) Resposta: as formas apresentas são: por confronto, por

comprometimento, por acomodação, por prevalência, por retirada.
5) Resposta: O uso de simuladores pode ser importante para verificar
protótipos de produtos, antes mesmo de eles serem construídos. Os
simuladores passaram a ser ainda mais importantes com o avanço da
informática, que permitiu o uso de simulação computacional, que poupa
217
book.indb Sec1:217 31/5/2007 14:24:13

tempo e dinheiro, especialmente em projetos de produtos complexos

ou muito grandes, como máquinas, grandes hidrelétricas, grandes
construções, etc.
UNIDADE 5
1) Resposta: os passos são:

desenvolver um plano de recuperação;
redefinir e gerenciar o propósito do projeto;
reavaliar o negócio;
replanejar o projeto usando métodos de estimativa;
gerenciar as expectativas dos clientes;
formular um plano de comunicação;
dividir o restante do projeto em pequenas partes;
tratar as dificuldades pessoais da equipe do projeto;
incorporar práticas corretivas;
reavaliar a liderança
(Os exemplos serão individuais).
2) Resposta: erros de comunicação no início do projeto causam frustrações

na fase final. Os clientes têm dificuldades para definir seus requisitos e
muitas vezes têm expectativas exageradas.
3) Resposta: pode-se evitar fracassos tomando as seguintes atitudes:
avaliando detalhadamente a viabilidade do projeto antes de
começá-lo;
fazendo uma análise de riscos criteriosa;
usando métodos de planejamento;
usando sistemas de controle durante a fase de desenvolvimento.
4) Resposta: subjetiva: haverá citações sobre o descontrole, sobre a falta
de liderança, sobre as interrupções constantes feitas pelo rei, sobre a falta
de conhecimento técnico apropriado, sobre o planejamento fraco, sobre a
falta de documentação.
218
book.indb Sec1:218 31/5/2007 14:24:13

Gerência de Projetos-UnisulVirtual

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerência de Projetos-UnisulVirtual

Enviado por

Direitos autorais:

Formatos disponíveis

Universidade do Sul de Santa Catarina

book.indb 1 31/5/2007 14:23:18

book.indb 2 31/5/2007 14:23:23

Parabéns, você está recebendo o livro didático da disciplina

O processo de ensino e aprendizagem na UnisulVirtual leva

São elementos desse processo:

Recomendamos que antes de você começar os seus estudos,

Desejamos que você tenha êxito neste curso!

book.indb 3 31/5/2007 14:23:23

2ª ed. revista e atualizada

book.indb 5 31/5/2007 14:23:23

Edição – Livro Didático

Projeto Gráﬁco e Capa

1. Administração de projetos. I. Bittencourt, Dênia Falcão de.

Ficha catalográfica elaborada pela Biblioteca Universitária da Unisul

book.indb 6 31/5/2007 14:23:23

UNIDADE 1 – Introdução aos projetos . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17

Para concluir o estudo . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205

book.indb 7 31/5/2007 14:23:23

Os livros dedicados à gestão de projetos dividem-se

Os do primeiro tipo acreditam que simplesmente

imensa de planilhas e relatórios - e mais recentemente

Os do segundo tipo analisam a gestão como uma

diferentes tipos de projetos, os quais envolvem sempre

Este livro didático explora esse assunto de uma outra

Neste sentido este não é um livro puramente acadêmico,

book.indb 9 31/5/2007 14:23:23

A palavra “gestão” está intimamente relacionada à função de

Com essas palavras iniciais gostaria então de convidá-lo a

Professor Mauro Faccioni Filho.

book.indb 10 31/5/2007 14:23:24

O plano de estudo visa orientar você no desenvolvimento

book.indb 11 31/5/2007 14:23:24

Unidade 1 - INTRODUÇÃO AOS PROJETOS. (12 h/a)

Unidade 2 - ANÁLISE DO PROJETO (12 h/a)

Unidade 3 - PLANEJAMENTO E ELABORAÇÃO (20 h/a)

book.indb 12 31/5/2007 14:23:24

Unidade 5 - ANÁLISE E CONCLUSÃO DO PROJETO (8 h/a)

book.indb 13 31/5/2007 14:23:24

 Veriﬁque com atenção o cronograma no “EVA”, organize-

 Antes de iniciar a realização das atividades de avaliação,

 Não perca os prazos das atividades. Registre no espaço

book.indb 14 31/5/2007 14:23:24

Avaliação presencial (AP)

Tenha por hábito, usar o quadro para agendar e programar as

book.indb 15 31/5/2007 14:23:24

Introdução aos projetos

Após a leitura dos conteúdos, realize as atividades

book.indb 17 31/5/2007 14:23:24

Para início de estudo

No entanto, saiba que há muitas idéias equivocadas sobre o que

Há várias diferenças entre projetos e tarefas de rotina, assim

Um fator importante é o da motivação para o projeto, que vai

Mas antes de você

book.indb 18 31/5/2007 14:23:24

de trabalho e como tal deﬁnição vem se modiﬁcando ao longo da

Na história da humanidade o trabalho foi se

Tribos nômades andavam pelo planeta há milhares de anos

Por essa época, surgem alguns empreendimentos

book.indb 19 31/5/2007 14:23:24

Figura 1.1 - As três pirâmides do Egito, dos Faraós Quéops, Quéfren e

Esses são exemplos de grandes projetos da antiguidade que

book.indb 20 31/5/2007 14:23:24

Pessoas envolvidas nesses projetos começaram a perceber algumas

Veriﬁque com atenção o cronograma no “EVA”, organize-

Antes de iniciar a realização das atividades de avaliação,

Não perca os prazos das atividades. Registre no espaço

O primeiro surgiu na empresa Du Pont em 1957,