Gestão de Projetos - Livro UP

Gestão de
Projetos
J. Amaro dos Santos
Superintendente Prof. Paulo Arns da Cunha
Reitor Prof. José Pio Martins
Pró-Reitor Acadêmico Prof. Carlos Longo
Coordenadora Editorial Profa. Manoela Pierina Tagliaferro
Coordenadora Pedagógica Profa. Adriana Pelizzari
Autoria Prof. José Amaro dos Santos
Supervisão Editorial Aline Scaliante Coelho, Josiane Cristina Rabac Stahl
e Pâmella de Carvalho Stadler
Análise de Conteúdo Paula Izabela Nogueira Bartkiw
Análise de Qualidade Betina Dias Ferreira
Edição de Texto Caroline Chaves de França
Design Instrucional Luana Przybylovicz e Wagner Gonçalves da Silva
Estágio de Design Instrucional Cezar Vinicius Joukovski
Design de Atividades Ana Carolina Ciampi e Lucelí de Souza Fabro
Layout de Capa Valdir de Oliveira
Imagem de Capa Juliano Henrique
Edição de Arte Denis Kaio Tanaami
Diagramação Ana Luiza Fernandes Marques e Regiane Rosa
Design Gráfico Ana Luiza Fernandes Marques,
Carlos Henrique Stabile e Juliano Henrique
Estágio de Design Gráfico Guilherme Rufatto, Larissa Pires e Rafael Crosewski
Revisão Ana Raquel Cruz, Elizabeth Pinheiro
e Joanice de Moura Andrade
Dados Internacionais de Catalogação na Publicação (CIP)

Biblioteca da Universidade Positivo – Curitiba – PR
S237 Santos, José Amaro dos

Gestão de projetos. / José Amaro dos Santos. ― Curitiba :
Universidade Positivo, 2015.
206 p. : il.
Sistema requerido: Adobe Acrobat Reader.

Modo de acesso: <http://www.up.edu.br>
Título da página da Web (acesso em 29 abr. 2015).
ISBN 978-85-8486-089-0
1. Administração de Projetos. 2. Planejamento estratégico.

I. Título.
CDU 65.012.2
* Todos os gráficos, tabelas e esquemas são creditados ao autor, salvo quando indicada a referência.
Informamos que é de inteira responsabilidade do autor a emissão de conceitos. Nenhuma parte desta publicação poderá
ser reproduzida por qualquer meio ou forma sem autorização. A violação dos direitos autorais é crime estabelecido pela
Lei n.º 9.610/98 e punido pelo artigo 184 do Código Penal.
Copyright Universidade Positivo 2015
Rua Prof. Pedro Viriato Parigot de Souza, 5300 – Campo Comprido
Curitiba-PR – CEP 81280-330
Ícones
Afirmação Curiosidade
Assista
Dicas
Biografia
Esclarecimento
Conceito
Contexto Exemplo
Sumário
Apresentação��14
O autor��15
Capítulo 1
Negócio do projeto e pesquisa de stakeholders ��17
1.1 Relevância dos projetos e análise do negócio��17
1.1.1 Projetos como motores da mudança�� 17
1.1.2 Áreas de aplicação �� 17
1.1.3 Conceitos fundamentais�� 18
1.1.4 Análise de negócios�� 20
1.2 Pesquisa de stakeholders��20
1.2.1 Identificação�� 21
1.2.2 Interesses�� 23
1.2.3 Classificação�� 26
1.2.4 Plano de gerenciamento dos stakeholders�� 27
1.3 O problema do projeto e pesquisa de soluções��27
1.3.1 O problema do projeto�� 27
1.3.2 Requisitos�� 28
1.3.3 Pesquisa de soluções�� 30
1.3.4 Estudos de viabilidade e seleção de soluções�� 31
1.4 Avaliação, validação e projeto da solução adotada��34
1.4.1 O escopo preliminar�� 34
1.4.2 Avaliação e validação da solução adotada�� 34
1.4.3 Business case e declaração do trabalho�� 35
1.4.4 Projeto e monitoramento da solução adotada�� 37
Referências��................................. 39
Capítulo 2
Abertura, integração e encerramento � ......................................................................... 41
2.1 Iniciação e termo de abertura�� 41
2.1.1 Papel da iniciação�� 41
2.1.2 Processo de iniciação�� 42
2.1.3 Termo de abertura (Project Charter)�� 42
2.2 Integração�� 43
2.2.1 Papel da integração�� 44
2.2.2 Plano de gerenciamento do projeto�� 44
2.2.3 Entregas e dados do desempenho do trabalho�� 48
2.2.4 Monitoramento e controle do trabalho do projeto�� 48
2.3 Controle integrado de mudanças�� 49
2.3.1 Papel do controle integrado�� 49
2.3.2 Planejamento do controle integrado de mudanças�� 49
2.3.3 Monitoramento e controle integrado�� 51
2.3.4 Gestão da configuração e da documentação�� 51
2.4 Encerramento��53
2.4.1 Processo de encerramento�� 53
2.4.2 Entrega do produto�� 54
2.4.3 Documentação e quitação de contratos�� 55
2.4.4 Um exemplo detalhado para pequenos projetos�� 55
Referências�� 65
Capítulo 3
Escopo e qualidade�� 67
3.1 Coleta de requisitos e definição do escopo�� 67
3.1.1 Conceitos fundamentais e plano de gestão do escopo�� 68
3.1.2 Aquisição, priorização e organização dos requisitos do escopo�� 69
3.1.3 Definição e elaboração do escopo�� 71
3.1.4 Aceitação e vinculação com contratos�� 73
3.2 Estrutura analítica do projeto e controle do escopo��74
3.2.1 Papel e desenvolvimento da EAP�� 75
3.2.2 Linha de base do escopo e matriz de responsabilidades�� 78
3.2.3 Avaliação e validação�� 79
3.2.4 Controle do escopo�� 81
3.3 Identificação, coleta e organização de requisitos da qualidade��82
3.3.1 Conceitos fundamentais e plano de gestão da qualidade�� 82
3.3.2 Identificação de requisitos da qualidade �� 84
3.3.3 Coleta dos requisitos�� 85
3.3.4 Priorização e organização�� 85
3.4 Garantia e controle da qualidade�� 86
3.4.1 Garantia da qualidade�� 86
3.4.2 Linha de base da qualidade�� 87
3.4.3 Avaliação de desempenho�� 88
3.4.4 Controle da qualidade�� 88
Capítulo 4
Tempo�� 91
4.1 Preparação do cronograma�� 92
4.1.1 Conceitos fundamentais e plano de gestão do tempo�� 92
4.1.2 Identificação e sequenciamento das atividades�� 93
4.1.3 Estimação dos recursos das atividades�� 94
4.1.4 Estimação das durações das atividades�� 95
4.2 Desenvolvimento do cronograma�� 96
4.2.1 Diagramas de barras e de marcos�� 96
4.2.2 Diagramas CPM�� 97
4.2.3 Diagrama PERT�� 100
4.2.4 Linha de base do cronograma�� 102
4.3 Controle do cronograma�� 102
4.3.1 Papel do controle�� 103
4.3.2 Análises de desempenho�� 103
4.3.3 Gestão de mudanças e simulações�� 104
4.3.4 Aceleração de projetos�� 105
4.4 Abordagens especiais e aplicativos de software�� 106
4.4.1 Software de gestão de projetos�� 106
4.4.2 A corrente crítica�� 108
4.4.3 Métodos ágeis�� 110
4.4.4 Perspectivas e tendências�� 111
Capítulo 5
Custos�� 115
5.1 Estimação dos custos�� 115
5.1.2 Plano da gestão dos custos�� 116
5.1.3 Técnicas básicas de estimação de custos�� 117
5.1.4 Técnicas especiais�� 118
5.2 Elaboração do orçamento�� 119
5.2.1 Papel do orçamento�� 119
5.2.2 Técnicas de orçamentação�� 119
5.2.3 Análise do fluxo de caixa ................................................................................................................................... 121
5.2.4 Linha de base dos custos�� 123
5.3 Controle dos custos�� 123
5.3.1 Papel do controle dos custos�� 124
5.3.2 Análise do valor agregado�� 125
5.3.3 Variações e índices de desempenho�� 126
5.3.4 Previsões de custos e tendências�� 127
5.4 Análise de tradeoffs�� 128
5.4.1 Objetivos e elementos do tradeoff�� 129
5.4.2 Processo de otimização�� 130
5.4.3 Controle de mudanças�� 131
5.4.4 Estimativa de impactos�� 132
Capítulo 6
Recursos humanos e comunicação�� 137
6.1 Formação e desenvolvimento de equipes de projetos�� 137
6.1.1 Conceitos fundamentais e plano dos recursos humanos�� 137
6.1.2 Formação de equipes�� 139
6.1.3 Avaliação de conhecimentos, habilidades e atitudes�� 140
6.1.4 Modos de trabalho em equipe e distribuição de responsabilidades�� 142
6.2 Coordenação e controle de equipes�� 143
6.2.1 Treinamento, capacitação e manutenção da equipe�� 144
6.2.2 Avaliação de desempenho da equipe�� 144
6.2.3 Conflitos e recompensas�� 145
6.2.4 Apoio e monitoramento de equipes�� 146
6.3 Gestão da comunicação�� 147
6.3.2 Plano da gestão da comunicação�� 149
6.3.3 Modelos e métodos�� 150
6.3.4 Comunicação no trabalho à distância�� 151
6.4 Controle da comunicação�� 152
6.4.1 Sistema de gestão da informação�� 152
6.4.2 Matriz de comunicação�� 153
6.4.3 Avaliação de desempenho�� 154
6.4.4 Ações para melhoramento�� 155
Capítulo 7
Riscos�� 157
7.1 Conceituação e identificação de riscos�� 157
7.1.2 Plano da gestão de riscos�� 159
7.1.3 Identificação dos riscos�� 160
7.1.4 Registro dos riscos�� 162
7.2 Análises qualitativa e quantitativa�� 162
7.2.1 Análise qualitativa dos riscos�� 162
7.2.2 Categorização e priorização�� 164
7.2.3 Análise quantitativa dos riscos�� 165
7.2.4 Análise de sensibilidade�� 168
7.3 Resposta aos riscos�� 168
7.3.1 Papel da resposta aos riscos�� 169
7.3.2 Estratégias de respostas aos riscos�� 169
7.3.3 Mitigação de riscos�� 171
7.3.4 Estratégias para riscos positivos�� 172
7.4 Controle dos riscos e avaliação de impactos�� 174
7.4.1 Papel do controle de riscos�� 174
7.4.2 Auditoria de riscos�� 174
7.4.3 Análises de variação e tendência�� 175
7.4.4 Impactos estratégicos dos riscos�� 176
Capítulo 8
Aquisições e suprimentos�� 181
8.1 Papel estratégico das aquisições�� 181
8.1.2 Abordagem estratégica�� 182
8.1.3 Plano de gestão e especificação do trabalho�� 183
8.1.4 Fontes dos recursos�� 184
8.2 Execução das aquisições�� 186
8.2.1 Seleção de fornecedores�� 186
8.2.2 Preparação de contratos�� 187
8.2.3 Programação das entregas e dos suprimentos�� 189
8.2.4 Programação de pagamentos�� 190
8.3 Controle das aquisições�� 190
8.3.1 Auditorias, inspeções e avaliações conjuntas�� 190
8.3.2 Sistemas de documentação�� 191
8.3.3 Análise de desempenho�� 192
8.3.4 Administração de reclamações e relacionamentos�� 192
8.4 Avaliação de impactos e encerramento das aquisições�� 194
8.4.1 Avaliação de impactos�� 194
8.4.2 Negociações, ajustes e correções�� 195
8.4.3 Encerramento de contratos e documentação�� 196
8.4.4 Um exemplo detalhado para pequenos projetos�� 197
Apresentação
Esta obra apresenta o gerenciamento de projetos segundo uma abordagem es-

tratégica, direcionada para resolver problemas em diversas áreas e aproveitar adequa-
damente oportunidades emergentes.
O gerenciamento de projetos procura alinhar as entregas e os produtos dos proje-
tos com os benefícios reais para o negócio. Os capítulos aqui apresentados tratam do
negócio, dos stakeholders, da abertura, da integração e do encerramento de um proje-
to, bem como de outras gestões específicas (escopo, prazos, custos, qualidade, comu-
nicações, riscos e aquisições).
Tendo como base o estudo deste material, o leitor terá condições de participar
ativamente no gerenciamento de um projeto real e contribuir de fato para seu sucesso.
Para aprofundamento futuro dos temas abordados no texto, referências bibliográficas
consagradas são apresentadas ao final de cada capítulo.
O autor
J. Amaro dos Santos é Doutor e Mestre em Administração (EAESP/FGV)
e Mestre e Graduado em Engenharia (EPUSP). É professor, pesquisador, consul-
tor e autor nas áreas de Gerenciamento de Projetos, Inovação e Desenvolvimento
do Produto. Sua formação e experiência profissional incluem países como Áustria,
Alemanha, Portugal, EUA e Holanda.
Currículo Lattes:
<http://buscatextual.cnpq.br/buscatextual/visualizacv.do?id=K4783819D4>
Dedico àqueles leitores ávidos

por ampliar sua capacitação
profissional, dispostos a enfrentar
desafios ambiciosos e críticos com
seus próprios trabalhos.
1 Negócio do projeto e pesquisa de stakeholders
Projetos e empreendimentos são criados
para resolver problemas e aproveitar oportuni-
dades. Esses objetivos representam o “negócio
© beermedia.de / / Fotolia
do projeto”, que é sua razão de ser. O geren-
ciamento de um projeto, segundo uma visão
estratégica, sempre procura contribuir explicita-
mente para o negócio do projeto.
O termo negócio não designa aqui um empreendimento lucrativo, mas sim a razão de ser de
um projeto. O projeto de construção de um parque municipal, por exemplo, não tem como ne-
gócio o lucro, mas a qualidade de vida da população e talvez até a melhoria da imagem da ad-
ministração municipal.
Gerenciar projetos com enfoque no negócio exige primeiramente um claro enten-

dimento sobre seus objetivos e stakeholders. A partir daí é que se definem questões
mais técnicas do projeto, tais como a gestão dos prazos, dos custos, das pessoas, entre
outras. O gerenciamento de projetos com foco no negócio constitui uma abordagem
estratégica do campo da Administração.
1.1 Relevância dos projetos e análise do negócio

A expansão do gerenciamento de projetos nos últimos anos se deve, em grande
parte, à necessidade de técnicos capacitados para transformar boas ideias em produ-
tos reais. Paralelamente, tem crescido a procura por profissionais aptos a entender o
negócio do projeto, construir pontes entre os visionários e os executores de ideias e
até mesmo “pensar junto” com esses visionários, em prol de seus negócios.
1.1.1 Projetos como motores da mudança

Projetos são sempre necessários em situações de mudança. Situações estáveis
não exigem projetos, mas sim um eficaz controle de suas operações. Uma situação tí-
pica de mudança ocorre quando o arranjo físico de um escritório é reprogramado ou se
redimensiona a equipe envolvida nas operações desse escritório.
1.1.2 Áreas de aplicação

Em um passado recente, projetos e empreendimentos denotavam iniciativas de
grande envergadura e complexidade. Atualmente, eles se referem também a proble-
mas mais cotidianos. A festa junina de uma empresa é um bom exemplo disso: ela en-
volve ecursos de diversos tipos, atividades com início e término claros, é coordenada
Gestão de Projetos 18
por pessoas, envolve trabalho em equipe e gera um produto bem definido. Portanto,
essa festa atende à definição de um projeto e pode se beneficiar das metodologias e
aplicativos modernos para gerenciar projetos.
A tabela a seguir apresenta diversas outras oportunidades para gerenciar projetos.
O problema do projeto: exemplos

Tipo de projetos Exemplos de produtos gerados
Projetos sociais Reurbanização de um bairro
Projetos ambientais Despoluição de um rio
Projetos de engenharia Barco à vela
Projetos de educação Separação do lixo doméstico
Projetos no trabalho Festa junina
Projetos de vida Mudança para uma casa na praia
Projetos de software Sistema de gestão de compras
Projetos de produto Vestuário
Projetos de serviço Cirurgia
Projetos de comunicação Jornal diário
Projetos estão em todos os lugares e as oportunidades para gerenciá-los não

mais se restringem ao ambiente das grandes empresas.
1.1.3 Conceitos fundamentais

A literatura sobre gestão, gerenciamento ou administração de projetos (esses
nomes serão empregados indistintamente no texto) possui alguns termos e conceitos
com significados específicos. Alguns deles são apresentados e discutidos a seguir.
Sobre projetos
Um projeto é um esforço temporário empreendido para criar um produto, servi-
ço ou resultado exclusivo (PMI, 2013). Essa definição reforça a ligação entre projetos
e situações de mudança. O Referencial Brasileiro de Competências em Gerenciamento
de Projetos – RBC (SANTOS; CARVALHO, 2006) define um projeto como “uma conju-
gação de esforços em que recursos humanos, materiais e financeiros são organizados
de forma inovadora para realizar um tipo único de trabalho, de acordo com especifica-
ções previamente definidas, com limitações de custos e de tempo, seguindo um ciclo
de vida padrão [...]”. Esse ciclo de vida padrão refere-se às fases típicas de um projeto:
iniciação, planejamento, execução, encerramento etc.
O gerenciamento de projetos é definido no PMBOK® (PMI, 2013) como “a apli-
cação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto
para atender aos seus requisitos”. Já o PRINCE2 (OGC, 2009) estabelece: “o planeja-
mento, a delegação, o monitoramento e o controle de todos os aspectos do projeto
e a motivação daqueles envolvidos para alcançar os objetivos do produto, dentro das
metas esperadas de prazos, custos, qualidade, escopo, benefícios e riscos”. Além des-
sas definições, diversas outras são encontradas na literatura técnica; algumas refe-
rem-se a aplicações especiais, por exemplo, nos setores aeroespacial, automotivo, da
construção civil e da medicina.
Embora um projeto se caracterize como um esforço individual, ele pode estar re-
lacionado com outros projetos, conforme indica a tabela a seguir.
Projeto, subprojeto, programa e portfólio

Termo Definição
Projeto Um esforço temporário empreendido para criar um produto, serviço ou resultado exclusivo.
Uma parte menor do projeto total, criada quando um projeto é subdividido em componentes
Subprojeto
ou partes mais facilmente gerenciáveis (PMI, 2013).
Um grupo de projetos, subprogramas e atividades do programa relacionados e que são ge-
renciados de modo coordenado para a obtenção de benefícios e controle que não estariam
disponíveis se eles fossem gerenciados individualmente (PMI, 2013).
Programa
Uma estrutura organizacional temporária e flexível, criada para coordenar, direcionar e super-
visionar a implementação de um conjunto de projetos relacionados e atividades, para entregar
resultados e benefícios relacionados aos objetivos estratégicos da organização (OGC, 2009).
Todos os programas e projetos isolados em andamento em uma organização, um grupo de
organizações ou uma unidade organizacional (OGC, 2009).
Um conjunto de projetos e/ou programas não necessariamente relacionados e que atuam em
Portfólio
conjunto para controlar, coordenar e otimizar o portfólio em sua totalidade (IPMA, 2006).
Todos os projetos de produto em andamento de uma empresa de cosmético constituem seu
portfólio.
A divisão de um projeto em subprojetos não permite que um deles seja eliminado

(por exemplo, a suspensão de um automóvel), sob pena do fracasso total do projeto. O
mesmo já não ocorre quando um programa perde um de seus projetos (um programa
de alfabetização pode sobreviver ao fracasso de um de seus projetos). Os portfólios se
caracterizam pela competição (nem sempre saudável) entre seus projetos.
Sobre o sucesso
Os textos tradicionais sobre gerenciamento de projetos relacionam o sucesso de
um projeto exclusivamente ao alcance das metas prefixadas. Metas de prazo, escopo
e custos (denominadas tripla restrição) são as mais utilizadas para medir e monitorar o
sucesso de um projeto (RABECHINI JR; CARVALHO, 2011). A abordagem estratégica
do gerenciamento de projetos procura avaliar o sucesso também em relação ao negó-
cio do projeto.
A avaliação do sucesso com base nos stakeholders envolve estimativas basea-
das em fatores mais subjetivos e processos de decisão mais demorados. Por exemplo,
considere-se um projeto para aumentar a rede de ciclovias da cidade de 60 km para
75 km, em três anos. O governo municipal mede os benefícios do projeto segundo
a quantidade de quilômetros expandidos na rede e divulga que o aumento de 25% é

excelente. Já o usuário e beneficiário do projeto critica os resultados ao questionar:
essa expansão me permite ir ao trabalho mais rapidamente? Tenho mais alternativas
nos trajetos de meu interesse? Os trechos construídos são seguros e agradáveis?
1.1.4 Análise de negócios

A análise de negócios é, segundo o BABOK® (IIBA, 2009, p. 3), “o conjunto de ati-
vidades técnicas utilizadas para servir como ligação entre os stakeholders, no intuito
de compreender a estrutura, as políticas e as operações de uma organização e para
recomendar soluções que permitam que a organização alcance suas metas”. Embora
ela enfoque primordialmente a organização permanente, sua estrutura também é útil
para organizações temporárias, ou seja, aquelas que têm prazo para serem encerra-
das, tais como projetos e empreendimentos. Ela propõe como uma organização deve,
sistematicamente, prospectar clientes, avaliar capabilidades, esboçar soluções, coor-
denar o projeto e avaliar/validar a solução mais adequada – sempre com foco nos inte-
resses dos stakeholders.
A inclusão de elementos da análise de negócio no gerenciamento de projetos tra-
dicional aumenta a chance de sucesso dos empreendimentos, pois estes não entregam
apenas produtos, mas soluções para atender aos interesses dos stakeholders.
Capabilidade é a habilidade de um processo ou sistema alcançar seus objetivos.
Considere-se um projeto já conhecido e administrado segundo o gerenciamento de projetos

tradicional. Incorporando-se alguns elementos da análise de negócios, como o produto gerado
terá maior chance de sucesso?
1.2 Pesquisa de stakeholders

A pesquisa de stakeholders procura identificar não apenas os stakeholders de
um projeto, mas também as necessidades, as restrições, as diretrizes, os recursos e as
oportunidades atreladas a eles. Os stakeholders representam pessoas, grupos de pes-
soas e entidades que são interessadas no desempenho e no sucesso do projeto, ou que
são influenciadas por ele (IPMA, 2006).
Stakeholders podem também ser denominados partes interessadas e intervenientes, no entan-

to, por ser de uso consagrado internacionalmente, inclusive em português, stakeholders será o
termo preferencialmente empregado nesta obra.
GESTÃO DE PROJETOS 21
Outras definições e debates acerca do termo stakeholder se encontram em Trentim (2013), que
discorre sobre a Teoria dos Stakeholders, originalmente proposta por Edward Freeman, em 1984.
Como os stakeholders de um projeto usualmente são múltiplos e distintos

(FREEMAN, 2013), seus interesses no projeto podem assumir intensidades também dis-
tintas. Satisfazer a todos os interessados no projeto é uma tarefa quase utópica. Por
exemplo, os interesses dos clientes de um projeto de construção podem conflitar com as
restrições impostas pela legislação ambiental – no entanto, ambos são stakeholders.
1�2�1 Identificação
A diversidade dos stakeholders de um projeto é ilustrada pela figura a seguir.
Exemplos de stakeholders típicos de projetos
Clientes Colegas Políticos
Patrocinadores Subordinados
Chefes
Vizinhos
Design Gráfi co: Guilherme Rufatto

Governos
Sindicatos Ambientalistas
Fornecedores
Outros
Mídias Chefes do chefe
Para a pesquisa de stakeholders, a figura a seguir propõe uma classificação em

cinco categorias.
O PRINCE2 (OGC, 2009) emprega três categorias: usuário, negócio e fornecedor.
Classificação dos stakeholders de um projeto

Clientes Organização Ambiente Concorrentes
Gestão estratégica do projeto

Stakeholders
Fornecedores
Essa classificação representa uma abordagem estratégica do gerenciamento do

projeto, ao orientar os esforços gerenciais para valor (KERZNER; SALADIS, 2009). Ela
permite classificar qualquer tipo de stakeholder nas cinco categorias indicadas.
Alguns métodos consagrados para a pesquisa de stakeholders nessas categorias
são mencionados a seguir. Suas vantagens/desvantagens e ferramentas de aplicação
são amplamente encontradas na literatura técnica.
(Clientes) Pesquisas de mercado,

enquetes, cluster analysis, grupo
focal.
(Concorrentes) Análise SWOT,

enquetes, painel de especialistas.
(Organização) Balanced scorecard,

análise SWOT, alinhamento estraté-
gico, mapeamento de recursos.
(Ambiente) Análise de riscos,

© Jakub Jirsák / / Fotolia; © alphaspirit / / Fotolia; © sepy / / Fotolia;
estudo de leis e normas técnicas,

mapeamento de concorrentes,
© Rawpixel / / Fotolia; © Photographee.eu / / Fotolia
brainstorming.
Design Gráfico: Guilherme Rufatto
(Fornecedores) Mapeamento da
cadeia de valor do produto, avalia-
ção de fornecedores, ferramentas
da logística de suprimentos.
Para a identificação dos stakeholders, Trentim (2013) sugere as seguintes questões:

• O que é importante saber sobre cada tipo de stakeholder?
• Onde e como as informações sobre os stakeholders podem ser obtidas?
• Quem é o responsável por coletar, analisar e interpretar informações?
• Quem distribui, quem usa e quem acessa as informações e como isso é feito?
1.2.2 Interesses
Usualmente, os stakeholders de um projeto ou empreendimento apresentam in-
teresses distintos e até conflitantes, que necessitam ser combinados e priorizados. Por
exemplo, no projeto de um ônibus, o dono da empresa de transporte deseja economia
de operação e retorno financeiro; o passageiro deseja conforto e um bom ambiente; o
motorista deseja segurança e dirigibilidade. Todos eles são stakeholders mas seus inte-
resses, justamente por muitas vezes serem conflitantes, talvez não possam ser atendi-
dos plenamente. Alguns interesses típicos dos stakeholders são comentados a seguir.
Os clientes e suas necessidades
Clientes possuem necessidades que devem ser satisfeitas pelo projeto ou empreen-
dimento. Eles podem ser consumidores finais do produto do projeto, usuários de servi-
ços, beneficiários indiretos, intermediários na produção ou comercialização do produto
etc. Alguns clientes possuem denominações específicas, tais como: passageiro (serviços
de transporte), paciente (clínicas e hospitais), aluno (escolas), usuário (serviços públicos),
candidato (processos de seleção).
Para definir o cliente do projeto, são úteis conhecimentos e ferramentas de dis-
ciplinas tais como a metodologia científica e a pesquisa de marketing.
A técnica “grupo focal” é especialmente útil quando se deseja pesquisar necessidades latentes,
talvez desconhecidas até pelos próprios clientes. Ao comentar que no automóvel X é difícil diri-
gir e comer ao mesmo tempo, o cliente expressa uma necessidade particular, não atendida por
aquele automóvel.
Embora o cliente procure valor no produto do projeto, a equipe de projetos se

orienta por metas predefinidas. Um desafio para a gestão do projeto é alinhar satisfa-
toriamente esses dois conceitos, de modo que as metas representem adequadamente
o valor almejado. Assim, o comprador de um automóvel vê como valor poder beber re-
frigerante enquanto dirige. Já a equipe de projetos busca incorporar no automóvel os
itens especificados – por exemplo, um porta-copos.
A organização e sua governança
Os interesses da organização são representados por sua governança. Ela se tra-
duz em procedimentos, normas, práticas, cultura e estilos típicos da organização
permanente. Já a governança de um projeto possui interesses análogos ao da orga-
nização, e atua no âmbito do próprio projeto. Ela busca identificar os objetivos do
projeto com a estratégia, as diretrizes, as práticas, a cultura e a postura ética da orga-
nização permanente.
Um produtor de alimentos define sua estratégia competitiva com base na segurança e na saúde de
seus clientes consumidores. Todos os projetos de novos produtos se submetem a normas internas
rigorosas, para qualidade, segurança e meio ambiente, desde a Engenharia até a Publicidade.
A governança influencia também os parceiros do projeto. O produtor de alimen-

tos estende suas exigências de qualidade, segurança e respeito ao meio ambiente
também a seus fornecedores. Parceiros são considerados integrantes temporários da
organização que abriga um projeto e atendem à governança dessa organização.
O ambiente e suas restrições
O ambiente representa as restrições externas impostas ao projeto. Algumas res-
trições típicas são as leis municipais, estaduais e federais, as normas técnicas e as re-
comendações de segurança. Restrições podem também ser menos normativas, tais
como a imagem da organização, padrões culturais, boas práticas etc. O produtor de
alimentos do exemplo anterior atende tanto às normas de segurança como aos pa-
drões de uma boa imagem da empresa no mercado. Ele não emprega ingredientes,
conservantes e corantes potencialmente danosos à saúde e à segurança dos clientes,
mesmo que esses componentes atendam às legislações vigentes.
Um tipo importante de restrição é representado pelas leis nacionais e internacio-
nais. Deixar de atender às leis resulta em consequências que podem ser trágicas para o
projeto, para a organização permanente e até mesmo para o gerente do projeto. Essas
consequências podem ser tanto não financeiras (perda de imagem, suspensões de van-
tagens) como financeiras (reparações, multas, processos judiciais). Projetos bem es-
truturados contam com apoio jurídico profissional, que audita, orienta e até defende
judicialmente o projeto e seus interesses.
Os concorrentes e seus desafios
Não é raro que um projeto ou empreendimento possua concorrentes dispostos a
entregar produtos e serviços similares. Projetos concorrentes incentivam a economia de
recursos, a qualidade dos produtos e prazos mais curtos. Eles podem ser classificados
como concorrentes externos (de outras organizações, por exemplo) e concorrentes inter-
nos (que disputam recursos em um portfólio da mesma organização, por exemplo).
Os desafios de um projeto são medidos preferencialmente em relação a referências, a padrões

e a metas bem definidos. É comum o emprego de benchmarking (processo de busca das melho-
res práticas com vistas a um desempenho superior) para estabelecer as referências.
O produtor de alimentos citado anteriormente adota padrões realistas de se-

gurança para seus produtos, que não devem ser menos rigorosos que os padrões dos
produtos concorrentes; mas também não devem ser demasiadamente exigentes a

ponto de causar descartes desnecessários de matéria-prima.
Os fornecedores e seus recursos
Recursos de um projeto são itens empregados para acrescentar valor ao produto e
também ao negócio do projeto. Eles são responsáveis por praticamente todos os gastos
do projeto – daí sua importância. Alguns recursos usuais são: materiais, infraestrutura,
equipamentos, mão de obra, serviços externos, tecnologias, informações, financiamen-
tos e direitos. Frequentemente, recursos de projetos são adquiridos do mercado, mas um
projeto também pode empregar recursos da própria organização, de parceiros e até mes-
mo de seus clientes.
O “envolvimento prematuro” de fornecedores em projetos de produtos permite
que eles, ainda no início do projeto, contribuam para o desenvolvimento do produto ao
apontarem oportunidades e problemas do projeto. Esse envolvimento previne perdas
nos projetos em datas futuras, na época das aquisições dos recursos. O produtor de
alimentos já mencionado solicita aos seus fornecedores mais críticos informações téc-
nicas sobre novos componentes e matérias-primas, bem como opiniões sobre tendên-
cias do mercado fornecedor.
Os stakeholders e suas soluções
Os stakeholders de um projeto, indicados na figura “Exemplos de stakeholders tí-
picos de projetos”, representam os mesmos cinco stakeholders indicados como as en-
tradas do processo. Seus interesses orientam o desenvolvimento da solução para o
empreendimento ou projeto. Diferentemente dos profissionais de projetos, que dire-
cionam seus esforços para produtos e resultados, stakeholders procuram soluções
para seus problemas (KERZNER; SALADIS, 2009).
Alguns métodos consagrados para pesquisar os interesses dos stakeholders em
projetos são grupos focais, brainstorming, análise de interface, análise de documentos,
observações participativas, entrevistas, prototipagem, workshops e enquetes. Os inte-
resses dos stakeholders são negociados e ajustados mediante análises de tradeoff.
Tradeoffs
A análise de tradeoff constitui um processo de negociação e acertos entre fatores,
de tal forma que os ganhos em um deles sejam compensados com perdas em outros.
Usualmente, ganhos generalizados (sem perda para qualquer outro fator) são inviá-
veis. Por exemplo, restrições de custo e de mercado impedem que todas as caracterís-
ticas técnicas de um produto sejam melhoradas simultaneamente.
Seja explícita ou implicitamente, os interesses dos stakeholders de um projeto
sempre se encontram em uma situação de tradeoff. Nessa situação, procura-se priori-
zar alguns interesses em detrimento de outros, com o intuito de maximizar o benefício
total do projeto. Por exemplo, o respeito às normas técnicas, em um projeto de produ-

to, pode aumentar o custo unitário do produto; por outro lado, evita pesadas multas.
Diversos critérios são empregados em uma análise de tradeoff, tais como o eco-
nômico, o financeiro, o político, o dos prazos, entre outros. Algumas técnicas quantita-
tivas úteis para uma análise de tradeoff são a análise hierárquica (AHP), a programação
linear, a matriz de decisão, a matriz de decisão de Pugh, a simulação de sistemas, di-
versos tipos de programação não linear, a análise de decisão multicritérios, entre ou-
tras. Também algoritmos e métodos não quantitativos proporcionam bons resultados
em situações de tradeoff presentes em projetos ou empreendimentos.
Para classificar muitas preferências coletadas sobre um produto, em um número reduzido de

categorias, anota-se cada opinião em um pequeno papel. Afixam-se todos os papéis em uma
parede e procura-se agrupá-los iterativamente. Esse processo de tradeoff não quantitativo for-
nece excelentes resultados.
1.2.3 Classificação
A classificação dos stakeholders visa associá-los a perfis bem homogêneos e defi-
nidos. Isso permite que o projeto enfoque primordialmente segmentos específicos, com
maiores chances de sucesso. Por exemplo, projetos ambientais geralmente têm como
importantes stakeholders pessoas preocupadas com a sustentabilidade do planeta.
Para classificar stakeholders, empregam-se bancos de dados e ferramentas de fil-
tragem e classificação. Com a recente popularização e facilidade do uso de planilhas
eletrônicas, elas são cada vez mais empregadas no lugar dos tradicionais aplicativos
para bancos de dados. Hoje em dia é muito comum o uso de tabelas dinâmicas para
classificar e acessar dados sobre stakeholders.
Alguns dados interessantes sobre os stakeholders de um projeto são:
• nomes, títulos, ocupações, funções (de clientes, fornecedores etc.);
• categorias a que pertencem;
• lista de papéis e responsabilidades;
• onde podem ser encontrados;
• interesses e necessidades especiais;
• normas, leis, hábitos, costumes, diretrizes;
• descrição de suas influências no projeto.
Essas informações facilitam a definição das prioridades do projeto.
1.2.4 Plano de gerenciamento dos stakeholders

Trata-se de um plano formal ou informal, detalhado a partir das necessidades do
projeto e alinhado com o negócio. Ele auxilia a estruturar a gestão do projeto de maneira
sistemática. Alguns de seus elementos cruciais são mostrados a seguir (PMI, 2013):
• nome e outras informações de identificação, conforme o stakeholder;
• requisitos e expectativas, influência no projeto e fase em que atua;
• origem interna/externa, suas posições e outras classificações;
• nível de engajamento no projeto, atual e potencial;
• impacto que terá com a mudança proposta no projeto;
• relacionamentos com outros stakeholders.
Outros itens também importantes para esse plano são:
• métodos de seleção das informações que serão distribuídas;
• formato da coleta, elaboração e distribuição das informações;
• causas e justificativas da distribuição das informações;
• métodos para atualizar o plano, bem como a frequência de atualização.
1.3 O problema do projeto e pesquisa de soluções

A precisa definição do problema de um projeto é um dos desafios mais importan-
tes da gestão. Projetos falham exatamente por negligenciarem esse ponto. Um proje-
to de software, por exemplo, pode atender muito bem às exigências de prazo, custo,
escopo e qualidade e, ainda assim, falhar, se não atender às reais necessidades do
cliente (por vezes nem o próprio cliente conhece suas próprias necessidades).
1.3.1 O problema do projeto

O problema do projeto se desdobra em múltiplas necessidades para o negócio do
projeto, e cada uma delas pode exigir capabilidades especiais. Ele pode ser formulado
como uma oportunidade para gerar benefícios ou respostas a problemas.
Uma maneira de definir o problema do projeto é perguntar repetidamente:
• Qual problema esse projeto vai realmente resolver?
• E como alguém vai ser beneficiado com a solução?
A tabela a seguir ilustra problemas reais de projetos e os respectivos produtos.
O problema do projeto: exemplos

Projeto Produto do projeto Problema real do projeto
Construir uma usina Usina instalada e Gerar eletricidade para a população
hidrelétrica funcionando regional
Desenvolver um software Oferecer agilidade e confiança para a
Software pronto e testado
para gestão contábil gestão
Realizar a festa de Natal
Festa realizada com sucesso Proporcionar um bom clima na empresa
da empresa
Lançar um novo livro Livro lançado no mercado Divulgar a chegada do livro no mercado
Como regra, um problema bem formulado gera um único benefício principal.
1.3.2 Requisitos
Em análise de negócios, requisitos são características empregadas para modelar
interesses e necessidades de um sistema, uma pessoa ou uma classe de pessoas. Um
requisito deve representar adequadamente a realidade que modela (IIBA, 2009).
Os requisitos têm por objetivo orientar a construção de soluções para resolver o
problema do projeto. Com base neles, definem-se as capabilidades e os recursos que a
solução adotada exigirá. Alguns requisitos típicos são:
• Requisitos do negócio – representam as necessidades do negócio.
• Requisitos dos stakeholders – representam seus interesses.
• Requisitos da solução – definem como uma solução é capaz de adicionar valor
ao negócio. Eles facilitam o desenvolvimento de capabilidades e recursos para a
construção da solução. Também atuam como ligação entre os requisitos dos sta-
keholders e do negócio.
O PMBOK® (PMI, 2013) indica várias técnicas para coletar requisitos, por exemplo:
entrevistas, grupos de discussão, oficinas, brainstorming, mapas mentais, diagramas de afi-
nidade, análises de decisão, métodos para decisão em grupo, questionários, protótipos,
observações, benchmarking, diagramas de contexto, análise documental, entre outros.
Priorização dos requisitos
Requisitos precisam ser priorizados para conferirem representatividade aos mo-
delos que os empregam. As soluções construídas com base nesses modelos buscam pri
vilegiar os interesses mais relevantes dos stakeholders. Diversos critérios de priorização
podem ser empregados. Alguns exemplos são indicados na tabela a seguir.
Alguns critérios para priorização de requisitos

Valor para o negócio Riscos para o negócio Riscos técnicos
Dificuldade de implantação Probabilidade de sucesso Governança corporativa
Urgência Custos de manutenção Custos de aquisição
Fonte: IIBA, 2009, p. 101. (Adaptado).
Algumas técnicas para priorizar requisitos foram mencionadas no item sobre os

tradeoffs. Outras técnicas também úteis são: análise da decisão, análise de riscos, pro-
cessos de votação, análises de consenso e análise e engenharia do valor.
Em um projeto, o processo de priorização de requisitos consiste na classificação
desses requisitos (mais importantes/menos importantes) com indicação das respecti-
vas prioridades (mais prioritários/menos prioritários).
Premissas e restrições
Em complementação à priorização dos requisitos, a construção de soluções exige
também a identificação de premissas e restrições.
Premissas são situações que se admitem como verdadeiras, mas que não se pode confirmar no
momento (por exemplo, durante a obra haverá 25 dias de chuva). Já as restrições são limita-
ções impostas a uma situação ou processo (por exemplo, o gerente contratado deve falar in-
glês fluentemente).
Uma premissa é sempre associada a riscos (de não se confirmar) e suas conse-
quências. Ela constitui um cenário (otimista, pessimista etc.) que é usado na constru-
ção da solução do problema do projeto. Variando-se as premissas, é possível simular
diversos cenários e seus respectivos resultados no processo de construção da solução.
Esse procedimento é conhecido como análise What-if (simulação de mudanças e verifi-
cação dos impactos) (PMI, 2013).
As restrições possuem diversas fontes e formas. Algumas das mais frequentes
são as restrições técnicas, as econômicas, as financeiras e as legais.
Verificação dos requisitos
A verificação dos requisitos investiga se eles são capazes de modelar a realidade
com boa qualidade, seja um negócio, uma solução, os interesses dos stakeholders etc.
Para essa finalidade, os requisitos são submetidos a testes que revelam se eles
são focados no objetivo, capazes de representar todo o problema, consistentes entre
si, determinados corretamente, viáveis, passíveis de modificação, definidos sem ambi-
guidades, verificáveis e, evidentemente, representativos da realidade modelada.
Validação dos requisitos

A validação reconhece que os requisitos aprovados são capazes de modelar bem
o processo de geração de valor para o negócio e para os stakeholders. O processo de
validação, que é individual para cada projeto, inclui:
• a identificação dos requisitos seleciona-

dos e priorizados;
• a identificação das premissas e restrições;
• a garantia de satisfação dos interesses
dos stakeholders;
• a definição de critérios de avaliação;
• a conceituação e determinação do valor
para o negócio;
• indicações sobre o alinhamento com o
business case provisório (o business case
© Sergey Nivens / / Fotolia

verifica se a organização é capaz de jus-
tificar o investimento necessário para en-
tregar a solução proposta).
Os requisitos validados, acompanhados das premissas e restrições, fornecem

confiança na construção de soluções para o problema do projeto.
1.3.3 Pesquisa de soluções

A pesquisa de soluções combina os interesses dos stakeholders com as capabilida-
des disponíveis e os recursos acessíveis. Uma solução deve ser capaz de:
• satisfazer às necessidades dos clientes;
• observar as limitações impostas pelo ambiente;
• atentar para a governança empresarial e do projeto;
• reagir aos desafios impostos pelos concorrentes;
• respeitar as condições oferecidas pelos fornecedores;
• empregar com eficiência as capabilidades e os recursos do projeto.
Diversos métodos úteis para o processo de geração de soluções são encontrados
nas bibliografias sobre desenvolvimento de produtos (ROZENFELD et al., 2006). Eles
incluem desde ferramentas específicas, como TRIZ, QFD e análise do valor, até téc-
nicas mais difundidas, como brainstorming, benchmarking, análise SWOT, diagrama de
causa e efeito e análise de gaps.
A solução eleita é específica para cada projeto. Ela deve ser bem descrita e docu-
mentada, para posteriormente apoiar o estudo de viabilidade do projeto.
1.3.4 Estudos de viabilidade e seleção de soluções

Os estudos de viabilidade podem ser empregados tanto para qualificar como
para avaliar projetos. No primeiro caso, eles verificam se um projeto atende a requi-
sitos mínimos de aceitação (nível qualificador); no segundo caso, qual é o nível do de-
sempenho do projeto e seus produtos (nível de desempenho). Eles pertencem aos mais
relevantes instrumentos de seleção de projetos e empreendimentos (HABER, 2004).
No estudo de viabilidade de um empreendimento, analisa-se uma solução para o
negócio desse empreendimento, para determinar se, e em que medida, ela consegue
beneficiar o negócio. Ele é útil para julgar soluções alternativas do empreendimento e
determinar qual delas proporciona maiores benefícios.
Um estudo de viabilidade pode ser separado em duas partes: uma reduz as soluções promis-
soras e viáveis a poucas (três a cinco) alternativas; a outra analisa detalhadamente essas alter-
nativas, sob critérios como benefícios, custos, qualidade, riscos ou prazos, de modo a eleger a
melhor solução.
Um estudo de viabilidade pode tanto preceder quanto suceder o business case; na

prática, são encontradas ambas as situações. Segundo Keeling (2012), ele deve ser rea-
lizado imediatamente após a proposta inicial, e consiste em:
• introduzir o conceito do projeto;
• verificar as reações dos potenciais interessados e obter seu apoio;
• estabelecer as bases teóricas para a realização do estudo de viabilidade.
Frequentemente, os estudos de viabilidade de projetos contemplam apenas cri-
térios financeiros e econômicos. Estudos mais completos consideram uma maior di-
versidade de critérios e seus respectivos impactos. Alguns dos critérios mais úteis são
indicados na figura a seguir, a qual também ilustra os respectivos níveis qualificadores
e de desempenho de cada critério.
Análise de viabilidade de um projeto ou empreendimento

Cada viabilidade é avaliada em uma escala de 1 a 5. As faixas à esquerda indi-
cam os valores mínimos aceitos para aprovação (nível qualificador). As faixas à direi-
ta indicam os desempenhos dos fatores já qualificados (nível de desempenho). Se, em
qualquer critério, a nota se encontrar dentro do nível qualificador, ações de melhoria
devem ser adotadas – caso contrário, o projeto é classificado como inviável.
O diagrama da figura anterior fornece uma pontuação geral que também indica
o desempenho total do projeto. Ela é calculada pela média de todas as notas atribuí-
das aos diversos critérios de viabilidade do projeto, em uma escala de 1 a 5 (desde que
todas as notas satisfaçam aos respectivos critérios de qualificação). Havendo soluções
concorrentes, aquela com maior pontuação é mais promissora no processo de escolha.
A avaliação da figura “Análise de viabilidade de um projeto ou empreendimento” pode ser re-

finada atribuindo-se importâncias relativas Ii aos vários critérios, com Σli = 100%. A pontuação
geral é calculada pela equação Σ(Q+D)iIi, que permite tratar alguns critérios como mais impor-
tantes do que outros.
Um estudo de viabilidade pode conter os seguintes itens (KEELING, 2012):
• Dados existentes – projetos e experiências anteriores.

• Escopo, objetivos, premissas – necessidade do projeto, teste das premissas.
• Esboço da estratégia – estratégia do projeto, alinhamento com a organização.
• Análise financeira externa – economia do país e global, tendências e ameaças.
• Análise financeira do empreendimento – estimativa de custos, fontes de capital.
• Retorno sobre o investimento – rentabilidade, eficiência, custo de oportunidade.
• Avaliação de riscos – decisões, identificação, análise e tratativas dos riscos.
• Fontes de apoio – patrocínios, identificação de quem apoia o projeto.
• Avaliação tecnológica – parcerias, aquisição de tecnologia e know how.
• Análise política – política do país e externa, política interna da organização.
• Avaliação de impacto ambiental – implicações ambientais, imagem ecológica.
• Impacto sociológico – estrutura social externa, implicações internas.
• Impacto cultural – implicações culturais externas e internas.
• Estrutura gerencial e administração – estrutura do projeto, competências.
• Recursos do empreendimento – especificação dos recursos, fontes, impactos.
• Requisitos dos stakeholders – clientes, organização, ambiente, concorrentes.
Um estudo de viabilidade deve sempre gerar um relatório ou documento. Keeling
(2012) sugere os seis itens seguintes (com adaptações) como modelo.
• Informações de identificação: equipe, fontes, justificativa, objetivos etc.
• Resumo executivo: descrição do estudo, previsões e implicações.
• Diversos tipos de análise: financeira, econômica, política, social etc.
• Conclusões: resumo, consequências, perigos, chances e alternativas.
• Recomendações: prosseguir ou não, correções necessárias, controles etc.
• Anexos e demonstrativos: diagramas, dados, documentos, avaliações etc.
Seleção de soluções
O método da figura “Análise de viabilidade de um projeto ou empreendimento”
não só filtra as soluções viáveis, mas ainda sugere suas classificações. Além desse, os
métodos subjetivos também são úteis. O painel de especialistas, por exemplo, empre-
ga fatores baseados em julgamentos individuais.
Rigorosamente, não há uma divisão clara entre esses tipos de métodos. Os métodos objetivos
também dependem de parâmetros estimados subjetivamente e, portanto, não são puramente
objetivos.
O processo de seleção resulta idealmente em uma única solução eleita ou adota-

da para o problema do projeto (“a melhor solução viável”). Mas mais de uma solução
pode ser selecionada e reanalisada futuramente. A solução eleita será então detalha-
da, validada, transmitida ao gerenciamento de projetos e monitorada.
1.4 Avaliação, validação e projeto da solução adotada

A avaliação e a validação da solução do problema do projeto têm como objetivos:
(1) garantir que a solução adotada para o empreendimento de fato gere valor para o ne-
gócio do projeto; (2) facilitar o desenvolvimento e a implantação da solução adotada. O
projeto da solução adotada inclui o desenvolvimento e o detalhamento dessa solução.
1.4.1 O escopo preliminar

A solução adotada para o problema do projeto possui características e funcio-
nalidades para resolver esse problema da melhor maneira possível (nem sempre per-
feitamente). A descrição dessas características e funcionalidades constitui o escopo
preliminar da solução adotada. Este pode se alterar ao longo do projeto, em função
das mudanças que ocorrem no próprio projeto.
Alguns elementos fundamentais para definir o escopo da solução são:
• as necessidades do negócio;
• as capabilidades necessárias para construir a solução do problema;
• premissas e restrições relacionadas à solução;
• funcionalidades e características da solução para resolver o problema.
O escopo preliminar fornece os detalhes necessários para a elaboração do business
case e da declaração de trabalho. As soluções propostas para o problema do projeto
são avaliadas e validadas antes de serem incorporadas no business case.
1.4.2 Avaliação e validação da solução adotada

As soluções propostas para o problema do projeto são avaliadas e validadas antes
de serem incorporadas no business case.
Avaliação da solução
A avaliação de uma solução verifica se ela possui condições adequadas para aten-
der aos interesses dos stakeholders do empreendimento. Essa avaliação se baseia nos
requisitos selecionados, devidamente priorizados e validados, na solução adotada, nas
capabilidades do projeto e no escopo preliminar.
Validação
A validação de uma solução proposta busca garantir que ela é capaz de atender
aos interesses dos stakeholders. Ela pressupõe resultados aprovados nos testes da so-
lução, bem como uma análise crítica das falhas que podem decorrer dessa solução.
Para validar uma solução, o BABOK® (IIBA, 2009) cita o seguinte procedimento
interativo, especialmente adequado para ser usado na forma de workshop:
• Identificação de problemas – verifica quais problemas podem ocorrer com a
solução proposta. Esse procedimento é análogo à identificação de riscos.
• Mitigação de impactos – reduz ou elimina as consequências que os problemas
identificados podem trazer para os stakeholders.
• Avaliação da contribuição da solução – investiga em que medida a solução
adotada será capaz de satisfazer às necessidades do negócio.
1.4.3 Business case e declaração do trabalho

O objetivo do business case é verificar se a organização é capaz de justificar o in-
vestimento necessário para entregar a solução proposta.
Por ser consagrado internacionalmente, inclusive no Brasil, o termo business case será empre-
gado sem tradução.
Ele indica a viabilidade do projeto com relação à capacidade de este adicionar

real valor ao negócio (KERZNER; SALADIS, 2009). Na prática, o business case atua
como uma ponte entre os objetivos estratégicos do negócio e as metas do projeto pro-
posto para apoiá-lo. Segundo Hedeman et al. (2005), ele serve como um guia para de-
senvolver o produto de um projeto.
O business case recebe atualizações, em decorrência de, por exemplo, novas de-
mandas do cliente, recentes mudanças nas leis ou alterações na governança da organi-
zação. Uma sugestão para a elaboração do business case é mostrada a seguir:
Business case
Nome do projeto:
Versão Data Responsável Comentários
1. Objetivos do business case

(Valor do projeto para o negócio e viabilidades do projeto.)
2. Objetivo do projeto
(Benefícios do projeto para os stakeholders e para o negócio. Critérios de sucesso.)
3. Stakeholders
(Stakeholders do projeto e os interesses de cada um. Importâncias relativas a eles.)
4. Interesses dos stakeholders
(Necessidades a serem atendidas pela solução do projeto.)
5. Indicadores de sucesso do projeto
(Indicadores relevantes para o sucesso. Vinculação com a solução do projeto.)
6. Principais entregas
(Principais entregas e suas datas. Impactos de eventuais atrasos nas entregas.)
7. Diretrizes da governança
(Requisitos de governança do projeto e as respectivas responsabilidades.)
8. Definição da solução
(Solução adotada e soluções alternativas para o projeto. Critérios de seleção.)
9. Recursos e capabilidades
(Principais recursos necessários para o projeto. Capabilidades e outros ativos.)
10. Orçamento
(Principais rubricas de custo e o orçamento do projeto.)
Aprovações
Patrocinador (assinatura) Data
Solicitante do projeto (assinatura) Data
O business case pode ser elaborado antes das propostas de soluções, dos estudos de viabili-
dade e da seleção da melhor solução com o intuito de orientar esses processos. Mas também
pode ser apresentado depois deles, para orientar o gerenciamento do projeto sobre o desen-
volvimento da solução adotada.
A declaração do trabalho (SOW ou Statement of Work), segundo o PMBOK®

(PMI, 2013), é uma descrição dos produtos, serviços ou resultados que serão entregues
pelo projeto. Para projetos internos, o responsável inicial ou patrocinador do projeto
fornece a especificação do trabalho com base nos requisitos das necessidades dos ne-
gócios, produtos ou serviços. Para projetos externos, a especificação do trabalho pode
ser recebida como parte de um documento de licitação ou de um contrato. A declara-
ção do trabalho especifica:
• As necessidades do negócio, que expressam demandas do mercado, imposi-
ções legais, ações dos concorrentes, diretrizes internas etc.
• A descrição do escopo do produto, que contém as características do produto

(bens, serviços, resultados) do projeto.
• O plano estratégico, que representa a visão estratégica, as metas e objetivos
da organização, aos quais os projetos devem se alinhar.
O modelo a seguir é útil para elaborar uma declaração do trabalho:
Declaração do trabalho
Nome do projeto:
1. Objetivos da declaração do trabalho

(Descrição de como o trabalho será realizado e as entregas a serem produzidas.)
2. Escopo do trabalho
(Descrição detalhada do trabalho a ser realizado.)
3. Cronograma de entregas
(Entregas previstas, respectivas datas previstas e critérios de aceitação.)
4. Normas e padrões pertinentes
(Normas técnicas, padrões da empresa ou da indústria e práticas consagradas.)
5. Requisitos e indicadores selecionados
(Requisitos e indicadores, com valores de referência e avaliação em relação a
estes.)
6. Atividades do trabalho
(Local em que o trabalho será realizado, períodos, durações, especificações.)
7. Competências
(Competências e experiências profissionais necessárias para as atividades.)
Aprovações
Solicitante do projeto (assinatura) Data
1.4.4 Projeto e monitoramento da solução adotada

A solução adotada e validada para o problema do projeto é posteriormente de-
senvolvida em um projeto e entregue. Por meio do escopo da solução, do business case
e da declaração de trabalho, ela será transmitida ao gerenciamento do projeto, res-
ponsável por gerar o produto do projeto. Esse produto, por sua vez, será convertido na
solução entregue aos stakeholders. Em uma data qualquer, a solução em desenvolvi-
mento representa o estado atual em que se encontra a solução em curso.
Produto não é o mesmo que solução. O primeiro resulta do gerenciamento do projeto e atende
aos stakeholders; a segunda adapta o produto gerado às necessidades dos diversos stakeholders
do negócio.
É muito provável que a solução em desenvolvimento, ao longo da duração do pro-

jeto, desvie da solução adotada. O mesmo ocorre para a solução entregue ao final do
projeto. Portanto, monitorar o desenvolvimento da solução é importante para:
• manter atualizados os profissionais da análise do negócio e do projeto;
• apoiar medidas preventivas e corretivas durante o desenvolvimento;
• estimar o valor real da solução para o negócio ao longo do processo.
A importância do monitoramento é evidente no projeto de uma residência de alto
padrão. Arquitetos, engenheiros e outros profissionais trabalham não apenas para en-
tregar o produto encomendado há dois anos do término. Eles procuram garantir que
as necessidades do cliente serão monitoradas durante o projeto e o produto final será
uma solução satisfatória para o cliente na época da entrega.
Referências
ALBUQUERQUE, I. S.; PERONDI, L. F. Gestão da Configuração e o Ciclo de Vida de
um Projeto na Área Espacial. In: WORKSHOP EM ENGENHARIA E TECNOLOGIA
ESPACIAIS, 1. (WETE), 2010, São José dos Campos. Anais... São José dos Campos:
INPE, 2010. Disponível em: <http://urlib.net/8JMKD3MGP7W/38UKP6H>. Acesso em:
06/02/2015.
AMARAL, D. C. et al. Gerenciamento Ágil de Projetos: aplicação em produtos inova-
dores. São Paulo: Saraiva, 2011.
AMARAL, J. A.; SBRAGIO, R. A. A Dinâmica do Projeto: uma visão sistêmica das con-
sequências de ações gerenciais. São Paulo: Scortecci, 2003.
BRUZZI, D. G. Gerência de Projetos: uma visão prática. São Paulo: Érica, 2002.
CARVALHO, M. M.; RABECHINI JR., R. Fundamentos em Gestão de Projetos. 3. ed.
São Paulo: Atlas, 2011.
CASAROTTO FILHO, N. Projeto de Negócio. São Paulo: Atlas, 2002.
FREEMAN, A. M. Stakeholder management and CSR: questions and answers.
In: Umweltwirtschaftsforum (Fórum da Economia do Meio Ambiente). Springer Link,
v. 21, n. 1, 2013.
HABER, M. Uma Contribuição para a Análise da Viabilidade de Projetos Envolvendo
Inovação Tecnológica – MADM. Tese de Doutorado. Programa de Pós Graduação em
Engenharia de Produção – Universidade de São Paulo. São Paulo USP, 2004.
HEDEMAN; B. et al. Project Management based on PRINCE2: an introduction.
Zaltbommel: VHP, 2005.
IIBA – INTERNATIONAL INSTITUTE OF BUSINESS ANALYSIS. A Guide to the
Business Analysis Body of Knowledge (BABOK®). Toronto: Kevin Brennan, 2009.
IPMA. ICB3® – IPMA Competence Baseline. Nijkerk: IPMA, 2006.
KEELING, R. Gestão de Projetos: uma abordagem global. 2. ed. São Paulo: Saraiva,
2012.
KERZNER, H.; SALADIS, F. P. Value Driven Project Management. New York: Wiley,
2009.
KERZNER, H. Gerenciamento de Projetos: uma abordagem sistêmica para planeja-
mento, programação e controle. São Paulo: Edgar Bluecher, 2011.
MAXIMIANO, A. C. A. Administração de Projetos: como transformar ideias em resul-
tados. São Paulo: Atlas, 1997.
MEREDITH, J. R. et al. Administração de Projetos: uma abordagem gerencial. 4. ed.

Rio de Janeiro: LTC, 2003.
OGC – OFFICE OF GOVERNMENT COMMERCE. Managing Successful Projects with
PRINCE2®. Norwich: TSO, 2009.
PMI – PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management
Body of Knowledge (PMBOK®). 5. ed. Upper Darbi: PMI, 2013.
PMI – PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Geren
ciamento de Projetos: guia PMBOK®. 4. ed. Newtown Square, PA: PMI, 2008.
ROZENFELD, H. et al. Gestão de Desenvolvimento de Produtos. São Paulo: Saraiva,
2006.
SANTOS, J. A. Gestão de Projetos. Curitiba: Editora Positivo, 2015.
SANTOS, J. A.; CARVALHO, H. G. RBC: Referencial Brasileiro de Competências em
Gerenciamento de Projetos. Curitiba: ABGP, 2006.
TRENTIM, M. H. Managing Stakeholders as Clients: Sponsorship, Partnership,
Leadership, and Citizenship. Campus Boulevard: PMI, 2013.
VALERIANO, D. Moderno Gerenciamento de Projetos. São Paulo: Prentice Hall, 2005.
VARELLA, L.; MOURA, G.; ANICETO, C. Aprimorando Competências de Gerente de
Projetos. v. 2. Rio de Janeiro: Brasport, 2013.
VARGAS, R. V. Gerenciamento de Projetos. 6. ed. Rio de Janeiro: Brasport, 2005.
______. Gerenciamento de Projetos: estabelecendo diferenciais competitivos. 7. ed.
Rio de Janeiro: Brasport, 2009.
XAVIER, C. M. S. Gerenciamento de Projetos: como definir e controlar o escopo do
projeto. 2. ed. São Paulo: Saraiva, 2008.
2 Abertura, integração e encerramento
Gerenciar um projeto é sempre uma
tarefa complexa, que envolve a coordena-
ção de pessoas, o conhecimento de várias
disciplinas e o controle de diversas variá-
veis. A integração do projeto torna-se cru-
cial para alinhar as decisões deste com os
interesses do negócio que o gerou, e defi-
nir bem seu início, seu meio e seu término.
Design Gráfico: Ana Luiza Fernandes Marques

Operacionalmente, a integração pro-
© Petr Ciz / / Fotolia. (Adaptado).

cura criar um bom clima de trabalho para a
equipe do projeto e garantir que as metas
serão cumpridas. Ela também documenta
os resultados e as lições aprendidas com o
projeto.
2.1 Iniciação e termo de abertura

A finalidade do processo de iniciação, segundo o PRINCE2 (OGC, 2009) é criar um
entendimento coletivo na organização sobre:
• os objetivos da realização do projeto, benefícios esperados e riscos;
• o escopo do trabalho a ser realizado e os produtos a serem entregues;
• como e quando os produtos serão entregues e a que custo;
• quem será envolvido nos processos decisórios do projeto;
• como a qualidade exigida será alcançada;
• como serão definidas e controladas as linhas de base do projeto;
• como os riscos e as mudanças serão identificados e avaliados;
• como o progresso será monitorado e controlado;
• quem necessita de quais informações, em qual formato e quando.
O PMBOK® (PMI, 2013) também menciona que a iniciação de um projeto valida o
alinhamento do projeto com a estratégia e o trabalho em progresso da organização.
2.1.1 Papel da iniciação

O papel da iniciação de um projeto é divulgar o projeto na organização e angariar
os apoios necessários para sua implantação e realização. Ela constitui a fase preliminar
do gerenciamento, na qual as condições adequadas para o projeto são criadas e os fun-
damentos para a execução do projeto são definidos. Uma providência crucial na fase
de iniciação é a criação da equipe do projeto (SANTOS; CARVALHO, 2006).
2.1.2 Processo de iniciação

As atividades típicas do processo de iniciação de um projeto são (IPMA, 2006):
• formalizar o processo de iniciação;
• comunicar na organização os objetivos do projeto e seu contexto;
• introduzir uma visão compartilhada do projeto nos planos;
• desenvolver e detalhar os planos de gerenciamento do projeto;
• adquirir aceitação do projeto e do plano de gerenciamento do projeto;
• integrar os trabalhos da equipe de projetos, com foco no negócio;
• garantir a disponibilidade dos recursos, nas datas necessárias;
• formalizar o início do projeto na organização e com parceiros;
• obter aprovações no termo de abertura do projeto e outros documentos;
• documentar as lições aprendidas para serem úteis em projetos futuros.
A reunião de iniciação (kick-off meeting) pertence ao processo de iniciação.
Também chamada de reunião de lançamento do projeto, costuma ser a primeira reunião entre o
cliente e a equipe do projeto.
2.1.3 Termo de abertura (Project charter)

O termo de abertura é o documento legal que reconhece a existência de um pro-
jeto, é como se fosse sua “certidão de nascimento”. Na literatura internacional, ele é
conhecido como project charter. Idealmente, esse termo é elaborado pelo iniciador ou
patrocinador do projeto, o qual confere ao gerente do projeto a autoridade para em-
pregar recursos da organização.
A figura a seguir ilustra um modelo típico de termo de abertura de um projeto.
Termo de abertura do projeto

Termo de abertura (Project Charter)
Nome do projeto:
1. Problema do negócio e justificativa do projeto

(Situação que motivou a realização do projeto.)
2. Nome e responsabilidades do gerente do projeto
(Identificação do gerente do projeto, suas responsabilidades e autoridade.)
3. Critérios de sucesso do projeto

(Definição e descrição dos critérios de sucesso.)
4. Problema do projeto
(Definição e descrição do problema a que o projeto se destina.)
5. Metas
(Identificação das metas do projeto e dos principais concorrentes e benchmarks.)
6. Requisitos e produtos
(Definição dos principais requisitos, entregas relevantes e produtos.)
7. Cronograma preliminar e marcos
(Diagrama de barras com indicação dos marcos relevantes.)
8. Custos e fluxo de caixa
(Estimativa inicial dos custos do projeto e do fluxo de caixa.)
9. Recursos
(Identificação dos principais recursos e suas quantidades.)
10. Premissas e restrições
(Definição das premissas e restrições do projeto.)
11. Necessidades de apoio da organização
(Definição do apoio que a organização fornecerá com recursos e avais.)
12. Riscos
(Identificação e avaliação resumida dos principais riscos.)
Aprovações
Gerente do projeto (assinatura) Data
O termo de abertura constitui um valioso instrumento de comunicação entre as

atividades de iniciação e planejamento de um projeto. Ele pode conter elementos de
um contrato formal, com as devidas assinaturas e autorizações (PMI, 2013).
2.2 Integração
O gerenciamento da integração abrange processos e atividades para identificar,
definir, combinar, unificar e coordenar os processos e atividades dentro dos grupos
de processo de um projeto (PMI, 2013). Ele inclui a tomada de decisões sobre aloca-
ção de recursos, alternativas conflitantes da gestão, negociação e ajustes (tradeoffs)
das prioridades do projeto, bem como adaptações para responder a mudanças durante
o desenvolvimento do projeto.
O gerenciamento da integração abrange o ciclo de vida do projeto. A figura a se-

guir ilustra o ciclo de vida e os documentos típicos de cada fase (MEREDITH et al., 2003).
Ciclo de vida de um projeto

Iniciação Organização e Execução Encerramento (Fases)
preparação
Recursos e custos

(Resultados) Tempo
Plano de Plano de Entregas Documentos

abertura gerenciamento aceitas do projeto
Fonte: PMI, 2013, p. 39. (Adaptado).
2.2.1 Papel da integração

A literatura técnica descreve os processos de gerenciamento de projetos com limi-
tes bem definidos ou como independentes, contudo, eles possuem superposições. O ge-
renciamento integrado desses processos busca justamente o alinhamento entre eles.
No projeto de um evento, a desistência súbita de um fornecedor é uma importante ameaça às

metas de pontualidade, custos e qualidade do evento. Ela exige a reavaliação dessas metas e
talvez até dos objetivos estratégicos do evento.
A coordenação dos planos das diversas áreas do conhecimento é uma das ativida-
des cruciais do gerenciamento da integração e se baseia no controle e na documenta-
ção das atividades da gestão de projetos.
2.2.2 Plano de gerenciamento do projeto

Esse plano constitui um documento formal e aprovado, que define como o pro-
jeto será executado, monitorado e controlado (CARVALHO; RABECHINI JR, 2011). O
desenvolvimento do plano inclui o processo de preparar e coordenar todos os planos
auxiliares do projeto, bem como integrá-los em um plano abrangente. Este contém
também as linhas de base (baselines) do escopo, dos custos e dos prazos do projeto.
Alguns dos elementos importantes para a construção do plano de gerenciamento

do projeto são (PMI, 2013):
• O Termo de abertura.
• Fatores ambientais da empresa (cultura, localização, normas internas e seto-
riais, regulamentações e leis, padrões, infraestrutura, recursos humanos, clima
político, bancos de dados externos, mercado etc.).
• Ativos organizacionais (diretrizes, instruções de trabalho, projetos anteriores,
procedimentos, bases de conhecimentos, informações históricas, licenças, con-
tratos de exclusividade, patentes etc.).
• Informações sobre o negócio (business case, necessidades dos stakeholders, posi-
ções dos concorrentes, plano de negócio etc.).
A tabela a seguir mostra um resumo dos planos auxiliares do plano de gerencia-
mento do projeto, bem como das linhas de base.
Planos auxiliares e linhas de base

Linhas de base Objetivos e descrições
Versão aprovada do escopo, da EAP e do dicionário da EAP. Só pode ser
Linha de base do escopo
modificada por meio de procedimentos formais.
Linha de base dos prazos Versão aprovada do cronograma. Usada como referência para avalia-
(ou do cronograma) ção e monitoramento dos prazos reais do projeto.
Versão aprovada do orçamento do projeto. Usada como referência
Linha de base dos custos
para avaliação e monitoramento dos custos reais.
Planos auxiliares Objetivos e descrições
O que o projeto entregará como produto; trabalhos realizados pelo
Gerenciamento do escopo projeto. Decomposição do escopo em entregas e trabalhos. Documen-
tos de avaliação e validação.
Como os requisitos serão analisados, priorizados, documentados e ad-
Gerenciamento dos requisitos ministrados. Eles podem ser do negócio, da solução, dos stakeholders,
do projeto, da qualidade e de transição.
Gerenciamento do Como definir as atividades do projeto, sequenciá-las, estimar durações
cronograma e recursos, criar e controlar um cronograma.
Como os recursos necessários para o projeto, suas quantidades, seus
Gerenciamento dos custos
custos e seu orçamento serão estimados e controlados.
Como determinar as políticas da qualidade, os objetivos e responsabi-
Gerenciamento da qualidade lidades para que o projeto satisfaça as necessidades para as quais ele
foi proposto.
Como detalhar e analisar o processo de desenvolvimento do produto
Melhoramento dos processos para gerar valor para os stakeholders mediante configuração e metas
do processo e metas de desempenho.
Como formar a equipe do projeto com os recursos humanos disponí-
Gerenciamento dos recursos
veis, desenvolver competências, interações e clima de trabalho, bem
humanos
como monitorar o desempenho da equipe.
Como criar, coletar, distribuir, armazenar, acessar e descartar informa-

Gerenciamento da
ções sobre o projeto, bem como monitorar e controlar a comunicação
comunicação
em todas as etapas do projeto.
Como identificar riscos potenciais, classificá-los, quantificá-los, desen-
Gerenciamento dos riscos
volver e controlar as respostas aos riscos.
Como adquirir (comprar, contratar, alugar etc.) produtos e serviços ne-
Gerenciamento das aquisições cessários para o projeto, bem como avaliar e selecionar fornecedores e
completar as aquisições.
Como identificar os stakeholders do projeto, satisfazer suas necessida-
Gerenciamento dos
des, desenvolver estratégias para engajá-los no projeto e monitorar os
stakeholders
relacionamentos com eles.
Fonte: PMI, 2013. (Adaptado).
O plano do gerenciamento do projeto também pode incluir, opcionalmente:

• Um plano para gerenciar mudanças e configurações no projeto.
• Indicação das maneiras como os trabalhos serão realizados.
• Escolhas e decisões específicas da equipe de projeto, tais como:
• ferramentas gerenciais a serem usadas em cada processo;
• relações de dependência entre processos;
• níveis de implantação mínimos e ideais, para cada processo.
• Indicação de técnicas e requisitos de ou processo específico.
A quantidade e a complexidade dos documentos necessários para o plano do ge-
renciamento podem desmotivar sua elaboração em pequenos projetos. Este é um erro
a ser evitado, pois o maior benefício desse plano não é sua abrangência, mas, sim, sua
existência.
Além do plano de gerenciamento do projeto, outros documentos externos ao pla-
no podem ser empregados no gerenciamento, conforme indica a tabela a seguir.
Documentos adicionais para gerenciar um projeto

Plano do
Gerenciamento do Outros documentos do projeto
Projeto
Plano de gestão da
Atributos das atividades Atribuições ao staff do projeto
mudança
Plano de gestão da
Estimativas de custo Declaração do trabalho
comunicação
Plano de gestão da
Estimativa de duração Checklist da qualidade
configuração
Linha de base dos
Lista de atividades Medidas de controle da qualidade
custos
Plano de gestão dos
Acordos Documentação dos requisitos
recursos humanos
Plano de melhoria de Matriz de rastreamento dos
Bases de estimativas
processos requisitos
Plano de gestão das Estrutura de decomposição do
Agenda de mudanças
aquisições produto
Linha de base do esco-
po (declaração do es-
Solicitações de mudança Calendário de recursos
copo, EAP, dicionário
EAP)
Plano de gestão da Previsões (estimativas
Registro de riscos
qualidade de custo, de prazo etc.)
Plano de gestão de
Agenda de assuntos Dados do cronograma
requisitos
Plano de gestão de
Lista de marcos Propostas de vendedores
riscos
Linha de base do Documentos das
Critérios de seleção de fontes
cronograma aquisições
Plano de gestão do Declaração de trabalho
Registro de stakeholders
cronograma das aquisições
Plano da gestão do Avaliação do desempenho da
Calendários do projeto
escopo equipe
Termo de abertura
Requisitos de Dados do desempenho do trabalho
Plano da gestão de financiamento Informações do desempenho
stakeholders
Cronograma Relatório do desempenho
Diagramas de rede
Fonte: PMI, 2013.
2.2.3 Entregas e dados do desempenho do trabalho

Uma entrega designa um produto ou resultado, completo ou parcial, que resulta
de um projeto, fase de um projeto ou processo. Ela visa satisfazer aos objetivos do pro-
jeto e se baseia idealmente no plano do gerenciamento do projeto.
Entregas dependem dos fatores ambientais do projeto formados por todas as
condições externas a ele, tais como: produtos de vários tipos, desenhos, esquemas,
descrições, modelos, protótipos, sistemas etc. (IPMA, 2006), bem como por proces-
sos, mudanças organizacionais, capacitação de pessoal, entre outras.
Já os dados do desempenho do trabalho, que também se baseiam no plano de
gerenciamento do projeto, são observações em estado bruto, que foram identificadas
durante a realização das atividades do projeto, tais como: datas de início e término de
atividades, medidas de desempenho, número de solicitações de mudança, número de
defeitos e reparos, custos medidos, durações medidas etc. (PMI, 2013).
Tanto as entregas como os dados do desempenho orientam as atividades e os re-
cursos necessários para atingir os objetivos do projeto.
2.2.4 Monitoramento e controle do trabalho do projeto

O trabalho do projeto deve ser verificado periodicamente, comparado com os re-
sultados realmente alcançados, monitorado ao longo do ciclo de vida e ajustado, se ne-
cessário. O objetivo não é só o de avaliar o desempenho do plano (monitoramento), mas
principalmente permitir ações corretivas e preventivas, mudanças de curso e aproveita-
mento de novas oportunidades (controle). Os passos constam na tabela a seguir.
Monitoramento e controle do plano de trabalho do projeto

1. Comparar o desempenho real do projeto 5. Gerar informações para a elaboração dos
com o plano de gerenciamento. relatórios de status, progresso e previsão.
2. Avaliar o desempenho para identificar 6. Gerar previsões para custos e prazos,
ações corretivas e preventivas. bem como outras variáveis afins.
3. Identificar riscos e controlar os riscos 7. Monitorar a execução das mudanças à
existentes. medida que elas ocorrem.
4. Construir, manter e documentar bases de 8. Elaborar relatórios adequados sobre o
dados sobre os produtos do projeto. progresso e situação do projeto.
Fonte: PMI, 2013.
As ferramentas para a realização do monitoramento e controle podem incluir tan-

to técnicas simples (estimativas pela média, análises de causa, gráficos de tendências,
modelos de relatórios etc.) quanto métodos sofisticados (análises multivariadas, agru-
pamentos hierárquicos, simulações matemáticas etc.). A escolha das ferramentas e
métodos depende da complexidade do projeto e da qualificação da equipe.
2.3 Controle integrado de mudanças

Há 2.500 anos, o pensador grego Heráclito postulou que a única coisa constante
no universo é a mudança; e que a mudança é real, enquanto a identidade é ilusória.
As ideias de Heráclito continuam atuais no mundo moderno, cujo progresso é
movido pela inovação. E elas se acentuam ainda mais no ambiente dos projetos, que
são os motores da mudança. Assim, um gerente de projetos considera a mudança não
como excepcionalidade, mas como normalidade.
No complexo ambiente dos projetos, mudanças ocorrem em vários pontos ao
longo do ciclo de vida do projeto e também nas diversas áreas. Se elas forem trata-
das isoladamente, até geram bons resultados locais, mas péssimos resultados para
os objetivos gerais do projeto. Portanto, um controle integrado de mudanças é
fundamental.
2.3.1 Papel do controle integrado

O controle integrado de mudanças em projetos inclui a coleta das solicitações de
mudança, a obtenção das devidas aprovações, a coordenação das ações ao longo do
processo de mudança, a avaliação da implantação e dos impactos, a documentação e a
comunicação seletiva das mudanças.
Esse controle recebe as solicitações de mudanças, avalia a pertinência de cada
uma delas, mede os impactos internos e externos ao projeto, aprova ou recusa a solici-
tação de mudança e, em caso de aprovação, revisa os planos de gerenciamento e as li-
nhas de base do projeto.
Dessa forma, as mudanças ocorrem de maneira integrada e com avaliação dos
benefícios globais – tanto para os stakeholders internos quanto para os externos.
2.3.2 Planejamento do controle integrado de mudanças

Em projetos de software, é comum que o cliente descubra suas reais necessida-
des à medida que o projeto avança. Não apenas suas necessidades mudam ao longo do
projeto, mas ele também aprende com quais novos recursos pode contar. Assim, o ge-
renciamento desse tipo de projeto considera as mudanças futuras como integrantes do
próprio projeto.
Segundo o RBC (SANTOS; CARVALHO, 2006), a gestão das mudanças enfoca as
mudanças de configuração que podem ocorrer no projeto e inclui as seguintes etapas:
• registro de todas as mudanças propostas;
• submissão dos pedidos de mudança e estimativa dos impactos;
• autorização ou rejeição das mudanças por pessoa autorizada;
• implantação das mudanças aprovadas;

• comunicação das mudanças;
• auditoria da execução das mudanças;
• avaliação crítica dos resultados do projeto com as mudanças.
A proposta de mudança no material de uma bicicleta implica novos cálculos estruturais e revi-
são do projeto da suspensão, até mesmo a velocidade máxima da bicicleta e a facilidade para
carregá-la são fatores que precisarão ser reavaliados.
Segundo o PMBOK® (PMI, 2013), solicitações de mudanças podem incluir:

• Ações corretivas – realinham o desempenho dos trabalhos com o plano.
• Ações preventivas – alinham o desempenho futuro com o plano.
• Reparo de defeito – modificam um produto ou componente não conforme.
• Atualizações – modificam documentos em função de conteúdos alterados.
À medida que o tempo avança, crescem exponencialmente os custos das mudan-
ças, enquanto diminui a flexibilidade para mudanças, conforme ilustra a figura a seguir.
Impacto das mudanças e dos riscos em projetos

Flexibilidade para a mudança

Valor
Custo da mudança
Tempo
Fonte: PMI, 2013, p. 39. (Adaptado).
O PRINCE2 (OGC, 2009) enfoca a gestão das mudanças em relação à linha de

base (baseline) das metas principais do desempenho do projeto: prazo, custo, quali-
dade, escopo, risco e benefícios. Ele associa os efeitos das mudanças à configuração
dos produtos do projeto, bem como ressalta a necessidade de avaliar os impactos de
cada mudança nos produtos (HEDEMAN et al., 2005). Essa visão focada no produto
(ROZENFELD et al., 2006) se justifica por ser o produto o resultado visível do projeto
para os stakeholders.
Trentin (2013) ressalta a importância do monitoramento e do controle das

mudanças na gestão dos stakeholders. Algumas questões típicas para mudanças em
projetos são:
• Quais objetos são incluídos no controle da mudança? Quais não são?
• Como são solicitadas as mudanças?
• Quem pode aprovar as mudanças?
• Como são documentadas as modificações e suas permissões?
• Como são documentadas as implantações das mudanças?
2.3.3 Monitoramento e controle integrado

O monitoramento e o controle integrado ajudam a verificar como uma mudança
impacta no produto do projeto e na solução para o problema do projeto. O primeiro in-
clui a coleta de informações, a avaliação de desempenho e o estudo de tendências das
mudanças. Já o controle prevê ações corretivas e preventivas advindas da mudança,
bem como a avaliação dessas ações e, se necessário, propostas de novas mudanças.
Alguns documentos úteis para monitorar e controlar as mudanças são:
• o plano de gerenciamento do escopo;
• a linha de base do escopo;
• o plano de gerenciamento de mudanças.
Alguns resultados decorrentes do monitoramento e controle integrados são:
• as aprovações formais das mudanças;
• a documentação e o registro das mudanças, em meios variados;
• atualizações nos planos de gestão do projeto e nas linhas de base;
• avaliação das mudanças para os stakeholders;
• avaliação dos impactos das mudanças para o negócio do projeto.
Projetos de novos produtos ilustram bem o papel de monitoramento e controle.
Embora eles se pautem por informações e especificações sobre o produto planejado,
este se modifica ao longo do tempo e exige atualizações periódicas e sistemáticas.
2.3.4 Gestão da configuração e da documentação

A gestão da configuração e a gestão da documentação são interligadas com a
gestão da mudança. Segundo Albuquerque e Perondi (2010), a gestão da configura-
ção busca conhecer, a qualquer momento, a descrição técnica do produto e seus com-
ponentes por meio de documentação; controlar continuamente a evolução técnica
do produto e a rastreabilidade dessa evolução; garantir a consistência entre os com-
ponentes do sistema e certificar-se de que a documentação corresponde sempre à
imagem fiel dos produtos descritos. Ela permite administrar as mudanças em um pro-
jeto de maneira sistemática e controlada. Embora seja mais empregada em projetos
de software, ela se aplica igualmente a qualquer tipo de projeto.
A configuração define as estruturas física e funcional do produto de um projeto. A gestão da

configuração minimiza as deficiências no projeto do produto.
A gestão da configuração pode ser estruturada segundo os seguintes passos:
3 – Registrar to- 7 – Realizar audi-

das as alterações torias periódicas
propostas nos para verificar o
produtos. sistema.
1 – Identificar os 5 – Verificar os
produtos sujeitos impactos causa-
ao controle de dos e mútuos.
configuração.
2 – Definir um sis- 6 – Avaliar, vali-

tema de gestão dar e comunicar
da configuração. as mudanças e
seus efeitos.
4 – Verificar os
8 – Elaborar e
relacionamentos
manter históricos
afetados pelas
das mudanças.
alterações.
Já a gestão da documentação procura garantir a exatidão, o acesso, a disponi-

bilidade, a confiabilidade e a segurança da informação fornecida aos stakeholders do
projeto (sejam internos ou externos à organização que abriga o projeto). Ela também
busca a coerência entre todas as informações do projeto, para que todas as pessoas
que necessitem acessar informações do projeto tenham conhecimento de sua disponi-
bilidade e formas de acesso, bem como dos métodos e procedimentos de acesso.
A gestão da documentação pode ser estruturada pelos seguintes passos (IPMA, 2006):
3 – Classificar
1 – Desenvolver 5 – Controlar as
documentos se-
um plano de atualizações e as
gundo critérios
documentação. versões.
de interesse.

2 – Garantir res- 6 – Registrar li-
4 – Armazenar
peito às políticas ções aprendidas
documentos (vá-
e diretrizes da e aplicar em
rios formatos).
organização. projetos futuros.
Uma efetiva coordenação entre as gestões da configuração e da documentação

facilita muito o controle integrado de mudanças. Em projetos automotivos, por exem-
plo, é comum desmembrar o projeto total em subprojetos quase autônomos (motor,
suspensão, painel etc.). Contudo, pode haver importantes interações entre esses sub-
projetos: um motor mais potente necessita de uma suspensão mais reforçada e talvez
um painel com instrumentos adicionais. A configuração e a documentação atualizadas
formam a base para a comunicação entre os subprojetos.
2.4 Encerramento
Encerrar um projeto ou uma fase do projeto implica finalizar todas suas ativida-
des e entregar todos os produtos e resultados. Cada fase do projeto deve ser encerra-
da com a avaliação e a documentação dos resultados. Também é necessário verificar
se os objetivos do projeto e as expectativas dos stakeholders foram atingidos.
Se houver contratos assinados, o encerramento do projeto incluirá também a
transferência de responsabilidades entre contratante e contratado do projeto, o início
do período de garantias e a cobrança do pagamento dos serviços prestados. Manuais e
treinamentos também devem ser produzidos para as partes que usarão os resultados
do projeto. Finalmente, procede-se à documentação dos resultados e das experiências
obtidas com o projeto, bem como à elaboração das lições aprendidas (IPMA, 2006).
2.4.1 Processo de encerramento

Além de finalizar todas as atividades do projeto e entregar os produtos e resul-
tados obtidos, o encerramento do projeto também implica a liberação de todos os re-
cursos da organização, de parceiros e do próprio projeto, para que estes possam ser
usados em outros projetos ou na organização permanente.
Entre os processos de encerramento do projeto constam:

• ações para atender às exigências formais para encerrar o projeto;
• ações para entregar os produtos e resultados para quem for de direito;
• elaboração das lições aprendidas e arquivamento de informações.
O PMBOK® (PMI, 2013) menciona que, durante o encerramento do projeto, o
gerente deve revisar todas as informações dos encerramentos de fases anteriores para
garantir que todo o trabalho do projeto esteja completo. Nesse processo, os stakeholders
devem ser idealmente envolvidos.
As atividades de encerramento mencionadas no PRINCE2 (OGC, 2009) incluem a
preparação do encerramento, a entrega dos produtos, a avaliação do projeto e a reco-
mendação formal para o encerramento. Uma lista de verificação para o encerramento
deve considerar as questões da tabela a seguir.
Documentos adicionais para gerenciar um projeto

8. Os impactos do projeto, para o negócio, foram
1. Os requisitos do projeto foram satisfeitos?
avaliados?
2. Todas as entregas foram verificadas e docu- 9. Se o projeto foi cancelado, as causas foram in-
mentadas? vestigadas?
10. Todos os contratos foram verificados, satisfei-
3. As entregas foram formalmente aceitas?
tos, encerrados e documentados?
4. As entregas e a documentação foram comuni- 11. Foi elaborado um relatório final? Este foi revisa-
cadas adequadamente? do e validado?
5. O produto do projeto foi passado para o contra-
12. Foi marcada uma reunião de encerramento?
tante ou para a próxima fase?
13. Os websites e as permissões do projeto foram
6. O sucesso do projeto foi avaliado?
desativados?
7. O business case e a declaração de trabalho fo- 14. As lições aprendidas do projeto foram devida-
ram satisfeitos? mente registradas?
Fonte: CARVALHO; RABECHINI JR., 2011. (Adaptado).
2.4.2 Entrega do produto

A entrega do produto implica sua aceitação formal pelos stakeholders, em espe-
cial o patrocinador do projeto. Esse processo exige assinaturas e termos de desobriga-
ção. O produto entregue é comparado com o escopo do produto proposto (no termo
de abertura e no escopo do produto). Além disso, é necessário verificar se a solução
obtida com o produto entregue atende aos interesses dos stakeholders, conforme o
que foi definido na análise do negócio do projeto (CASAROTTO, 2002).
A importância da entrega formal do produto é ilustrada com um projeto de
software para controle de experimentos farmacêuticos. Devido à pressa do cliente
para usar o software, ele negociou uma implantação antecipada e provisória antes do
término dos testes e das simulações. O uso antecipado ignorou defeitos no software,
que causaram enormes prejuízos ao cliente e o obrigou a refazer o trabalho de meses.
O caso resultou em ações legais entre o cliente, o gerente do projeto e o fornecedor.
2.4.3 Documentação e quitação de contratos

A elaboração, catalogação e armazenamento dos arquivos do encerramento in-
cluem diversos documentos típicos, tais como plano do gerenciamento do projeto,
planos auxiliares, avaliação de desempenho do projeto, contratos iniciais e revisados,
linhas de base originais e revisadas, apreciação crítica do projeto e lições aprendidas.
Documentos legais recebem atenção especial porque constituem a base para a
aceitação do produto do projeto e eventuais disputas. Eles devem ser submetidos a
uma apreciação jurídica como precondição para o encerramento do projeto.
Em alguns tipos de projeto, a documentação e a quitação de contratos sistemati-
camente recebe menos atenção do que poderia. Projetos de eventos são um caso típi-
co: não é de praxe a elaboração de manuais (como no projeto de produtos), tampouco
os contratos consideram muitos dos riscos envolvidos e as respectivas responsabilida-
des. Analogamente, também as lições aprendidas não costumam ser documentadas
com o mesmo cuidado que se tem nos projetos de produtos tangíveis.
2.4.4 Um exemplo detalhado para pequenos projetos

O gerenciamento da integração não é formalizado na maior parte dos pequenos
projetos conhecidos. Um provável motivo para isso é a quantidade e a complexidade
dos documentos que ele prescreve.
Para ilustrar o emprego desse gerenciamento, apresenta-se a seguir um exemplo
específico de projeto de pequeno porte. Sendo este um projeto de serviço, apresenta
maiores desafios para a integração de suas gestões. Dado seu pequeno tamanho, ele
deixa de empregar parte dos documentos de apoio em projetos maiores.
A. Descrição do projeto e condições iniciais

Nome do projeto
“Tele-lançamento de um livro”
Palavras-chave
Livro, lançamento de livro, projeto de serviço, projeto de pequeno porte.
Objetivo
Ilustrar os documentos do Gerenciamento da Integração em um projeto.
Descrição do projeto e suas condições (briefing)
O projeto trata do lançamento do livro Guia de Tecnologia com um evento em
tempo real na internet, durante 40 minutos. No final do evento, os participantes
podem encomendar o livro e recebê-lo pelo correio, autografado pelo autor.
O orçamento é R$ 50.000,00, sendo R$ 30.000,00 a fundo perdido e o restan-
te captado pelo próprio projeto. O prazo de preparação do lançamento é de seis
meses. Da coordenação do projeto participam o pessoal da editora, o próprio autor
e uma equipe externa contratada temporariamente.
O tele-lançamento é um conceito novo, idealizado e desenvolvido para esse
projeto. Ele pretende superar o modelo tradicional de lançamento de livros em li-
vrarias, nos quais comparecem poucas pessoas que adquirem o livro autografado
pelo autor. O tele-lançamento busca principalmente a “visibilidade” e esta é pro-
porcionada de duas maneiras: no ato do lançamento e nas fases pré e pós-lança-
mento. Para reforçar a visibilidade, conta-se com o serviço de mailing estratificado,
com os sítios eletrônicos da editora e com um sítio eletrônico criado exclusivamen-
te para divulgar o lançamento.
Para motivar as pessoas a assistirem ao lançamento em tempo real, são pre-
vistos três videoclipes: dois com shows musicais de artistas conhecidos e outro com
a entrevista de um gerente de projetos da área de telefonia. O lançamento (inclu-
sive os videoclipes) são acessíveis apenas em tempo real. Essa restrição imprime
mais autenticidade e novidade ao evento e atrai mais público.
O livro resulta de um projeto também inovador: é uma obra cara, com todas
as páginas impressas em cores, que descreve os mais importantes conceitos de
base tecnológica da atualidade (por exemplo: o que é nanotecnologia, bioinformá-
tica, robótica, bioenergia, segurança da informação, armas e sistemas militares,
inteligência autônoma, técnicas de medição etc.). Ele tem cerca de 500 páginas
e 1000 fotos e desenhos coloridos. O público-alvo é composto por pessoas que
presenteiam amigos e filhos em idade pré-universitária, bem como por bibliotecas

de escolas e faculdades.
O negócio, o problema, a solução e o produto do projeto
O negócio do projeto consiste na visibilidade que o lançamento da obra pro-
porcionará ao livro e à editora. Essa visibilidade será convertida em vendas de li-
vros durante o lançamento e também depois dele. Ela também beneficiará a boa
imagem da editora e seus objetivos comerciais com outros livros.
O problema do projeto é o lançamento do livro de forma a atingir um grande
número de participantes e alavancar as vendas iniciais.
A solução do problema do projeto é o lançamento baseado na plataforma ele-
trônica e nas competências gerenciais da equipe (capabilidades). Ela proporciona ao
participante uma experiência marcante, inesquecível, e reforça a marca da editora.
O produto do projeto é o evento de lançamento, que dura cerca de 40 minu-
tos (o produto não é o livro) e resulta do esforço do projeto. Por outro lado, o tra-
balho do projeto dura cerca de 6 meses e resulta no livro lançado.
O sucesso
O sucesso do projeto se define como a satisfação de suas metas: entregar o
produto no prazo, no custo aprovado e na qualidade especificada. Já o sucesso da
solução se define como a satisfação dos diversos stakeholders, cada qual com suas
exigências (clientes, editora, autor, legislação, fornecedores etc.), bem como a con-
tribuição que o projeto gera para o valor do negócio (KERZNER; SALADIS, 2009).
Os stakeholders
Os principais stakeholders e seus interesses são resumidos na tabela a seguir.
Stakeholders do projeto
Stakeholders Interesses
Autor Visibilidade de seu nome, vendas posteriores de exemplares.
Editora Visibilidade de sua marca, vendas no lançamento e depois dele.
Clientes Evento agradável e inesquecível, que vale o tempo investido.
Legislações Requisitos legais observados, normas da indústria também.
Concorrentes Padrões de sucesso para o lançamento convencional de livros.
Governança Diretrizes da empresa quanto à imagem, à segurança e ao pioneirismo.
Documentos da governança
Os documentos da governança do negócio (da organização) referem-se à edi-
tora. Eles resumem as obrigações legais da empresa, bem como seus valores, mis-
são e visão. Além disso, descrevem valores culturais, sociais e ambientais, bem
como regras que representam o compromisso da editora com a sociedade.
Além da governança da organização, foi também elaborada uma governan-
ça do projeto, alinhada com a da organização. Assim, os compromissos da editora
com a disseminação do conhecimento científico e a valorização de soluções inova-
doras constituem diretrizes norteadoras para decisões corriqueiras do projeto.
Business case
O business case do projeto contém os seguintes elementos:
Business case
Elementos Descrição
Objetivo do projeto Lançamento eletrônico de um livro.
Stakeholders Autor, clientes, editora, legislação, concorrentes, governança.
Interesses dos
Mencionados na Tabela “Stakeholders do projeto”.
stakeholders
Indicadores de
Sucesso do projeto e sucesso da solução (acima).
sucesso
Principais entregas Livro lançado conforme especificações e interesses.
Diretrizes da
Imagem da editora reforçada, normas internas respeitadas.
governança
Definição da solução Lançamento de livro com base em plataforma eletrônica.
Recursos e
Plataforma eletrônica contratada, pessoal capacitado.
capabilidades
Orçamento R$ 80.000,00, sendo R$ 50.000,00 a fundo perdido.
Documentos de referência
• termo de abertura;
• plano do gerenciamento do projeto;
• planos auxiliares;
• documentos da governança;
• contratos entre autor, editora e donos da plataforma eletrônica.
Responsabilidades
O gerente do projeto é responsável pelo desenvolvimento e pela implantação
do projeto. O patrocinador é responsável pelos recursos a fundo perdido. O diretor de
marketing da editora assume a definição do negócio do projeto e o desenho da solução.
Contratos
As relações entre o projeto e fornecedores externos são regidas por contra-
tos. Estes podem ser formais (registrados em cartório, assinados por testemunhas
etc.) ou informais (solicitações verbais, bilhetes etc.). Tanto um quanto outro são
amparados por lei e devem ser cumpridos.
Assim que o escopo do projeto foi definido, firmaram-se contratos de presta-
ção de serviços com os fornecedores selecionados. Também foram realizados con-
tratos entre editora e autor para a cessão dos direitos sobre o evento. Optou-se
por realizar as gestões desses contratos em cada área de interesse, e não de forma
centralizada.
Ciclo de vida do projeto
O projeto é dividido em quatro fases principais:
• Iniciação: dois meses para preparar as condições e analisar o negócio.
• Organização: três meses de preparação das atividades.
• Execução: 40 minutos (evento).
• Encerramento: um mês para documentação, análises e providências.
Termo de abertura (Project charter)
O termo de abertura formaliza a existência do projeto. Ele fornece ao gerente do
projeto a autoridade para representar o projeto na organização e fora dela, bem como
agir legalmente em nome do projeto, realizar despesas e comprometer recursos. O ter-
mo de abertura do projeto do lançamento do livro contém os seguintes itens:
• Problema do negócio e justificativa do projeto: lançamento de um livro
para proporcionar visibilidade ao próprio livro e à editora.
• Metas: realizar o evento na data anunciada, com alto impacto positivo en-
tre os clientes e manter o orçamento previsto, com risco moderado.
• Requisitos e produtos: uso de plataforma eletrônica desenvolvida para
este projeto e lançamento com alcance nacional, em tempo real.
• Cronograma preliminar e marcos: o prazo do projeto é de seis meses, divi-
dido em fases bem definidas e marcos específicos.
• Custos e fluxo de caixa: o projeto conta com um orçamento total de

R$ 80.000,00, com gastos acumulados mostrados em uma curva S.
• Recursos: são previstos o aluguel de um estúdio e de uma plataforma de
transmissão via internet, assim como a contratação de profissionais de fil-
magem e informática.
• Premissas e restrições: serão captados R$ 30.000,00, um estúdio adequa-
do estará disponível na data e o evento não será pré-gravado.
• Apoio da organização: além do apoio financeiro, a coordenação do proje-
to, o acesso aos bancos de dados e o uso da marca da editora.
• Riscos e tratativas: falhas na transmissão ao vivo (contratar equipamentos
de reserva) e ausência de patrocínio (cortar o escopo).
Por ser um documento formal, o termo de abertura exige as assinaturas do
gerente do projeto e do representante da editora. Ele não constitui um contrato,
mas um referencial para os trabalhos e pode ser usado para elaborar contratos.
B. Planos auxiliares do gerenciamento do projeto
© rashadashurov / / Fotolia. (Adaptado).

© Warakorn / / Fotolia. (Adaptado).
Escopo e exclusões
O escopo do projeto (XAVIER, 2008) abrange todos os trabalhos a serem reali-
zados para gerar o produto do projeto segundo as condições, as premissas e as restri-
ções indicadas no business case. Nesse projeto, as exclusões do escopo se resumem
em: não realizar testes reais do lançamento, por causa da falta de tempo.
O escopo do produto abrange o produto do projeto e suas partes. No caso, ele
consiste no lançamento do livro pela plataforma eletrônica, na gravação e na trans-
missão de dois videoclipes musicais gravados para a ocasião por artistas consagrados,
além de uma entrevista com o diretor do escritório de projetos de uma grande empre-
sa de telefonia. Duas exclusões do escopo do produto são: a isenção da tarifa de entre-
ga do livro pelo correio e a possibilidade de assistir ao lançamento após sua realização.
Mudanças no escopo
Por ser um projeto inovador, o lançamento eletrônico do livro está sujeito a
várias mudanças ao longo de seu planejamento e implantação. Mudanças no esco-
po influem no custo e na qualidade do projeto e trazem riscos aos prazos.
Um procedimento para solicitação de mudanças no escopo do projeto pede:
• nome do proponente;
• justificativa da solicitação;
• impactos para as metas (custos, prazos, riscos, qualidade etc.);
• impactos para o negócio;
• disponibilidade dos recursos exigidos;
• aprovações.
As solicitações de mudanças do escopo são registradas e geram documen-
tos úteis para ações futuras. Alguns registros importantes são: quem solicita, qual
o motivo, quais benefícios previstos, quais problemas resolve, quais gestões rece-
berão impactos, quem coordenará a análise e quais pessoas serão informadas do
andamento.
Qualidade
Por ser mais difícil de definir e medir, a qualidade em um projeto costuma ser
avaliada menos frequentemente do que grandezas unidimensionais, tais como cus-
to e prazo. Projetos de serviços empregam conceitos subjetivos ainda mais difíceis
de qualidade e de mensuração.
No tele-lançamento do livro, cinco enfoques consagrados para a qualidade do
produto podem ser interpretadas como indica a tabela a seguir.
Enfoques da qualidade no projeto do tele-lançamento do livro

Enfoque Qualidade é...
Transcendental ...um evento incomparável, inesquecível, emocionante.
Baseado no produto ...um evento bem pontuado segundo os padrões do mercado.
Baseado no usuário ...um evento que satisfaz a cada cliente, individualmente.
Baseado na produção ...um evento em conformidade com as especificações.
Baseado no valor ...um evento que compensa o tempo investido pelo usuário.
Embora todos esses enfoques sejam “corretos”, alguns deles são mais ade-
quados para cada caso específico. O tele-lançamento do livro empregou os enfo-
ques transcendental e baseado no produto.
O gerenciamento da qualidade também se refere à qualidade do projeto, repre-
sentada, por exemplo, pelo bom clima de trabalho para a equipe, término no prazo,
documentação armazenada adequadamente, registro das lições aprendidas etc.
Prazos e cronograma
O prazo total de seis meses corresponde às atividades indicadas na figura a seguir.
Diagrama de barras
Atividades Linha do tempo (meses)
1 2 3 4 5 6
1. Definição de negócio
2. Pesquisa de stakeholders
3. Desenho da solução
4. Esboço do projeto
5. Captação de patrocínios
6. Desenvolvimentos técnicos
7. Formação de pessoal
8. Desenho da plataforma
9. Testes simulados
10. Divulgação do lançamento
11. Instruções aos atores

12. Lançamento on-line
13. Vendas e entregas
14. Avaliação do desempenho

Custos e fluxo de gastos

Os custos do projeto são estimados segundo o conceito bottom-up somando-
-se todos os custos parciais estimados. Embora haja uma limitação do investimen-
to a fundo perdido (R$ 50.000,00), é possível contar com captações adicionais de
patrocínios.
Muitos dos itens de custos foram estimados por analogia com atividades pa-
recidas, mas não iguais. A justificativa é que o projeto é inovador e não há dados de
outros projetos iguais que possam fornecer estimativas mais acuradas.
Os gastos do projeto são representados em gráfico conhecido como curva S.
Gastos do projeto “Lançamento eletrônico de um livro”

100%
90%
80%
CP
70%
CR
60%
% dos gastos efetuados
50%
40%
30%
20%
VA
10%
0%
0 1 2 3 4 5 6
Linha do tempo (meses)

Medição do progresso
A curva S possibilita a medição do progresso do projeto, em apoio à análise
do valor agregado (KERZNER, 2009; VALERIANO, 2005), das seguintes maneiras:
• Comparando-se o valor daquilo que foi realmente realizado (VA = valor
agregado) com o custo planejado (CP) até uma data D, conclui-se se o pro-
jeto está atrasado. Se VA/CP < 1,0, o projeto está atrasado.
• Comparando-se o VA com o gasto total incorrido (CR = custo real) até uma
data D, conclui-se que o projeto está gastando acima do que deveria. Se
VA/CR < 1,0, o orçamento está ameaçado.
Uma medição baseada no valor também é possível. Dividindo-se o valor (V)
estimado do benefício que o projeto proporciona pelo custo estimado do projeto
ao seu final (CF) obtém-se um índice sobre o valor do projeto (I = V/CF), medido em
qualquer data D. Se esse índice diminuiu ao longo do tempo, é porque houve uma
redução do valor do projeto para o negócio.
C. Análise
O exemplo descrito ilustra os documentos do gerenciamento da integração,
em especial o plano de gerenciamento de projeto, planos auxiliares e algumas li-
nhas de base. O projeto descrito foi intencionalmente escolhido por ser pequeno e
simples.
O objetivo do exemplo é mostrar que mesmo pequenos projetos podem se
beneficiar com um gerenciamento da integração realizado de modo sistemático e
documentado. Um plano simples para integrar as gestões de um projeto ainda é
melhor do que nenhum plano.
Referências
06/02/2015.
FREEMAN, A. M. Stakeholder management and CSR: questions and answers. In:
Umweltwirtschaftsforum (Fórum da Economia do Meio Ambiente). Springer Link, v.
21, n. 1, 2013.
Inovação Tecnológica – MADM. Tese de Doutorado. Programa de Pós- Graduação em
Amsterdam: VHP, 2005.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK®). Amsterdam:
Kevin Brennan, 2009.
IPMA. ICB3® – IPMA Competence Baseline. Amsterdam: IPMA, 2006.
2012.
2009.

PRINCE2®. Londres: TSO, 2009.
PMI – PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em geren-
ciamento de projetos: guia PMBOK®. 4. ed. Newtown Square, PA: PMI, 2008.
2006.
VALERIANO, D. Moderno Gerenciamento de Projetos. São Paulo: Prentice Hall,
2005.
Projetos. v. 2. Rio de Janeiro: Brasport, 2013.
3 Escopo e qualidade
O escopo de um projeto procura definir claramente os limites dos seus trabalhos,
a fim de garantir que sejam executadas todas as atividades necessárias, e apenas es-
tas. Assim, evitam-se trabalhos mal definidos, incompletos, redundantes ou até exa-
gerados, os quais podem implicar desperdícios de recursos, atrasos e diversos tipos de
risco. Por outro lado, o escopo do produto gerado pelo projeto descreve as funcionali-
dades do produto e busca evitar tanto faltas quanto desperdícios de recursos no proje-
to desse produto.
Produtos “bons demais” podem ser caros e difíceis de serem vendidos; produtos “modestos
demais” podem não atender às expectativas do cliente.
Preocupação análoga ocorre com a qualidade. A qualidade do projeto exige es-

forços na medida certa – nem mais, nem menos. Caso contrário, ocorre desperdício ou
falta de recursos no projeto. Também a qualidade do produto busca suas funcionali-
dades na medida correta; produtos com excesso ou falta de qualidade podem ser caros
ou incapazes de satisfazer os clientes. O gerenciamento da qualidade do projeto busca
garantir que os requisitos do projeto, inclusive os requisitos do produto (ROZENFELD
et al., 2006), sejam cumpridos e validados.
Por vezes é difícil separar o escopo da qualidade em um produto. Para o usuário, a quanti-
dade de velocidades de um liquidificador pode ser associada tanto à funcionalidade quanto
à qualidade. Assim, os gerenciamentos do escopo e da qualidade possuem alguns desafios
em comum.
3.1 Coleta de requisitos e definição do escopo

Em análise de negócios, requisitos são características empregadas para modelar
as necessidades de uma pessoa, de uma classe de pessoas ou de um sistema. Um re-
quisito representa a realidade que ele modela (IIBA, 2009).
O termo requisito equivale à exigência, em português.
A coleta de requisitos inclui a aquisição, a documentação e a administração dos

requisitos relativos à qualidade. Estes consideram tanto os interesses dos stakeholders
(TRENTIM, 2013) quanto as necessidades específicas da solução pesquisada. Embora o
PMBOK® (PMI, 2013) mencione as “necessidades” dos stakeholders, “interesse” é um
conceito mais amplo por abranger também restrições, diretrizes, recursos etc.
Os requisitos têm por objetivo orientar a construção de soluções para resolver o

problema do projeto. Com base neles, definem-se as capabilidades e os recursos que
a solução adotada exigirá.
A definição do escopo consiste na descrição tanto do escopo do projeto como do
escopo do produto e suas entregas parciais (VALERIANO, 2005).
3.1.1 Conceitos fundamentais e plano de gestão do escopo

Definições
Escopo de um projeto é o trabalho a ser desenvolvido para garantir a entrega de
um produto com especificações e funções bem definidas. Ele descreve formalmente o
objetivo de um projeto (KEELING, 2012). Segundo o ICB3 (IPMA, 2006), o escopo de-
fine os limites do projeto. Para os stakeholders do projeto (TRENTIM, 2013), o escopo
abrange a totalidade de todas as entregas (deliverables) do projeto, sejam elas funcio-
nais, técnicas ou de interface com usuários.
Uma entrega refere-se tanto ao produto final como a resultados parciais realizados pelo projeto.
Em muitas situações é essencial explicitar o escopo negativo de um projeto

(XAVIER, 2008), que consiste nas exclusões explícitas do escopo (OGC, 2009). Tal pro-
cedimento procura evitar interpretações e litígios judiciais no futuro.
É interessante diferenciar o escopo do produto do projeto do escopo do projeto.
O PMBOK® (PMI, 2013) define o primeiro como “características e funções que carac-
terizam um produto, serviço ou resultado”, e o último, como “o trabalho que deve ser
realizado para entregar um produto, serviço ou resultado com as características espe-
cificadas”. Assim, o projeto de uma festa comemorativa tem como escopo do produto
a festa em si e todos os seus componentes naquele dia. Já o escopo do projeto abrange
os trabalhos nos meses de preparação da festa. Uma provável exclusão do escopo do
produto é o transporte dos convidados até o local da festa.
Analogamente, o escopo da solução de um projeto ou empreendimento refere-se
à descrição dos itens e funções que compõem a solução proposta. Uma solução pode
ser entendida como um produto capaz de resolver o problema do projeto sob o ponto
de vista dos stakeholders, não da equipe do projeto.
Enquanto o PMBOK® (PMI; 2013) enfatiza a gestão do escopo do projeto e suas
atividades, o PRINCE2 (OGC, 2009) enfoca primordialmente o escopo do produto e
suas entregas. Este último explica que a definição de escopo é complexa e sutil: ela
pode ter diferentes interpretações para o cliente e para o gerente de um projeto.
Planejamento da gestão do escopo

Em alguns projetos, o escopo tende a permanecer inalterado, como é o caso de uma
cirurgia plástica. Em outros, ele está mais sujeito a mudanças, por exemplo, em um proje-
to de software. Um adequado planejamento do escopo torna mais ágil o processo de alte-
ração do escopo e também facilita o controle sistemático de todas as gestões do projeto.
O planejamento da gestão do escopo gera um plano que indica como o escopo
será definido, desenvolvido, validado e controlado (XAVIER, 2008). A gestão do esco-
po pode ser resumida pelos processos da tabela a seguir.
Processos da gestão do escopo

Processos Alguns resultados
Planejamento da gestão do escopo Plano para gerenciar o escopo.
Coleta dos interesses dos stakeholders Interesses dos diversos stakeholders.
Definição do escopo Declaração formal do escopo.
Criação da EAP EAP e linha de base do escopo.
Validação do escopo Aceitação formal da proposta de escopo.
Controle do escopo Medições de desempenho e ações corretivas.
Fonte: PMI, 2013.
Em grandes projetos, o plano para gerenciar o escopo é formal e detalhado, já em

projetos simples ele pode se resumir a pequenos guias de referência.
3.1.2 Aquisição, priorização e organização dos requisitos do escopo

Muitos dos dados empregados para definir os requisitos de um projeto provêm do
termo de abertura e das pesquisas das partes interessadas, já disponíveis nessa etapa
do projeto. Outros dados são coletados com base em ferramentas gerenciais adequa-
das para cada caso, como as indicadas na tabela a seguir:
Ferramentas de pesquisa de requisitos

Técnicas de coleta Descrição resumida
Brainstorming Geração de ideias dirigidas a um problema específico.
Análise documental Pesquisa com base em documentos – escritos ou não.
Grupos focais Identifica problemas e avalia conceitos sobre um tema definido.
Análise de interface Identifica interfaces entre soluções e seus componentes.
Entrevistas Conversa entre pessoas para gerar informações direcionadas.
Observação Coleta de informações por meios visuais, para análise posterior.
Observação participativa O pesquisador participa ativamente do ambiente observado.
Prototipagem Criação de versão inicial de um sistema futuro, para testes.
Workshop de requisitos Reunião interativa de analistas e clientes para obter requisitos.
Enquete Pesquisa informal na qual pessoas respondem a perguntas.
Voz do cliente Identifica o que o cliente necessita, não o que ele pede.
Benchmarking Define padrões de excelência na área.
Grupos de E-discussão Coleta opiniões em rede de discussão na internet.
Diagramas de contexto Mostra relação entre um sistema e entidades externas.
Fonte: IIBA, 2009; PMI, 2013.
Um requisito é mais objetivo e quantificável do que um interesse. Na transforma-

ção de interesses em requisitos, perdem-se informações subjetivas, mas se ganha ob-
jetividade e racionalidade. Isso facilita o estabelecimento de metas concretas e claras
para orientar um projeto. A tabela a seguir identifica e classifica alguns tipos principais
de requisitos de projetos.
Tipos de requisitos de projetos

Requisitos Explicação
Requisitos do negócio Razões da existência do projeto.
Requisitos dos stakeholders Interesses dos stakeholders na solução do projeto.
Requisitos da solução funcional Comportamento do produto como solução de problema.
Requisitos da solução não funcional Condições para o produto ser eficaz.
Requisitos de transição Condições temporárias, mudança de estado.
Requisitos do próprio projeto Ações, processo e condições do próprio projeto.
Requisitos da qualidade Critérios para validar o sucesso das entregas.
Fonte: PMI, 2013.
Outros requisitos podem ser acrescentados à tabela anterior, se necessário.

Uma vez coletados os requisitos, procede-se à sua priorização. Ela é necessária
porque nem todos os requisitos coletados possuem a mesma relevância para o proje-
to. Diversos métodos e modelos podem ser empregados nesse processo – muitos deles
conhecidos de projetos semelhantes. Alguns métodos consagrados são:
• Lista de prioridades: lista os principais itens e atribui importância a cada um
deles. Apenas os itens com maior importância são selecionados.
• Matriz de prioridades: lista os principais itens e atribui nota de desempenho e
importância a cada um deles. Multiplicando-se as notas pelas respectivas im-
portâncias, obtém-se uma pontuação que classifica os requisitos. A tabela a
seguir ilustra o método para um projeto de software.
Exemplo da matriz de prioridades

Requisito I Notas Total
Rapidez 10% 80 8
Confiabilidade 50% 70 35
Padronização 40% 100 40
• Análises de tradeoffs: podem ser realizadas com a Matriz de Decisão, a Matriz

de Decisão de Pugh, a Análise Hierárquica (AHP), a Programação Linear, diver-
sos tipos de programação não linear, a simulação de sistemas, a análise de de-
cisão multicritérios etc. Também métodos e algoritmos não quantitativos são
úteis para análises de tradeoff.
• Modelo do tipo balanced scorecard: a estrutura do BSC pode também priori-
zar requisitos de projetos. Uma vantagem dessa solução é agrupar requisitos
por afinidades, conforme mostrado na tabela a seguir.
Modelo com pesos ponderados

Grupos Requisito I Notas Total Grupos
Rapidez 10% 70 7
Clientes
Confiabilidade 8% 50 4 23
(30%)
Padronização 12% 100 12
Governança Imagem da empresa 10% 40 4
16
(25%) Sustentabilidade 15% 80 12
Restrições legais Leis ambientais 15% 60 9
24
(45%) Código Defesa do Consumidor 30% 50 15
3.1.3 Definição e elaboração do escopo

A definição do escopo se baseia no termo de abertura e nos interesses dos
stakeholders do projeto. Seus principais itens são indicados a seguir (PMI, 2013):
1. Objetivos do documento
(Descrever qual produto será gerado e suas finalidades.)
2. Benefícios do projeto
(Indicar os benefícios do projeto e do produto para os stakeholders.)
3. Escopo do produto
(Descrever o produto criado pelo projeto e suas partes.)
4. Exclusões do escopo
(Descrever tudo o que se deseja enfatizar que não pertence ao escopo do
produto.)
5. Principais entregas
(Indicar os produtos e resultados parciais, bem como suas datas de entrega.)
6. Critérios de aceitação
(Descrever as condições para a aceitação das entregas.)
7. Restrições
(Descrever as limitações ao produto ou às atividades do projeto.)
8. Premissas
(Descrever situações assumidas como verdadeiras, mesmo sem comprovação.)
Muitos dos itens indicados se encontram também no termo de abertura do projeto, de forma
mais superficial.
A definição do escopo de um projeto pode ser dificultada por armadilhas semân-

ticas ou pela falsa segurança que possuímos acerca do termo escopo. O seguinte exem-
plo ilustra essa dificuldade.
Caso: Loja de conveniência para impressões

Nos Estados Unidos, os ser-
viços de fotocópias são oferecidos,
junto a diversos outros, em lojas
usualmente localizadas próximo a
universidades. Nessas lojas, o clien-
te pode contar com fotocópias de
© Moreno Soppelsa / / Fotolia

qualidade standard (normalmente o
próprio cliente faz as fotocópias), fo-
tocópias de alta qualidade (ele deixa
as fotocópias para serem feitas, no
entanto paga um valor bem maior),
fotocópias coloridas, serviços de fax,
serviços de encadernação, scanning,
mini-papelaria do self-service, serviço
de editoração e impressão de traba-
lhos, consulta a e-mail e até serviços
de digitação, correção ortográfica,
redação de trabalhos etc.
© freepeoplea / / Fotolia
Essas lojas são usualmente ope-

radas por poucas pessoas – uma ou
duas no balcão e uma ou duas na re-
taguarda. Só um gerente é necessário, o qual conta com o apoio de estudantes pa-
gos por hora para as tarefas operacionais. O espaço físico da loja em geral é bem
grande (10x10m no mínimo, para o salão de atendimento), de forma a comportar
grande número de clientes com relativo conforto.
Um brasileiro que visitou os Estados Unidos recentemente pretende implan-
tar o mesmo conceito dessa loja no Brasil: “Afinal, por que não profissionalizar e
padronizar mais o serviço local e, ao mesmo tempo, aumentar sua qualidade?”, ele
argumenta. Ele precisará elaborar um plano detalhado do negócio brasileiro.
Nesse caso, qual será o escopo do produto? Erram aqueles que apontam os diver-
sos serviços oferecidos pela loja. O produto do projeto é a loja implantada no Brasil e
o escopo descreve esse produto, suas condições, premissas, restrições, entregas etc.
3.1.4 Aceitação e vinculação com contratos

A aceitação do escopo ocorre mediante uma negociação dos interesses dos
stakeholders e a formalização de um termo de aceitação, na forma de contra-
to. Diversos instrumentos são úteis para apoiar o processo de aceitação do escopo.
Entre eles se destacam as técnicas de negociação e os checklists (listas de verifica-
ção). A finalidade dos primeiros é buscar soluções para o escopo, as quais podem ser
consensuais, negociadas, impostas etc. Já os checklists (GAWANDE, 2011) têm como
benefício verificar quais exigências para o escopo são satisfeitas e quais não são.
Sempre deve ser claro para os stakeholders quais são os critérios empregados para
aceitar o escopo e qual é o nível mínimo aceitável em cada critério (nível de qualificação).
No projeto de um software para vendas, o escopo do produto incluiu manuais detalhados, 40

horas de treinamento, três revisões gratuitas e exclusividade do produto. Os critérios de acei-
tação são objetivos, contudo o termo manuais detalhados ainda não ficou claro no projeto.
Uma vez aceito o escopo do projeto, é necessário formalizar os compromissos

com contratos. No contexto dos projetos, o ICB3 (IPMA, 2009) define contrato como
um “acordo legal que vincula duas ou mais partes para a realização de um trabalho ou
o suprimento de recursos, sob condições específicas”. Os contratos para aquisição de
recursos de um projeto possuem fontes internas (da mesma organização), externas (do
mercado) ou de parceiros (têm benefícios vinculados aos resultados do projeto).
Um contrato pode assumir várias formas: um documento escrito, um acordo ver-
bal com testemunhas ou gravação, um e-mail, um arquivo eletrônico, um telefonema
gravado e até um gesto (em um leilão). Um simples e-mail já gera obrigações formais
entre comprador e vendedor, com força de contrato legal. Segundo Valeriano (2005), a
gestão dos contratos em um projeto deve estar presente desde seu início.
A vinculação do escopo a contratos ocorre após a aceitação do escopo pelos
stakeholders. Em grandes projetos, é indispensável uma assessoria jurídica durante a
elaboração do escopo. Ela diminui a necessidade de corrigir o escopo futuramente.
O projeto de uma barragem na região Nordeste contou, desde o início, com apoio jurídico sóli-
do. As obras de benfeitoria para a região foram incluídas no escopo do projeto e evitaram rei-
vindicações posteriores por parte das comunidades locais atingidas.
Embora cada contrato de projeto seja específico e único, apresentam-se na tabe-

la a seguir alguns itens típicos de contratos de projetos.
Exemplos de itens de contratos de projetos

• Dados dos contratantes e contratados. • Preço orçado e detalhamentos eventuais.
• Escopo do produto e exclusões. • Prêmios e vantagens por bom desempenho.
• Prazos de entrega do produto e suas partes. • Critérios de aceitação do produto e partes.
• Responsabilidades e atribuições no projeto. • Seguros e mecanismos de controle de perdas.
• Responsabilidades frente a terceiros. • Leis, normas técnicas e outras referências.
• Remunerações específicas (se cabíveis). • Cláusulas de rescisão e foro de disputas.
• Condições e valores de penalidades várias. • Outras cláusulas pertinentes ao projeto.
Essa lista de itens, embora genérica, pode ser convertida em uma lista de verifi-
cação (checklist) padronizada para cada tipo de projeto. Para alguns projetos, alguns
itens podem ser excluídos; para outros, eles podem ser mais detalhados. Por exemplo,
cláusulas sobre seguro contra roubo são muito importantes para projetos que envol-
vem transportes de valor, mas são menos relevantes para obras civis.
3.2 Estrutura analítica do projeto e controle do escopo

A Estrutura Analítica do Projeto (EAP), mais conhecida como WBS ou Work
Breakdown Structure, é a decomposição hierárquica do escopo total do trabalho a ser
executado pela equipe do projeto a fim de alcançar os objetivos do projeto e criar as
entregas exigidas (PMI, 2013). O ICB3 (IPMA, 2009) trata do assunto de maneira simi-
lar. Já Hedeman et al. (2005) e o PRINCE2 (OGC, 2009) preferem enfocar a estrutura
do produto e decompor o produto do projeto de maneira análoga à EAP.
A EAP é uma estrutura hierárquica dividida em níveis, com os mais detalhados in-
dicados na base (XAVIER, 2008). Um exemplo de EAP é mostrado na figura a seguir.
EAP na forma de diagrama hierárquico

Projeto
Alfa
Produtos Gestões
Design Gráfico: Carlos Henrique Stabile
P.01 P.02 P.03 01. Escopo 02. Prazos 03. Custos 04. Riscos 05. Outras
P.02.01 G.01.01 G.03.01 G.05.01
P.02.02 G.01.02 G.03.02 G.05.02
P.02.03 G.03.03
Fonte: CARVALHO; RABECHINI, 2011. (Adaptado).

A EAP é um instrumento de comunicação que permite à equipe do projeto:

• obter visão panorâmica e, ao mesmo tempo, detalhada do produto do projeto
e/ou dos processos empregados para criar esse produto;
• atribuir responsabilidades a pessoas dos vários níveis do projeto;
• administrar facilmente as mudanças no produto do projeto;
• verificar a coerência do projeto e do produto com os pacotes de trabalho;
• embasar a criação de outros instrumentos do gerenciamento do projeto tais
como a estrutura de custos, cronogramas, diagramas de risco etc.
Dada a enorme importância da EAP para um projeto, ela não deve ser elaborada
apressadamente ou apenas copiada de projetos similares. Correções posteriores, mu-
danças ou rearranjos na EAP implicam custos e atrasos ao longo de todo o projeto.
3.2.1 Papel e desenvolvimento da EAP

A EAP nasce da decomposição do escopo total do projeto em níveis mais detalha-
dos. Esse processo envolve mais arte do que técnica. A maneira de realizar a decom-
posição depende do julgamento de quem elabora essa tarefa: um mesmo escopo pode
gerar EAPs com lógicas completamente distintas.
Existem três condições básicas às quais uma EAP deve satisfazer:
• Todo o trabalho está representado na EAP – nenhuma parte do escopo é dei-
xada fora da EAP.
• Somente o trabalho está na EAP – nada do que está representado na EAP ex-
cede o escopo do projeto.
• Os trabalhos representados na EAP são mutuamente excludentes – um mesmo
trabalho não aparece em mais de um lugar na EAP.
Essas condições podem e devem ser verificadas repetida e alternadamente na
construção de uma EAP até que se obtenha uma solução satisfatória.
Há diversas formas de representar uma EAP (KERZNER, 2011). As duas mais
usuais são o diagrama hierárquico, conforme representado anteriormente na figura
“EAP na forma de diagrama hierárquico”, e a tabela representada a seguir – ambos re-
ferentes ao mesmo projeto. Vamos comparar essas duas formas em um projeto real.
EAP na forma de tabela

Projeto Alfa

Produtos

P.01

P.02

P.02.01

P.02.02

P.02.03

P.03

Gestões

01. Escopo

G.01.01

G.01.02

02. Prazos

03. Custos

G.03.01

G.03.02

G.03.03

04. Riscos

05. Outras

G.05.01

G.05.02

Sob o ponto de vista formal, ambas as formas são equivalentes. Algumas vanta-
gens e desvantagens entre elas são comentadas na tabela a seguir.
Representações de uma EAP

Representação por Diagrama Representação por Tabela
Mais fácil de ler e entender. Exige prática para entender.
Difícil para desenhar e alterar. Mais fácil de elaborar e corrigir.
Necessita maior espaço para armazenar. Mais fácil para armazenar no computador.
Exige adaptações manuais e demoradas. Aceita adaptações pré-programadas.
Tamanho limitado pelo papel ou tela. Tamanho praticamente ilimitado.

O processo para a criação de uma EAP pode ser representado pelos seguintes pas-
sos – decompondo-se o projeto em atividades, conforme indica o PMBOK®, (PMI, 2013):
• Definir o Nível 0 com o nome do projeto: um nome sucinto que represente
bem o escopo do projeto.
• Definir os elementos do Nível 1 segundo a lógica eleita: o Nível 1 pode conter
como componentes: atividades, ou produtos, ou locais, ou fases ou um conjunto
de elementos que satisfaçam às condições básicas já citadas.
• Decompor os elementos do Nível 1 no Nível 2: os subelementos do Nível 2,
somados, equivalem às entregas dos elementos no Nível 1.
• Repetir a decomposição para os níveis inferiores: o processo de decomposi-
ção cessa quando não é mais necessário. Os elementos nos níveis mais baixos
são denominados pacotes de trabalho.
• Atribuir custos, prazos, responsáveis: a cada pacote de trabalho, ou subele-
mento do nível mais baixo em um ramo da EAP, podem ser atribuídos custos,
duração, pessoa responsável etc.
• Reavaliar criticamente a EAP: simular alterações e melhorar a EAP até que ela
atinja um estado aparentemente ótimo e seja bem aceita pela equipe.
Algumas lições práticas e simples ajudam na elaboração da EAP. Por exemplo:
• Não decompor um elemento em apenas um subelemento.
• Os nomes dos elementos devem ser simples, curtos e significativos.
• Um dicionário de apoio registra descrições detalhadas dos elementos.
• A mesma lógica é mantida em todas as decomposições (não variar).
• Um mesmo elemento não aparece em dois ou mais lugares na EAP.
• As tarefas de um elemento é a soma daquelas de seus subelementos.
Uma dúvida frequente na criação de uma EAP é: até que nível se deve detalhar
seus componentes. É razoável detalhar uma EAP até onde se consiga ou se deseja con-
trolar suas atividades, sugere Kerzner (2011). Por exemplo, quando se terceiriza uma
atividade ou um conjunto de atividades, não adianta continuar detalhando a EAP, bas-
ta que se controlem os resultados que serão entregues.
O seguinte checklist é útil para determinar se a EAP está bem detalhada:
• É necessário mais acurácia na estimativa do orçamento e/ou prazo?
• Mais de uma pessoa é responsável por um mesmo trabalho na EAP?
• Algum elemento prevê mais de uma entrega ou mais de um processo?
• A EAP consegue ser claramente entendida pela equipe?
• Os contratos do projeto mencionam itens não mostrados na EAP?
• Há conflitos ou duplicidade nos elementos na EAP?
Em uma EAP, algumas ramificações podem ser mais curtas ou mais longas do que
as demais, isso é normal e não obrigatoriamente indica necessidade de ajustes.
3.2.2 Linha de base do escopo e matriz de responsabilidades

A linha de base do escopo (scope baseline) é a versão aprovada do escopo, de sua
EAP e de outros documentos de apoio. Ela é empregada como referência no processo
de mudança do escopo e evita mudanças descontroladas.
A Matriz de Responsabilidades é uma estrutura que relaciona a EAP com a es-
trutura organizacional do projeto, para garantir que cada pacote de trabalho seja atri-
buído a um responsável (pessoa, departamento, equipe, assessoria etc.), como mostra
a tabela a seguir. Os índices P1, P2,...,P12 representam pessoas ou responsáveis.
Matriz de Responsabilidades
Tarefas/ Quem P1 P2 P3 P4 P5 P6 P7 P8 P9 P10 P11 P12
Projeto Construção G
Área A G
Construção Civil G I I
Terraplanagem E, I
Fundações e E
estruturas
Acabamentos E
arquitetônicos
Eletromecânica G, A I E, I
Eletrot. e controle E
Tubulações E I
Equipamentos E I
Área B
Construção Civil G I
Terraplanagem E, I I
Fundações e E
estruturas
Acabamentos E
arquitetônicos
Eletromecânica G, A I E, I
Eletrot. e controle E
Tubulações E I
Equipamentos E I
G = Gerencia E = Executa A = Aprova I = é informado
As responsabilidades pelas atividades de um projeto (ou as entregas de um pro-

duto) são classificadas de diversas formas. Na tabela anterior, elas são: Gerencia,
Executa, Aprova e é Informado. Outras Matrizes de Responsabilidades podem incluir
atribuições distintas, tais como: Responde por, Controla, Valida, Informa, Aceita etc.
O principal benefício da Matriz de Responsabilidades é a facilidade de comu-
nicação que ela proporciona entre os participantes de um projeto (KERZNER, 2011).
Com pouco esforço, entende-se quais são os principais trabalhos de um projeto e qual
é o papel de cada pessoa envolvida.
Em projetos complexos ou grandes empregam-se várias matrizes de responsabilidades.
A Matriz de Responsabilidades mostra que mudanças no escopo e na EAP do pro-

jeto podem implicar mudanças no pessoal do projeto.
3.2.3 Avaliação e validação

O escopo do projeto, bem como a EAP que o decompõe, resulta de uma modela-
gem da solução ideal para os stakeholders do projeto. Como qualquer modelo, ele ne-
cessita ser testado, avaliado e validado.
Avaliação
A avaliação do escopo verifica como os resultados do projeto se posicionam em
relação às metas propostas. A finalidade principal da avaliação é fornecer indicadores
do grau de sucesso obtido com o projeto. Em uma campanha publicitária, a avaliação
do sucesso pode se pautar pelo aumento nas vendas do produto ou pela beleza do ma-
terial gráfico. Tudo depende como se define “sucesso” no projeto.
A figura a seguir ilustra uma técnica simples mas útil para a avaliação do escopo
de projetos baseada na Matriz de Decisão. Cada fator relevante do escopo é associado
a um nível mínimo aceitável qualificador (Q); acima deste, definem-se os níveis D de
desempenho (D). Uma pontuação no nível qualificador significa insucesso no respec-
tivo fator (e no projeto); nesse caso, são necessárias ações de melhoria de desempe-
nho ou então a diminuição do limite de qualificação. A avaliação total do desempenho
é calculada pela média dos resultados alcançados nos fatores (se todos estiverem nas
zonas de qualificação). Essa média pode também ser ponderada pelas Importâncias (I).
Exemplo de avaliação do escopo

1 2 3 4 5 Fator Metas Qualif. Desemp. Import.
Fator 1 4,7 2,0 1,5 25%
Fator 2 4,8 4,0 0,5 10%
Fator 3 4,0 3,0 (-) 15%

Fator 4 5,0 3,5 0,5 50%
Fator 5 3,3 2,5 1,0 20%
Pontos = média [∑(Q+D)i] ou =∑(Q+D)i Ii

Nível Nível de
qualificador desempenho
Os itens avaliados se referem tanto a entregas já realizadas como àquelas em de-
senvolvimento ou apenas planejadas. O procedimento permite simular resultados e
avaliar os respectivos impactos no sucesso do projeto.
A avaliação do escopo pode ser sucedida por correções e ajustes sucessivos, até
que o escopo do produto/solução alcançado seja aprovado. Este deve então ser sub-
metido novamente a um outro processo de validação.
Validação
A validação do escopo é o processo de formalizar a aceitação das entregas do
projeto. Idealmente, a validação conta com a participação dos stakeholders principais,
a fim de garantir formalmente a aceitação dos produtos e as entregas do projeto.
Em certos projetos, não há uma definição prévia sobre os padrões de aceitação, uma vez que o
produto do projeto não é bem definido no início. Por exemplo, em projetos de desenvolvimen-
to tecnológico, quando a definição do produto evolui junto com o projeto.
Para a validação do escopo são úteis ferramentas gerenciais tais como:

1. Inspeções: revisões periódicas, de fase e esporádicas, auditorias, verificação
do produto, análise de riscos, checklists etc.
2. Técnicas de decisão: Delphi, votações estruturadas, sistemas de apoio à deci-
são, esquemas de decisão social etc.
Um dos maiores benefícios da validação do escopo é a geração do apoio formal à
solução proposta para o projeto. Isso motiva a equipe do projeto e confere segurança
ao trabalho realizado.
No projeto de uma loja de brinquedos, os requisitos “design arrojado” e “segurança” eram prio-
ritários, mas conflitantes. Isso causou muitas modificações no escopo do projeto. Somente
após validar a solução proposta é que os designers conseguiram planejar e detalhar o trabalho
com objetividade.
Do escopo validado resulta a linha de base do escopo. Esta somente pode ser mo-
dificada mediante a abertura de um processo formal para modificar o escopo.
3.2.4 Controle do escopo

Como projetos são instrumentos de mudanças, estas influenciam diretamente o
planejamento e o controle do escopo. Alguns tipos de projetos contam com mais mu-
danças do que outros: por exemplo, um projeto de software é mais susceptível a alte-
rações do que o projeto de uma obra pública licitada.
O controle do escopo é “o processo de monitorar o status do escopo do proje-
to e do produto, bem como de administrar as mudanças na linha de base do escopo”
(PMI, 2013). O benefício principal do controle é manter atualizada a linha de base do
escopo ao longo do projeto.
No controle do escopo, a EAP representa a desagregação do escopo e seus
elementos principais (para baixo) e a agregação de atividades ou elementos para
compor o escopo (para cima), segundo Rabechini e Monteiro (2011). Esses concei-
tos são ilustrados pela figura “EAP na forma de diagrama hierárquico”, apresentada
anteriormente.
Uma técnica também consagrada para o controle do escopo de um projeto é a
análise da variação (variance analysis), que determina a variação entre a situação real
do escopo do projeto e a linha de base do escopo.
O RBC (SANTOS; CARVALHO, 2006) aborda o controle do escopo dentro do item
“mudanças de configuração do projeto”. Segundo esse guia, a partir de uma linha
base do escopo, as mudanças podem ser orientadas pelos seguintes procedimentos:
1. Registrar todas as modificações propostas.
2. Propor solicitações de modificações.
3. Avaliar seus impactos no projeto.
4. Autorizar ou rejeitar as modificações propostas.
5. Implementar as modificações aprovadas.
6. Auditar a execução das modificações aprovadas.
7. Monitorar a mudança durante período adequado.
8. Documentar as lições aprendidas com as modificações.
No projeto de um estádio de futebol para a Copa do Mundo FIFA 2014, houve necessidades de
adaptar o escopo em função de novos padrões de iluminação do estádio. Para permitir trans-
missão por TV de alta definição e 3D, o número inicial de lâmpadas foi multiplicado por quatro
no projeto final.
3.3 Identificação, coleta e organização de requisitos

da qualidade
Os requisitos da qualidade traduzem o padrão desejado para o produto do proje-
to e expressam as condições necessárias para validar o projeto e seu produto.
Segundo o PMBOK® (PMI, 2013) um projeto gera “entregas”, que são produtos finais ou
intermediários e até mesmo parciais. No presente texto, emprega-se tanto “produto” quanto
“entrega”, indistintamente. O termo “solução” refere-se a um produto capaz de satisfazer aos
interesses dos stakeholders.
O gerenciamento da qualidade procura garantir que os requisitos do projeto, bem

como os do produto, sejam satisfeitos e validados. Algumas de suas etapas são:
1. Identificar requisitos e padrões relevantes.
2. Coletar os requisitos relevantes e suas importâncias relativas.
3. Auditar os requisitos e comparar com os padrões adotados.
4. Monitorar os resultados ao longo do ciclo de vida do projeto.
5. Empreender ações corretivas e preventivas com base nos resultados.
6. Documentar processos e seus resultados, como referências futuras.
Ao gerenciamento da qualidade pertence a busca do nível ótimo da qualidade.
Não se trata apenas de maximizar a qualidade, pois isso encareceria o produto do pro-
jeto; trata-se de buscar o nível adequado da qualidade para satisfazer os interesses
conflitantes dos stakeholders da melhor maneira possível. Ele indica como a organiza-
ção permitirá ao projeto praticar os padrões da qualidade definidos.
3.3.1 Conceitos fundamentais e plano de gestão da qualidade

O termo qualidade abrange muitas interpretações. Ele pode ser vago ou até es-
pecífico, a depender de seu enfoque. Alguns enfoques para a qualidade do produto
(ROZENFELD et al., 2006) são indicados na tabela a seguir.
Alguns enfoques da qualidade

Enfoque da
Descrição Críticas
qualidade
Qualidade como excelência nata, absoluta e universal. Pouco prático,
Não varia no tempo, nem depende de tendências. Sugere não indica como
Transcendental
interpretação pessoal, mesmo se coletiva. Por exemplo, melhorar, apenas
padrões de “beleza”; como julgar.
Qualidade como variável precisa e mensurável. Depende da Supõe preferências
Baseado no
“dosagem” das características técnicas do produto. Objetiva, semelhantes para
produto
facilita a quantificação. as pessoas.
Qualidade depende do usuário individual. Produto tem Dificulta a
Baseado no
qualidade se satisfaz às preferências de cada indivíduo. generalização e a
usuário
Qualidade se contrapõe a preço. padronização.
Qualidade é conformidade com as especificações. Bom para Não questiona o
Baseado na
o Controle da Qualidade. Qualidade é eficiência técnica, significado das
fabricação
custo baixo e produtividade. especificações.
Qualidade é definida por Benefícios versus Preços ou Difícil de medir,
Baseado no
Conformidade do produto versus Custos. Valoriza a eficiência aplicar e monitorar,
valor
e a sensação de ganhos pessoais. na prática.
Fonte: GARVIN, 1992. (Adaptado).
Em um projeto, interessa entender qual é o enfoque adequado para seu produto.

Para a qualidade de uma pintura, é adequado o enfoque transcendental; para a quali-
dade de um parafuso, o enfoque da fabricação; para a qualidade de um serviço, o enfo-
que com base no usuário ou o enfoque baseado no valor.
Também pode-se diferenciar a qualidade do produto como objetiva versus subjetiva, ou téc-
nica versus percebida. A qualidade subjetiva e a percebida são mais complexas, incertas e exi-
gem mais recursos para serem pesquisadas.
O Plano de Gerenciamento da Qualidade descreve como as políticas da qualidade

da organização serão consideradas no projeto e orienta a busca da qualidade do pro-
duto do projeto. Os principais itens desse plano são indicados a seguir.
1. Objetivos do Plano
(Descrever como considerar no projeto a política da qualidade da organização.)
2. Objetivos do projeto
(Indicar os benefícios do projeto e do produto para os stakeholders.)
3. Justificativa do projeto
(Indicar quais foram as razões para a proposta do projeto e o que ele beneficia.)
4. Indicadores do sucesso
(Esclarecer como verificar se o projeto obteve sucesso.)
5. Enfoque da qualidade
(Adotar o enfoque mais adequado para definir a qualidade do produto do projeto.)
6. Métricas da qualidade
(Indicar os padrões de referência do projeto – normas técnicas, padrões internos
da empresa, padrões do setor, padrões internacionais, benchmarks etc.)
Requisito da qualidade Referência adotada Meta própria Como atingir
7. Ferramentas da qualidade
(Descrever quais ferramentas podem ser empregadas, como e onde.)
8. Entregas e respectivos critérios de aceitação
(Descrever as entregas e produtos e os respectivos critérios de aceitação.)
9. Monitoramento e controle
(Avaliar o grau de satisfação com as entregas, por parte dos stakeholders.)
Requisito da Indicador da Ações Pessoa
Meta Como medir Resultados
qualidade qualidade corretivas responsável
10. Avaliação dos impactos na solução

(Avaliar o impacto da qualidade de fato praticada, na solução obtida com o produto.)
11. Documentação e lições aprendidas
(Documentar os planos e resultados obtidos, bem como as lições aprendidas.)
Planejar o gerenciamento da qualidade significa identificar os requisitos da quali-
dade e indicar como o projeto demonstrará conformidade com os requisitos relevantes
(PMI, 2013). Segundo uma visão estratégica, significa também selecionar o enfoque
adequado para a qualidade, estabelecer padrões com base nesse enfoque, monitorar
a qualidade segundo os padrões adotados e avaliar o impacto da qualidade praticada
junto aos stakeholders (TRENTIM, 2013).
Em um certo projeto de óculos, a qualidade enfoca o usuário e suas preferências individuais, tais
como design e estética. Esses atributos são considerados mais importantes do que os técnicos
(enfoque da fabricação), os quais privilegiam a precisão, a boa visão e a perfeição técnica.
3.3.2 Identificação de requisitos da qualidade

A identificação dos requisitos define as características técnicas de um produto, as
quais descrevem sua qualidade. Ela também define as métricas, as escalas e suas refe-
rências, bem como as metas para a qualidade. A totalidade das características técnicas
mais relevantes determinam então a qualidade do produto. Nesse processo, interes-
sa identificar apenas os requisitos mais importantes. Por exemplo, no projeto de um
liquidificador, os requisitos relativos a velocidade, capacidade do copo e peso definem

as respectivas características técnicas: 1800 rotações por minuto, 1,5 litro e 2,0 quilos.
Esse conjunto de características pode indicar a qualidade do produto.
3�3�3 Coleta dos requisitos

A coleta dos requisitos da qualidade in-
clui a busca, o registro e a documentação
dos requisitos relacionados com a qualidade
do projeto e do produto do projeto. Algumas
técnicas especialmente úteis para a cole-
ta dos requisitos foram indicadas na tabe-
la “Ferramentas de pesquisa de requisitos.”,
apresentada anteriormente.
Requisitos de projetos devem expres-
sar não só as necessidades dos clientes, se-
gundo ICB3 (IPMA, 2006), mas também
interesses dos demais stakeholders.
A Matriz de Rastreabilidade dos
Requisitos é uma tabela que associa os
requisitos aos produtos e às soluções
do projeto. Ela identifica a influência de
© Torbz / / Fotolia
cada requisito na geração de valor para
o produto e para o negócio do projeto.
Matriz de rastreabilidade dos requisitos

Descrição do Necessidades Entrega Valor para Valor para
Identificação
requisito do negócio na WBS o projeto o negócio
0.1.1.1
0.1.1.2
3�3�4 Priorização e organização

A priorização dos requisitos tem por objetivo garantir o foco nos requisitos mais
críticos, que mais adicionam valor ao negócio do projeto. Ela filtra os requisitos para
análises mais detalhadas, no futuro, e aqueles que serão atendidos mais prontamente.
O resultado disso é uma lista de requisitos com maior importância relativa. O proces-
so de priorização se baseia no business case, nos interesses dos stakeholders e no poder
de influência dos stakeholders.
A tabela a seguir apresenta algumas técnicas para a priorização de requisitos.
Algumas técnicas para a priorização de requisitos

Técnicas Observações
Cada requisito recebe importância e notas segundo critérios pré-definidos.
Matriz de prioridades
Prioriza-se o fator P = Importância X Notas.
Votação Cada participante distribui pontos entre os vários requisitos.
Para um orçamento fixo, (1) adicionam-se requisitos relevantes até o
limite do orçamento ou (2) incluem-se todos os requisitos, eliminando-os
Orçamentação
sucessivamente ou (3) simulam-se adições dos requisitos mais promissores
até encontrar a solução ideal.
Moscow Classificam-se os requisitos em: Must – Should – Could – Won’t.
Calcula-se o risco para o projeto relacionado com cada requisito e decide-se
Análise de risco
pela sua adoção ou não em função do risco.
Simulam-se diferentes combinações de requisitos e elege-se aquela que
Simulação
proporcionar maior valor para a solução do projeto.
Fonte: IIBA, 2009. (Adaptado).
Em um projeto no qual “todos os requisitos são muito importantes”, perde-se o

foco na essência do produto – e talvez o diferencial competitivo. Empresas que lançam
muitos produtos novos priorizam os requisitos desses produtos como diferencial com-
petitivo. Na indústria de smartphones, questiona-se: qual é o diferencial de cada mar-
ca? Os investimentos serão canalizados para os requisitos mais relevantes.
3.4 Garantia e controle da qualidade

A garantia da qualidade consiste no processo de auditoria dos requisitos da quali-
dade. Esse processo, baseado em métricas, é seguido pelo monitoramento e controle
da qualidade, que avalia os impactos e recomenda ações de mudanças. Uma métrica
descreve um atributo da qualidade e seu processo de medição.
No projeto de uma conferência, a pontualidade das palestras é um atributo da qualidade do

produto do projeto. Esse atributo é medido pelo desvio em relação aos valores de referência:
os horários planejados para as palestras.
Métricas subjetivas exigem medições mais difíceis e onerosas. No exemplo da con-

ferência, o conforto das instalações e a comunicação dos palestrantes são exemplos de
tais métricas. Elas empregam opiniões, observação e outros processos de avaliação.
3.4.1 Garantia da qualidade

A garantia da qualidade assegura, especialmente para os stakeholders do proje-
to, que a coordenação do projeto se alinha com as diretrizes da empresa para a quali-
dade. Assim, as referências para a garantia da qualidade são externas ao projeto e se
encontram fora do domínio da equipe do projeto – ao passo que o planejamento e o

controle da qualidade pertencem ao domínio da equipe do projeto.
A garantia da qualidade se baseia na auditoria: (1) da qualidade e (2) dos resulta-
dos medidos no controle da qualidade. Ela coordena ações e processos do plano de ge-
renciamento da qualidade. Ela ainda busca assegurar que produtos a serem entregues
em datas futuras possam ser terminados de forma a satisfazer aos requisitos e interes-
ses dos stakeholders. Alguns dos resultados da garantida da qualidade, mencionados
em PMI (2013), são:
• Indicações para ações de mudanças: para que o projeto consiga gerar seus pro-
dutos conforme especificações e exigências pré-definidas.
• Atualizações no plano e outros documentos do projeto: para manter o plano e
demais documentos atualizados e alinhados.
• Adaptações nos recursos: garantir que os recursos do projeto são adequados
para gerar os resultados replanejados.
A literatura técnica indica diversos métodos e procedimentos úteis para a gestão
da garantia da qualidade – em especial, aqueles conhecidos como “as sete ferramentas
da qualidade” e outros da gestão da qualidade total (MOURA, 1993).
No projeto da conferência, matrizes de priorização revelam os requisitos-chave, os quais são

satisfeitos, monitorados e controlados. O sucesso é medido em relação à linha de base da qua-
lidade e avaliado segundo os interesses dos stakeholders: os participantes do evento, o patroci-
nador e a coordenação.
3.4.2 Linha de base da qualidade

Assim como o escopo, o prazo e os custos do projeto possuem linhas de base, por
isso é útil definir uma linha de base para a qualidade. Ela representa um conjunto de
referências para as variáveis da qualidade, em uma determinada data, em relação ao
qual serão monitorados e controlados os parâmetros da qualidade. Desvios em relação
à linha de base indicam necessidade de correções na qualidade planejada.
A representação da linha de base da qualidade pode empregar a Matriz de
Decisão. Para cada requisito, define-se uma região de qualificação e uma região de
desempenho. Também se definem valores de referência, tais como benchmarks, me-
tas, situações dos concorrentes etc. Analogamente, define-se a estimativa da situação
do requisito, em uma certa data. A matriz serve então como um raio-X da situação na
data analisada e permite a adoção de ações corretivas.
3.4.3 Avaliação de desempenho

Para a avaliação de desempenho da qualidade, procura-se avaliar se os níveis pla-
nejados da qualidade satisfazem bem ou têm condições de satisfazer bem aos interes-
ses dos stakeholders. Para tanto, é útil o emprego de:
• Métricas: permitem comparar os níveis da qualidade a serem alcançados com
os respectivos itens da linha de base da qualidade. Podem indicar a situação de
cada item em uma escala de desempenho. Representam os principais atributos
da qualidade e seus potenciais de impacto no negócio do projeto e podem for-
necer uma avaliação consolidada da qualidade.
• Listas de verificação (checklists): permitem verificar e catalogar os itens da
qualidade aprovados/reprovados segundo critérios específicos. Elas podem
empregar fatores qualificadores como critérios de aceitação.
No projeto da conferência, algumas métricas são a pontualidade das palestras, o número de

doces do lanche e a nota atribuída a cada palestra. No checklist pode constar se cada palestra
foi pontual, se houve ao menos 5 tipos de doces no lanche e se a palestra obteve avaliação mí-
nima igual a 7.
3.4.4 Controle da qualidade

O controle da qualidade se baseia na avaliação de desempenho da qualidade e
dele resultam ações corretivas e preventivas. Ele emprega, por exemplo:
• Gráficos de controle: indicam se um processo é estável e monitoram como
uma variável da qualidade se comporta ao longo do tempo.
• Avaliação de status: permite verificar quais serão os níveis da qualidade alcan-
çado com o projeto, com base em estimativas atuais.
• Análise de riscos: estima os riscos de não se atingirem as metas da qualidade e
avalia as consequências para o projeto e seu negócio.
• Análise de gaps: indica quais deficiências existem em projetos de serviços e
sugerem medidas para diminuir/eliminar essas deficiências.
• Análise de tradeoffs: busca balancear os níveis da qualidade medidos, de
modo a garantir um ótimo desempenho global do produto. Ela pode sugerir o
remanejamento de recursos entre itens da qualidade.
Informações úteis para o controle da qualidade no projeto são: as métricas da
qualidade adotadas, os níveis da qualidade exigidos pelos stakeholders, os benchmarks
da qualidade, os checklists e as descrições dos produtos conforme, conforme descritas
no business case, na declaração de trabalho e nos contratos do projeto.
No projeto da conferência, verifica-se até que ponto os níveis da qualidade do lanche e das pa-
lestras serão alcançados. Caso algum item possua avaliação prévia deficiente, destina-se mais
recursos a esse item e menos ao website.
Referências
AMARAL, J. A. SBRAGIO, R. A. A Dinâmica do Projeto: uma visão sistêmica das con-
GARVIN, D. A. Gerenciando a Qualidade: a visão estratégica e a competitiva. Rio
Janeiro: Qualitymark, 1992.
IIBA A Guide to the Business Analysis Body of Knowledge (BABOK®). Kevin Brennan:
Toronto, 2009.
2012.
2009.
Body of Knowledge (PMBOK®). 5. ed. PMI, Upper Darbi, 2013.
PMI – PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em gerenci-
amento de projetos: (Guia PMBOK®). 4. ed. Newtown Square, PA: PMI, 2008.
2006.

Leadership, and Citizenship. PMI, Campus Boulevard, 2013.
2005.
4 Tempo
A entrega do produto no prazo prometido é um fa-
tor determinante para o sucesso do projeto. Atrasos
na inauguração de um shopping center podem des-
truir as vendas do Natal. E apenas um dia de
atraso na festa do aniversário de uma cidade
equivale ao fracasso completo do projeto, com
enorme prejuízo financeiro e de imagem.
Em função das incertezas nos projetos,
em vários casos, o “tempo” constitui o princi-
pal fator de (in)sucesso, à frente do escopo, da
© alphaspirit / / Fotolia
qualidade e dos custos − com os quais ele compe-
te por prioridade de atenção nos projetos (KERZNER;
SALADIS, 2009). Isso ocorre frequentemente nos proje-
tos de lançamento de produtos do setor automotivo.
Atrasos em projetos são frequentemente atribuídos à falta de sorte. Contudo, na
maior parte das vezes, eles ocorrem por falta de planejamento adequado, de planos de
contingência ou de análise de riscos e poderiam ser evitados.
Os procedimentos para produzir um programa de execução das atividades são re-
feridos no RBC (SANTOS; CARVALHO, 2006, p. 71) como programação do tempo e
contém os seguintes passos:
• detalhar os pacotes de trabalho em atividades;
• definir as relações de precedência e as durações das atividades;
• avaliar os respectivos recursos para cada atividade;
• definir a lista dos marcos;
• calcular as datas de início e término das atividades;
• sequenciar as atividades;
• comparar as datas atingidas, planejadas e presentes;
• elaborar novas previsões e ajustar o cronograma detalhado;
• atualizar os custos, os produtos parciais (entregas) e os recursos.
A programação do tempo se baseia em um plano de execução das atividades
de um projeto, o qual permite respeitar as datas-chave e os objetivos do projeto. Ela
identifica e incorpora, nesse plano, as fases do projeto, os pacotes de trabalho, as ati-
vidades e respectivas precedências, os marcos (ou milestones), as necessidades e dis-
ponibilidades de recursos, as limitações temporais e as restrições internas/externas.
Algumas questões desafiadoras para a gestão do tempo de um projeto são:

• Qual é o prazo de término previsto?
• Quais são as principais atividades do projeto?
• Quanto tempo duram as atividades?
• Quais são as relações de precedência das atividades?
• Como relacionar as atividades em um cronograma?
• Como recalcular e atualizar as estimativas de prazos?
• Quando ocorrem entregas de produtos parciais?
• Quais são os principais riscos relacionados com os prazos?
• Quais são os recursos atribuídos às atividades?
• Como controlar o cronograma e os prazos do projeto?
• Quais são os impactos, para os stakeholders, dos atrasos no projeto?
• Como recuperar um projeto atrasado?
Qualquer conjunto de técnicas, simples ou sofisticadas, destinadas a responder a
essas perguntas, contribui para a gestão do tempo em projetos.
4.1 Preparação do cronograma

Um cronograma consiste em uma representação que permite planejar, executar e
controlar os tempos (durações, folgas etc.) das atividades de um projeto.
4.1.1 Conceitos fundamentais e plano de gestão do tempo

Para estudar a gestão do tempo no gerenciamento de projetos (VALERIANO, 2005),
empregam-se as definições:
• Atividade − ação com início, duração e término bem definidos. Usualmente ela
utiliza um verbo para descrever um processo. Cada atividade possui nome, du-
ração e relações de precedências com outras atividades.
• Evento − acontecimento pontual no projeto. Associado a uma referência tempo-
ral ou data (a atividade lembra um filme; o evento, uma fotografia).
• Marco (ou milestone) − data de um evento de interesse, por exemplo, uma en-
trega de produto, o início/término de uma fase etc. Ele fixa uma data no tem-
po, sem relação com as durações das atividades do projeto.
• Precedência − ordem de execução de atividades sequenciais, por exemplo: a ati-
vidade A precede a atividade B; ou B sucede A.
No projeto de um novo produto, as várias atividades (pesquisar o cliente, definir seus desejos,
propor um protótipo etc.) são sequenciadas em função das suas precedências. Em um dia, no
futuro, ocorrerá um teste, que é um evento ainda sem data marcada. A data do teste é um dos
marcos do projeto.
4.1.2 Identificação e sequenciamento das atividades

Um primeiro desafio no estudo dos tempos de um projeto é a identificação das
atividades relevantes, capazes de descrever todo o projeto e definir seu término. Para
tanto, essas atividades necessitam ser relacionadas temporalmente e sequenciadas.
Identificação
O escopo de um projeto é decomposto em pacotes de trabalho nos níveis mais
inferiores da EAP. Esses pacotes de trabalho são depois decompostos em outros ní-
veis, ainda mais inferiores, chamados atividades. A execução das atividades de um pa-
cote de trabalho contribui para a entrega do produto do projeto.
A tabela a seguir exemplifica as atividades, as durações e as precedências do proje-
to de uma fábrica (as atividades são iguais aos pacotes de trabalho, por simplicidade).
Projeto de uma fábrica

Atividade Precedências Duração (semanas)
A. Projetar fábrica – 12
B. Escolher local ativ. A 8
C. Selecionar fornecedores ativ. A 4
D. Escolher pessoal ativ. A 3
E. Preparar local ativ. B 12
F. Fabricar gerador ativ. C 18
G. Preparar operações ativ. C 5
H. Instalar gerador ativ. E, F 4
I. Treinar operadores ativ. D, G 9
J. Obter licença ativ. H, I 6
Fonte: MONKS, 1991. (Adaptado).
A lista de atividades relevantes é o primeiro passo para a elaboração do cronogra-

ma detalhado do projeto.
Sequenciamento
O processo de sequenciamento das atividades de um projeto consiste em conec-
tar todas as atividades e os marcos já identificados, respeitando as relações de pre-
cedência e sucessão, bem como as durações das atividades e as datas determinadas
pelos marcos.
Um resultado do sequenciamento é o cronograma com as durações, as relações de

precedência das atividades e os marcos prédefinidos. O cronograma também identifi-
ca e documenta os relacionamentos entre as diversas atividades do projeto. O sequen
ciamento não é uma tarefa simples, mesmo para projetos com poucas atividades.
O leitor se surpreenderá com a complexidade da tarefa se tentar sequenciar apenas dez ou

doze atividades de uma viagem ao exterior.
No exemplo da tabela “Projeto de uma fábrica”, o sequenciamento resulta no dia-

grama da figura a seguir.
Sequenciamento de atividades: projeto de instalação de fábrica

E
B H
A C F J
G
D I
O desenho da figura anterior é um diagrama de rede para o projeto da instalação.
4.1.3 Estimação dos recursos das atividades

Atividades consomem recursos – por exemplo, materiais, trabalho de pessoas,
equipamentos, informações, entre outros. Deseja-se estimar os volumes desses recur-
sos e quando eles serão empregados; por exemplo, quantas horas de engenheiros, téc-
nicos e secretárias serão contratadas em cada semana de um projeto.
Várias técnicas ajudam a definir os recursos de um projeto, como:
• Estimativa bottom-up − parte dos níveis mais inferiores das atividades e pacotes
de trabalho para compor a lista de recursos totais para o projeto. Como ilustra-
ção, define-se o orçamento total do projeto em função de seus custos parciais.
• Analogia com outras atividades − baseia-se em estimativas análogas ou seme-
lhantes para estimar os recursos de uma atividade nova. Para esse fim, são úteis
bancos de dados de outros projetos e índices padronizados.
• Opinião de especialistas − especialistas conseguem estimar recursos de maneira
subjetiva com mais acurácia do que métodos quantitativos ou modelos matemáti-
cos. A exatidão dos modelos e métodos quantitativos depende muito da validação
deles, das incertas condições ambientais e da estimação de parâmetros.
A estimação de recursos gera listas que indicam os recursos necessários para cada
atividade: quando eles serão empregados, quanto já está disponível para o projeto e
quanto deve ser adquirido, principais fornecedores e condições para aquisição.
4.1.4 Estimação das durações das atividades

A duração total de um projeto depende especialmente das durações das ativida-
des individuais. Para estimar a duração total existem diversas técnicas, algumas delas
indicadas no PMBOK® (PMI, 2013) como:
• Estimativa de três pontos − baseia-se em três estimativas, a pessimista (tP),
a otimista (tO) e a mais provável (tM). Elas determinam a estimativa da ativi-
dade (tE). As distribuições mais usuais são a triangular e a Beta. Na primeira,
tE = (tP + tM + tO)/3 e, na segunda, tE = (tP + 4tM + tO)/6. Por exemplo, a instalação
de uma máquina usualmente consome 12 dias. Em situações muito favoráveis,
ela emprega 10 dias. Quando há falta de peças ou de pessoal, não é raro se es-
tender para 20 dias. A estimativa de três pontos fornece o valor de 78/6 = 13 dias.
• Estimativa paramétrica − baseia-se em dados históricos, combinados com pa-
râmetros do projeto. Por exemplo, a atividade “elaboração de relatório” pode
usar como parâmetros o número de páginas do relatório e o número de dese-
nhos para estimar o tempo do relatório do projeto.
• Opinião de especialistas − pessoas experientes na área de aplicação de um
projeto produzem boas estimativas de duração das atividades.
• Estimativa análoga − também emprega dados históricos de projetos seme-
lhantes. Ela fornece a duração ou o custo total do projeto a partir, apenas, de
algumas atividades-chave. Em projetos de balcões frigoríficos, algumas dimen-
sões já indicam o custo e o prazo de entrega do produto. É uma estimativa me-
nos precisa, porém rápida.
• Brainstorming e outras técnicas de decisão em grupo − podem ser empregadas
separadamente ou em complementação a outras estimativas. São especialmen-
te úteis para projetos inovadores, quando não há históricos semelhantes. Por
exemplo, projetos de produtos.
• Imposição de marcos − a duração resulta da imposição de data certa (por exem-
plo, uma entrega programada e inegociável). Nesse caso, impõe-se a necessida-
de de se manter a data “a qualquer custo”.
A escolha de uma ou outra técnica depende do orçamento e do tempo disponí-
veis. É comum o emprego de duas ou mais técnicas para confirmar estimativas.
4�2 Desenvolvimentos do cronograma

O cronograma representa a duração de todo o projeto e também as datas de iní-
cio e término de cada atividade, assim como as respectivas folgas. Ele é elaborado com
base nos dados e nas estimativas das atividades, indicados nos itens anteriores.
O cronograma é muito útil para a gestão do projeto porque permite:
• alterar atividades individuais e reavaliar a duração total do projeto;
• impor marcos, ou datas fixas para atividades do projeto;
• simular mudanças, com análises what if (e se);
• visualizar todas as atividades, ou grupos de atividades, com clareza;
• atribuir prazos, custos, recursos e responsabilidade às atividades;
• elaborar análise de sensibilidade nas atividades.
Quando elaborado de maneira interativa e dinâmica, o cronograma possibilita
monitorar o andamento do projeto e apontar necessidades de ajustes em cada ativida-
de. Por exemplo, se há um grande atraso no projeto, adota-se o paralelismo de ativi-
dades, que transforma atividades sequenciais em concomitantes ou paralelas.
4�2�1 Diagramas de barras e de marcos

Esses diagramas são empregados para representar o cronograma de um projeto.
Diagrama de barras
O diagrama de barras (gráfico de Gantt) mostra, sequencialmente, o nome de cada
atividade do projeto e a respectiva duração conforme a próxima figura. Ele fornece uma
visão genérica sobre o início e o término do projeto e suas atividades, assim como permi-
te análises do tipo what-if (simulação de mudanças e verificação dos impactos).
Um tipo particular do diagrama de barras é o diagrama interligado. Ele represen-
ta o relacionamento entre atividades (relações de precedência) na figura a seguir.
Diagrama de blocos interligados
Design Gráfi co: Carlos Henrique Stabile
A cada atividade de um diagrama de barras podem ser associadas informações

detalhadas do projeto, tais como custos, duração, disponibilidade de recursos etc.
Diagrama de marcos
O diagrama de marcos é análogo ao diagrama de barras, mas indica apenas iní-
cios e/ou términos das atividades. Ele não é tão informativo quanto o primeiro, nem
tão conhecido. Por vezes, emprega-se uma combinação de ambos em um só gráfico.
Diagrama de marcos – projeto de instalação de uma fábrica

Início Término
4�2�2 Diagramas CPM

O diagrama CPM é um tipo de diagrama de rede e representa, em um gráfico bi-
dimensional, as atividades do projeto e as relações de dependência entre estas. Três
dos tipos mais conhecidos desses diagramas são indicados na figura a seguir.
Tipos usuais dos diagramas de redes para projetos


Fonte: KERZNER, 2009. (Adaptado).
A figura a seguir indica um diagrama de rede representado por atividades nas setas,
denominado Método de Diagramação por Atividades (MDA).
Diagrama de rede – Representação por Atividades (MDA)
E=12
B=8
Design Gráfico: Rafael Crosewski

H=4
A=12 C=4 F=18 J=6
G=5
D=3 I=9
Ao contrário do diagrama de barras, aqui os comprimentos das setas não são pro-
porcionais às durações das respectivas atividades. No MDA, pode ser necessário criar
atividades fictícias, com duração zero – por exemplo, quando duas atividades possuem
uma mesma predecessora e uma mesma sucessora. Sem a variável fictícia, não seria
possível calcular as folgas e o caminho crítico com clareza.
Em um diagrama de rede, caminho crítico é o de maior duração entre todos os caminhos possí-
veis, considerando-se o intervalo que vai do início ao término do projeto.
Uma outra forma do diagrama de redes é definida com base no Método de

Diagramação por Precedências (MDP) da figura a seguir.
Diagrama de rede – Representação por Precedências (MDP)

O MDP armazena mais informações do que o do MDA e se presta melhor a apli-
cativos de software. Além disso, ele não necessita de atividades fictícias, como o MDA.
Suas informações são organizadas em blocos como ilustra a figura a seguir.
Bloco com informações sobre atividades nos projetos
Número da Pessoa
responsável Duração
atividade
Descrição da atividade
Data mais Data mais cedo

Folga total
cedo de início de término
Data mais tarde Data mais tarde

Folga livre
de início de término
O diagrama de rede fornece, mediante cálculos com os dados indicados na figura

“Diagrama de rede – Representação por Precedências (MDP)”, as seguintes informa-
ções (KANABAR; WARBURTON, 2012):
• Data mais cedo de início (DMCI) − calcula-se a MCI da atividade anterior mais
a duração D daquela. Havendo mais de uma atividade anterior, a maior DMCI
prevalece. Para a atividade 4.1, MCI = 0 + 12 = 12.
• Data mais cedo de término (DMCT) − é igual à MCI da atividade presente,

mais sua duração D. Para a atividade 4.1, MCT = 12 + 8 = 20.
• Data mais tarde de início (DMTI) − é a MTT da atividade presente menos sua
própria duração D. Para a atividade 4.1, MTI = 29 − 3 = 26.
• Data mais tarde de término (DMTT) − calcula-se a DMTT da atividade poste-
rior, menos a duração daquela. Havendo mais de uma atividade posterior, ado-
ta-se a menor DMCI. Para a atividade 2.1, DMTT = 16 – 4 = 12.
• Folga livre (FL) − é o período que uma atividade pode atrasar, sem que atra-
se a DMCI de qualquer atividade subsequente. Calcula-se como a DMCI da ati-
vidade posterior menos a DMCT da atividade presente. Para a atividade 4.1,
FL = 21 – 15 = 6.
• Folga total (FT) − é a diferença de tempo e entre o caminho crítico e outro ca-
minho não crítico do projeto. É o tempo que a atividade pode atrasar sem que
atrase o término do projeto. Calcula-se FT como a DMTI menos a DMCI de uma
mesma atividade. Para a atividade 4.1, FT = 26 – 12 = 14.
As folgas constituem indicadores úteis para o gerente de projetos controlar o
cronograma de um projeto e tomar decisões rápidas sobre desvios. Assim, se uma ati-
vidade tem folga livre = 6 meses, ela pode atrasar até 6 meses sem atrasar o projeto.
No caminho crítico, todas as folgas são nulas. Qualquer atraso nesse caminho implica
igual atraso na duração total do projeto.
O Método de Representação por Eventos (MDE) usa marcos para sequenciar um
projeto e mostrar suas entregas parciais. Ele é útil para orientar o cronograma em fun-
ção de datas específicas, ao invés de atividades, mas é menos usado do que os demais.
4.2.3 Diagrama PERT

Nos diagramas CPM, as durações das atividades parecem bem definidas. Contudo,
elas estão sujeitas a incertezas associadas às durações. Cronogramas com variáveis pro-
babilísticas podem fornecer resultados mais acertados.
Método PERT
No método CPM, definem-se as durações mais prováveis das atividades (é co-
mum que essas estimativas possuam folgas, por medida de segurança). O cronogra-
ma resultante dessas durações apresenta uma duração total determinística, única.
Contudo, considerando-se que a duração de cada atividade pode variar (para mais ou
para menos), pode-se associar a duração total do projeto a uma distribuição probabi-
lística. Daí decorrem diversos benefícios, por exemplo, uma análise de riscos baseada
em probabilidades. Essa é a principal vantagem do método PERT.
O método PERT (Program Evaluation and Review Technique) difere do CPM pelo
cálculo do tempo esperado (Te), para cada atividade (SANTOS, 2004). No PERT, Te é
calculado segundo a fórmula indicada na figura a seguir. A penúltima coluna mostra os
valores Te, e a última coluna representa as respectivas variâncias.
Método PERT – Exemplo clássico

Método PERT Atividade a m b Te �2
a + 4m + b
Projetar a fábrica 1-2 10 12 23 13,50 4,69 Te =
Escolher o local 2-3 2 8 36 11,67 32,11
6
Escolher o fornecedor 2-4 1 4 5 3,67 0,44
2
Escolher o pessoal 2-6 2 3 4 3,00 0,11 b–a
Preparar o local 3-5 8 12 20 12,67 4,00 σ =
2
6
Fabricar o gerador 4-5 15 18 30 19,50 6,25
Preparar o manual 4-6 3 5 8 5,17 0,69
Instalar o gerador 5-7 2 4 8 4,33 1,00
Treinar operadores 6-7 6 9 12 9,00 1,00
Licenciar a fábrica 7-8 4 6 14 7,00 2,78
As durações pessimistas usualmente são mais afastadas do valor mais provável

do que as otimistas. Portanto, é natural que os valores Te sejam tipicamente maiores
do que aqueles indicados na tabela “Projeto de uma fábrica”, apresentada anterior-
mente. A nova duração total do projeto agora passa a 49,17 semanas. Examinando-se
os caminhos possíveis para as atividades do projeto, nota-se que o caminho crítico mu-
dou (vide figura a seguir).
Caminhos Tempos (semanas)

A: 1-2-3-5-7-8 13,50 + 11,67 + 12,67 + 4,33 + 7,00 = 49,17
B: 1-2-4-5-7-8 13,50 + 3,67 + 19,50 + 4,33 + 7,00 = 48,00
C: 1-2-4-6-7-8 13,50 + 3,67 + 5,17 + 9,00 + 7,00 = 38,34
D: 1-2-6-7-8 13,50 + 3,00 + 9,00 + 7,00 = 32,50
z=7,3
Te=49,17
σ=6,7
Te ≅ 49 Tx=58
Design Gráfi co: Rafael Crosewski
3
12,67 Tx(50%) = 49 m
Tx(90%) = 58 m
11,67 5 4,33 Tx(97%) = 61 m
19,50
13,50 3,67 7,00
1 2 4 7 8
5,17
3,00 9,00
6
Caminhos no diagrama de rede e duração total – Método PERT�

A diferença mais notável entre esse método e o anterior está em seu tratamen-
to probabilístico dos dados. No PERT, consegue-se associar uma previsão a sua proba-
bilidade de ocorrência. Por exemplo, a probabilidade de o prazo total exceder Te = 49 é
50%; ou seja, a metade à direita da curva normal da figura “Caminhos no diagrama de
rede e duração total – Método PERT”. Quanto maior é a data fixada para o término do
projeto, maior é a certeza de ele não atrasar (contudo, prazos excessivamente longos
tornam o projeto inviável).
4.2.4 Linha de base do cronograma

A linha de base do cronograma é a versão aprovada de um cronograma, que so-
mente pode ser alterada mediante procedimentos formais, e que é empregada como
referência em comparação com resultados medidos ao longo do projeto (PMI, 2013).
A linha de base serve tanto para controlar atrasos no projeto como para monito-
rar acelerações do cronograma. Ela é validada e aceita pelos stakeholders competen-
tes. Uma mudança no cronograma pode alterar:
• a linha de base do próprio cronograma;
• a linha de base dos custos estimados;
• o escopo do produto;
• a linha de base dos diversos tipos de recursos;
• a qualidade dos produtos e das entregas predefinidas;
• os vários riscos envolvidos na gestão do projeto;
• a percepção dos stakeholders sobre os produtos.
Mudanças na linha de base do cronograma podem causar impactos financeiros,
redimensionamento dos recursos e onerosas revisões nos contratos dos projetos – mo-
tivos pelos quais busca-se evitá-las ao máximo.
4.3 Controle do cronograma

Entre as mudanças que ocorrem em qualquer projeto, alterações no cronograma
são talvez as mais frequentes. O cronograma depende de todas as atividades de um
projeto e, assim, varia em função de cada alteração individual. Os efeitos das altera-
ções podem ser amenizados, e até compensados, se houver um adequado controle do
cronograma. Por exemplo, um atraso na preparação para a concretagem de uma obra
não é grave, se previsto antecipadamente e controlado; mas implica grande prejuízo se
o caminhão com cocreto não for avisado a tempo.
O objetivo do controle é medir os progressos e os desempenhos do projeto, com-
parar os resultados com a linha de base e adotar as ações necessárias para corrigir
problemas existentes ou se prevenir contra futuros problemas. Essa função se aplica
analogamente ao controle do cronograma do projeto (IPMA, 2006).
A base para o controle do cronograma é o próprio cronograma. A partir dele, po-

de-se elaborar tabelas com indicações de, por exemplo: prazos previstos, alterações
previstas, prazos novos, ações necessárias, implicações para o projeto, impactos no
negócio do projeto, pessoa responsável, registro das alterações. Essas tabelas podem
ser formatadas em função das necessidades de cada projeto.
No projeto de corridas de rua, são necessárias diversas aprovações da administração municipal

(Detran, Polícia Militar, Secretaria do Meio Ambiente etc.). Um bom controle do cronograma
dessas aprovações diminui o risco de cancelamento do evento.
4.3.1 Papel do controle

O controle de um projeto se baseia em seus objetivos, metas, planos e contra-
tos. Segundo o ICB3 (IPMA, 2006), ele mede o progresso e o desempenho do proje-
to, compara os resultados com as linhas de base (baselines) e adota ações corretivas e
preventivas.
O controle do tempo de um projeto emprega como variáveis de interesse datas
e durações de atividades. Como em projetos também vale o conceito “tempo é dinhei-
ro”, desvios no tempo implicam necessariamente efeitos (usualmente negativos) nos
custos do projeto. Esses desvios não ameaçam apenas os custos, mas também a qua-
lidade, o escopo e os riscos associados ao produto e às próprias atividades do projeto.
O papel do controle do tempo em um projeto inclui os atrasos no cronograma,
bem como os objetivos do produto e da solução do problema do projeto.
Uma montadora automotiva paga a seu fornecedor de chicote elétrico 12% além do preço mí-
nimo do mercado. Porém, o fornecedor assume pagar o enorme custo da parada de linha da
montadora, em caso de atraso na entrega. Chicotes não podem ser instalados como retraba-
lho; eles param a linha de montagem.
4.3.2 Análises de desempenho

A análise de desempenho de um projeto é análoga aos controles empregados na
navegação de um barco ou de uma aeronave em uma viagem. Nesse sentido, ela deve:
• estabelecer mecanismos para monitorar os resultados alcançados em relação
àqueles programados;
• avaliar a viabilidade de atingir as metas e objetivos pré-programados;
• definir ações para corrigir desvios das metas e dos objetivos – sejam esses des-
vios já ocorridos ou previstos para ocorrer.
O desempenho do projeto se avalia em função de a solução gerada conseguir sa-

tisfazer aos objetivos do projeto ao seu término. Para a gestão do tempo, isso implica
verificar sistematicamente a situação (status) presente e a futura do cronograma, bem
como prevenir ou corrigir desvios detectados.
Por exemplo, em projetos de navios, as destinações e o detalhamento dos espa-
ços (parte passageiros, parte granel, parte container etc.) dependem fortemente das
demandas a que os navios deverão atender. Alterações nas demandas ao longo do pro-
jeto influenciam o escopo e o cronograma da construção e ainda exigem ações (pre-
ventivas e corretivas) para manter a programação de entregas.
Os controles do desempenho são classificados no PRINCE2® (OGC, 2009) como:
• Controle baseado em eventos: orienta-se por marcos ou datas-chave. Por
exemplo, a data de término da fundação de uma casa.
• Controle baseado em atividades: orienta-se por intervalos em que se desen-
volvem atividades. Por exemplo, o período de construção da fundação. O foco
nas atividades é afim com o monitoramento, enquanto o foco nos eventos é
afim com o controle (tomada de decisões).
No exemplo do projeto de navios, um diagrama de marcos indica as datas-chave
das entregas parciais, necessárias para liberar pagamentos e cumprir os contratos. Já
um diagrama de barras ajuda a controlar as durações e recursos previstos para cada
atividade – e, eventualmente, tomar decisões para corrigir e prevenir desvios.
4.3.3 Gestão de mudanças e simulações

Mudanças estão sempre presentes nos projetos e causam impactos imediatos
no seu desempenho e sucesso. Portanto elas precisam ser administradas de manei-
ra sistemática. Segundo o RBC (2006), “no controle das modificações em um projeto
se identificam, descrevem, avaliam, aprovam, realizam e verificam todas as modifica-
ções”. O PRINCE2® (OGC, 2009) enfatiza a necessidade de se realizarem correções e
prevenções nos projetos devido às mudanças.
O projeto de uma feira de profissões previa a visita de 1.000 pessoas por dia. Com uma inespe-
rada aceitação das faculdades locais, a expectativa subiu para 16.000 pessoas/dia. Foi necessá-
rio adiar três meses o evento para poder adotar ações adequadas para essa grande feira.
Na gestão do tempo de um projeto, mudanças reais (e mesmo a perspectiva de

mudanças) impõem duas questões:
• (Q1) Qual é a situação real do projeto em relação aos planos para a data D?
Resposta: Compara-se a linha de base do tempo com as entregas planeja-
das para a data D. Na construção de um muro de 200 metros, está prevista a
entrega de 100 metros de muro em 5 meses; mas até essa data foram construí-
dos somente 90 metros.
• (Q2) Qual é a data provável de entrega, estimada na data D, do produto final
do projeto?
Resposta: Projeta-se a nova entrega com base nos dados da data D. No projeto
do muro, houve atraso de 10 metros. Estima-se, simplificadamente, que em 10
meses serão 20 metros. Isso deve atrasar o projeto em 10% do tempo. Ou seja,
em um mês.
Nas mudanças das durações de atividades é necessário revisar todo o cronograma
para verificar o impacto do conjunto das mudanças nos prazos. Contudo, há atrasos
em atividades que não causam atraso no prazo total do projeto.
Mudanças esperadas nas durações de atividades podem ser estudadas mediante
simulações. Um exemplo é ilustrado no projeto da figura a seguir.
Simulação de cenários e seus efeitos nos prazos (em semanas)

Cenário Ativ.1 Ativ.2 Ativ.3 Ativ.4 Ativ.5 Ativ.6 Ativ.7 Ativ.8 Ativ.9 Ativ.10 Ttot
A +4s +3s +4s
B +6s +5s -3s +5s +9s +12s
C +6s -1s +12s -2s +10s
D -2s +5s +6s +5s
Nesse exemplo, cada tempo total (Ttot) do projeto resulta de um cronograma ela-
borado com base nas mudanças impostas pelos cenários A, B, C e D. O emprego de
aplicativos de software na simulação de cenários para cronogramas é essencial.
4.3.4 Aceleração de projetos

Acelerar um projeto, ou comprimir um cronograma, significa antecipar a data de
entrega do produto final ou de entregas parciais. Algumas razões para isso podem ser:
• compensar atrasos passados;
• antecipar o lançamento de um produto;
• corrigir falhas de planejamento.
Diversos tipos de ações isoladas podem ajudar a acelerar um projeto: a contrata-
ção de mais recursos, a eliminação de atividades, a restrição do escopo etc. Contudo,
somente com a análise conjunta das atividades do projeto é que se pode determinar a
compressão real em todo o cronograma do projeto.
Um procedimento útil para comprimir cronogramas é a simulação. Em particular, a
simulação por enumeração, que consiste em propor cortes possíveis nos prazos das ativi-
dades e então verificar os efeitos no projeto final. A figura a seguir ilustra o procedimento.
Simulação por enumeração

Ativ. Custos variáveis para acelerar (por dia) Máx.
A R$ 4.000,00 por dia, até 2 dias 2
B R$ 3.500,00 (1.º dia), R$ 8.000,00 (2.º dia) 2
C Nenhuma redução possível 0
D R$ 4.500,00 (1.º dia), R$ 11.000,00 (demais dias) 3
Redução Soluções possíveis (redução de dias em A; B; C; D) Menor custo*

0 dia 0; 0; 0; 0*/ 1; 0; 0; 0/ 2; 0; 0; 0 R$ 0,00
0; 0; 0; 1*/0; 0; 0; 2/ 0; 0; 0; 3/ 0; 1; 0; 0/ 0; 1; 0; 1/ 0; 1; 0; 2/ 0; 1; 0; 3/ 0; 2;
1 dia R$ 4.500,00
0; 0/ 0; 2; 0; 1/ 0; 2; 0; 2/ 0; 2; 0; 3/ 1; 0; 0; 1/ 1; 1; 0; 0/ 2; 0; 0; 0/ 2; 1; 0; 0
1; 0; 0; 2/ 1; 0; 0; 3/ 1; 1; 0; 1*/ 1; 1; 0; 2/ 1; 1; 0; 3/ 1; 2; 0; 0/ 1; 2; 0; 1/ 1; 2;
2 dias R$ 12.000,00
0; 2/ 1; 2; 0; 3/ 2; 0; 0; 2/ 2; 1; 0; 1/ 2; 2; 0; 0
3 dias 2; 0; 0; 3*/ 2; 1; 0; 2/ 2; 1; 0; 3/ 2; 2; 0; 1/ 2; 2; 0; 2/ 2; 2; 0; 3 R$ 34.500,00
Se os custos fixos do projeto são R$ 5.000,00 por dia, acelerar um dia econo-
mizaria R$ 500,00 (R$ 4.500,00 – R$ 5.000,00), dois dias gastam mais R$ 2.000,00
(R$ 12.000,00 − R$ 10.000,00) e três dias mais R$ 19.500,00 (R$ 34.500,00 − R$ 15.000,00).
Embora exija muitos cálculos, esse procedimento é rápido e simples. Ele fornece
uma avaliação razoável, porém não exata, do custo da aceleração do projeto.
Um procedimento análogo, empregado no mesmo exemplo, consiste em pré-
-analisar as várias possibilidades de cortes de prazos e somente considerar aquelas
possíveis. Em lugar de analisar as 36 soluções apresentadas na figura “Simulação por
enumeração”, já se eliminam aquelas inviáveis (por exemplo, reduzir só o prazo da ati-
vidade A não acelera o projeto). Essa alternativa envolve menos cálculos, porém mais
verificações lógicas.
4�4 Abordagens especiais e aplicativos de software

Os fundamentos do gerenciamento do tempo, apresentados anteriormente, são
agora suplementados com quatro tópicos mais avançados, discutidos a seguir.
4�4�1 Software de gestão de projetos

O gerenciamento de projetos conta com competências sociais (soft skills) e
competências técnicas (hard skills). As primeiras se referem a atributos e compe-
tências pessoais que facilitam a relação com outras pessoas e assim proporcio-
nam benefícios (frequentemente, no sentido profissional) e são mais difíceis de
serem padronizadas e até mesmo avaliadas. Já as competências técnicas se referem
a habilidades e a conhecimentos adquiridos mediante qualificação e capacitação.
Elas têm sido sistematizadas por meio de métodos, ferramentas técnicas e heurísticas,
bem como transformadas em aplicativos de software.
Tarefas que mais se beneficiam com o emprego de aplicativos de software para
gerenciamento de projetos são, por exemplo (algumas disponíveis apenas em aplicati-
vos sofisticados):
• agendamentos de tarefas;
• alocação de recursos;
• coleta, organização e distribuição de informações;
• diversas representações gráficas de cronogramas e diagramas;
• calendários múltiplos;
• comparação entre datas planejadas e datas reais;
• simulação de mudanças no cronograma e análise what-if;
• análises de custo e de variações;
• otimizações de recursos, prazos e custos;
• análise on-line de alternativas para recuperação e aceleração;
• sistemas de alerta antecipados;
• alinhamento de objetivos dos projetos com os da organização;
• atribuição de custos a atividades;
• atribuição de responsabilidades a atividades;
• análise de multiprojetos (portfólios, programas etc.);
• compartilhamento de recursos entre projetos distintos;
• representação gráfica de tendências;
• interfaces para outros sistemas;
• arquivo de linhas de base de custos, prazos, escopo, riscos etc.;
• emissão de relatórios de prazos, custos, recursos e responsabilidades.
Os aplicativos de gerenciamento de projetos beneficiam o planejamento, a orga-
nização e o controle dos recursos dos projetos. Outra vantagem que eles apresentam é
a facilidade para rapidamente atualizar dados, diagramas e relatórios em caso de mu-
danças no projeto (e projetos mudam constantemente).
Os aplicativos comerciais podem ser classificados resumidamente em:
• Aplicativos pessoais: apresentam funcionalidades básicas (por exemplo, tare-
fas, calendário, prazos) e são empregados por um usuário ou um pequeno nú-
mero de usuários.
• Aplicativos colaborativos: apresentam funcionalidades mais elaboradas (por
exemplo, controles de acesso, compartilhamento de documentos, proteção em
vários níveis, atualizações com várias entradas, participação em fóruns etc.).

São usualmente instalados em redes ou em nuvens.
• Aplicativos integrados: conseguem se vincular a outros sistemas da organiza-
ção (ERP, PLM, CRM, sistemas de compra etc.). Compartilham protocolos de
comunicação com outros sistemas.
Alguns critérios de escolha do aplicativo envolvem custos da aquisição, custo da
manutenção, capacidade do software, lógica do software, facilidade para trabalhar em
rede ou integrado, tipos de relatórios etc.
4.4.2 A corrente crítica

Na estimativa de durações de atividades, é comum se adicionar “folga” ou “gor-
dura” às atividades de um projeto. A justificativa é que, se algum imprevisto ocorrer, a
atividade poderá usar essa folga para as correções sem atrasar o prazo prometido. Mas
a prática de atribuir folgas às atividades traz impactos negativos para o prazo total do
projeto, pelos seguintes motivos:
• Lei de Parkinson − o trabalho se expande e tende a usar todo o tempo dispo-
nível para sua realização. Consequência: uso excessivo de recursos. Exemplo:
para uma atividade de 12 semanas, será estimado um prazo de 14 semanas,
por segurança. Mesmo se a atividade puder terminar em 12 semanas, ela não
será entregue antes das 14 semanas.
• Síndrome do Estudante (procrastinação) − o estudante adia o trabalho até o
último momento possível. Consequência: qualquer imprevisto vai atrasar a ati-
vidade. Exemplo: ao se solicitar 14 semanas para a atividade, sabe-se que há 2
semanas de folga. Então se inicia a atividade na semana 3, para usar a folga já
de início; qualquer imprevisto provocará atraso.
• Multitarefa − a tarefa é dividida e executada em partes separadas. Conse-
quência: perda de energia e recursos para mudar de uma tarefa para outra.
Exemplo: Duas tarefas, A e B, divididas em três partes cada, são realizadas as-
sim: A1-B1-A2-B2-A3-B3. Mas A e B perdem menos recursos se forem realizadas
assim: A1-A2-A3-B1-B2-B3.
Os passos básicos para o emprego da corrente crítica são:
• construir a rede do projeto;
• determinar a duração total:
• estimar o tempo de cada atividade com a respectiva segurança;
• retirar todas as seguranças, ou usar os “tempos secos”;
• incluir no final uma segurança total (pulmão do projeto), igual a 50% da
soma das seguranças no caminho crítico do cronograma.
Um exemplo ilustrativo é mostrado na figura a seguir.
Ilustração da corrente crítica

44 12/2=6

10 10 16 8 8 12
20 16 6
16 16 12 12
Ttot=56 Ttot=50
Os tempos das atividades, com as respectivas seguranças iniciais, resultam em

uma duração total de 56 semanas. No lado direito, os tempos secos totais resultam em
uma duração de 44 semanas. Adicionando-se metade da folga ao final do cronograma
(6 semanas), o tempo total resulta em 50 semanas (inclusive com uma folga de 6 se-
manas no final, que é o pulmão do projeto ou buffer do projeto).
A figura a seguir representa, esquematicamente, a distribuição de um recurso es-
casso no projeto. Como esse recurso é único, ele pode ser usado somente por um pro-
jeto de cada vez. Assim, cria-se um pulmão de capacidade para esse recurso.
Prazos estimados em função da probabilidade de sucesso

O controle dos prazos de um projeto baseia-se no controle dos pulmões (figura a

seguir): se estes são “invadidos”, é porque o projeto enfrenta perigo de atraso.
Controle dos pulmões de diversos projetos

Esses conceitos básicos ilustram os princípios da corrente crítica. Algumas van-
tagens do método são: menor tempo total do projeto, ambiente colaborativo; melhor
distribuição dos recursos entre projetos; uso mais uniforme dos recursos ao longo do
projeto; menor risco de atraso; facilidade para controlar o cronograma e maior trans-
parência no controle, quanto à situação real do projeto.
Para aprofundar o assunto, leia A Corrente Crítica, escrito por E. Goldratt (2005).
4.4.3 Métodos ágeis

O gerenciamento ágil de projetos (APM, de Agile Project Management) trata as
gestões do escopo e do tempo de maneira um pouco distinta da tradicional. Ele é uma
abordagem incremental e interativa para gerenciar projetos em situações tais como:
muitas mudanças, incertezas, interações, prazos curtos, recursos escassos, competiti-
vidade ou inovações radicais. O APM se aplica a todos os tipos de projetos.
Segundo Amaral et al. (2011) os princípios da APM, que compõem o manifesto ágil
para o gerenciamento de projetos, podem ser descritos assim:
• prioridade na satisfação do cliente, com criação de valor pelo projeto;
• foco principal na visão do produto, em vez de nas atividades do projeto;
• aceitação de mudanças no projeto, em todas as suas fases;
• curto período de desenvolvimento do produto;
• entregas parciais em curtos espaços de tempo;
• trabalho colaborativo de desenvolvedores e gestores;
• motivação do pessoal de projetos, mediante delegação e autonomia;
• simplicidade para o produto e as atividades do projeto;
• autogestão das equipes.
No APM, os processos são definidos, segundo Highsmith (2004), pelas seguintes fases:
• Criação da visão: definir a visão e o escopo, bem como a comunidade e a equi-
pe do projeto.
• Especulação: desenvolver um esboço baseado nas funcionalidades, nos marcos
e no plano de interação, para realizar as entregas conforme a visão.
• Exploração: criar funcionalidades em curto espaço de tempo, constantemente
procurando reduzir os riscos e incertezas do projeto.
• Adaptação: reavaliar os resultados alcançados, a situação atual e o desempe-
nho da equipe do projeto e proceder às adaptações necessárias.
• Encerramento: concluir o projeto, disseminar as lições aprendidas principais e
comemorar.
A gestão de um projeto na abordagem APM enfoca primordialmente o produto,
em lugar das atividades do projeto, bem como o valor para os stakeholders, em lugar
de metas predefinidas. Ela se aplica melhor a projetos de inovações mais radicais do
que a de melhoramentos incrementais do produto.
A abordagem ágil tem relação imediata com o cronograma do projeto, uma vez
que encurta o período de desenvolvimento do produto e evita retrabalhos.
4.4.4 Perspectivas e tendências

A gestão dos tempos em projetos tem se beneficiado largamente das novas tec-
nologias e formas de organizações do trabalho.
No passado, quando os diagramas de rede eram elaborados manualmente, ape-
nas algumas dezenas de atividades consumiam muitas horas de análise e tentativas
manuais. Com o desenvolvimento dos aplicativos de software, esse trabalho foi muito
simplificado e suas potencialidades expandidas.
Hoje em dia, mesmo aplicativos mais modestos são capazes de organizar os crono-
gramas, associá-los a custos e recursos, simular alternativas, permitir correções rápidas e
até otimizar alternativas. Elementos de inteligência artificial, programação matemática,
sistemas de apoio à decisão, trabalho colaborativo à distância, comunicação via internet
e open innovation, entre outras disciplinas, estão presentes (muitas vezes, ocultos) nos
modernos aplicativos de gerenciamento de projetos.
Uma Secretaria de Obras enfrentava a falta de transparência no controle dos cronogramas de

seus projetos. Muitos relatórios não eram fiéis à realidade das obras. Com a aerofotogrametria
e a postagem na internet em tempo real, ela permitiu que qualquer pessoa pudesse acompa-
nhar o andamento das obras.
Referências
AMARAL, D. C. et al. Gerenciamento Ágil de Projetos: aplicação em produtos
novadores. São Paulo: Saraiva, 2011.
AMARAL, J. A.; SBRAGIO, R. A. A Dinâmica do Projeto: uma visão sistêmica das
consequências de ações gerenciais. São Paulo: Scortecci, 2003.
HEDEMAN, B. et al. Project Management Based on PRINCE2®: an introduction.
HIGHSMITH, J. Agile Project Management. Boston: Adison Wesley, 2004.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK®). Toronto: Kevin
Brennan, 2009.
KANABAR, V.; WARBURTON, R. D. Gestão de Projetos. São Paulo: Saraiva, 2012.
2012.
2009.
MAXIMIANO, A. C. A. Administração de Projetos: como transformar ideias em
resultados. São Paulo: Atlas, 1997.
MONKS, J. Administración de Operaciones. 2. ed. McGraw Hill, 1991. Managing
Successful Projects with PRINCE2®. TSO, 2009.
PMI – PROJECT MANAGEMENT INSTITUTE. Um Guia do Conhecimento em Geren-
ciamento de Projetos: (guia PMBOK®). 4. ed. Newtown Square, PA: PMI, 2008.

VARGAS, R. Gerenciamento de Projetos. 6. ed. Rio de Janeiro: Brasport, 2005.
5 Custos
Todos os projetos envolvem custos. Tipicamente, esses custos são expressos em
unidades monetárias. Contudo, projetos também podem incorrer em custos não mone-
tários, tais como trabalho voluntário e doações em espécie. Em qualquer um dos ca-
sos, um dos principais objetivos do gerenciamento do projeto é manter os custos tão
baixos quanto possível (CARVALHO; RABECHINI, 2011).
A construção de um templo religioso tem custos de materiais, pagos monetariamente com

doações e fundos da Igreja. Contudo, a construção também conta com o trabalho voluntário
dos fiéis e algumas doações de materiais.
Os conceitos apresentados neste capítulo referem-se aos custos monetários,

que, por sua vez, também podem ser adaptados para contabilizar os custos não mone-
tários – ou os equivalentes monetários desses custos.
Ao lado dos fatores escopo, tempo, qualidade e riscos (OGC, 2009; HEDEMAN,
2005), os custos definem as metas típicas de um projeto. Em muitos projetos, os cus-
tos são o principal fator de viabilidade ou inviabilidade e determinam a decisão final
entre as soluções alternativas do projeto. Em casos menos frequentes, os custos po-
dem assumir um papel secundário – por exemplo, em projetos emergenciais, projetos
com riscos de vida, projetos de inovação radical etc. De um modo geral, a preocupação
com os custos em um projeto se refere mais à eficiência do empreendimento (fazer
barato), e menos à eficácia (conseguir fazer de fato).
5.1 Estimação dos custos

Projetos incorrem em custos para pagar os recursos de que necessitam: mate-
riais, pessoal, serviços contratados, aluguéis diversos, informações, equipamentos,
direitos de uso, financiamento etc. Estimar os custos significa prever os custos dos re-
cursos que serão empregados para completar todas as atividades do projeto.
O processo de estimativa dos custos é um investimento para o projeto. Quanto
mais acurada a estimativa, mais caro ela pode custar; porém mais problemas e surpre-
sas desagradáveis ela pode evitar. Diversos projetos não conseguem contar com uma
boa estimativa de custos (por exemplo, o desenvolvimento de uma nova vacina) por-
que os resultados são incertos. Já outros projetos possuem custos muito previsíveis
(por exemplo, contratos de serviços de limpeza). Em cada um desses casos, existe uma
medida razoável do investimento que se deve fazer com a estimativa dos custos.

Algumas modalidades típicas de custos (ROZENFELD, 2006):
• Custos fixos: não variam em função da quantidade produzida em um sistema
de produção. Por exemplo, o aluguel, em uma fábrica de móveis.
• Custos variáveis: variam em função da quantidade produzida. Por exemplo, os
custos das peças pro-duzidas, descontados os custos fixos.
• Custos diretos: são atribuídos diretamente a cada tipo de produto. Por exem-
plo, os puxadores do móvel A (somente este móvel usa puxador).
• Custos indiretos: não podem ser atribuídos a um produto específico. Por
exemplo, quatro tipos de móveis usam uma mesma serra de fita.
• Target cost (custo alvo): custo de referência para o produto, o qual não pode
ser ultrapassado e que orienta o desenvolvimento do produto.
Em projetos, existem níveis de tolerância aceitáveis quanto às estimativas dos cus-
tos. A Association for Advancement of Cost Engineering International emprega as seguin-
tes tolerâncias para a construção civil e engenharia, em função da fase do projeto:
• fase conceitual:......................50% abaixo, 100% acima;
• fase viabilidade:.....................30% abaixo, 50% acima;
• fase preliminar:......................20% abaixo, 30% acima;
• fase definitiva:.......................15% abaixo, 20% acima;
• fase de controle:....................10% abaixo, 15% acima.
Tolerâncias não constituem “permissão para errar”, pois o objetivo das previsões
continua sendo atingir valores mais próximos possíveis das metas.
5.1.2 Plano da gestão dos custos

O plano de gerenciamento dos custos descreve como os custos do projeto serão
planejados, estruturados e controlados. Alguns dos principais itens desse plano podem
ser descritos como:
1. Objetivo do Plano de Gerenciamento dos Custos
(Descrever o objetivo do plano.)
2. Método do Gerenciamento de Custos
(Identificar os componentes do plano de gerenciamento dos custos.)
3. Processos do Gerenciamento de Custos
(Detalhar processos e as respectivas ferramentas gerenciais para:
• estimar os custos;
• determinar o orçamento;
• controlar e monitorar os custos do projeto.)
4. Responsabilidades da equipe
(Listar as responsabilidades, competências e autoridade relacionadas com os
custos.)
5. Lições aprendidas
(Identificar, analisar e organizar as lições aprendidas com o projeto.)
6. Documentação
(Descrever, catalogar e armazenar os documentos padronizados para as aquisições.
Para cada documento, informar: número, nome, descrição e modelo padrão.)
Em função das necessidades específicas do projeto, outras informações relevan-
tes podem ser incorporadas ao plano. Por exemplo, os projetos de eventos interna-
cionais exigem a descrição detalhada das metodologias de medição de custos, já que
podem captar recursos de vários países, empregar diversas moedas e prestar contas
para diferentes sistemas tributários.
5.1.3 Técnicas básicas de estimação de custos

A estimação dos custos consiste na avaliação dos custos prováveis dos recursos e
demais despesas que serão necessárias para realizar uma atividade, um conjunto de ati-
vidades de um projeto ou até mesmo todo o projeto. Algumas das técnicas usuais são
(PMI, 2013):
• Opinião de especialistas – emprega opiniões, tanto objetivas quanto subjeti-
vas, de profissionais competentes e experientes na área do projeto.
• Estimativa bottom-up – parte dos níveis mais inferiores das atividades e paco-
tes de trabalho para compor a lista de recursos totais para o projeto. No proje-
to de uma festa, o custo total é a soma de todos os custos parciais estimados.
• Estimativa top-down – atribui um custo global para o projeto, o qual é pos-
teriormente detalhado até as atividades para verificar a viabilidade (ou sugerir
cortes). No caso do projeto da festa, a verba disponível é R$ 50.000,00, e não
pode mudar.
• Estimativa paramétrica – emprega parâmetros conhecidos (até publicados)
para estimar os custos de um trabalho. No projeto da festa, o custo de alimen-
tação por pessoa e o custo horário da banda são parâmetros úteis.
• Orçamentos de fornecedores – solicita cotação de fornecedores para aquisi-
ções de bens e serviços do projeto (compra, aluguel etc.). Também é útil para
estimar os custos de recursos da própria organização do projeto.
• Decisões em grupo – abrange diversas técnicas de bases subjetivas, tais como
brainstorming, Delphi, grupo focal, painel especialista etc.
• Estimativa de três pontos – emprega uma estimativa otimista (Co), uma pessi-
mista (Cp) e uma mais provável (Cm), para calcular o custo estimado (Ce). Assim,
Ce = (Co + Cm + Cp) / 3 (distribuição triangular) ou Ce = (Co + 4Cm + Cp) / 6 (distri-

buição Beta). Esta última é empregada no Método PERT. No projeto da festa,
o custo provável da alimentação será R$ 72,00 por pessoa. A depender de ne-
gociações, ele poderá cair para R$ 66,00; por outro lado, poderá passar a R$
90,00 no dia da festa. A estimativa é R$ 444,00 / 6 = R$ 76,00.
• Estimativa análoga – emprega valores baseados em projetos anteriores que
sejam semelhantes ao projeto atual para estimar os custos (parciais ou total)
deste. É uma técnica preliminar, econômica, porém com resultados menos
precisos.
Não é raro que seja empregada mais de uma técnica de estimação para confir-
mar resultados e oferecer mais segurança na estimativa dos custos. Havendo discrepân-
cia entre os custos obtidos com técnicas diferentes, é possível: (1) refinar as estimativas
com mais investimento de tempo (e dinheiro), (2) empregar outras técnicas para reforçar
uma das estimativas ou (3) calcular uma média ponderada dos valores encontrados, com
maior peso para aquelas técnicas consideradas mais confiáveis.
5.1.4 Técnicas especiais

No orçamento de projetos, muitas vezes, são esquecidos ou ignorados custos im-
portantes. Essa é uma das causas do surgimento de sobrecustos, mais tarde. Alguns
itens especiais de custos, que devem ser agregados de alguma forma nos custos do
projeto, são os seguintes:
• Custos dos riscos: riscos geram custos, só que associados a probabilidades.
Uma obra com 10% de probabilidade de pagar uma multa de R$ 80.000,00
deve provisionar R$ 8.000,00 como custo deste risco. Embora esse procedi-
mento pareça óbvio, não é frequentemente adotado.
• Custos da não qualidade: referem-se a danos causados ao projeto ou à sociedade
pela falta de qualidade. No projeto de uma máquina, por exemplo, provavelmen-
te R$ 4.000,00 serão gastos com reparos (estimativa histórica) no primeiro ano.
Também são esperados danos ambientais de R$ 3.000,00.
• Custos de responsabilidades: representam os danos causados pelo projeto a
terceiros. Um projeto de construção civil pode provocar rachaduras em casas
vizinhas, danificar a rede elétrica local ou causar barulho extremo.
• Custos de perda de imagem: referem-se a perdas decorrentes de danos à ima-
gem da organização ou pessoa responsável pelo projeto. Um projeto que em-
pregue trabalho infantil trará enormes danos à imagem da empresa.
Os cálculos desses custos menos usuais podem envolver técnicas específicas para
cada situação. Por exemplo, as perdas decorrentes da utilização de trabalho infantil
em um projeto incluem campanhas publicitárias milionárias e até a reestruturação da
empresa, no intuito de tentar reverter as perdas monetárias e não monetárias.
5.2 Elaboração do orçamento

Na gestão dos custos de um projeto, interessa estimar, primordialmente, o custo
total ao final e os custos em cada data importante do projeto. De posse desses dados
– ou estimativas – pode-se acompanhar o desenvolvimento do projeto e efetuar as cor-
reções necessárias até seu encerramento bem sucedido. A representação dos custos
do projeto ao longo de seu ciclo de vida constitui a linha de base dos custos do projeto,
que é uma importante referência para o controle dos custos.
5.2.1 Papel do orçamento

A função da orçamentação do projeto é estabelecer uma linha de base dos custos
para orientar o controle de custos ao longo do ciclo de vida do projeto e permitir que
ele respeite as restrições dos custos planejados sem prejuízo para as demais metas,
tais como a qualidade do produto, os prazos, o escopo, os riscos etc.
O projeto de uma cerimônia pública conta com um orçamento fixo e limitado. Ao longo do
projeto, é crucial verificar se a estimativa dos custos ao término será respeitada. Eventuais
desvios indicam a necessidade de ações corretivas imediatas, pois não será possível contar
com recursos adicionais.
Um orçamento realista e bem atualizado pode fundamentar decisões importan-

tes, como o cancelamento do projeto, a captação de recursos adicionais e até mesmo a
destinação de recursos excedentes.
É uma das funções do gerente de projetos estimar e controlar o orçamento de
seus projetos, bem como alinhá-lo com elementos financiadores, como o departamen-
to financeiro da empresa, bancos, fontes governamentais de financiamento, patroci-
nadores etc. Igualmente, cabe também ao gerente de um projeto prestar contas dos
recursos destinados à consecução do projeto.
5.2.2 Técnicas de orçamentação

Diversas técnicas ou maneiras ajudam a preparação de um bom orçamento. Elas
não são mutuamente excludentes, mas sim complementares. Assim, mais de uma des-
sas técnicas pode ser empregada para conferir ou completar um orçamento já estima-
do. Algumas delas são:
• Agregação de custo – as estimativas de custos são compiladas nos pacotes de
trabalho definidos na EAP (Estrutura Analítica do Projeto). Os pacotes de tra-
balho agregam estimativas de custos nos níveis dos componentes mais altos da
EAP, e assim sucessivamente, até que o custo final é agregado no nível do es-
copo do projeto, ou seja, no mais alto nível hierárquico da EAP (XAVIER, 2008).
A figura a seguir ilustra o procedimento.
Agregação de custos
Design Gráfico: Juliano Henrique

$ $ $ $
$ $ $ $ $ $ $ $ $
$ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ $ T
• Formação de contingências – também conhecida como Análise de Reservas
(PMI, 2013), procura estabelecer recursos e ações na medida adequada, para
serem empregados caso ocorram eventos que desviem o projeto de suas metas
de custos. A medida “adequada” pode ser definida com base em critérios obje-
tivos, como o histórico de desvios das metas de custo. Mas ela também pode
se basear em critérios mais subjetivos, como a percepção do risco da falta de
recursos. À medida que as informações sobre os gastos do projeto (montante,
datas etc.) se tornam mais acuradas, as contingências para custos podem ser
diminuídas ou até mesmo eliminadas. Por exemplo, para um treinamento no
exterior, prepara-se uma verba de 20 mil euros. Para eventualidades (em caso
de doença, perdas ou até novas oportunidades), leva-se uma reserva de con-
tingência de 5 mil euros. As reservas de contingência não são incluídas na linha
de base dos custos, mas sim no orçamento do projeto, como uma reserva para
casos de emergência (se elas forem usadas, então são incorporadas posterior-
mente na linha de base dos custos do projeto).
• Análise de riscos – definindo-se o risco como uma medida da expectativa de
uma perda (risco negativo) ou ganho (risco positivo), deve-se incluir o valor do
risco nos orçamentos dos projetos. Por exemplo, historicamente, o risco de
chuvas em uma região é 10% em cada dia de janeiro. Uma obra que não pode
ser realizada na chuva deve, então, acrescer no orçamento o valor esperado das
perdas associadas às chuvas.
• Julgamentos de especialistas – conta com as opiniões (muitas vezes sub-
jetivas) de pessoas com comprovada experiência em projetos semelhantes.
Exemplos mais usuais desses especialistas são: consultores, gerentes de proje-
tos já realizados, stakeholders diversos, profissionais do mercado, analistas de
negócios (IIBA, 2009), membros de escritórios de projetos etc. Mesmo quan-
do subjetivas, as opiniões de especialistas podem apresentar confiabilidade
tão grande ou até maior do que outras metodologias. No exemplo da viagem

ao exterior, os colegas veteranos podem ser consultados para estimarem os
custos.
• Histórico de relacionamentos – fornecem dados úteis para a formação de mo-
delos, heurísticas ou algoritmos capazes de estimar com boa acurácia o orça-
mento de um projeto. Alguns desses modelos podem ser simples, por exemplo,
o orçamento do projeto de uma mudança residencial se baseia no volume dos
elementos transportados e nas distâncias percorridas. Mas eles podem tam-
bém ser complexos, por exemplo, incluindo no projeto da mudança variáveis
como dimensões dos objetos, natureza, fragilidade, preço de mercado, neces-
sidade de embalagem de cada peça etc.
O termo acurácia se refere à proximidade do resultado obtido e o verdadeiro valor da variável. É

diferente de precisão, que representa a concentração dos valores obtidos em processos repetitivos.
• Cálculo de custos de transação – representam os custos de negociar, redigir e

controlar o cumprimento de um contrato. Eles podem incluir os custos de reali-
zar e manter relacionamentos com fornecedores, por exemplo.
• Inclusão de custos de administração – algumas vezes esquecidos, eles se re-
ferem às funções gerenciais, de consultoria e de apoio para a administração de
um projeto.
A expatriação de um funcionário, por um ano, é um projeto que envolve vários
custos “ocultos”. Além do transporte aéreo, salário, aluguel e alimentação, também
devem ser considerados: seguro saúde, assistência dentária, ajuda para mudança, au-
xílio para compra de roupas de inverno, curso de idioma, assessoria para procurar mora-
dia, custos administrativos com a preparação da viagem, custos de rescisão de contrato
e recontratação (se for o caso), custo com escola para os filhos, custos com uma visita ao
país de origem (a combinar), entre outros. Para o negócio, há ainda os custos dos riscos –
por exemplo, o funcionário pode não se adaptar ao país e querer voltar.
5.2.3 Análise do fluxo de caixa

Assim como organizações permanentes, um projeto possui um fluxo de caixa que
representa a movimentação de dinheiro recebido e gasto durante seu ciclo de vida. Em
analogia à Contabilidade, o fluxo de caixa planejado para o projeto representa os re-
cebimentos e pagamentos esperados durante as fases do projeto. Ao término do pro-
jeto, o fluxo de caixa é atualizado pelos valores financeiros realmente movimentados
durante todo o ciclo de vida do projeto.
Fluxo de caixa de um projeto – exemplo gráfico

600 250 140 60 40 140

Tempo
200 310 220 170 130 200
A distribuição dos recebimentos e pagamentos ilustrada na figura “Fluxo de caixa de um

projeto”, indica, por exemplo, se um projeto necessitará empréstimos adicionais, para seu
financiamento. Mesmo se as receitas totais superarem os pagamentos totais, em alguns
períodos o caixa pode ser negativo.
Com base no fluxo de caixa do projeto, é possível extrair informações, como:

• taxa interna de retorno do projeto;
• valores presentes e futuros, corrigidos por inflação, juros etc.
• atratividade de um projeto em relação a outras opções;
• provisões necessárias para realizar pagamentos;
• necessidades de empréstimos ou antecipações de recebimentos;
• consolidação de pagamentos e recebimentos de diversos projetos.
Para uma análise mais detalhada, consulte a obra Princípios de Administração Financeira, de
Lawrence J. Gitman (2010).
Como todo projeto sempre deve ser encerrado algum dia, o fluxo de caixa final
tem que equilibrar todos os recebimentos com os pagamentos, mesmo se restarem
saldos ou contas a pagar. Ou seja, ∑i(Receitas)i= ∑i(Despesas)i.
Os pagamentos efetuados serão comparados com os trabalhos realmente rea-
lizados ou agregados no projeto, como uma medida de avaliação de desempenho do
projeto.
A análise do fluxo de caixa é talvez o principal instrumento de verificação da via-
bilidade financeira de um projeto. Enquanto a viabilidade econômica atesta que os
resultados do projeto compensam os gastos e remuneram o capital e o esforço inves-
tidos, a análise financeira indica se o fluxo de receitas e despesas são coordenados de
maneira que os pagamentos possam ser realizados nos prazos.
5.2.4 Linha de base dos custos

A linha de base dos custos consiste na versão aprovada do orçamento do proje-
to distribuído ao longo do período deste. Ela serve como referência para monitorar e
controlar o desempenho do projeto, e somente deve ser modificada mediante proce-
dimentos formais. Essa exigência tem por objetivo dificultar tentativas de esconder
maus desempenhos do projeto.
A figura a seguir representa a linha de base dos custos, construída com os va-
lores planejados acumulados (VP) e os respectivos custos ao longo do projeto (C).
Tipicamente, os maiores gastos ocorrem mais perto do meio do cronograma. Portanto,
a curva das despesas acumuladas assume uma forma parecida com um “S”. Por cau-
sa disso, o gráfico a seguir é popularmente conhecido como “a curva S do projeto”
(SANTOS; CARVALHO, 2006).
Linha de base dos custos: a “curva S”

Período C VP
120
Custos acumulados
1 4 4
100 ENT
2 7 11 80
3 10 21 60 VP
4 13 34 40
20 C
5 16 50
0
6 16 66

0 2 4 6 8 10 12
7 13 79
10 Tempo
8 89
9 7 96 Periódicos Planejados
10 4 100
O custo total planejado para o projeto é denominado Estimativa no Término

(ENT) ou Budget at Complaint (BAC). Ele inclui todos os custos atribuídos ao projeto e
pode ser calculado como ∑i(Despesa)i, sendo “i” cada custo individual.
5.3 Controle dos custos

Analogamente aos prazos, os custos são frequentemente empregados como indi-
cadores de sucesso. Quanto mais os custos reais do projeto (estimados em datas inter-
mediárias e no final) se afastam das previsões, pior é o desempenho do projeto. Assim,
um controle de custos sistemático e ativo é necessário para identificar, corrigir e pre-
venir desvios do orçamento, ao longo do ciclo de vida do projeto.
O controle de custos de um projeto pode empregar em ações como as seguintes:
• Monitorar o progresso dos gastos ao longo de seu ciclo de vida e comparar os
resultados com as previsões e a linha de base dos custos.
• Projetar os desvios verificados nos custos para datas futuras – em especial,

para a data do término do projeto.
• Elaborar e adotar ações para conduzir os gastos do projeto a patamares dese-
jáveis, bem como avaliar os impactos dessas ações no sucesso do projeto e do
negócio do projeto.
• Identificar a necessidade de adotar e implantar medidas preventivas para evi-
tar desvios dos custos em relação ao orçamento.
Projetos com características específicas (por exemplo, que envolvem gastos em
diversas moedas e paga impostos em diversos países) podem exigir ações mais especí-
ficas de controle de custos.
A importância do controle de custos é exemplificada com o projeto de implanta-
ção de uma padaria de alto padrão em Curitiba, em um período de 10 meses. O dife-
rencial do negócio era a excelência no atendimento e a oferta de produtos importados.
Os altos custos dos produtos seriam compensados pelos preços um pouco mais altos.
Medições mensais indicaram uma tendência de queda no faturamento mensal. Em seis
meses, a padaria foi fechada.
O exemplo anterior nos mostra que não foi necessário esperar o final do perío-
do de implantação para decidir pelo fechamento do negócio. Medidas corretivas (por
exemplo, campanhas publicitárias) não foram suficientes para reverter os prejuízos ao
longo do projeto. Outras ações, como promoções e enxugamento do quadro de pes-
soal, não seriam adequadas, pois prejudicariam o diferencial do negócio – que eram o
atendimento de excelência e os produtos de alto padrão.
5.3.1 Papel do controle dos custos

A principal função do controle de custos é manter os gastos em torno dos va-
lores planejados, com base em constantes ações corretivas ao longo do ciclo de vida
do projeto. Essa função complementa as ações preventivas realizadas durante a or-
çamentação do projeto, as quais incluem, por exemplo, a formação de recursos de
contingências.
Essa função tradicional do controle de custos é coerente com as abordagens mais
técnicas do gerenciamento de projetos. Contudo, ela não contempla bem a visão do
negócio do projeto, nem as oportunidades que um custo adicional pode gerar para
esse negócio. Por exemplo, no projeto de uma residência com custo previsto de R$ 1
milhão e preço de venda de R$ 1,3 milhão, um aumento nos gastos para R$ 1,2 milhão
diminui sensivelmente o lucro do negócio e, portanto, significaria um fracasso do pro-
jeto. Contudo, se este aumento de custo agregar valor à residência e impulsionar seu
preço de mercado para R$ 1,8 milhão, então ele será bem-vindo. A abordagem do ge-
renciamento de projetos para negócios permite que o gerente de projetos reveja sua
postura tradicional, reacionária a qualquer aumento de custos, e opte por uma postura
aberta a oportunidades e a benefícios reais.
Posteriormente, também será discutida a relação mútua entre os custos e ou-
tras metas do projeto no item sobre análise de tradeoffs. Com base em análises de
tradeoff, pode-se concluir que é benéfico para o projeto ultrapassar os custos previs-
tos, desde que outros benefícios sejam agregados ao produto do projeto: mais qualida-
de, menor prazo, menor risco etc.
Expressão em inglês que denota um conflito entre alternativas, em um processo de escolha.

Usualmente, esse processo considera as vantagens e as desvantagens de cada alternativa. Por
isso, por vezes, se utiliza também a expressão perde-ganha.
5.3.2 Análise do valor agregado

A Análise do Valor Agregado (AVA) avalia o desempenho do projeto em função do
progresso do produto (escopo), do tempo decorrido e dos custos do projeto. Ela se ba-
seia em três variáveis-chave conforme mostra a figura a seguir (KERZNER, 2011).
Análise do Valor Agregado (AVA)

140
CR
120
VP
Custos acumulados
100
80 Design Gráfico: Guilherme Rufatto
VA
60
40
20
0 C
0 2 4 6 8 10 12
Tempo
Periódicos Planejados Agregado Reais
• Valor Planejado (VP): representa as despesas previstas acumuladas do pro-

jeto, ou ∑i (Despesa)i, ao longo do período de duração deste. É uma linha de
base, em relação a qual se avalia o desempenho do projeto. Ele pode ser defi-
nido já no início do projeto e atualizado periodicamente. O VP na data final do
projeto é a Estimativa no Término (ENT).
• Valor Agregado (VA): é quanto vale o trabalho realmente executado, até a
data de análise. Ele exige a medição do que foi, de fato, realizado.
• Custo Real (CR): é o custo do trabalho realmente executado, até a data de aná-
lise. O CR no término do projeto é o Orçamento no Término (ONT).
Por exemplo, no gráfico anterior, os valores planejados (VP) são definidos no iní-
cio do projeto. À medida que o projeto avança, medem-se VA e CR. Na data D = 5,
VP = 50, VA = 40 e CR = 60. Isso significa que o valor agregado dos trabalhos realizados
até essa data é apenas 40. Então, o projeto está atrasado, porque executou menos do
que o trabalho planejado. Por outro lado, o custo para executar o valor agregado de 40
foi 60; então, os trabalhos realizados custaram muito mais caro (20) do que deveriam.
Em suma, o projeto está atrasado e custa mais caro do que deveria.
5.3.3 Variações e índices de desempenho

A análise do valor agregado, ilustrada no item anterior, pode ser realizada com
base nas variações e nos índices de desempenho. Em ambos os casos, o elemento bá-
sico para a análise é a curva S do projeto.
Análise das variações
As variações empregadas nessa análise são de dois tipos (KERZNER, 2011):
• Variações de prazo (VPR) – calculada como VPR = VA – VP, ou seja, o Valor
Agregado menos o Valor Planejado. Se VPR < 0 na data D, então o projeto está
atrasado nesta data; se VPR > 0, ele está adiantado.
• Variações de custos (VC) – calculada como VC = VA – CR, ou seja, o Valor
Agregado menos o Custo Real. Se VC < 0 na data D, então o projeto apresenta
sobrecusto nesta data; se VC > 0, seu custo possui folga.
Quatro casos de variações na curva S são ilustrados na figura a seguir:
• Superior esquerda – projeto atrasado, custos excessivos (VPR < 0, VC < 0).
• Superior direita – projeto atrasado, custos excessivos (VPR < 0, VC < 0).
• Inferior esquerda – projeto atrasado, custos com folga (VPR < 0, VC > 0).
• Inferior esquerda – projeto adiantado, custos excessivos (VPR > 0, VC < 0).
Exemplo de curva S
Custos acumulados Custos acumulados
ENT ENT
CR
VP VP
CR
VA
VA
Data de análise Tempo Data de análise Tempo

Custos acumulados Custos acumulados
ENT CR ENT

VA
VP
VA VP
CR
Data de análise Tempo Data de análise Tempo
Com base nas análises dessas situações, pode-se estimar o custo no término
(ENT) e o prazo no término (duração total do projeto).
Índices de desempenho
Os índices de desempenho revelam também a situação do projeto quanto a atra-
sos e a custos – analogamente à análise das variações. Contudo, eles indicam uma me-
dida da eficiência (%) do projeto. São de dois tipos (KERZNER, 2011):
• Índice de Desempenho de Prazos (IDP) – calculado como IDP = VA / VP. Ou
seja, ele mede a eficiência do uso do tempo no projeto. Se IDP < 1 na data D,
então menos trabalho foi executado do que planejado (atraso).
• Índice de Desempenho de Custos (IDC) – calculado como IDC = VA / CR. Ou
seja, ele mede os custos no trabalho executado. Se IDP < 1 na data D, então
houve excesso de custo para o trabalho executado (sobrecusto).
Diversos casos típicos de variações na curva S são ilustrados na figura anterior:
• Superior esquerda: IDP≈80% e IDC≈67%, atraso e sobrecusto.
• Superior direita: IDP≈80% e IDC≈90%, atraso e sobrecusto.
• Inferior esquerda: IDP≈90% e IDC≈110%, atraso e folga no custo.
• Inferior esquerda: IDP≈110% e IDC≈90%, adiantamento e sobrecusto.
Tanto a análise das variações quanto os índices de desempenho revelam desvios
de custos e de prazos em projetos. Os primeiros permitem estimar as consequências
reais dos desvios, enquanto os segundos indicam uma eficiência da gestão dos custos.
5.3.4 Previsões de custos e tendências

À medida que o projeto se desenvolve, mudam as previsões sobre a estimativa no
término (ENT), que representa o custo total do projeto estimado para o término. Uma
boa previsão de ENT é crucial para decisões sobre a continuidade ou não do projeto.
A estimativa de ENT é composta por duas parcelas:
• o custo real calculado na data D de análise (conhecido);
• o custo estimado para terminar o trabalho que falta (estimado).
As medições do valor agregado (VA) e dos custos reais (CR) não apenas indicam
os atrasos e os custos excessivos na data D. Elas também servem para duas estimati-
vas relevantes para o término do projeto:
• A data do término do projeto – calculada, por exemplo, com o mesmo atraso
na data D (imaginando-se que o projeto atrasou, mas não terá novos atrasos);
ou com um atraso proporcional ao da data D (continuará atrasando na mesma
proporção até o final); ou ainda, uma combinação dessas situações. Na figura a
seguir, o atraso na data D = 5 é igual a 1 (= 6 – 5); para o final do projeto, ele
pode ser 2 (= 12 – 10), de modo que ENT = 12.
• O custo real no término do projeto – calculado, por exemplo, com o mesmo
sobrecusto da data D; ou proporcionalmente a este, em datas futuras. Na figu-
ra a seguir, o sobrecusto na data D = 5 é igual 20 (= 60 – 40). Ele pode ser esti-
mado como os mesmos 20 no término, ou proporcionalmente, igual a 40. Na
realidade, o projeto vai atrasar e o custo real será +30 na data real do término,
em D = 12.
Data do término e custo do término

140
ENT
120
100
80

60
40
20
0
0 2 4 6 8 10 12 14
Planejados Agregado Reais
Em resumo, o projeto da figura anterior deve atrasar e extrapolar o orçamento. A

estimativa do atraso e do sobrecusto no término são atualizados em qualquer data D.
5.4 Análise de tradeoffs

Uma análise de tradeoff se baseia em um processo de ajustes entre fatores, de
maneira que ganhos em um deles sejam compensados necessariamente com perdas
em outros. Isso se deve a restrições de recursos, que impedem, por exemplo, somente
ganhos em todos os fatores.
A figura a seguir ilustra o tradeoff entre as metas típicas de um projeto. As situa-
ções A e B indicam diferentes prioridades ou estratégias atribuídas às metas.
Tradeoffs entre fatores de sucesso de projetos
Escopo E
Q P
Prazo Tradeoff

Qualidade Custo Situação A
Situação B
C
A análise de tradeoff da figura anterior representa o balanceamento entre as me-

tas do projeto, não entre interesses dos stakeholders. Frequentemente, um gerente de
projeto se depara com situações de tradeoff e precisa gerenciar esse processo de de-
cisão. Por exemplo, manter baixo o custo de um software e ainda assim incluir todos
os componentes previstos e realizar os testes necessários (é um tradeoff entre custo,
escopo e qualidade). Ele poderá decidir por si só quais exigências deixará de atender
(prática menos comum) ou consultar o dono do projeto a respeito (mais usual).
5�4�1 Objetivos e elementos do tradeoff

A finalidade de uma análise de tradeoff é eleger a “melhor” solução entre as vá-
rias alternativas viáveis. Por exemplo, os fatores típicos de avaliação do sucesso
em projetos (escopo, qualidade, prazo e custo) constituem entre si uma relação de
tradeoff. Projetos com excelente avaliação de escopo, qualidade e prazo provavelmen-
te custam caro; projetos com escopo abrangente, baixo custo e prazos curtos, prova-
velmente apresentam baixa qualidade, e assim por diante.
Por exemplo, uma obra civil pode recuperar o atraso se empregar mais equipa-
mentos de escavação. Contudo, ela custará mais caro do que o planejado. Cogita-se
cortar parte do escopo para manter o custo; ou, ainda, diminuir a qualidade do produ-
to para manter prazo, qualidade e escopo. Esse é um processo de tradeoff.
Para analisar um processo de tradeoff, empregam-se, por exemplo:
• Técnicas matemáticas, tais como a programação linear, a simulação de siste-
mas, as análises financeiras, a modelagem de custos etc.
• Técnicas não matemáticas, tais como heurísticas, análise de cenários, pro-
cessos what-if, consenso, painel de especialistas, votações etc. Essas técnicas
apresentam bons resultados por serem amigáveis e envolverem bem a equipe
do projeto.
No exemplo anterior, sobre a obra civil, é evidente o benefício das técnicas mate-
máticas para apoiar processos decisórios que envolvem custos. Contudo, técnicas não
matemáticas podem considerar nuances e aspectos subjetivos difíceis de serem mo-
delados. Idealmente, consideram-se essas duas abordagens (matemáticas e não mate-
máticas) complementares.
5.4.2 Processo de otimização

Em um sentido matemático, a otimização se refere a métodos capazes de mode-
lar um problema como uma função (“função-objetivo”) e determinar os valores má-
ximos ou mínimos dessa função, em face de restrições claramente estabelecidas. O
gráfico seguinte ilustra a modelagem do custo total de um projeto (Ct) em função dos
investimentos na qualidade do produto gerado (Iq).
Custos de um projeto em função da qualidade

Custos
Ct = Custo total
Cq = Custo da qualidade

Cr = Custo de reparos
lq
lq (ótimo)
No gráfico anterior, o custo da qualidade é uma função do tipo Cq = 50 + 20 Iq e

o custo dos reparos, uma função do tipo Cr = 40 / Iq, válida no intervalo de interesse
sombreado. O custo total então é Ct = 50 + 20 Iq + 40 / Iq e fornece um valor mínimo
nesse intervalo, quando Iq = Iq (ótimo).
Segundo o gráfico, quanto maior o investimento na qualidade do produto gera-
do, maior seu custo. Por outro lado, menores são os custos com posteriores reparos do
produto. O gráfico sugere que soluções extremas para os investimentos na qualidade
(Iq) não são razoáveis. Em algum ponto intermediário está a solução ótima.
A modelagem matemática permite que a solução ótima seja determinada com
exatidão. Isso proporciona uma economia de recursos e vantagens competitivas.
Nesse exemplo, a otimização trata-se de um processo de minimização de custos (em
outros casos pode ser um processo de maximização de lucros, por exemplo).
Alguns fatores, contudo, dificultam o uso mais amplo da modelagem:
• ela é sempre uma representação imperfeita da realidade (pode ignorar variá-
veis importantes que mudariam significativamente os resultados);
• exige alguma base matemática para quem modela e quem interpreta;

• pode sugerir uma falsa sensação de segurança (o modelo “diz que...”);
• exige investimento de tempo para preparação.
Talvez por causa dessas dificuldades, a modelagem matemática (e as otimizações
dela decorrentes) sejam ainda empregadas moderadamente nos projetos – apesar dos
evidentes ganhos que podem proporcionar.
Por outro lado, existem processos que não se baseiam em técnicas de otimização
pura, mas são capazes de gerar soluções também muito boas, ou quase ótimas. Eles
podem apresentar vantagens, em relação aos primeiros, tais como a facilidade de
serem entendidos e aplicados. Alguns desses métodos são:
• a simulação por enumeração (calculam-se todos os resultados possíveis, por
combinação, e então se elegem os melhores – máximos ou mínimos);
• a simulação de Monte Carlos (geram-se resultados calculados a partir de nú-
meros aleatórios e escolhem-se os melhores resultados, sejam estes máximos
ou mínimos);
• métodos iterativos (geram soluções aproximadas, que vão melhorando com
sucessivas iterações, até atingirem um critério de parada);
• métodos interativos qualitativos, para decisão grupal (coordenam a troca de infor-
mações de um grupo de decisores até se obter um consenso) (MAZZILLI, 1994).
Em uma obra civil, é possível utilizar uma série de combinações de resultados para acelerar o
projeto. Para cada combinação, estimam-se os efeitos nos prazos, nos custos, no escopo e na
qualidade (enumeração). As melhores soluções são aquelas que satisfazem bem aos fatores de
sucesso do projeto.
Para muitos profissionais de projetos, a modelagem de um problema e a tentati-

va de otimizar os resultados podem parecer caras, complexas e demoradas. Com apli-
cativos de software cada vez mais amigáveis, essa tarefa tem se tornado mais simples.
Embora não seja razoável tentar modelar “todo o projeto”, podem-se buscar soluções
ótimas ou quase ótimas em partes específicas dos projetos.
5.4.3 Controle de mudanças

No gerenciamento de qualquer projeto, mudanças não são ocorrências excepcio-
nais, mas normais. Elas impactam diretamente os pacotes de trabalho do projeto e,
portanto, exigem atualizações nos respectivos custos (mesmo quando o orçamento
total do projeto não muda, os custos dos pacotes de trabalho mudam). Mudanças em
projetos exigem também atualizações nas análises de tradeoff, na busca de um novo
conjunto ideal dos fatores de sucesso do projeto.
Analogamente ao que ocorre na gestão da integração (VALERIANO, 2005), o

controle de mudanças também prevê reavaliações no tradeoff entre as metas do pro-
jeto, com base em no conjunto (E, Q, T, C, R) indicado a seguir:
• Fator escopo (E): escopo aprovado.
• Fator qualidade (Q): parâmetros aprovados da qualidade.
• Fator tempo (T): cronograma aprovado.
• Fator custo (C): linha de base dos custos, aprovada.
• Fator risco (R): níveis de risco adotado e impactos nos demais fatores.
No caso de uma obra civil, mudanças decorrentes de novas exigências do cliente (expansão do es-
copo) podem implicar, por exemplo, a impossibilidade de se atingirem as atuais metas de custo.
Uma nova relação de tradeoff é necessária para equilibrar idealmente as novas metas do projeto.
A figura ”Tradeoffs entre fatores de sucesso de projetos”, apresentada anterior-

mente, ilustra a situação de mudança nas metas de um projeto e a respectiva análise de
tradeoff. O resultado é um novo conjunto de metas para o projeto, que representa uma
nova estratégia para o sucesso de seu produto. Assim, a passagem dos parâmetros (E A ,
Q A , TA , C A , R A), antes do processo de tradeoff, para os parâmetros (EB, QB, TB, CB, RB),
depois do processo de tradeoff, implica uma nova configuração do produto do projeto,
mais adaptada às necessidades dos stakeholders. Nesse processo, o custo é apenas um
dos componentes do tradeoff, cujo objetivo é a maximização do valor do produto.
O processo de controle de mudanças identifica, documenta e aprova/rejeita modi-
ficações em documentos, produtos e linhas de base de um projeto. Esse mesmo pro-
cesso é válido para mudanças relativas aos custos do projeto.
Segundo a abordagem voltada para o negócio, mudanças devem ser planejadas
e monitoradas em relação à estimativa dos impactos que elas causam não apenas no
projeto, mas também no negócio do projeto (CASAROTTO, 2002). Até aqui, o controle
das mudanças enfocou as metas técnicas do projeto. No próximo item, serão explora-
dos os impactos que as mudanças podem causar no negócio do projeto.
5.4.4 Estimativa de impactos

Abordagens modernas do gerenciamento de projetos buscam estimar os impac-
tos das mudanças não apenas no ambiente do próprio projeto, mas principalmente nos
níveis estratégicos do negócio, sob a ótica dos stakeholders (FREEMAN, 2013).
Enquanto no primeiro caso os impactos são estimados em função de variáveis
relevantes para o projeto (tais como escopo, qualidade, tempo, custo e risco), no ní-
vel do negócio eles se manifestam em variáveis relevantes para o negócio do projeto
(SANTOS, 2015). A título de exemplo, listam-se algumas dessas variáveis:
• Preço do produto (P);

• Qualidade percebida (Qp);
• Tempo (T);
• Competitividade (C);
• Sustentabilidade (S);
• Risco para o negócio (R) etc.
Com base nessas variáveis, elabora-se uma nova análise de tradeoff, desta vez
para o nível estratégico. A figura a seguir ilustra o procedimento.
Tradeoffs para o nível estratégico

T C
Tempo Competitividade Solução A
Risco Preço R P

Tradeoff
Qualidade Sustentabilidade Solução B Qp S

percebida
Pela figura, percebe-se que diferentes escolhas do conjunto (P, Qp, T, C, S, R) re-
sultam em diferentes soluções estratégicas para o problema do projeto. A solução ideal
deve ser capaz de satisfazer da melhor forma possível os interesses dos stakeholders.
Ela pode ser eleita por meio de métodos quantitativos (pontuações, análises de gaps,
ponderação de valores etc.) ou procedimentos qualitativos (análise de consenso, opi-
niões de especialistas, consultas a stakeholders etc.).
Aplicando-se esses conceitos ao caso da obra civil relatado anteriormente, bus-
ca-se agora equilibrar os interesses dos stakeholders (TRENTIM, 2013), em um novo
cenário que combina (P, Qp, T, C, S, R) da melhor maneira possível. Note-se que
esse processo de tradeoff emprega variáveis distintas daquele comentado no item
“Controle de mudanças”, realizado para o nível do projeto.
Como exemplo, cita-se uma fábrica de meias de inverno que empregava material
antiderrapante de alta qualidade no solado. Para economizar 4% dos custos (C), esse
material foi substituído por um similar menos aderente. Inicialmente, não se percebeu
impacto nas vendas, mas, após 6 meses, elas caíram cerca de 30% porque a qualidade
percebida (Qp) recebeu um impacto negativo no nível do negócio.
Nesse caso das meias, a reação adotada para o problema foi fabricar dois tipos de
produtos. Ou seja:
• voltar a fabricar o produto com o material original, para atender a um público
mais exigente;
• simplificar ainda mais o produto e reduzir os custos para atender a um público
relutante em pagar os altos preços daquelas meias de alto padrão.
Cada um desses dois casos exigiu uma análise de tradeoff própria, para definir as
metas de custo e qualidade adequadas.
Em resumo, os custos de um projeto devem sempre ser bem estimados e conti-
nuamente controlados. Desvios dos custos planejados constituem talvez a causa mais
visível do insucesso de projetos (e uma das mais frequentes). Eles não prejudicam ape-
nas as metas dos projetos, mas os objetivos estratégicos de seus negócios. Este últi-
mo efeito, se detectado a tempo, pode gerar ações corretivas e salvar um projeto do
fracasso.
Referências
AACE International Recommended Practice No. 18R-97, 2005. Cost Estimate
Classification System – as applied in engineering, procurement, and construction
for the process industries. Disponível em:< http://www.aeso.ca/downloads/AACE_
CLASSIFICATION_SYSTEM.pdf>. Acesso em: 06/02/2015.
06/02/2015.
UmweltWirtschaftsForum, Springer, v. 21, n.1, 2013.
GITMAN, L. Princípios de Administração Financeira. 12. ed. Pearson, São Paulo,
2010.
HEDEMAN; B. et al. Project Management Based on PRINCE2®: an introduction.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK®) . Toronto:
IPMA. ICB3® - IPMA Competence Baseline. Nijkerk: IPMA, 2006.
KEELING, R. Gestão de Projetos: uma abordagem global, 2. ed. São Paulo: Saraiva,
2012.
KERZNER, H. SALADIS, F.P. Value Driven Project Management. Nova Iorque: Wiley,
2009.
KERZNER, H. Gerenciamento de Projetos: uma abordagem sistêmica para
planejamento, programação e controle. São Paulo: Edgar Bluecher, 2011.
MAZZILLI, C. Sistemas interativos de apoio à decisão: um processo coletivo. In:
Revista de Administração, v. 29, n. 3, p. 41-54, jul-set 1994.
OGC. Managing Successful Projects with PRINCE2®. TSO, 2009.
PMI – A Guide to the Project Management Body of Knowledge: PMBOK®. 5. ed. Upper
Darbi: PMI, 2013.
2006.
SANTOS, J. A. Gestão de Projetos. 1. ed. Curitiba: Editora Positivo, 2015.
SANTOS, J. A.; CARVALHO, H.G. RBC: Referencial Brasileiro de Competências em
2005.
VARGAS, Ricardo. Gerenciamento de Projetos. 6. ed. Rio de Janeiro: Brasport, 2005.
6 Recursos humanos e comunicação
Projetos são realizados por pessoas. Não é essencial que elas possuam uma mes-
ma formação nem compartilhem das mesmas opiniões – pelo contrário, a diversida-
de de opiniões, formações e personalidades é benéfica, principalmente quando se
trata de projetos inovadores. No entanto, é necessário que as pessoas envolvidas em
um projeto – ou seus recursos humanos – trabalhem de maneira coordenada e alinha-
da para que o projeto obtenha sucesso. Também é essencial que essas pessoas se co-
muniquem de maneira adequada, para que não desperdicem seus esforços e recursos
do projeto. Para essas finalidades, o gerenciamento profissional de projetos conta com
planos, ferramentas e procedimentos consagrados, que serão apresentados a seguir.
O enfoque deste capítulo será a comunicação entre as pessoas atuantes em um
projeto – sejam elas internas à organização que abriga o projeto ou externas (forne-
cedores, clientes, governo etc.). Problemas relacionados com a comunicação entre
pessoas são apontados como os fatores de sucesso/insucesso mais relevantes no ge-
renciamento de projetos.
6.1 Formação e desenvolvimento de equipes de projetos

A coordenação de um projeto pode ser muito simples quando realizada por uma
só pessoa, no estilo “deixem que eu faço”, pois, nesse caso, os esforços de comunica-
ção são menores, assim como as tomadas de decisão e prestação de contas. No entan-
to, na maioria dos projetos, é indispensável formar grandes equipes, principalmente
quando estes contam com um volume considerável de trabalho, diversidade de com-
petências e/ou vasta rede de relacionamentos. Nessas situações, os esforços para es-
tabelecer e manter relacionamentos, bem como elaborar documentos, podem ser
consideráveis e, se menosprezados, acabam colocando em risco o sucesso do projeto.
Um exemplo dessa situação foi observado em uma equipe de seis pessoas que
elabora projetos de gerenciamento de riscos para grandes empresas industriais. Um
engenheiro é o mais competente profissional da equipe, muito experiente e cuidadoso
com a qualidade dos trabalhos. Mas seu relacionamento com os demais profissionais é
sempre tenso. Quando ele entra em uma equipe, os trabalhos travam.
6.1.1 Conceitos fundamentais e plano de gestão dos recursos humanos

Como o gerenciamento de qualquer projeto é realizado por pessoas, a importân-
cia de uma boa gestão dos recursos humanos é essencial para o sucesso dos projetos.
Um superdimensionamento desses recursos implica ineficiência e desperdício; já um
subdimensionamento é ainda pior porque ocasiona, por exemplo, atrasos e má quali-
dade do projeto. O seguinte exemplo ilustra a situação.
Um projeto de franquias em diversos países necessitava de dois engenheiros de

produção e uma secretária – todos fluentes em inglês, espanhol e alemão, e capacita-
dos no pacote Office – em período integral. Ele obteve um engenheiro em tempo par-
cial e dois estagiários com noções de inglês e espanhol para realizar o mesmo trabalho.
Essa situação é encontrada frequentemente em outros projetos. Ela ilustra um desafio
típico para gerenciar recursos humanos em projetos: realizar as mesmas entregas, con-
tando com menos recursos do que os necessários.
O dimensionamento dos recursos humanos em projetos pressupõe:
• A estimativa das necessidades de pessoal para o projeto: previsão de quais re-
cursos serão necessários, quando, por quanto tempo, a que custo e com quais
capacitações.
• Os relacionamentos disponíveis para obter os recursos pretendidos: quais fon-
tes são acessíveis para fornecer os recursos previstos, em quais condições e por
meio de quais contatos. Essas fontes podem ser o próprio projeto, a organiza-
ção hospedeira do projeto, parceiros e o mercado. Na escolha, consideram-se
fatores tais como custo, confiabilidade, riscos e disponibilidade de pessoal.
• A verificação da disponibilidade dos recursos humanos desejados: quais recur-
sos são disponíveis e em quais fontes. Muitas vezes, recursos humanos são ex-
clusivos e difíceis de serem substituídos (“quero somente aquele profissional”)
– o que dificulta sua aquisição.
• A obtenção dos recursos possíveis: definir um determinado recurso humano e
descobrir suas fontes não é equivalente a obtê-lo. Isso exige negociações com
as próprias pessoas desejadas, mas também com seus superiores hierárquicos,
seja na própria organização ou até em outras. Os recursos possíveis são fre-
quentemente distintos daqueles planejados.
• A verificação dos impactos dos recursos obtidos nos objetivos do projeto e do
negócio do projeto (IIBA, 2009): avaliar quais serão os efeitos causados pelo
emprego de recursos humanos distintos daqueles planejados.
Comparando-se os recursos idealmente planejados àqueles realmente obtidos, é
possível avaliar o impacto (usualmente negativo) nos produtos gerados pelo projeto e
na solução proposta para o problema do projeto.
O plano de gerenciamento dos recursos humanos é um documento que descre-
ve como os papéis, as responsabilidades, a estrutura hierárquica e o gerenciamento do
pessoal serão estruturados em um projeto (VALERIANO, 2005). Ele é esboçado no pla-
nejamento inicial do projeto (como parte do plano de gerenciamento do projeto) e de-
talhado/atualizado posteriormente. Esse plano inclui itens tais como:
1. Objetivo do plano de gerenciamento dos recursos humanos
(Descrever o objetivo do plano.)
2. Método do gerenciamento dos recursos humanos

(Identificar os componentes do plano de gerenciamento dos recursos humanos.)
3. Processos do gerenciamento de recursos humanos
(Detalhar processos e as respectivas ferramentas gerenciais para formar, desen-
volver e gerenciar a equipe.)
4. Responsabilidades da equipe
(Listar as responsabilidades, competências e autoridade.)
5. Necessidades de recursos humanos
(Identificar quais as necessidades de pessoal: quando, com qual formação.)
6. Disponibilidade de recursos humanos
(Indicar quais pessoas podem estar disponíveis e em quais períodos.)
7. Aquisição da equipe
(Indicar as negociações necessárias para conseguir as pessoas ideais.)
8. Alocação de pessoas
(Indicar em quais períodos as pessoas serão alocadas nas funções necessárias.)
9. Restrições dos membros da equipe
(Indicar quais restrições cada membro da equipe possui e quais serão impostas.)
10. Plano de treinamentos
(Definir quais treinamentos serão necessários, para quem e quando ocorrerão.)
11. Regras para recompensas e penalidadades
(Definir recompensas e penalidades previstas para cada situação.)
12. Documentação
(Descrever, catalogar e armazenar documentos padronizados para as contrata-
ções. Para cada documento, informar: número, nome, descrição e modelo.)
Outras informações relevantes podem ser incorporadas a esse plano, em função
das necessidades específicas do projeto. O PMBOK (PMI, 2013), por exemplo, apresen-
ta alguns itens adicionais, tais como calendário de recursos, tabela de mobilização da
equipe, conformidade e segurança.
6.1.2 Formação de equipes

A formação da equipe de um projeto ocorre usualmente segundo duas perspecti-
vas. A mais formal baseia-se em reuniões de iniciação do projeto, workshops e seminá-
rios para gerentes e membros da equipe. Já a perspectiva mais informal visa criar um
espírito de equipe e promover a motivação individual, mediante, por exemplo, eventos
sociais e dinâmicas. Ambas as perspectivas são igualmente importantes para formar e
consolidar a equipe que assumirá os trabalhos do projeto.
As dificuldades que podem ocorrer na formação das equipes dependem em gran-

de parte das especificidades do projeto e das diferenças em relação a aspectos cultu-
rais, educacionais, interesses e hábitos de trabalho dos membros da equipe.
O principal benefício do processo de formação da equipe é orientar a seleção dos
profissionais e designar as responsabilidades dentro da equipe, de modo que esta seja
capaz de entregar os resultados planejados do projeto e as soluções que atendem bem
aos interesses dos stakeholders (FREEMAN, 2013).
Em muitos casos, o gerente do projeto não consegue compor o que seria “a equi-
pe ideal” e, mesmo com uma equipe mais limitada do que gostaria, ele precisa en-
tregar os mesmos resultados planejados. Esse desafio se torna ainda maior quando se
trata de equipes virtuais e trabalho colaborativo à distância. Nesses casos, os trabalhos
não contam com as nuances permitidas nas reuniões presenciais e o controle perma-
nente das atividades também se torna mais difícil.
A mobilização da equipe do projeto consiste em um processo que inclui a confir-
mação das disponibilidades dos recursos humanos planejados, a real obtenção desses
recursos e a composição formal da equipe segundo critérios de eficácia (“conseguir fa-
zer”) e eficiência (“fazer barato”). Esse processo envolve as seguintes etapas:
• Negociação: para obter ou liberar os recursos ideais para o projeto.
• Contratação: para formalizar a disponibilidade do recurso no projeto.
• Ocupação: para empregar os recurso de maneira eficiente e eficaz (caso con-
trário, o recurso encarece o projeto e ameaça seu sucesso).
A depender do modo como as pessoas são alocadas na equipe, a coordenação
desse projeto enfrenta dificuldades adicionais. Por exemplo, é comum a alocação se-
gundo o conceito de organização matricial: um profissional trabalha algumas horas
por semana no projeto e o restante do tempo na organização permanente ou em ou-
tros projetos. A praticidade, a flexibilidade e a economia que essa forma de trabalho
proporciona pode não compensar os problemas que ela cria, como dificuldades para
marcar reuniões, baixo comprometimento, faltas ao trabalho (para atender prioritaria-
mente a outros projetos), tempo adicional para retormar o trabalho etc.
Esse caso particular de alocação de pessoas exemplifica a necessidade de se rea-
lizar um julgamento detalhado das suas vantagens e desvantagens no processo de for-
mação de equipes de projetos.
6.1.3 Avaliação de conhecimentos, experiências e atitudes

O bom funcionamento de uma equipe depende fundamentalmente de dois fato-
res: das características individuais dessas pessoas e da interação que haverá entre elas
durante o tempo em que trabalharem juntas.
No ambiente de projetos, as caraterísticas das pessoas são definidas, segundo o

ICB3 (IPMA, 2006) e o RBC (SANTOS; CARVALHO, 2006) como:
• Conhecimentos: incluem todos os conhecimentos adquiridos sobre matérias
pertinentes ao gerenciamento de projetos. Esses conhecimentos podem ser
avaliados por meio de provas, exames, testes, workshops etc.
• Experiências: incluem as experiências anteriores com a prática do gerencia-
mento de projetos. Elas podem ser constatadas e avaliadas com base em rela-
tórios, currículos, entrevistas, histórico profissional etc.
• Atitudes pessoais: incluem características e valores pessoais do profissional
de projetos, tais como a capacidade de comunicação, a iniciativa, a habilida-
de para estabelecer relacionamentos, a sensibilidade, a facilidade para resolver
conflitos, a capacidade para formular soluções, a lealdade e a liderança. As ati-
tudes pessoais podem ser avaliadas com base em entrevistas, workshops com
psicólogos, questionários etc.
A causa do fracasso total ou parcial de muitos projetos é principalmente a com-
posição inadequada da equipe de projetos. Investimentos de tempo e dinheiro para a
formação, desenvolvimento e manutenção de equipes têm sido recompensados com
maiores taxas de sucesso para o projeto e para o negócio do projeto (IIBA, 2009).
Na contratação de gerentes de projetos com formação mais sólida na área, tem-
-se valorizado cada vez mais a certificação em gerenciamento de projetos (por exem-
plo, as certificações IPMA, PRINCE2, PMI). O mesmo critério vale para a seleção de
participantes de uma equipe de projeto. O objetivo da certificação é atestar a compe-
tência de um profissional em gerenciamento de projetos (embora ela não garanta o su-
cesso da atuação futura desse profissional) (VARELLA; MOURA, 2014).
Avaliar a interação entre as pessoas costuma ser uma tarefa mais complexa do
que avaliar as características dessas pesssoas. Isso porque a interação depende sem-
pre da situação de cada projeto específico. Por exemplo, é possível que um profissional
tenha se saído muito bem em diversos projetos passados, mas apresente um péssimo
desempenho na próxima equipe em que atuar. Algumas formas de avaliar a interação
entre as pessoas de um projeto se baseiam em: pesquisas de clima organizacional, ma-
pas de competência, workshops e análise de perfis psicológicos.
Esforços para avaliar a interação entre pessoas costumam ser recompensados
com uma melhor identificação e correção de problemas, e também com uma maior
produtividade da equipe. Eles também ajudam a combater os efeitos de problemas re-
correntes em equipes de projetos, tais como a falta dos recursos humanos idealizados
e as constantes mudanças na composição da equipe (ela pode mudar várias vezes ao
longo das fases do projeto).
Em muitos casos, avaliar e promover a interação entre profissionais de um proje-

to se baseia mais em “arte” do que em técnica. Esse fator se torna ainda mais evidente
quando é preciso lidar com aspectos culturais, sociais e comportamentais para formar
uma equipe de projetos. Por exemplo, em projetos internacionais (em que atuam pro-
fissionais de diversas nacionalidades e culturas), para algumas pessoas, criticar aberta-
mente uma ideia ou um colega demonstra proatividade, engajamento e contribuição;
já para outras, essa atitude é considerada uma grande ofensa. Caberá ao gestor ter
sensilidade para perceber as diversidades culturais, educacionais etc. e, quem sabe, até
convertê-las em vantagens para o bom funcionamento da equipe.
6.1.4 Modos de trabalho em equipe e distribuição de responsabilidades

O trabalho em equipe exige um esforço de coordenação bem estruturado e docu-
mentado. Nesse sentido, o PMBOK (PMI, 2013) cita três tipos de formatos de documenta-
ção: o hierárquico, o matricial e o textual.
O formato hierárquico é semelhante a uma Estrutura Analítica do Projeto (EAP),
mas com foco na hierarquia. O documento usual é uma Estrutura Analítica da Organização
(EAO), acompanhada de uma descrição de funções, conforme a figura a seguir.
Gerente
A1
P1 P2 P3
P21 P22 P23 P31 P32

P11
P12 P231 P321
P232
Descrição de Funções
Função:
Responsabilidades:
Autoridade:
Esse formato descreve as funções relevantes para os projetos, indicando depar-

tamentos, unidades ou equipes da organização na EAO. Ele permite, por exemplo, que
cada departamento mapeie todas as suas atividades correntes em projetos.
O formato matricial relaciona profissionais de projetos (ou departamentos, equi-
pes, assessores etc.) com as atividades ou pacotes de trabalho de um projeto. Sua re-
presentação típica é a Matriz de Responsabilidades, um instrumento usualmente
empregado na gestão do escopo do projeto e ilustrado a seguir.
Matriz de Responsabilidades para um projeto de suprimento.

TAREFAS/Quem P1 P2 P3 P4 P5 P6 P7 P8 P9 P10
Projeto de Suprimento G
- Fornecedores internos G I
- Pessoal G E, I
- Materiais E G
- Infraestrutrua G E
- Fornecedores externos G, A I E, I
- Pessoal G E
- Informações G E
- Equipamentos G E
G – Gerencia E – Executa A – Aprova I – É informado
Nesse exemplo, em particular, as principais responsabilidades em um projeto são:

Gerencia, Executa, Aprova e É informado. Outras matrizes de responsabilidades podem
incluir atribuições distintas, tais como: Responde por, Controla, Valida, Informa, Aceita etc.
A matriz de responsabilidade facilita principalmente a organização entre os participantes
de um projeto. Outros benefícios que ela proporciona são a facilidade de comunicação e a
rápida identificação da carga de trabalho de cada membro da equipe (KERZNER, 2011). Ela
deve ser atualizada quando houver mudança no escopo do projeto.
O formato textual consiste em documentos ou fichas que listam e descrevem as
responsabilidades nas atividades de um projeto (VARGAS, 2009). Sua principal carac-
tertística é o detalhamento das descrição das funções no projeto. Enquanto os forma-
tos anteriores se pautam pela representação visual das informações, o formato textual
enfoca a exatidão e facilita o registro, a busca e a indexação de informações segundo
estruturas de bancos de dados.
6.2 Coordenação e controle de equipes

Equipes de projeto precisam de coordenação, atualização e manutenção. Por cau-
sa da especificidade dos projetos (produtos únicos, equipes temporárias etc.), há a ne-
cessidade de se estudar as características de novos produtos, aprender novos termos e
adaptar métodos de trabalho.
6.2.1 Treinamento, capacitação e manutenção da equipe

É bastante comum que os participantes de uma equipe de projetos precisem de
algum treinamento ou capacitação sobre o projeto no qual irão trabalhar. Por exemplo,
em um projeto de software para desenhos de engenharia, conceitos e siglas específicas
da área gráfica devem ser interpretados e padronizados para o produto em desenvolvi-
mento e, posteriormente, repassadas para a equipe do projeto.
Um plano de capacitação pode ser considerado um subprojeto de um projeto.
Ele pode incluir treinamentos, estudos autônomos, experimentações, simulações e até
certificações. Esse subprojeto pode conter, por exemplo (ICB3, 2006; SANTOS, 2006):
• Definição dos conteúdos das capacitações por pessoa.
• Indicação dos benefícios proporcionados e das deficiências trabalhadas.
• Cronogramas das capacitações.
• Avaliações, provas, certificados e aplicações práticas previstas.
• Custos e análise comparativa do custo-benefício das capacitações.
• Programação de captação e gastos dos recursos financeiros.
• Contabilização dos custos (definir quem paga as contas e como).
• Aquisição das capacitações (se internas, do mercado ou de parceiros).
A manutenção envolve todos os esforços para proporcionar a coesão da equipe
e a criação de boas condições de trabalho. Em muitos projetos, esses esforços são es-
senciais para o sucesso (KERZNER, 2009) e consomem parcelas consideráveis do or-
çamento do projeto. Os esforços para manutenção da equipe não visam apenas ao
projeto em andamento. Empresas que empreendem muitos projetos realizam ações
para motivar os bons profissionais a aceitarem, no futuro, o convite para integrarem
novos projetos.
Em projetos que exigem muita criatividade, os gastos para promover um bom ambiente para
a equipe de desenvolvimento podem incluir viagens, estadias em resorts, alimentação em am-
bientes exclusivos, jantares sofisticados etc. Esses benefícios demonstram o reconhecimento
dos membros da equipe do projetos.
6.2.2 Avaliação de desempenho da equipe

A avaliação de desempenho busca verificar se a equipe do projeto consegue equi-
librar o binômio eficácia versus eficiência. Equipes podem ser eficazes às custas do
superdimensionamento de recursos – o que contribui para minimizar os riscos de fra-
casso. Por outro lado, recursos superabundantes implicam desperdícios e perdas de
eficiência do projeto. Esse dilema decorre da necessidade de balancear eficácia e efi-
ciência. A avaliação da eficácia se baseia em indicadores, tais como:
• o desenvolvimento de habilidades e competências pessoais;

• a quantidade de recursos planejados;
• o desenvolvimento da coesão da equipe;
• o emprego de ferramentas e recursos de apoio (software etc.).
Já a avaliação da eficiência busca verificar:
• a quantidade de recursos empregados para determinada tarefa;
• a quantidade de recursos empregados para um determinado produto;
• o valor do produto ou da tarefa realizada por unidade de investimento;
• as diversas medidas da competitividade do produto gerado.
Além da eficácia e da eficiência, o risco também deve ser avaliado: uma equipe
pode ser eficiente e eficaz, mas às custas de expor o projeto a riscos muito elevados.
No desenvolvimento de um projeto, o desempenho da equipe deve ser regular-
mente verificado e, se necessário, ações corretivas adotadas.
6.2.3 Conflitos e recompensas

Conflitos decorrem de situações antagônicas, quando é necessário tomar alguma
decisão entre opções incompatíveis. As características peculiares dos projetos (tempo
escasso, equipes multidisciplinares e até multiculturais, trabalho temporário etc.) favo-
recem o surgimento de conflitos. É da responsabilidade do gerente de projetos admi-
nistrar os conflitos, no sentido de minimizá-los ou até tirar proveito deles.
A gestão de conflitos é tratada no RBGP (SANTOS; CARVALHO, 2005, p. 70)
como “a arte de lidar criativamente com conflitos”. Daí, deduz-se que o tratamento
dos conflitos em projetos depende menos de técnicas e mais de habilidades pessoais.
Conflitos podem surgir porque usualmente um projeto abrange grande quantidade de
stakeholders e porque nele as pessoas interagem intensamente, sem muito tempo de
preparação.
O PMBOK (PMI, 2013) cita cinco técnicas para tratar conflitos:
• Recuar/Evitar: sair de uma situação de conflito, evitando-a ou adiando-a.
• Suavizar/Acomodar: enfatizar os pontos em comum, não as diferenças.
• Comprometer/Reconciliar: buscar soluções para a satisfação de todos.
• Forçar/Direcionar: forçar um ponto de vista à custa de outro (ganha-perde).
• Colaborar/Resolver o problema: incorporar várias opiniões na solução.
O projeto de implantação de uma estátua em uma praça pública de uma pequena
cidade paulista ilustra situações de conflito. O projeto devia atender aos interesses dos
cidadãos, dos políticos, do artista e das leis locais. Como a verba disponível era muito
limitada (R$ 180 mil), surgiu um conflito quanto às prioridades do projeto (mais verba
para a publicidade, para o artista, para a segurança da obra, para ajardinamento em tor-
no da estátua etc.) e a quem seria creditada a obra pronta. Em caso de impasse, todos
acabariam perdendo. Aplicando as técnicas recém-citadas nesse caso real, as seguintes
soluções são esboçadas: (1) cancelar o projeto, (2) concentrar os gastos nos itens impor-
tantes para todas as partes (a estátua em si?), (3) propor uma solução que contemple um
pouco de cada interesse (do artista, do político etc.), (4) verificar quem decide de fato e
priorizar seus interesses ou (5) realizar uma pesquisa de opinião para tentar incorporar
no projeto as preferências mais diversas. Dentre essas técnicas, não há uma sempre cor-
reta ou ideal. A escolha é função do projeto e até do perfil do gerente.
O plano de gerenciamento de recursos humanos pode prever a atribuição de
recompensas para os profissionais de projetos. Os critérios para a atribuição de re-
compensas devem ser tão claros, objetivos, indiscutíveis e justos quanto possível.
Contudo, costuma ser muito difícil estabelecer tais critérios, dada a constante presen-
ça de conflitos entre as metas do projeto.
O gerenciamento de projetos direcionado ao negócio trata desse problema com
relativa facilidade quando emprega critérios de recompensa baseados no sucesso do
negócio. Por exemplo, a recompensa por cumprimento do prazo, em um projeto de
construção civil, opõe-se ao cumprimento das metas da qualidade: quanto mais se
apressa a obra, mais provável será que a qualidade do produto diminua (conflito análo-
go ocorre com escopo e custo).
Ao se estabelecer a recompensa com base na satisfação do cliente com um
tradeoff “adequado” entre as metas do projeto, pode-se recompensar a equipe pelo
sucesso total do projeto, e não apenas pelas metas de prazo (SANTOS, 2015). Assim,
promove-se a recompensa com base no “comprometimento comum” e evita-se o con-
flito entre metas específicas. Por outro lado, quando um critério de recompensa é
muito preponderante em relação aos demais (por exemplo, o prazo no projeto de um
evento), esse critério domina os outros. Sendo projetos empreendimentos temporá-
rios, é importante promover o reconhecimento da equipe ainda durante seu ciclo de
vida, e não depois depois do término.
6.2.4 Apoio e monitoramento de equipes

Em projetos, não se tem tempo para errar. Por empregarem estruturas provisó-
rias e gerarem produtos únicos, projetos envolvem necessariamente algum grau de ex-
perimentação e inovação, mas devem ser capazes de apresentar respostas rápidas e
eficazes aos problemas que inevitavelmente surgirão. Nesse processo, é fundamental
que a equipe do projeto conte com apoio e monitoramento constantes.
Cabe ao gerente de projetos não só encontrar soluções para os problemas jun-

to com sua equipe, mas também capacitá-la e delegar autoridade para que ela mesma
consiga detectar problemas, propor soluções e avaliar os resultados desse processo.
Algumas ações para auxiliar essa tarefa se destacam (PMI, 2013; OGC, 2009; SANTOS;
CARVALHO, 2006; IPMA, 2006):
• Promover o desenvolvimento de lideranças e autogestão.
• Estabelecer canais de comunicação formal e informal.
• Definir critérios amplamente aceitos para tomadas de decisão.
• Propor e aprovar regras de convivência e procedimentos de trabalho.
• Verificar periodicamente o engajamento dos profissionais da equipe.
• Aceitar críticas e contribuições da equipe, sem prejudicar as metas.
Um gerente de publicidade possuía alto desempenho, grande brilho pessoal e uma equipe mo-
desta e de baixo custo. Seu sucesso, nesse caso, era de alto risco. Ao trocar sua equipe por ou-
tra bem mais capacitada e de maior custo, ele pôde se dedicar mais ao negócio, o que diminuiu
os riscos do projeto.
O monitoramento de equipes de projetos pode empregar ferramentas também

usadas para monitorar equipes permanentes em sistemas de produção. Contudo, em
projetos, a composição da equipe pode se alterar rapidamente, de modo que referên-
cias históricas de produtividade, medidas de eficiência etc. têm menor utilidade. Essa
situação favorece o emprego do controle por metas ou objetivos alcançados. Ela tam-
bém valoriza a comunicação como instrumento de apoio ao trabalho em equipe.
6.3 Gestão da comunicação

Profissionais experientes costumam dizer que, no “gerenciamento de projetos,
90% dos esforços são destinados à comunicação”. Embora soe exagerado, essa afirmação
representa o papel da comunicação para essa área (CARVALHO; RABECHINI JR., 2011).
Comunicação envolve a transmissão efetiva de informações e a interação entre os
agentes transmissor e receptor. Ela é fundamental na criação de condições adequadas para
promover a motivação, o trabalho e as decisões do receptor (SANTOS; CARVALHO, 2006).
A comunicação em projetos pode ocorrer de várias maneiras (escrita, oral, gráfica,
sonora etc.) e por diversos meios (eletrônicos, verbais, escritos, gestuais etc.).
No projeto da implantação das normas ISO 9000 em uma granja, muitos dos funcionários res-
ponsáveis por recolher os ovos eram completamente analfabetos. Por isso, as instruções ne-
cessárias para a implantação da certificação foram documentadas utilizando-se desenhos.
No âmbito dos projetos, a comunicação ocorre frequentemente em seminários,

encontros, conferências, conversas e reuniões, na troca de opiniões, mensagens e re-
latórios. Frequentemente, desenvolvem-se linguagens próprias para tornar a comu-
nicação mais eficiente e eficaz. Por exemplo, no projeto de um software de apoio a
diagnósticos médicos foi necessário criar dicionários e linguagens específicas. Eles fa-
cilitaram o trabalho dos stakeholders com diferentes formações e atuações, principal-
mente os desenvolvedores e usuários.

Um modelo de comunicação representa os principais componentes que atuam
em um processo de transmissão de informações.
O modelo básico de comunicação mais conhecido (também na comunicação em
gerenciamento de projetos) é representado na figura a seguir.
Modelo básico de comunicação

Mensagem Transmitida
Codificador RUÍDO Decodificador
RUÍDO confirmação

Emissor Receptor
MEIO
Decodificador Codificador
resposta
RUÍDO
Na codificação, os pensamentos e ideias são convertidos em linguagem pelo

emissor. Na transmissão da mensagem, as informações são enviadas pelo emissor
através do meio; nesse processo, parte das informações pode ser perdida ou distorci-
da por causa de ruídos (causados geralmente por dificuldades com a linguagem e com
a tecnologia empregada, bem como por diversidade cultural e de formação dos agen-
tes envolvidos). Na decodificação, a mensagem é convertida pelo receptor em pen-
samentos ou ideias. Na confirmação, o receptor sinaliza que recebeu a mensagem
sem, contudo, garantir que ela foi entendida adequadamente. Na resposta, o recep-
tor codifica ideias e pensamentos em uma mensagem e a transmite ao emissor origi-
nal (PMI, 2013).
Segundo o modelo apresentado, na comunicação podem ocorrer diversos proble-
mas. Alguns deles são relacionados na tabela a seguir, que também indica sugestões
para minimizá-los.
Problemas típicos na comunicação

Problemas Consequências Sugestões
O emissor não transforma Falta de habilidade do emissor Capacitação na linguagem ou na
ideias em mensagens. na linguagem ou nas ideias. formulação do conteúdo.
Ruídos distorcem o conteúdo Informação chega diferente da- Diminuição de ruídos: melhores
da informação. quela que foi emitida. tecnologia ou capacitação.
O meio não permite rápida Melhorias no meio: tecnologia, in-
Informação chega atrasada.
transmissão. fraestrutura.
A decodificação é diferente Mensagem é decodificada de Padronização dos processos de
da codificação. maneira distinta. codificação e decodificação.
Falta de confirmação do re- Insegurança do emissor sobre o Padronização da prática de confir-
ceptor. recebimento; atrasos. mação.
Resposta não corresponde à Emissor recebe resposta de ou- Na confirmação, informar como
mensagem original. tro problema. chegou a mensagem.
A decodificação não usa a Mensagem recebida difere da- Padronização da chave de codifi-
mesa chave da codificação. quela emitida. cação/ decodificação.
O meio impõe muitas dificul- Atrasos, perda da qualidade da Pesquisas de melhorias no meio,
dades. mensagem, ruídos. desistência da comunicação.
O seguinte exemplo ilustra a aplicação do modelo da comunicação apresentado.

Em um um julgamento criminal, duas testemunhas-chave são polonesas e seus de-
poimentos devem ser traduzidos para o português. Como se trata de um caso de ho-
micídio, qualquer imprecisão na tradução pode implicar graves consequências. Para
garantir boa qualidade na tradução, os depoimentos em polonês são inicialmente ver-
tidos para o português, por um tradutor A. O texto traduzido é então vertido para o
polonês, por um um tradutor B. A versão polonesa resultante é então comparada com
o depoimento original e só então submetida à aprovação dos depoentes. Esse procedi-
mento tem por finalidade garantir que os depoimentos e suas nuances foram bem en-
tendidas pelo tribunal brasileiro.
6.3.2 Plano da gestão da comunicação

O planejamento das comunicações em um projeto inclui o desenvolvimento de uma
abordagem para as comunicações e um plano de gestão da comunicação específico para
esse projeto. Os principais benefícios são a formação e a documentação de uma aborda-
gem de comunicação para as partes interessadas, e também entre elas. O plano de ges-
tão da comunicação pode apresentar elementos, tais como (KERZNER, 2011):
1. Necessidades da comunicação
(Definir os stakeholders e os respectivos benefícios da comunicação.)
2. Motivos da distribuição das informações
(Justificar por que as informações devem ser distribuídas e por quais métodos.)
3. Métodos do gerenciamento das comunicações
(Definir os métodos de transmissão/recepção.)
4. Formatos das informações

(Especificar idioma, termos técnicos, padrões de texto/áudio/vídeo, linguagem etc.)
5. Formatos e meios de comunicação
(Definir formas e tecnologias de transmissão, com as devidas justificativas.)
6. Condições da comunicação
(Definir frequência de comunicação, urgências, contrapartidas, contratos.)
7. Autorizações para divulgação
(Definir pessoas responsáveis pela liberação e divulgação das informações.)
8. Fluxo e mapas das informações
(Representar os fluxos de informações.)
9. Recursos disponíveis
(Definir recursos destinados à comunicação, bem como suas fontes e condições.)
10. Processamento das informações
(Definir como as informações coletadas serão processadas, modificadas, adaptadas.)
11. Distribuição das informações
(Definir como as informações serão distribuídas. Usar a matriz de comunicação.)
12. Restrições e acesso
(Definir permissões de acesso e restrição a informações.)
13. Documentação e acesso
(Definir como as informações serão documentadas e acessadas.)
(Indicar as boas experiências e oportunidades de melhoria para projetos futuros.)
Outras informações relevantes podem ser incorporadas ao plano de gestão da co-
municação em função das necessidades específicas do projeto. O emprego sistemáti-
co do plano tem como principais benefícios evitar atrasos no projeto e permitir que ele
atinja suas metas com mais facilidade.
6.3.3 Modelos e métodos

O gerenciamento da comunicação inclui a criação, a coleta, a distribuição o ar-
mazenamento, a recuperação e até o descarte seletivo de informações de um projeto.
Essas tarefas são facilitadas quando realizadas com base em modelos e métodos con-
sagrados e padronizados. A seguir, alguns deles são comentados.
Métodos de comunicação:
• Comunicação ativa: enfoca a distribuição. O emissor busca atingir o receptor
com base em telefonemas, e-mails, cartas, relatórios, malas-diretas, apresen-
tações, blogs. Não há garantia da entrega da informação.
• Comunicação passiva: o emissor coloca a informação para ser buscada pelo

receptor em websites, repositório de lições aprendidas, publicações em biblio-
tecas, ouvidorias, serviço de atendimento a clientes.
• Comunicação interativa: existe intercâmbio de informações entre emissor
e receptor. Emprega os instrumentos das outras duas modalidades, mas com
foco na rapidez da transmissão, para facilitar diálogos e interações.
• Reuniões: permitem o diálogo, as discussões criativas, o engajamento, a criati-
vidade e o desenvolvimento do comprometimento.
Um exemplo de aplicação dos modelos apresentados é fornecido por uma em-
presa de expedição, concorrente dos Correios no segmento de encomendas. Essa nova
empresa necessita divulgar seu nome no mercado e, para tanto, desenvolveu um siste-
ma de comunicação ativa baseado em mala-direta a clientes potenciais, apresentações
em empresas e outdoors espalhados nas capitais onde atua. Para a comunicação passi-
va, ela encomendou um portal, um forte serviço de atendimento a clientes (SAC), um
serviço de rastreamento automático e uma ouvidoria. Para apoiar seu diferencial de
ótimo contato com o cliente, a empresa criou um sistema de atendimento interativo,
baseado em acesso telefônico, atendimento on-line e até um fórum 24h de discussões
de soluções personalizadas. Como o serviço de entrega é fortemente baseado em con-
fiança e agilidade, a empresa usa a comunicação para reforçar estes atributos como di-
ferencial competitivo.
6.3.4 Comunicação no trabalho à distância

A crescente complexidade e abrangência dos projetos exige, muitas vezes, que
pessoas situadas em diferentes ambientes (empresas, cidades, países) atuem em con-
junto, de maneira síncrona ou assíncrona (RBGP, 2006). O trabalho colaborativo à
distância em projetos busca coordenar e controlar atividades desenvolvidas por parti-
cipantes de equipes de projetos que se encontram em locais distintos.
O conceito de “distância” é muito relativo nesse caso. Tanto os profissionais de
uma equipe de projetos internacional podem estar distantes quanto aqueles que se si-
tuam em dois bairros de uma mesma cidade, mas possuem dificuldades para se reunir
presencialmente. Ambos podem se beneficiar com as técnicas do trabalho à distância
e empregar as mesmas metodologias de comunicação.
O trabalho à distância não apresenta apenas desvantagens por causa da distân-
cia. Ele pode também explorar novas vantagens, inexistentes no trabalho convencio-
nal presencial. Por exemplo, a Volkswagen desenvolveu o programa “Engenharia 24
horas”, que consiste em trabalhar em projetos ininterruptamente. Os trabalhos de um
projeto iniciados na Alemanha, por exemplo, são repassados para algum país da Ásia
no final do expediente alemão. Posteriormente, eles continuam a ser desenvolvidos
nos Estados Unidos ou no Brasil depois do final do expediente chinês e voltam para a
Alemanha depois do expediente americano ou brasileiro. E assim ele se desloca conti-
nuamente por países com diferentes fusos horários.
Algumas das ferramentas utilizadas na comunicação do trabalho à distância são:
correio eletrônico, videoconferência, sistemas de apoio à decisão, sistemas de apoio a
reuniões, editores cooperativos, sistemas para gerenciamento de documentos eletrô-
nicos e workflow. Devido ao contínuo desenvolvimento de novas tecnologias de comu-
nicação, o trabalho à distância sempre conta com novas ferramentas.
Esse tipo de trabalho tem se tornado mais comum ultimamente, pois apresenta
baixo custo, participação de grande diversidade de profissionais e alta eficiência. Suas
deficiências naturais (falta de contato “olho no olho”, impessoalidade, dificuldade para
construir confiança etc.) têm sido paulatinamente reduzidas pelos recentes desenvolvi-
mentos tecnológicos (videoconferências, chamadas com imagens etc.).
6.4 Controle da comunicação

O controle da comunicação prevê o monitoramento e as ações necessárias para
uma comunicação adequada ao longo dos projetos. Ele garante um fluxo ideal de in-
formações entre todos os participantes e também com as pessoas externas a ele. Por
causa das constantes mudanças nos projetos, não basta apenas planejar e executar as
tarefas da comunicação, também é crucial controlá-las adequadamente.
6.4.1 Sistema de gestão da informação

Um sistema para distribuir informações trabalha com um conjunto de métodos e
ferramentas que permite ao gerente de projetos coletar, processar, distribuir e arma-
zenar informações sobre o projeto. Hoje em dia, muitos desses sistemas se baseiam
em aplicativos de software (existem várias marcas comerciais no mercado), que permi-
tem a emissão de documentos de diversos tipos. Alguns deles são:
• Relatórios: escritos, com redação e análises.
• Planilhas: informações numéricas com cálculos automáticos.
• Bancos de dados: registros para classificação e acessos indexados.
• Gráficos: representações autônomas ou vinculadas a tabelas/ textos.
• Esboços: gráficos e desenhos interativos com facilidade de edição.
Entre as vantagens do uso de sistemas de gestão da informação em projetos se
destacam:
• a rapidez: para buscar, armazenar e recuperar informações;
• a capacidade de armazenamento: suficiente até para projetos complexos;
• a facilidade de buscas: por indexação, combinação e pesquisa de resultados.
6.4.2 Matriz de comunicação

Projetos pouco complexos usualmente não possuem dificuldades relativas à co-
municação: os problemas se resolvem informalmente e até individualmente. Já proje-
tos complexos exigem maiores esforços para garantir uma comunicação de qualidade.
Um projeto militar para atacar instalações inimigas depende fundamentalmente de uma exce-
lente gestão da comunicação e gasta uma considerável parcela dos recursos totais da operação
justamente nessa área.
Uma ferramenta relevante para a gestão da comunicação em projetos é a matriz

de comunicação, ilustrada na tabela a seguir.
Matriz de comunicação de um projeto

Tipo de
Objetivos Meio Frequência Público Responsável Entregas
comunicação
Patrocinador,
Reunião gerente do Gerente do Ata de
Iniciação Presencial Única
inicial projeto, projeto reunião
stakeholders
Reunião de Rever e ple- Presencial/ Equipe Gerente do Ata de
Semanal
equipe nejar telecom projeto projeto reunião
Reuniões Desenvol- Se preciso/ Pessoal Ata de
Presencial Líder técnico
técnicas ver, rever mensal técnico reunião
Reuniões se- Conferir, Presencial/ Equipe pro- Gerente do Ata de re-
Semanal
manais planejar telecom jeto projeto união
Equipe,
Relatório de Relatar, E-mail/ Gerente do Relatório
Bimensal patrocinador,
situação avaliar website projeto de situação
stakeholders
Fonte: VIEIRA et al. (2011). (Adaptado).
Os itens de uma matriz de comunicação podem e devem ser adaptados aos inte-
resses específicos de um determinado projeto. Por exemplo, um projeto que trate de
temas sensíveis à mídia pode incluir a coluna “Autorização para divulgação externa”.
Uma outra forma de apresentar a matriz de comunicação lista os stakeholders na pri-
meira coluna. Ela exige a elaboração prévia de uma pesquisa de stakeholders (TRENTIM,
2013) e seus interesses como base para a matriz de comunicação. Keeling (2010) ilustra,
nesse sentido, o projeto da pista de um aeroporto, conforme a tabela a seguir.
Matriz de comunicação do projeto: pista de um aeroporto

Grupos de O que o grupo
Foco Método Quando
interessados precisa saber
Públicos e Interesses Informações Reuniões, No início e pe-
periféricos individuais gerais circulares riodicamente
Pessoas a serem Pacotes de Impactos sobre Reuniões, entre- Após decisão
deslocadas indenização pessoas vistas individuais final sobre pista
Governo e diretor Dados Custos, méto- Discussões, do- Em todos os
da aviação civil operacionais dos, prazos cumentos do marcos
projeto
......................... ..................... ......................... ......................... .........................
Gerente do pro- Controle Atualização e Reuniões diárias, Diariamente e
jeto, líderes de progresso diários atualizações sob demanda
equipe on-line
Fonte: KEELING, 2010. (Adaptado).
Outras formas de matriz de comunicação podem ser usadas, considerando-se as

características particulares de cada projeto e as preferências de quem elabora a ma-
triz. Algumas organizações padronizam o formato da matriz de comunicação.
6.4.3 Avaliação de desempenho

Um sistema de comunicação consome recursos que não podem ser desconsidera-
dos. Por isso, ele sempre procura equilibrar os benefícios que proporciona com os cus-
tos que gera para o projeto.
Os principais benefícios do controle da comunicação incluem a confiabilidade e a
qualidade das informações para o projeto. Falhas nesse sentido resultam em enormes
prejuízos ao projeto, seja por desperdícios ou por danos. Por exemplo, grandes proje-
tos de construção civil se baseiam em complexos sistemas de previsão de chuvas, com
precisão de minutos e cruzamento de informações de diversos serviços meteorológi-
cos. Isso permite que, por exemplo, as concretagens a céu aberto possam ser plane-
jadas com mais segurança, evitando-se atrasos e perda de materiais. Analogamente,
mal entendidos entre equipes de projetos que trabalham virtualmente costumam ge-
rar retrabalhos caros e atrasos nas entregas dos produtos.
Uma questão crucial sobre o desempenho do controle da comunicação em proje-
tos é se ele é adequado, ou seja, suficiente, mas sem desperdícios. Para verificar essa
questão, procura-se:
• Analisar custos e benefícios de propostas alternativas para o controle da comu-
nicação: no mínimo três propostas são esboçadas e orçadas.
• Realizar análise de sensibilidade: a partir de uma proposta básica, incrementa-
-se/simplifica-se a comunicação e verificam-se os impactos.
• Analisar os riscos do sistema: o superdimensionamento pode se justificar em
muitos projetos se o impacto da falha de comuniação for grande.
• Consultar equipes de especialistas no assunto para avaliar o nível do controle

das comunicações de projetos específicos.
Os níveis de desempenho do sistema de comunicação podem, portanto, va-
riar de um projeto para outro, sendo difícil a adoção de padrões rígidos para seu
dimensionamento.
6.4.4 Ações para melhoramento

Em função da avaliação de desempenho do sistema de comunicação em um pro-
jeto, é desejável ou mesmo necessário introduzir melhoramentos no sistema e estes
exigem ações que usualmente incluem:
• treinamento da equipe e de indivíduos – em idiomas, técnicas de comunicação,
redação, software, sistemas próprios etc.
• aquisição de sistema de comunicação – software, aplicativos etc.
• investimento em equipamentos – sistemas de transmissão de dados, sistemas
de voz e troca de mensagens, aparelhos de teleconferência etc.
• desenvolvimento de padrões – linguagens, códigos, procedimentos etc.
• avaliação periódica da comunicação – reuniões, opiniões de especialistas, his-
tóricos de falhas, análises de risco, avaliação de benefícios etc.
As ações para melhoramento são coordenadas com as avaliações de desempenho
do sistema de comunicação.
Em um projeto de um evento entre Suécia e Brasil, questões culturais causaram grandes atra-
sos e prejuízos, pois os suecos evitavam cobrar muito aquilo que já havia sido combinado por
julgarem desnecessário e pouco cordial; já os brasileiros esperavam confirmações e cobranças
antes de prosseguir.
Como ações de melhoramento nos sistemas de comunicação podem envolver al-

tos investimentos (por parte do projeto ou da organização permanente que o abriga),
elas se deparam com um conhecido dilema: o custo de fazer versus o custo de não fa-
zer. Essa questão pode ser ampliada para “até onde vale a pena investir em um sistema
de comunicação”.
Aí consideram-se não apenas os benefícios para o projeto em andamento, mas
também para projetos futuros. Algumas dessas vantagens são: mais rapidez na comu-
nicação, menor custo para aquisição e tratamento de informações, padronização do
sistema de comunicação e maior participação dos profissionais de projetos, entre ou-
tras. O dimensionamento do sistema de comunicação de um projeto envolve custos
que serão pagos pelo projeto, por um conjunto de projetos ou pela organização per-
manente – ou uma combinação entre essas partes.
Referências
dores. Saraiva, São Paulo, 2011.
21, n. 1, 2013.
HEDEMAN; B, et al. Project Management Based on PRINCE2®: an introduction.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK®). Toronto:
2012.
2009.
________. Um guia do conhecimento em gerenciamento de projetos: guia PMBOK®.
4. ed. Newtown Square, PA: PMI, 2008.
2005.
Projetos, v. 2, 2013.
VARGAS, R. V. Gerenciamento de Projetos: estabelecendo diferenciais competitivos.
7. ed. Rio de Janeiro: Brasport, 2009.
VIEIRA, M.A., VIEIRA, D.A. VIEIRA, D.R. Estruturação da comunicação em projetos:
fundamentos e case. In: Revista MundoP, ano 7, nº 37, pag. 24 - 29, 2011.
7 Riscos
Projetos sempre buscam alcançar metas – sejam elas do projeto (escopo, qualida-
de, custos, prazos etc.) ou do negócio do projeto (lucratividade, satisfação, visibilidade
etc.). A busca das metas envolve processos permeados por ameaças e incertezas – ele-
mentos estes que caracterizam os riscos.
Embora a noção de risco possa ser definida de maneira intuitiva (por exemplo,
andar por uma rua escura e deserta provoca uma sensação de risco), em projetos são
necessárias abordagens mais objetivas sobre o assunto. Isso porque as medidas para
tratar, prevenir ou evitar riscos podem envolver altos investimentos e, portanto, preci-
sam de argumentos mais palpáveis do que a mera intuição.
Alguns tipos de riscos mais comuns são: financeiros, técnicos, econômicos, polí-
ticos, ambientais, de atraso, da má qualidade, de danos à imagem etc. Esses riscos es-
tão presentes em todo o ciclo de vida de um projeto, embora sejam mais visíveis em
algumas fases – por exemplo nos estudos de viabilidade (HABER, 2004).
Neste capítulo, apresentam-se conceitos, técnicas e modelos úteis para um tra-
tamento mais objetivo da gestão de riscos em projetos. Essa abordagem facilita o tra-
balho em equipe, as tomadas de decisão e a previsão do sucesso de um projeto. No
entanto, não se excluem os métodos baseados na subjetividade (muito importantes
também) e procura-se enfatizar aqueles com maior grau de racionalidade.
No projeto de uma ponte, admite-se que ela possa ser destruída por cheias e causar mortes. O
número de mortes estimado diminui quanto mais reforçada (e cara, talvez) for a ponte. Assim,
é possível estimar qual é o valor que se atribui a uma vida humana, em função do que se quer
investir no projeto.
Infelizmente, diversos projetos não contêm uma análise de riscos sistemática, e um

dos motivos para isso pode ser a aversão a cálculos estatísticos e a análises quantitati-
vas. Assim, esses projetos podem deixar de adotar até mesmo medidas básicas sobre ris-
cos, como a elaboração de planos de contingência. Sobre essa questão ressalta-se que
uma análise de risco, quando realizada de maneira modesta mas consistente e abrangen-
te, ainda é melhor do que nenhuma.
7.1 Conceituação e identificação de riscos

Por ser um conceito com alto grau de subjetividade (cada pessoa interpreta de ma-
neira individual), o risco em um projeto torna-se difícil de padronizar, identificar, anali-
sar e tratar. Além disso, um projeto “sem riscos” ou com riscos ínfimos pode ser muito
caro. Portanto, é esperado que os projetos priorizem alguns riscos para serem tratados,
ao mesmo tempo que aceitam conviver com outros sem tratamento. Os passos iniciais
na gestão dos riscos consistem então em definir o que são riscos, identificar riscos po-
tenciais e escolher alguns deles para serem analisados com prioridade.

O conceito de risco é muito controverso na literatura técnica. Mesmo quando apli-
cado a uma área específica – por exemplo, no gerenciamento de projetos – não há una-
nimidade nas definições. Autores consagrados, tais como IPMA (2006), OGC (2009), PMI
(2013), Santos (1988), Carvalho e Rabechini Jr. (2011), Valeriano (2005) e Santos e Carvalho
(2006), empregam diferentes definições para riscos em gerenciamento de projetos. Alguns
deles associam um risco a um evento; outros a uma probabilidade; outros, ao impacto de-
corrente de um evento; e outros, a uma combinação desses conceitos.
Nesta obra, é importante que o conceito adotado para definir “risco” consiga, por
um lado, representar adequadamente os riscos de um projeto e por outro embasar cla-
ramente as estimativas dos riscos nos projetos. Assim, assumimos que risco, quando
associado a situações negativas, pode ser entendido como “a expectativa das perdas
decorrentes de um evento incerto”. Analogamente, uma medida do risco pode ser
associada ao “valor esperado das perdas decorrentes de um evento incerto”.
Essas definições facilitam a estimativa dos riscos, seja ela qualitativa ou quantita-
tiva. Embora diversas outras definições de risco sejam encontradas na literatura técni-
ca, nenhuma dessas é tão útil quanto a do parágrafo anterior, para o cálculo de riscos
que serão apresentados nos próximos itens.
Ampliando-se a definição acima, risco pode ser formulado como a expectativa das
perdas e dos ganhos decorrentes de um conjunto de eventos incertos, em relação a va-
lores de referência. As perdas e ganhos admitem resultados tanto negativos (risco puro)
quanto positivos (chance). E a medida do risco é o valor esperado das perdas e dos ga-
nhos decorrentes de um conjunto de eventos incertos, em relação a valores de referência.
Essa abordagem mais ampla admite tanto os riscos negativos (perdas) quanto os
positivos (ganhos). Ela também considera não apenas um evento, mas um conjunto de
eventos relacionados entre si e que se associam a um risco. A menção a valores de re-
ferência é crucial para entender o risco em certos casos, como no exemplo seguinte.
O projeto de uma piscina é orçado em R$ 150 mil. A probabilidade de que ele
atrase duas semanas é 30% e de que adiante uma semana é 25%. No primeiro caso, ele
gera ao negócio perdas de R$ 20 mil, em relação ao valor de referência de R$ 150 mil.
No último caso, ele gera um ganho de R$ 5 mil. Nesse exemplo, se o custo de mercado
da piscina for R$ 100 mil, em qualquer caso o projeto apresentará perdas para o negó-
cio (R$ 70 mil se atrasar duas semanas, R$ 45 mil se adiantar uma semana e R$ 50 mil
se terminar no prazo). Nesse caso, o risco para o negócio é sempre negativo, pois o va-
lor de referência para o custo é agora R$ 100 mil.
Um risco não é um evento, tampouco sua probabilidade de ocorrência. Sendo de-
finido como “expectativa”, um risco também admite avaliações subjetivas (BENZANI;
FALCON, 1987).
A medida do risco usualmente emprega valores monetários. Mas ela também
pode ser associada a outras variáveis, algumas delas objetivas (número de acidentes
em uma obra) e outras subjetivas (prejuízos à reputação da empresa). Nas análises,
tenta-se converter as variáveis dos riscos em valores monetários equivalentes. Mas às
vezes essa é uma tarefa difícil ou até mesmo impossível – por exemplo, quando se fala
de vidas humanas ou de imagem institucional. O caso a seguir ilustra esse assunto.
No projeto de resgate de 28 mineiros soterrados, estima-se que a desobstrução de
um poço vertical consumirá 8 dias. Há uma expectativa de 7 óbitos (25% dos mineiros)
por falta de ar. Uma solução B, alternativa, prevê o uso de um potente equipamento
para abrir um novo túnel paralelo, que possibilita o resgate em 3 dias e o salvamento de
todos. Contudo, experiências anteriores indicam que essa operação pode causar des-
moronamento instantâneo, com a perda de todas as vidas – o que já ocorreu em 10%
das tentativas semelhantes. Rigorosamente, a solução com o equipamento potente
possui uma perda esperada menor (10% de 28 vidas, em vez de 7 vidas). Contudo, se for
escolhida a solução B, o impacto emocional com a morte de todos os mineiros seria ca-
tastrófico para a imagem do governo. Portanto, a solução A foi a escolhida.
7.1.2 Plano da gestão de riscos

Um plano de gestão de riscos tem por finalidade orientar a gestão sistemática
e bem fundamentada dos riscos de um projeto. Ele é parte integrante do plano de
gerenciamento do projeto e trata dos seguintes processos:
• a conscientização sobre a importância dos riscos em um projeto;
• a avaliação dos benefícios da análise de riscos;
• a sistematização da gestão dos riscos;
• a definição dos riscos;
• a identificação dos riscos;
• a avaliação qualitativa dos riscos;
• a avaliação quantitativa dos riscos;
• as tratativas dos riscos;
• o controle dos riscos.
Alguns elementos usualmente relevantes para um plano de gestão de riscos são:

1. Objetivos e justificativas da gestão de riscos no projeto
(Definir os objetivos da gestão de riscos e justificar os investimentos necessários.)
2. Responsabilidades pela gestão dos riscos
(Indicar quais pessoas participam da gestão dos riscos e quais papéis assumem.)
3. Estrutura analítica dos riscos (EAR)
(Definir as categorias dos riscos em diversos níveis, agrupados por afinidades.)
4. Identificação dos riscos
(Identificar os principais riscos para o projeto, o negócio e seus stakeholders.)
5. Definição da atitude em relação aos riscos
(Definir a atitude em relação aos riscos em função do apetite, da tolerância e
do limite.)
6. Análise qualitativa dos riscos
(Descrever para que serve e como realizar a análise qualitativa dos riscos.)
7. Construção de escalas para avaliar riscos
(Descrever como construir escalas para avaliar riscos.)
8. Matriz de probabilidade versus impacto
(Definir a matriz de probabilidade versus impacto para os riscos do projeto.)
9. Análise quantitativa dos riscos
(Descrever para que serve e como realizar a análise quantitativa dos riscos.)
10. Tratativas dos riscos
(Definir as respostas aos riscos e os critérios para justificar essas respostas.)
11. Monitoramento e controle dos riscos
(Descrever sucintamente como os riscos do projeto serão monitorados e
controlados.)
(Indicar as experiências e oportunidades de melhoria para projetos futuros.)
Outros procedimentos e informações importantes podem ser acrescentados ao
plano de gestão dos riscos em função das características específicas de cada projeto.
7.1.3 Identificação dos riscos

Uma dificuldade inicial na gestão dos riscos de um projeto é identificar os prin-
cipais riscos para posterior análise. Evitar pesquisar os riscos equivale a não consultar
um médico com receio de descobrir alguma doença grave e indesejável.
A identificação dos riscos pode contar com a participação do gerente, da equi-
pe do projeto, de clientes, fornecedores e outras partes interessadas. É um processo
constante, uma vez que novos riscos podem surgir ao longo do ciclo de vida do projeto.
No processo de identificação de riscos é usual verificar se há ameaças às metas

predefinidas para o projeto. Nesse sentido, algumas das principais fontes para identifi-
car riscos são as seguintes (PMI, 2013):
• Plano de gestão dos custos.
• Plano de gestão do tempo.
• Plano de gestão da qualidade.
• Plano de gestão das aquisições.
• Linha de base do escopo.
• Plano de gestão dos custos.
• Objetivos do projeto.
Analogamente, os riscos relacionados com o negócio do projeto (IIBA, 2009) se
baseiam em fontes como:
• Itens da satisfação dos stakeholders, com as respectivas metas.
• Itens da qualidade percebida, com as respectivas metas.
• Itens do escopo, com as respectivas metas.
• Itens dos custos, com as respectivas metas.
• Itens dos prazos de entregas, com as respectivas metas.
Algumas técnicas e procedimentos para a identificação dos riscos são:
• Técnicas de coletas de informação: brainstorming, Delphi, entrevistas, diagra-
mas de causa e efeito, históricos de riscos, entre outras que revelam ameaças
às metas do projeto e do negócio.
• Análise de listas de verificação (Checklists): emprega listas e modelos dispo-
níveis na organização, com riscos conhecidos.
• Análise de premissas: verifica a validade das premissas assumidas.
• Diagramas: de causa e efeito, fluxogramas, de influência etc.
• Análise SWOT: forças, fraquezas, oportunidades e ameaças.
• Opiniões de especialistas: baseadas na experiência profissional.
A própria identificação dos riscos já é um passo importante para conscientizar a
equipe de um projeto sobre a importância da análise dos riscos. Ela acaba reforçan-
do a necessidade de se tratar e controlar os riscos do projeto de modo mais sistemáti-
co e menos espontâneo. Por exemplo, um fabricante de balcões frigoríficos do Paraná
encanta seus clientes devido a sua agilidade: o cliente telefona, apresenta suas neces-
sidades e informa os dados técnicos do balcão que deseja; ainda durante a ligação,
ele recebe uma previsão do preço e do prazo de entrega do produto instalado. Um
checklist, aplicado durante a consulta telefônica, identifica os principais riscos do pedi-
do e indica os respectivos acréscimos de preço que devem ser cobrados.
7.1.4 Registro dos riscos

O registro dos riscos gera um documento de referência em que os riscos são con-
ceituados, identificados, priorizados, analisados e tratados. Alguns dos itens relevan-
tes do registro dos riscos, mencionados em (PMI, 2013) são:
• Conceitos e definições: dos riscos do projeto em questão.
• Lista dos riscos identificados: com indicações úteis, por exemplo, do tipo de
evento, das causas, dos efeitos potenciais, da severidade, da probabilidade,
dos desdobramentos etc.
• Lista dos riscos prioritários: com indicações dos riscos que serão eleitos para
um estudo detalhado (análise de riscos).
• Lista de prováveis tratativas: indicações preliminares de prováveis respostas
aos riscos, que serão depois analisadas com mais rigor.
O registro dos riscos não apenas facilita as decisões sobre os riscos do projeto em
andamento, mas também é útil para projetos futuros em condições semelhantes.
7.2 Análises qualitativa e quantitativa

Na análise de riscos, pesquisam-se a frequência e os intervalos de confian-
ça de determinados eventos, bem como estabelece-se o potencial de perdas (ou ga-
nhos) relativos a tais eventos, em termos físicos, financeiros e de responsabilidade
(JERÔNYMO, 1986). A análise qualitativa busca filtrar e priorizar os principais ris-
cos de um projeto para posterior estudo em profundidade na análise quantitativa
(VARGAS, 2009). Em muitos projetos, só a primeira análise é realizada, dada a maior
dificuldade para a elaboração de uma análise quantitativa.
7.2.1 Análise qualitativa dos riscos

A análise qualitativa classifica os riscos de um projeto mediante a combinação de
probabilidade e impacto relativos à ocorrência de um evento em risco. Como resulta-
do, identificam-se os riscos de mais alta prioridade, os quais serão quantificados na
análise quantitativa. Os resultados da análise qualitativa são revisados periodicamente
para se verificar sua validade e se as prioridades que eles estabelecem devem ser man-
tidas ou não.
Um instrumento típico da análise qualitativa de riscos em projetos é a matriz de
probabilidade e impacto. Ela se baseia na prévia estimação da probabilidade de ocor-
rência de um evento em risco e do respectivo impacto (usualmente, financeiro).
Estimação de probabilidades e impactos
A estimativa da probabilidade de ocorrência de um evento em risco prevê que se
atribua a ele probabilidade entre 0 e 1 (ou 0 e 100%) – por exemplo, a probabilidade de
queda de uma torre em construção. Alguns métodos úteis para esse processo são, por
exemplo:
• Opiniões de especialistas: profissionais experientes conseguem intuir ou esti-
mar com boa acurácia a probabilidade de ocorrência de um evento.
• Dados históricos: obtidos de projetos anteriores ou similares, bancos de da-
dos, trabalhos científicos, empresas seguradoras, entre outras fontes.
• Estimativas análogas: baseadas em projetos diferentes, mas com elementos
em comum com o projeto corrente.
• Simulação: principalmente quando a probabilidade depende de eventos con-
juntos, difíceis de serem analisados analiticamente.
• Técnicas de coletas de informação: brainstorming, Delphi, entrevistas, diagra-
mas de causa e efeito, históricos de riscos, entre outras que revelam ameaças
às metas do projeto e do negócio.
A estimativa do impacto (ou severidade) decorrente de um evento prevê que se
atribuam grandezas às consequências dos eventos em risco – por exemplo, o dano de-
corrente da queda de uma torre em construção. Usualmente, essas grandezas são mo-
netárias, mas também podem ser expressas em número de mortes, dias de atraso,
reclamações de clientes etc. Alguns métodos úteis para esse fim são:
• Os métodos mencionados para a estimativa das probabilidades.
• Cálculos contábeis: para valores de bens, imóveis e veículos.
• Pesquisa de valores de mercado: para estimativas com valores de mercado.
• Avaliação de custos de reposição: para gastos destinados a restabelecer uma
situação – por exemplo, a reconstrução de uma estrutura danificada.
• Cálculos de danos à imagem e responsabilidades: para valores subjetivos con-
vertidos em valores monetários por especialistas, juízes, peritos etc.
Tanto as estimativas das probabilidades quanto dos impactos podem empregar
parâmetros subjetivos, sem que isso implique menor confiabilidade para os resultados.
Por exemplo, publicações sobre tendências das preferências de consumidores são úteis
para projetos de design de produtos. Elas se baseiam em análises subjetivas de tendên-
cias e ajudam a diminuir o risco de fracasso de novas coleções de roupas.
Matriz probabilidade e impacto
Com base nas estimativas de probabilidade e impacto, explicadas no item ante-
rior, constrói-se a matriz de riscos ou matriz de probabilidade e impacto, indicada na
figura a seguir.
Matriz de riscos
Probabilidade Peso Impacto = P× I
Muito alta 5 5 10 20 40 50
Alta 4 4 8 16 32 40
Moderada 3 3 6 12 24 30
2 2 4 8 16 20

Baixa
Muito baixa 1 1 2 4 8 10
Peso 1 2 4 8 10
Impacto Muito Baixo Mode- Muito
baixo rado Alto alto
Nessa matriz, não é necessário empregar as reais probabilidades de ocorrência
do evento em risco – bastam valores representados em uma escala numérica. Por re-
presentar uma análise qualitativa, os valores numéricos da matriz apenas indicam ca-
tegorias “muito alta”, “alta” etc. Por exemplo, uma probabilidade “muito alta” poderia
ser algo como 0,5%, em se tratando do risco de explosão de uma turbina aeronáutica;
mas no risco de atraso de uma compra, 0,5% seria “muito baixa”.
Analogamente, no eixo horizontal são representados os impactos (usualmente
monetários), na escala de 1 a 10. O nível 10 pode significar, por exemplo, um impacto de
R$ 50 mil ou R$ 1 milhão – a depender do risco e do projeto em estudo.
Uma matriz de probabilidade deve ser construída para cada risco em separado. Suas
escalas de probabilidade e impacto devem, igualmente, ser construídas e calibradas para
cada risco em análise. A matriz de riscos pode ser empregada tanto para riscos negativos,
vinculados às ameaças, como para riscos positivos, relacionados com as oportunidades.
7�2�2 Categorização e priorização

A matriz de riscos, apresentada anteriormente, constitui uma ferramenta útil
para categorizar os riscos em baixo, médio e alto, indicados na zonas de diferentes
tons, e pode ser empregada também para sugerir respostas ou tratativas aos riscos.
Riscos maiores recebem naturalmente maior prioridade para posterior análise
quantitativa e ações de mitigação/ eliminação. Uma outra maneira de categorizar ris-
cos é com base na Estrutura Analítica de Riscos (EAR), representada na figura a seguir.
Estrutura Analítica de Riscos (EAR)

Projeto
Gerenciamento
Técnico Externo Organizacional
de projetos
Subcontratadas Dependências
Requisitos Estimativa
e fornecedores do projeto
Tecnologia Regulamentos Recursos Planejamento

Complexidade
Mercado Financiamento Controle
e interfaces
Desempenhos
e confiabilidade Cliente Priorização Comunicação
Qualidade Clima
A EAR facilita o agrupamento de causas de riscos para posterior tratamento em

conjunto. Ela também permite estimar o custo das tratativas dos riscos por categoria.
Seu maior benefício, contudo, é a visão panorâmica que oferece sobre os riscos.
Outras técnicas de priorização consagradas (por exemplo, técnicas da gestão da
qualidade) também podem ser adaptadas para priorizar os riscos de um projeto.
7.2.3 Análise quantitativa dos riscos

A análise quantitativa dos riscos estima o impacto dos riscos identificados e prio-
rizados nos objetivos do projeto. Seu maior benefício é estimar objetivamente o valor
do risco, ou quanto o risco custará para o projeto. Esse valor deverá então ser incluí-
do, de alguma maneira, na estimativa dos custos do projeto, pois também constitui um
custo. Além disso, ele deve ser pago por alguma fonte: pelo projeto, pelo cliente, pela
organização etc. Se o valor do risco não for estimado, ele pode permanecer latente no
projeto, e então aparecer inesperadamente quando ocorrer o evento em risco.
Uma forma simples de considerar quantitativamente um risco no projeto é cotar ou avaliar

quanto uma seguradora do mercado cobraria para assumir o risco. Descontados o lucro da se-
guradora e os impostos, o restante equivale ao custo do risco para o projeto.
Algumas técnicas para a análise quantitativa dos riscos são:

Estimativas de especialistas: profissionais experientes conseguem estimar
quantitativamente um risco. Eles podem definir um intervalo (amplitude) para o valor,
ou então estimar três valores de referência (estimativa de três pontos): mínimo, mais
provável e máximo.
Análise do valor monetário esperado: calcula o resultado médio dos valores pro-
váveis em diferentes cenários. Ela pode ser formulada pela equação R = Σpi . ii, onde pi
e ii são a probabilidade e o impacto do risco em um determinado cenário (i).
A figura a seguir ilustra esses conceitos para os riscos de atraso de um projeto de
construção previsto para 200 dias. A perda esperada com multas por atraso é uma me-
dida do risco, calculada pela expressão:
R = 15% * R$ 10 mil + 4% * 11d * R$ 30 mil + 2% * 6d * R$ 50 mil = R$ 23.700,00
Os intervalos de atrasos, indicados na figura seguinte, são iguais a 3, 11 e 6 dias e
as respectivas multas por atraso, são iguais a R$ 10 mil, R$ 30 mil e R$ 50 mil.
Análise do valor monetário esperado

Função probabilidade
0,15
0,04
0,02
200] 203] 214] 220]
Função penalidade
R$ 50 mil
R$ 30 mil
R$ 10 mil
200] 203] 214] 220]

Conceito análogo é empregado quando a função de probabilidade e/ou a função

penalidade são contínuas, em vez de discretas. Contudo, os cálculos são mais complexos.
Árvore de decisão: representa os cenários indicados na figura “Análise do valor
monetário esperado” em uma árvore de decisão. Cenário A: R$ 10mil de multa com
15% de probabilidade; Cenários B e C, análogos. Os cálculos são os mesmos daqueles
indicados no item anterior.
Simulação de Monte Carlo: recomendada para análise conjunta de riscos múl-
tiplos, riscos complexos ou distribuições contínuas, quando as soluções analíticas são
muito trabalhosas ou inviáveis. No exemplo da figura “Análise do valor monetário es-
perado” a Simulação de Monte Carlo sortearia aleatoriamente um dia e verificaria a
multa correspondente, repetindo esse procedimento milhares de vezes para determi-
nar o valor médio das multas.
Para mais detalhes sobre a Simulação de Monte Carlo sugerimos a obra Introduction to simulation
and risk analysis (EVANS; OLSON, 2002).
Estimativas com dados históricos: usam valores de riscos de projetos ou situa-

ções semelhantes para estimar o custo do risco no projeto atual. Podem ser imprecisas
ou necessitarem de ajustes elaborados.
Os métodos acima são os mais usualmente empregados como referência. Existem
diversos outros, com diferentes graus de sofisticação e complexidade.
Uma vez realizada a análise quantitativa dos riscos, uma questão pouco abordada
na literatura técnica é: o que fazer com o resultado calculado? Afinal, o risco é um gas-
to esperado e quantificado que terá que ser contabilizado de alguma forma (mesmo sem
a ocorrência do evento). Algumas alternativas e consequências podem ser, por exemplo:
• Repassar ao cliente: implica aumento do custo do projeto e o cliente pode não
concordar porque o evento em risco ainda não ocorreu de fato.
• Pagar pelo próprio projeto: diminui a margem e a atratividade do projeto, em
relação aos seus custos de oportunidade.
• Repassar à organização: diminui os resultados contábeis da organização, pois
os custos aumentam.
• Ignorar o risco: torna vulnerável o sucesso do projeto, pois o evento em risco
poderá ocorrer e causar enormes danos financeiros.
• Repassar o risco: “vendê-lo” a uma seguradora ou repassá-lo ao cliente ou ou-
tro stakeholder mediante contrato. Exige negociação.
A solução ideal para custear os riscos do projeto depende do seu tipo de contrata-
ção (contratos de preço fixo, de custos reembolsáveis, por tempo e material etc.), en-
tre outros fatores. Portanto, não há uma só solução ideal para todos os projetos.
Uma construtora precisa conviver com riscos de chuvas e atrasos nas entregas, por isso seus
orçamentos já incluem reservas para esses riscos. Em situações excepcionais (chuvas excessi-
vas ou greves nos transportes) ela negocia pagamentos adicionais com seus clientes; mas nem
sempre com sucesso.
As análises qualitativa e quantitativa de riscos não são necessariamente métodos

concorrentes entre si. Frequentemente, elas são empregadas de maneira complemen-
tar. Por exemplo, a primeira pode indicar os principais riscos e suas magnitudes, já a
segunda estima valores monetários para esses riscos selecionados.
7.2.4 Análise de sensibilidade

Essa técnica emprega a variação dos resultados do projeto como indicador do
risco (KEELING, 2012). Quanto maior for a incerteza ou a variação dos resultados esti-
mados de uma variável que representa um risco, maior esse risco será.
No projeto de instalação de uma máquina industrial, o risco de atraso do projeto depende das
faltas dos técnicos ao trabalho. O eletricista possui uma frequência de faltas muito superior à
do mecânico, portanto ele representa maior risco. Além disso, ele ganha mais, o que aumenta
ainda mais o risco.
A estimativa da variação dos resultados é frequentemente subjetiva – já que ge-

ralmente os projetos não contam com muitos dados históricos. Portanto, opiniões de
especialistas são um importante instrumento de estimação nesse caso.
Uma conhecida técnica que facilita estimar as variações dos resultados é a esti-
mativa por três pontos (que usa a previsão mais baixa, a mais alta e a mais provável).
Seu desvio-padrão pode ser empregado como indicador das variações dos resultados.
Ele é calculado como [DP=(estimativa de maior valor – estimativa de menor valor)/6],
para uma distribuição de probabilidades do tipo beta. Maiores diferenças entre esti-
mativas de maior e menor valor indicam, portanto, maiores riscos.
7.3 Resposta aos riscos

As respostas aos riscos, ou tratativas dos riscos, determinam as opções para
ações destinadas a mudar (usualmente, diminuir) a probabilidade de ocorrência do
evento em risco, os impactos dos riscos ou ambos. Elas possuem grande importância
no gerenciamento dos riscos (e do projeto) pelos seguintes motivos:
• Envolvem gastos significativos com os riscos (prevenção, correção etc.).

• Podem recomendar até o cancelamento do projeto, em casos extremos.
• Impactam no fluxo de caixa e no orçamento do projeto.
Por esses motivos, as respostas aos riscos assumem um papel não apenas tático-
-operacional nos projetos, mas também influem nas decisões estratégicas.
7.3.1 Papel da resposta aos riscos

A resposta aos riscos corresponde à tomada de decisões para assumir os riscos na
medida desejada. Esse processo pode resultar tanto na diminuição como no aumento
dos riscos, conforme for melhor para o projeto.
Se a diminuição de riscos implica custos extras, como é usual, riscos muito baixos
podem onerar consideravelmente um projeto. Esse é exatamente o caso do projeto de
um novo avião de pequeno porte, no qual se empregaram sistemas eletrônicos de se-
gurança em duplicidade para prevenir panes. Falhando um sistema, outro entraria em
ação. Já veículos espaciais contam com entre quatro e seis sistemas de segurança pa-
ralelos; os baixos riscos desejados justificam os altos custos.
A resposta aos riscos em um projeto assume o papel de tentar dosar a medida
ideal do risco, mediante o tradeoff entre prevenção e correção. Enquanto ações de pre-
venção em excesso podem estagnar o projeto (e encarecê-lo demasiadamente), um
foco excessivo na correção pode expor o projeto a altos riscos de fracasso. Uma dosa-
gem em alguma posição intermediária costuma ser a solução ideal.
7.3.2 Estratégias de respostas aos riscos

A disciplina Gerenciamento de Riscos prevê as seguintes estratégias para a trata-
tiva dos riscos, representadas na figura a seguir ao lado da matriz de riscos.
Tratativas dos riscos e matriz de riscos

Tentativas dos riscos
Financiamento Controle
Transferência Retenção Redução Eliminação
– Seguros – Autoadoção – Controle – Abandono

– Contratos – Autosseguro – Prevenção – Modificação
– Créditos – Segurança – Substituição
– Contingências
Custos do risco
Impacto
Transferir Eliminar
Aceitar Administrar
Probabilidade
Fonte: SANTOS, 1988. (Adaptado).
As estratégias das tratativas são classificadas em financeiras e de controle. As

primeiras tratam os riscos transferindo-os a terceiros ou retendo-os. Já as segundas
preveem ações de mitigação dos riscos – em caso extremo, até a eliminação total da
causa do risco mediante abandono do projeto.
A matriz de riscos, representada na figura anterior à direita, apresenta algumas

tratativas típicas em função dos valores da probabilidade de ocorrência e do impacto
de um evento em risco. Por exemplo, a contratação de seguros (transferência de ris-
co) é recomendada apenas em casos de baixa probabilidade com alto impacto. As se-
tas indicadas na matriz representam a possibilidade de modificar a probabilidade ou o
impacto da ocorrência do evento em risco mediante a adoção das tratativas. As linhas
tracejadas delimitam regiões de riscos altos, baixos e intermediários, para os quais há
estratégias típicas.
Uma estratégia muito usual para gerenciar riscos em projetos é a formação de
contingências ou reservas de contingência. Elas constituem recursos que serão usa-
dos somente se ocorrer realmente um evento em risco (SANTOS, 1988). Essas estraté-
gias podem se direcionar:
• ao nível do negócio: por exemplo, reserva financeira para cobrir gastos não
previstos, variações cambiais ou ações judiciais inesperadas.
• ao nível do projeto: reservas, créditos e garantias para socorrerem o projeto
em caso de eventos negativos. Por exemplo, reserva de 8% do orçamento para
pagar multas por atraso ou recuperar o cronograma.
• ao nível das atividades: por exemplo, acréscimo de folgas nos custos previstos
para cada atividade, pessoal de reserva para emergências.
Uma dificuldade para a formação de contingências é conseguir seu financiamen-
to, seja pelo cliente, pelo próprio projeto ou pela organização do projeto. Muitos consi-
deram reservas de contingência supérfluas e desnecessárias.
Os vidros de uma fachada envidraçada em construção ilustram soluções alternati-
vas para as tratativas dos riscos. Como eles apresentam alto risco de quebra, cogitam-
-se as tratativas: contratar seguro, receber os vidros já no local da colocação, alugar
equipamento para colocação segura, formar reserva financeira, substituir o vidro por
outro material e eliminar os vidros. Essas alternativas, baseadas na figura “Tratativas
dos riscos e matriz de riscos”, apresentam vantagens e desvantagens próprias, que de-
vem ser consideradas na análise do negócio.
7.3.3 Mitigação de riscos

Entre as tratativas usuais do gerenciamento de riscos, aquelas que resultam na
redução ou mitigação dos riscos interessam em especial aos tomadores de decisão. A
mitigação atua tanto pela redução da probabilidade de ocorrência do evento em ris-
co como pela redução do impacto das consequências do evento. Ambas resultam em
custos, que devem ser avaliados em conjunto na análise de riscos.
Por exemplo, na limpeza de tanques de aço, acidentes de trabalho custam 3% do

orçamento. O uso de botas de borracha diminui esse valor para 2%, pois reduz a pro-
babilidade de quedas, mas custa 1,2% do orçamento. Já o uso de capacetes diminui o
valor em 0,8%, pois reduz o impacto no caso de queda, mas custa 1%.
Esse exemplo ilustra a necessidade de se avaliar qual é o nível ideal dos riscos em
um projeto em função dos custos de prevenção e de reparação. A tabela a seguir suge-
re uma verificação dessa questão para cada risco.
Verificação do nível de risco ideal

Situação Vantagens Desvantagens
Reduzir a probabilidade de Menor ocorrência do evento Maior custo com ações
ocorrência em risco preventivas
Reduzir impacto com a Menores consequências, Maior custo com ações
ocorrência caso o evento ocorra corretivas
Em alguns casos, ações incompletas podem causar a falsa sensação de seguran-

ça ao projeto e expô-lo ao fracasso. O seguinte exemplo ilustra essa situação. Uma loja
de roupas adquire um seguro contra incêndio com cobertura de R$ 5 milhões. Se ocor-
rer um incêndio, o negócio será interrompido por oito meses, até sua reconstrução.
Nesse período, a loja tem gastos trabalhistas, de aluguel, entre outros, e nenhuma re-
ceita. Portanto é fundamental que seu seguro inclua a modalidade lucros cessantes,
que cobre a falta de receitas provenientes das operações da empresa.
O nível ideal do risco adotado depende das oportunidades do negócio do proje-
to. Níveis de risco muito baixos tendem a inviabilizar os projetos, pois eles se tornam
muito caros. Já níveis de risco muito altos podem submeter os projetos a situações se-
melhantes a uma loteria – difíceis de se justificar, caso ocorram danos. Nessa situação
típica de conflito é útil o emprego da análise de tradeoff.
7.3.4 Estratégias para riscos positivos

Riscos positivos, também denominados “chances”, relacionam-se com oportuni-
dades de ganhos para o projeto e o negócio do projeto. Por exemplo, a estimativa de
250 dias para a entrega de um novo software de gestão de relacionamentos envolve
não só riscos de atraso, mas também de adiantamento. O custo de um atraso de 20
dias é 8% do valor do contrato; já o custo para adiantá-lo em 20 dias gera um benefício
de 3% desse valor, porque ajuda o cronograma de implantação. Esse último caso ca-
racteriza um risco positivo.
A avaliação das estratégias para riscos positivos também emprega a matriz de ris-
cos. Contudo, a região com pontuação mais alta representa maior atratividade para
o projeto (e não a sua eliminação, como no caso dos riscos negativos). Com base no
PMBOK (PMI, 2013) elencam-se as seguintes estratégias para os riscos positivos:
• Explorar: investir esforços para concretizar a oportunidade. Por exemplo, de-
signar pessoal mais capacitado para o projeto, buscar financiamentos.
• Administrar: administrar os ganhos modestos, mas seguros, ou aumentar o
impacto. Por exemplo, controlar de perto os resultados e tendências dos riscos
positivos; negociar premiações para entregas adiantadas etc.
• Compartilhar: buscar parceiros mais capacitados, técnica ou financeiramente.
Por exemplo, terceirizar atividades do projeto para parceiros mais especializa-
dos, que trabalharão com maior eficiência.
• Aceitar: não empreender qualquer ação quanto a riscos, não compensa o es-
forço. Por exemplo, satisfazer-se com eventuais ganhos modestos.
Esquematicamente, algumas estratégias típicas para riscos positivos podem ser
ilustradas na matriz de risco da seguinte maneira:
Matriz de riscos positivos: exemplo

Impacto
Compartilhar Explorar
Aceitar Administrar
Probabilidade
Essa matriz é análoga àquela representada na figura “Tratativas dos riscos e matriz
de riscos”, para riscos negativos. Ela mostra que negócios com alta perspectiva de ganho
(impacto) e alta probabilidade de sucesso devem ser explorados. Já quando a probabili-
dade de sucesso é pequena, é prudente dividir os riscos com parceiros. E quando o im-
pacto é pequeno, o ideal é apenas manter com baixo nível de investimento.
Enquanto os riscos negativos são tratados mediante financiamento ou controle,
os positivos se baseiam em ações de terceirização/parcerias ou investimento próprio.
7.4 Controle dos riscos e avaliação de impactos

Gerenciar riscos não significa apenas identificá-los e tratá-los, é necessário mo-
nitorá-los e controlá-los ao longo do tempo. Em projetos, o controle é exercido duran-
te o ciclo de vida do projeto, o que compreende o período desde sua iniciação até seu
encerramento. Especialmente em projetos de longa duração e em ambientes de cons-
tantes mudanças, o monitoramento e o controle de riscos procuram minimizar perdas
e garantir que os resultados do projeto satisfaçam às metas e aos objetivos da melhor
maneira possível. Esse é o caso, por exemplo do desenvolvimentos de automóveis ou
de grandes obras de infraestrutura (ROZENFELD, 2006).
Uma importante atividade relacionada com o controle é a avaliação de impac-
tos dos eventos que ocorrem ao longo do projeto. Essa avaliação pode ocorrer antes
(no planejamento), durante (na execução) ou ao final do projeto (no encerramento). Ela
pode revelar, por exemplo, se os riscos do projeto cresceram a ponto de inviabilizá-lo.
7.4.1 Papel do controle de riscos

Controlar os riscos em um projeto significa implementar os planos de resposta
aos riscos, monitorar os riscos residuais, identificar novos riscos e avaliar a eficácia do
processo de riscos durante o ciclo de vida do projeto, segundo o PMBOK (PMI, 2013).
A estimativa objetiva do risco (por exemplo, em valores monetários, dias de
atraso, quantidade de feridos) facilita seu monitoramento e controle, bem como a ava-
liação de seus impactos.
O treinamento de um astronauta necessita alinhamento com o cronograma da missão e os

treinamentos de seus colegas. O monitoramento de cada etapa se baseia em testes físicos e
de aprendizado. Com base nos resultados, adotam-se ações de aceleração ou relaxamento do
treinamento.
Um importante papel do controle dos riscos em um projeto é manter o nível do ris-

co próximo do considerado ideal. Para tanto, é necessário equilibrar as ações preven-
tivas com as corretivas, bem como os investimentos para mitigação dos riscos com os
benefícios da mitigação. Duas dificuldades nesse sentido consistem em estimar os riscos
objetivamente (segundo o princípio: o que não se pode medir, não se pode controlar) e
auditar os riscos periodicamente.
7.4.2 Auditoria de riscos

Uma auditoria de riscos tem por finalidade verificar se as tratativas dos riscos identi-
ficados no projeto são de fato eficazes e eficientes. Como as tratativas de risco envolvem
investimentos (com prevenções, financiamentos, formação de reservas etc.), é necessário
questionar se as alternativas escolhidas para tratar os riscos são, de fato, as ideais.
Essas verificações podem ser realizadas:

• No nível do negócio: se os custos das tratativas dos riscos assumidos para o
negócio são compatíveis com os benefícios.
• No nível do projeto: se os investimentos em prevenção e correção são compa-
tíveis com as metas do projeto.
• No nível das atividades: se os níveis de risco assumidos para a atividade são
compatíveis com situações similares em outros projetos.
Por exemplo, um parque de diversões projeta um propulsor que permite o voo
controlado de pessoas em um raio de 50 m. Tecnicamente, é baixo o risco para o ne-
gócio e para as atividades do projeto. Contudo, é enorme o risco de contratar e manter
por 18 meses engenheiros e cientistas de altíssimo nível nesse projeto.
As auditorias internas costumam ser mais econômicas e fáceis de programar. Elas
podem ser realizadas por pessoal do projeto, da organização ou do escritório de pro-
jetos, se houver um na organização. Já as auditorias externas podem contar com refe-
rências mais abrangentes e fornecer maior credibilidade aos stakeholders interessados
(TRENTIM, 2013).
7.4.3 Análises de variação e tendência

A análise de variação consiste em uma técnica para revelar as causas da diferença
entre o desempenho medido e o valor planejado. Já a análise de tendências emprega
técnicas para estimar resultados futuros com base em valores históricos.
Aplicadas à gestão de riscos, as análises de variação e tendências verificam o des-
vio provável dos resultados em relação às metas do projeto e estimam as tendências
para situações futuras. Um exemplo ocorre com os desvios do custo e prazo do pro-
jeto, em uma data D do seu ciclo de vida. Com base nesses desvios, estima-se a nova
data de término e o novo custo do projeto no término.
Associando-se o risco às possíveis variações dos valores previstos, percebe-se,
pela figura a seguir, que o risco diminui à medida que o projeto avança, pois as estima-
tivas diferem cada vez menos dos valores reais ao final do projeto. Percebe-se, tam-
bém, na figura à esquerda, que as oportunidades para corrigir os resultados do projeto
diminuem cada vez mais. A partir de uma data T, mesmo condições muito favoráveis
não mais conseguirão reconduzir os resultados futuros à meta inicial.
Diminuição do risco ao longo do ciclo de vida

estimativa
estimativa
meta meta

T tempo tempo
A figura anterior à direita representa situações em que os desvios em relação à

meta são menores – talvez em função do maior nível de informações no projeto e da
adoção de mais ações de controle (provavelmente com maior custo).
Em resumo, em cada momento do projeto, pode-se avaliar os desvios entre os re-
sultados reais em relação aos valores planejados e recalcular as previsões dos resulta-
dos ao final do projeto.
O projeto de um novo medicamento demora 15 anos e convive com incertezas sobre testes
laboratoriais, autorizações legais e novas tecnologias. Em vários momentos, avaliam-se os
custos e prazos previstos e as diversas viabilidades e estimam-se os riscos de continuar e de in-
terromper o processo.
7�4�4 Impactos estratégicos dos riscos

No gerenciamento de projetos direcionado para o negócio, os impactos estratégi-
cos dos riscos são calculados em relação aos fatores de sucesso para os stakeholders do
projeto. A seguir, apresenta-se uma lista com os impactos relevantes:
• Para os clientes: solução é entregue no prazo, a custo reduzido, com alta qualidade
percebida e escopo plenamente satisfeito.
• Para a organização: projeto respeita normas, políticas, diretrizes, métodos de traba-
lho, cultura e padrões éticos.
• Para o ambiente: solução e sua implantação atendem a leis, normas técnicas, costu-
mes locais, proteção a gerações futuras.
• Para os concorrentes: soluções geradas são competitivas, atingem altos níveis de
excelência, respeitam o meio ambiente.
• Para os fornecedores: recursos adquiridos são pagos em dia, contratos são respeita-
dos, fornecimento atende a padrões da ética.
Desvios em relação às metas estabelecidas segundo esses fatores ameaçam o su-

cesso do projeto e, portanto, constituem risco para o negócio do projeto.
Uma ferramenta simples e muito eficaz para controlar os riscos no nível estratégi-
co é a lista de verificação ou checklist. Ela pode ser elaborada, por exemplo, com base
nos fatores apontados acima, mas especificamente para cada projeto ou tipo de proje-
to. Quanto mais específica for a lista de verificação, mais eficaz é seu emprego.
Escalar o Everest, antes uma aventura exótica, hoje tornou-se até modismo, mas ainda é um
projeto que envolve riscos altos. Talvez o maior deles seja a qualidade da preparação da via-
gem: na escalada, nada pode falhar. Falhas na qualidade comprometem o enorme investimen-
to e até a vida do aventureiro.
Referências
BENZANI, J. C.; FALCON, J. C. M. Conceito e análise de risco. Simpósio Nacional de
Instalações Prediais. São Paulo. n. 4, p. 193-206, 1987.
EVANS, J. R.; OLSON, D. L. Introduction to simulation and risk analysis. New Jersey:
Prentice Hall, 2002.
Umweltwirtschaftsforum (Fórum da Economia do Meio Ambiente). Springer Link, v. 21,
n. 1, 2013.
IIBA. A Guide to the Business Analysis Body of Knowledge (BABOK®). Toronto:
JERONYMO, E. A gerência de riscos e o mercado segurador brasileiro. Cadernos de
Seguro, v. 18, p. 25-27. Rio de Janeiro: Funenseg, 1986.
2012.
2009.
OGC. Managing Successful Projects with PRINCE2®. Norwich: TSO, 2009.
2006.
SANTOS, J. A. A Prática do Gerenciamento de Riscos por Grandes Empresas

Privadas do Setor Industrial – um estudo exploratório. Dissertação de Mestrado.
EAESP/FGV, São Paulo, 1988.
8 Aquisições e suprimentos
No gerenciamento de projetos focado no negócio, a importância estratégica dos
suprimentos (SANTOS; CARVALHO, 2006) pode ser bem ilustrada com uma pergunta:
Qual é o impacto para o negócio, quando um material requisitado pelo projeto é

substituído por outro?
Essa pergunta aborda um problema corriqueiro no gerenciamento de qualquer

projeto, que é a dificuldade de se conseguir o suprimento de todos os recursos da for-
ma como foram previstos: com a qualidade especificada, entregues nas datas corretas,
ao custo contratado, com o risco controlado etc. A questão representa bem o papel es-
tratégico dos suprimentos em um projeto, em particular o processo de aquisição, e
pode ser aplicada no seguinte caso prático.
Uma campanha de vacinação infantil no norte de Minas Gerais previa diversas
ações de preparação. Por exemplo, conscientizar a população quanto à necessidade de
tomar vacinas e de incentivar cada família a manter um caderno de controle atualiza-
do. Sem essas ações, a campanha teria baixa adesão e desperdiçaria recursos. Para as
ações de preparação, eram necessários mais seis médicos e mais quinze assistentes so-
ciais. Conseguiu-se apenas um médico e duas assistentes sociais para o mesmo traba-
lho, por falta de recursos.
Essa situação é encontrada frequentemente em outros projetos. No caso anali-
sado, os recursos não estavam disponíveis conforme a necessidade; mas as metas
do projeto e do negócio continuaram as mesmas. Trata-se de uma situação atípica?
Infelizmente não, pois esse é um tipo de desafio frequente para gerentes de projetos.
8.1 Papel estratégico das aquisições

Ele se caracteriza pela investigação dos impactos das aquisições no negócio do pro-
jeto, e não apenas em suas metas técnicas. Assim, a aquisição de quatro puxadores de
plástico para um móvel, em substituição a puxadores de aço, pode gerar economia de
R$ 50,00; mas essa economia não será positiva se o móvel se desvalorizar em R$ 200,00.
O pessoal de compras se orienta fundamentalmente pelos custos das aquisições
especificadas. Já o analista do negócio do projeto emprega como eferência o valor do
produto ou da solução para os stakeholders. Cabe ao gerente de projetos relacionar es-
sas duas referências para cumprir as metas e, ao mesmo tempo, gerar valor.

Todos os projetos necessitam de recursos: materiais, equipamentos, mão de
obra, informações etc.
O processo de suprimento desses recursos tem sido tratado amplamente na Logística

(BOWERSOX, 2006). Aplicações em projetos enfocam mais o processo de aquisição dos
recursos (com menor ênfase na sincronização das entregas para a produção).
Por aquisição entende-se a compra de um material, a contratação de uma pessoa, o agendamento

de um serviço, o empréstimo de um equipamento, o recebimento de uma doação, o arrendamento
de um terreno etc. Em resumo, ela representa todas as entradas de recursos para o projeto.
A depender do projeto, o fornecedor também pode ser denominado contratado,

vendedor, prestador de serviço, freelancer, parceiro etc. Por outro lado, o cliente tam-
bém atende por comprador, solicitante, contratante, beneficiário etc. Em alguns casos, o
cliente também pode fornecer insumos próprios para um projeto.
8�1�2 Abordagem estratégica

Para tratar da aquisição de recursos para um projeto, segundo a abordagem es-
tratégica adotada, verificam-se cinco questões fundamentais (SANTOS, 2007):
• Quais recursos são especificados pelo projeto?
• Quais são os fornecedores ou fontes potenciais desses recursos?
• Como estabelecer e manter os relacionamentos necessários com as fontes?
• Quais recursos são, de fato, adquiridos?
• Qual é o impacto no produto dos recursos realmente adquiridos?
Esquematicamente, essas perguntas são representadas na figura a seguir.
Relacionamentos com as fontes de recursos

Fontes de
Gestões específicas
suprimento
Exigências do 1. Pessoas
projeto 2. Materiais
3. Equipamentos
Relacionamentos 4. Instalações
R 1 23 4567 89 5. Informações
6. Tecnologias
7. Financiamento
Design Gráfi co: Larissa Pires
Efeitos no 8. Serviços
produto 9. Outros
Aquisições
reais
Os recursos indicados são principalmente obtidos de uma das seguintes fontes

(ou de uma combinação entre elas):
• organização;
• parceiros;
• mercado.
No diagrama da figura anterior, apenas oito tipos de recursos (R1, R2, ... R8) são
especificados, mas outros podem ser adicionados. Para cada recurso crítico R, verifi-
cam-se as cinco questões fundamentais, como exemplifica o caso seguinte.
Em um congresso médico, o mais ilustre palestrante é russo, e o projeto exige um
bom intérprete desse idioma. Contudo, as fontes desse tipo de profissional são escas-
sas. A contratação real exige um relacionamento privilegiado no consulado. Consegue-
se um estudante do idioma. O impacto estimado é catastrófico.
Ao se analisar a contratação do intérprete para o russo, pode-se tentar: (1) mudar

a exigência do projeto para outro idioma (inglês?); (2) buscar outra fonte de supri-
mento (de outra cidade?); (3) buscar relacionamentos de apoio ao projeto (embai-
xada em Brasília?); (4) verificar quais são as características da aquisição realmente
disponíveis (o estudante apresenta habilidades satisfatórias?) e (5) verificar o im-
pacto do recurso disponível no projeto (pode-se realizar um teste antecipado com
o estudante e medir a satisfação em uma amostra do público-alvo?).
A verificação da exequibilidade da aquisição de um recurso, mediante as cinco

questões fundamentais mencionadas, ajuda a eliminar problemas prematuramente.
Mais importante ainda, ela avalia o impacto estratégico de qualquer modificação na
aquisição prevista. Por exemplo, a substituição de um material pelo comprador passa
a ser avaliada não apenas tecnicamente (Qualidade equivalente? Preço compatível?),
mas pelo impacto estimado (O cliente perceberá a mudança? Ficará insatisfeito?).
8.1.3 Plano de gestão e especificação do trabalho

O plano de gestão das aquisições indica como o projeto irá adquirir servi-
ços e bens dentro e fora da organização, em quais condições e sob quais premissas
(VALERIANO, 2005). Alguns dos elementos relevantes desse plano são:
1. Objetivos da gestão das aquisições
(Definir os objetivos da gestão de aquisições e justificar sua importância.)
2. Responsabilidades pelas aquisições
(Indicar quais pessoas participam da gestão das aquisições e seus papéis.)
3. Redes de fornecedores
(Definir padrões e sistemas para gerenciar e coordenar múltiplos fornecedores.)
4. Itens especificados para aquisição

(Definir os bens e serviços para aquisição, com as especificações e restrições.)
5. Estudo de alternativas para aquisições
(Analisar alternativas de fazer ou comprar, alugar, arrendar ou adquirir etc.)
6. Fornecedores potenciais
(Identificar os principais fornecedores potenciais para itens a serem adquiridos.)
7. Relacionamentos com fornecedores
(Indicar como manter os relacionamentos com fornecedores-chaves e seus
custos.)
8. Contratos
(Descrever os tipos de contratos empregados no projeto.)
9. Itens realmente adquiridos
(Especificar os bens e serviços realmente adquiridos e em quais condições.)
11. Impacto das aquisições reais
(Estimar o impacto dos itens adquiridos, no projeto e no negócio do projeto.)
12. Documentos padronizados
(Descrever os documentos padronizados para aquisições.)
13. Monitoramento e controle das aquisições
(Descrever como as aquisições do projeto serão monitoradas e controladas.)
(Indicar as experiências e oportunidades de melhoria para projetos futuros.)
Outros itens relevantes podem ser acrescentados ao plano de gestão das aquisi-
ções, em função das características de cada projeto.
Há 15 anos, a festa de Natal da empresa é gerenciada como um projeto. Ela reúne mais de
2.000 pessoas e espelha a imagem da empresa. A aquisição de mais de 180 tipos de itens já
mereceu a padronização, em nível profissional, de documentos, contratos, fornecedores, ser-
viços e pessoal.
Além do plano de gestão das aquisições, o processo de planejamento das aquisi-

ções também produz outros documentos auxiliares relevantes para cada projeto.
8.1.4 Fontes dos recursos

As fontes dos recursos, ou fornecedores, podem se relacionar com o projeto e sua or-
ganização de diversas maneiras. A figura a seguir mostra alguns relacionamentos típicos
da logística (DORNIER et al., 2000); (BOWERSOX, 2006), também úteis para projetos.
Relacionamentos com as fontes de recursos

Transações Transações Relacionamento
simples repetidas de longo prazo
Parcerias
Design Gráfico: Larissa Pires

Integração Organização Alianças
vertical em rede estratégicas
As transações simples se referem a aquisições avulsas ou esporádicas. Elas são

muito utilizadas em projetos, já que eles são organizações temporárias. As transações
repetidas envolvem compras ou contratações recorrentes, pela organização – não ne-
cessariamente em um mesmo projeto. Os relacionamentos de longo prazo ocorrem
quando a organização compra do mesmo fornecedor por um longo período – por exem-
plo, uma construtora compra portas de uma mesma empresa há anos, para suas obras.
Uma característica das parcerias é que o parceiro participa dos resultados do
projeto, sejam eles positivos ou negativos – como nas joint ventures. Já a aliança es-
tratégica (associação entre duas ou mais organizações para desenvolver uma ativida-
de específica) e a organização em rede (qualquer forma organizacional que substitua
a forma multidivisional, como a maneira dominante de estruturar uma empresa) be-
neficiam menos os projetos corriqueiros; elas se aplicam mais em casos de parques in-
dustriais, por exemplo. Finalmente, a integração vertical ocorre quando a organização
permanente adquire um fornecedor estratégico – por exemplo, contrata um designer que
prestava serviços eventuais, ou adquire a empresa do designer.
Um congresso médico arrecada R$ 330 mil. O gasto diário total com um bom intérprete do
idioma russo é R$ 3 mil. Há três datas prováveis para o evento. Por precaução, contratou-se o
intérprete para todas, pois esse é um recurso escasso, que poderá comprometer o evento.
Em muitas situações, há mais de uma alternativa para a fonte de uma aquisição.

A decisão pela “melhor” alternativa depende de cada projeto e de cada situação em
particular. Um fabricante de caminhões que compra chassis para seus produtos con-
vencionais segundo o modelo “relacionamento de longo prazo” pode optar por uma
“parceria” para codesenvolver e adquirir os chassis especiais de um novo modelo de ca-
minhão. Se a tecnologia dos chassis for uma vantagem competitiva exclusiva, a empre-
sa talvez considere a integração (compra) do fornecedor.
8.2 Execução das aquisições

O processo de execução das aquisições consiste em selecionar fornecedores po-
tenciais para os recursos especificados, realizar cotações de preço, elaborar convi-
tes ou conduzir processo licitatório, e formalizar as aquisições mediante contrato.
(VARGAS, 2009). Na prática, ele é responsável pelo suprimento correto (na quantidade
certa, no tempo certo, na qualidade certa e nas condições certas) dos recursos neces-
sários para um projeto.
A aparente simplicidade na execução das aquisições é enganosa. O processo de
aquisição, mencionado anteriormente, não ocorre de maneira automática e impessoal.
Na prática, ele enfrenta muitas dificuldades, principalmente por depender fortemen-
te de fatores não controláveis, encontrados, por exemplo, nas empresas dos fornece-
dores, nas leis comerciais, nas leis do setor público, nas práticas de mercado, nas ações
dos concorrentes etc.
8.2.1 Seleção de fornecedores

A seleção de fornecedores se baseia em critérios bem definidos, muitas vezes pa-
dronizados e documentados. Esses critérios são fundamentais para posterior análise
do desempenho dos fornecedores e dos benefícios para o negócio do projeto.
Usualmente, empregam-se como critério o preço de compra e a qualidade técni-
ca (define-se a qualidade, e então a competição ocorre por preço). O PMBOK® (PMI,
2013) apresenta uma longa lista de critérios adicionais que podem também ser em-
pregados na seleção de fornecedores (VARGAS, 2009). Alguns deles são: custo da
aquisição no ciclo de vida do produto (inclui durabilidade, manutenções, seguros etc.),
capacidade técnica do fornecedor, risco de falhas, garantias, capacidade financeira, tra-
dição, desempenho anterior, referências, exigência de direitos de propriedade, potencial
de transferência de tecnologia, probabilidade de negócios futuros etc.
Com base nos critérios mencionados, é possível eleger um fornecedor vitorioso
mediante o emprego de uma matriz de decisão (SANTOS, 2015), ilustrada na tabela a
seguir. A pontuação final é o resultado da soma das notas ponderadas pelas importân-
cias (multiplicam-se as notas pelas respectivas importâncias para se obter os pontos e
somam-se os resultados para cada fornecedor).
Matriz de decisão para seleção de fornecedor

Fornecedor 1 Fornecedor 2 Fornecedor 3
Nota Pontos Nota Pontos Nota Pontos
Critério Import.
1 1 2 2 3 3
Pontualidade 30% 3 0,90 4 1,20 1 0,30
Capacidade técnica 15% 4 0,60 5 0,75 5 0,75
Capacidade financeira 15% 2 0,30 3 0,45 4 0,60
Referências 10% 5 0,50 4 0,40 5 0,50
Tradição 10% 3 0,30 2 0,20 2 0,20
Potencial para parceria 20% 1 0,20 1 0,20 3 0,60
Soma dos pontos 100% 280 3,20 2,95
Fonte: SANTOS, 2015.
Diversos outros métodos podem ser aplicados para avaliar e selecionar fornece-
dores, desde a opinião de especialistas até complexos modelos probabilísticos. Cada
projeto define qual deles é mais adequado, em função da aceitação da equipe e dos
trabalhos envolvidos. O emprego de mais de um método fornece maior segurança.
Em licitações (usualmente para órgãos públicos) cabe ao comprador especificar
detalhadamente o recurso desejado para que o único critério de escolha pendente seja
o preço, contudo, esse procedimento exige cuidado, conforme mostra o exemplo a se-
guir. A reforma de uma escola pública prevê a aquisição de carteiras. Uma licitação
descreveu o produto vagamente e teve que ser anulada, pois o vencedor apresentou
baixíssima qualidade. Uma segunda licitação especificou o produto com alto detalha-
mento técnico, mas não apareceu uma única oferta.
8.2.2 Preparação de contratos

Os processos de aquisição para projetos são usualmente respaldados por acordos,
sejam eles formais ou informais. Esses últimos representam os contratos, que também
podem ser formalmente celebrados (documentados, assinados, registrados em cartó-
rio etc.) ou não (a encomenda verbal de um lote de peças é um tipo de contrato que
gera responsabilidades). O PMBOK® (PMI, 2013) define contrato como um acordo mú-
tuo que obriga o fornecedor a oferecer algo de valor e obriga o comprador a fornecer
uma compensação, monetária ou de outro tipo. Por exemplo, um contrato para trei-
namento no pacote Office ou um contrato para a aquisição mensal de combustível.
É indispensável que um gerente de projetos possua conhecimentos mínimos so-
bre as regras, os costumes e as leis básicas sobre acordos e contratos e que se atente a
questões legais, culturais, regionais etc. entre as partes envolvidas. Contudo, por cau-
sa da complexidade do assunto, um apoio profissional pode ser muito valioso nos cam-
pos jurídico, técnico, político, econômico, de importação, entre outros.
Projetos de reparos envolvem a aquisição de centenas de itens distintos, desde serviços, ma-
teriais, aluguel de equipamentos etc., mas possuem prazos muito apertados. Por isso, às ve-
zes eles empregam contratações informais, baseadas apenas em telefonemas, indicações etc.,
para se ganhar tempo.
Não há um padrão sobre a época correta para o estabelecimento de um contra-

to em projetos. Contratos são especialmente úteis para estabelecer obrigações logo
após a definição do escopo do projeto, por exemplo. Antes disso, o business case
e o termo de abertura também oferecem condições para a celebração de contratos.
Qualquer aquisição, por menor que seja, também provoca a realização de algum tipo
de contrato.
Contratos mal celebrados ou inexistentes podem resultar longas discussões, atra-
sos e rupturas entre cliente e fornecedor – além de caríssimas disputas judiciais.
Uma empresa desenvolveu um software para agendamentos médicos por R$ 250 mil. Na en-
trega, o cliente cobrou manuais, treinamentos e testes. Não havia menção sobre esses itens no
contrato. O que era “óbvio” para uma parte, não era para a outra. A longa disputa judicial ge-
rou perdas para ambas as partes.
Alguns tipos de contratos mais usuais nos projetos são (VALERIANO, 2005):
De preço fixo
Um preço total remunera todos os produtos e serviços produzidos, os quais de-
vem ser previamente bem especificados, técnica e funcionalmente. O contratado po-
derá sofrer prejuízo em caso de danos inesperados no projeto (a menos que se consiga
negociar com o contratante). Em caso de mudanças no escopo do projeto, o preço do
contrato será renegociado. Alguns desses contratos podem prever reajustes automáti-
cos no preço em função de condições predefinidas, tais como inflação, variações cam-
biais, greves de transportes etc.
De custos reembolsáveis
Baseiam-se nos custos e nas despesas incorridas pelo contratado para entregar
o produto ou serviço, acrescidos de um lucro predefinido. Eles possuem flexibilidade
para remunerar ou penalizar o fornecedor em função de este exceder ou não alcançar
as metas. Uma vantagem desse tipo de contrato é a flexibilidade para ajustar, ao longo
do projeto, as especificações e as exigências dos recursos adquiridos. É pouco adequa-
do para projetos do setor público.
Por tempo e material

Podem ser considerados uma combinação entre os dois tipos anteriores de con-
trato. São aplicados principalmente quando o projeto não pode especificar precisa-
mente os recursos necessários, já no início. Por exemplo, em projetos de pesquisa, as
especificações dependem de resultados futuros, por isso o montante total do contrato
e os itens entregues podem ser incertos. Mas algumas taxas de remuneração de pes-
soal e índices de gasto de material podem ser padronizadas e imutáveis – para dimi-
nuir a tentação de se aumentarem os custos reais do projeto depois de celebrado o
contrato.
Mais detalhes sobre contratos em projetos podem ser encontrados em PMBOK® (PMI, 2013),
item 12.1.1.9.
A escolha do tipo “ideal” do contrato é, muitas vezes, evidente (por exemplo,

contratos para projetos no setor público). A escolha do tipo ideal ocorre mediante o es-
tudo das vantagens/desvantagens de cada alternativa e até a simulação de cláusulas
específicas. Por exemplo, em um contrato de preço fixo para uma obra, pode-se prever
a correção dos preços em função da ocorrência de chuvas em excesso, em um período.
8.2.3 Programação das entregas e dos suprimentos

A gestão dos prazos do projeto enfoca as datas das entregas dos produtos (bens
e serviços) gerados. Tanto o cronograma quanto a curva S são exemplos de técnicas
básicas, relacionadas com as entregas. Contudo, para garantir essas entregas, é pre-
ciso coordenar a aquisição de uma grande quantidade de recursos e as atividades que
os processam. Por exemplo, a realização de uma festa exige a coordenação do recebi-
mento dos alimentos, da recepção dos músicos, da limpeza do local etc.
Nesse sentido, cada atividade do projeto pode ser tratada como um peque-
no subprojeto, com início e fim bem definidos, que emprega recursos para gerar suas
próprias entregas. Atrasos no suprimento dos recursos prejudicam o cronograma do
projeto, se aumentarem o seu caminho crítico (sequência de atividades que definem
a duração do projeto). Assim, é necessário programar os suprimentos do projeto em
consonância com o cronograma de entrega dos produtos.
Com base no cronograma principal, criam-se cronogramas auxiliares de supri-
mentos. Estes devem garantir que, para se realizar uma atividade, os recursos neces-
sários estarão disponíveis na data certa, nas quantidades pedidas e nas especificações
corretas. Dada a usual exiguidade do tempo nos projetos, devoluções de mercadorias e
reparos em serviços impõem prejuízos certos ao projeto e ao negócio.
8.2.4 Programação de pagamentos

As aquisições de um projeto desencadeiam pagamentos ou compensações. Estes
influenciam e também são influenciados pelo fluxo de caixa previsto para o projeto.
Desalinhamentos nesse sentido podem comprometer o sucesso do projeto.
Santos e Carvalho (2006) ponderam que, assim como os suprimentos possuem
seus cronogramas de entrega, também os pagamentos desses suprimentos precisam ser
realizados nas datas corretas. Projetos de pequeno e médio porte não possuem estrutu-
ra própria para administrar pagamentos; usualmente, eles empregam a estrutura da or-
ganização permanente. Uma forma alternativa, frequente em financiamentos públicos, é
a contratação de fundações ou institutos com contas auditadas, para administrarem os
recursos financeiros de um projeto.
8.3 Controle das aquisições

O controle das aquisições administra os relacionamentos com fornecedores e o
monitoramento dos suprimentos previstos em contratos. Se forem verificados desvios
nesses processos, o controle de aquisições também propõe modificações nos relacio-
namentos e nos contratos, bem como cuida da implantação dessas mudanças.
Como as aquisições são fortemente dependentes de relacionamentos externos a
um projeto e a sua organização permanente, elas não podem ser controladas da mes-
ma forma que os processos internos do projeto. Entre os fatores que dificultam o con-
trole das aquisições, destacam-se a autonomia que os fornecedores possuem para
administrar suas entregas (o gerente de projetos não exerce autoridade sobre fornece-
dores) e as incertezas sobre os processos internos dos fornecedores (o gerente de pro-
jetos não possui informações detalhadas a respeito).
Por esses motivos, o controle das aquisições se depara com desafios considerá-
veis no gerenciamento de um projeto.
8.3.1 Auditorias, inspeções e avaliações conjuntas

No projeto de um parque de diversões, tanto o dono do empreendimento quan-
to o fornecedor dos equipamentos respondem solidariamente pelos acidentes com
os brinquedos – portanto, ambos têm interesse em identificar, avaliar e reparar fa-
lhas potenciais nos equipamentos. Assim como nesse caso, em alguns tipos de projeto,
clientes e fornecedores realizam auditorias, inspeções e avaliações em conjunto, no in-
teresse de uma das partes ou de ambas (VIEIRA; ROUX, 2012). Para essa finalidade, as
seguintes ações podem ser adotadas:
• Identificar pontos de inspeção – recursos que impactam na segurança do
comprador, nos objetivos do negócio do projeto, nos riscos do projeto.
• Negociar a realização de inspeção – com autorização do fornecedor.

• Sistematizar a inspeção – para situações que exigem repetições.
• Documentar – registrar os resultados e a avaliação do custo-benefício.
Não é exclusivamente nos casos de responsabilidades solidárias que há interesse
em inspecionar e avaliar as entregas de um projeto (VIEIRA; ROUX, 2012). A avaliação
prematura do impacto dos recursos no negócio do projeto permite planejar e executar
melhor os ajustes e as negociações necessárias com fornecedores. Como ilustração da
avaliação prematura, considere-se o seguinte exemplo.
O projeto de um veículo exige o desenvolvimento de uma nova peça. Atrasos
no fornecimento dessa peça podem comprometer a data de lançamento do veículo.
Segundo uma prática usual no setor, a montadora envolve prematuramente o forne-
cedor no projeto do veículo, bem como participa do desenvolvimento da peça em con-
junto com o fornecedor. Assim, a montadora consegue controlar melhor seu prazo de
lançamento do veículo, bem como avaliar prematuramente os impactos de eventuais
atrasos, problemas com a qualidade e custos excessivos.
Além das imposições legais para as inspeções e auditorias, em muitos ca-
sos o cliente do projeto pode adotar tais ações por iniciativa própria ou norma da
organização.
8.3.2 Sistemas de documentação

Aquisições e contratos necessitam ser adequadamente registrados. Alguns dos
principais tipos de benefícios decorrentes dessa ação são:
• Legais – respaldar reclamações e reivindicações futuras.
• Gerenciais – fundamentar decisões, recuperar informações, controlar.
• Estratégicas – beneficiar projetos futuros.
• Documental – armazenar informações e lições aprendidas.
Um sistema de registro de informação sobre aquisições idealmente se baseia em
bancos de dados ou planilhas eletrônicas. Hoje em dia, ambos permitem buscas inde-
xadas, que constituem uma das principais vantagens do registro das informações.
Não há um formato padrão para o sistema de documentação. Frequentemente
são empregados os seguintes campos:
• identificação do fornecedor e de pessoas de contato;
• histórico de aquisições;
• avaliação dos fornecimentos passados, com pontos fortes e fracos;
• cópia dos contratos passados e vigentes;
• oportunidades de parcerias, desenvolvimentos conjuntos, negócios etc.
A depender do projeto, outros campos podem ser selecionados.
8.3.3 Análise de desempenho

Trata-se de uma avaliação sistemática e estruturada do fornecedor. Ela inclui o
histórico do fornecedor quanto à entrega das aquisições, de acordo com as condições:
• Prazo – Atrasos na entrega? Cancelamentos?
• Escopo – Entregou o que prometeu?
• Qualidade – Entregou na qualidade contratada?
• Flexibilidade – Consegue administrar bem mudanças no pedido?
• Inovação – Está sempre atualizado? Oferta inovações?
• Preço – Possui preços competitivos em geral?
Quanto mais competitivo for o mercado fornecedor, mais provável é que exista
uma autorregulação da qualidade do fornecimento. Ou seja, somente permanecem no
mercado bons fornecedores, e as diferenças entre eles são pequenas. Mesmo assim, a
análise de desempenho continua importante para explorar as condições mais valoriza-
das em cada projeto ou organização em particular.
Além dos itens de desempenho mencionados anteriormente, é útil manter um
registro das boas e más experiências com fornecedores. Esse procedimento ajuda a
obter rápidas decisões para projetos futuros, bem como a repassar informações aos
profissionais atuantes nos novos projetos.
A análise de desempenho de um fornecedor pode ser realizada nos proje-
tos em andamento ou no término destes. Os critérios de análise precisam ser claros
e não devem mudar muito, para que proporcionem uma melhor comparação entre os
fornecedores.
8.3.4 Administração de reclamações e relacionamentos

Em projetos, não é raro o surgimento de conflitos. A escassez de tempo e
recursos nos projetos, assim como a existência de vários tipos de stakeholders, contri-
buem para esse fenômeno. Muitos desses conflitos resultam em reclamações e reivin-
dicações, as quais devem ser adequadamente administradas. A gestão desses tópicos
em projetos é tratada em diversos pontos do RBC (SANTOS; CARVALHO, 2006) como
procedimento para controlar e avaliar os desvios ou alterações, bem como suas conse-
quências econômicas em relação a acordos preestabelecidos. Seus objetivos são de-
finir, evitar, motivar ou executar reivindicações. Estas ocorrem quando fornecedor e
comprador não chegam a um acordo. Elas podem ser resolvidas entre as partes, por
terceiros ou judicialmente.
A execução da gestão de reclamações e reivindicações envolve tanto aspec-
tos técnicos (para fundamentar as reclamações e reivindicações) como políticos (para
negociar reparações) e até jurídicos (para executar ações legais). Na maior parte dos
casos de reclamações, não é possível parar o projeto para negociar ou reivindicar repa-
rações; frequentemente, estas são pleiteadas só após o encerramento do projeto.
A administração de reclamações e reivindicações custa tempo e dinheiro, porém,
é necessária, pois pode beneficiar importantes relacionamentos com fornecedores, em
projetos futuros.
Um outro procedimento para diminuir prejuízos com as aquisições é a gestão dos
relacionamentos com fornecedores. Embora ela implique custos de transação (para
construir, manter e controlar relacionamentos), apresenta benefícios como:
• facilidade para negociar compensações, em caso de reclamações;
• agilidade no atendimento do fornecedor;
• descontos de preço e formas facilitadas de pagamento;
• parcerias para desenvolver produtos e serviços sob medida;
• prioridade no atendimento.
Algumas providências para gerenciar os relacionamentos com fornecedores im-
portantes são, por exemplo:
1. Manter o contato – relacionamentos regulares com o fornecedor.

2. Avaliar o desempenho – mesmo se não houver compras recentes.
3. Avaliar a capacidade de suprimento – volume, atualização, novidades.
4. Buscar ideias – inovações potencialmente úteis para futuros projetos.
5. Afirmar comprometimento – manter-se como parceiro privilegiado.
Para manutenções em seu website, uma loja experimentou diversas equipes de design.
Invariavelmente, os serviços atrasaram, não apresentaram qualidade e precisaram ser corrigi-
dos sob muita insistência. As multas recebidas pelos maus serviços não compensaram os pre-
juízos para o negócio.
As gestões das reivindicações e dos relacionamentos têm recebido cada vez mais
atenção, não apenas nos projetos, mas também nas operações. Em ambos os casos
têm crescido recentemente os investimentos em providências nesse sentido, tais como
a construção de call centers e websites interativos, a realização de pesquisas de opinião
e a contratação de pessoal jurídico de apoio.
8.4 Avaliação de impactos e encerramento das aquisições

Neste item busca-se avaliar os impactos das aquisições reais de um projeto quan-
do essas diferem das aquisições especificadas. Esse assunto foi anteriormente formu-
lado pela seguinte pergunta:
• Qual é o impacto para o negócio, quando um material requisitado pelo projeto
é substituído por outro?
Diferenças entre aquisições especificadas e reais podem resultar em variações de
custo mínimas para um projeto, mas consequências financeiras enormes para o negó-
cio do projeto. Enquanto as primeiras não são difíceis de serem calculadas, as últimas
exigem bem mais esforços. A seguir, discute-se esse assunto em nível técnico e apre-
sentam-se sugestões para algumas aplicações mais usuais.
8.4.1 Avaliação de impactos

Os impactos de uma aquisição consideram três níveis administrativos e seus res-
pectivos critérios de sucesso, conforme indica a tabela a seguir.
Impactos das aquisições

Nos níveis Critérios de sucesso
Da própria aquisição Pontualidade da entrega, conformidade com especificações, descri-
ção de conteúdo e custo combinado são garantidos.
Do projeto Cronograma do projeto sem atraso, orçamento mantido, qualidade
técnica mantida, escopo conforme o termo de abertura.
Do negócio Solução entregue no prazo, com qualidade percebida esperada, es-
copo previsto em contrato, riscos adequados.
O impacto mais relevante ocorre no nível do negócio, que é a razão de ser do pro-
jeto e das aquisições. Um problema recorrente em projetos é a falta de tempo para
avaliar sistematicamente o impacto de cada aquisição no negócio. Assim, não rara-
mente, ocorrem divergências entre recurso especificado e recurso realmente adqui-
rido, sem que se consigam pesquisar os efeitos junto aos stakeholders (FREEMAN,
2013). O exemplo do bolo de cereja, a seguir, ilustra bem o caso.
Uma panificadora produzia bolos artesanais de cereja, famosos em toda a região.
Gradualmente ela automatizou a produção e otimizou a receita, bem como substituiu
diversos ingredientes por outros mais baratos. O produto deixou de vender quando as
cerejas “gigantes” foram substituídas devido ao seu alto custo. Esse exemplo ilustra a
perda de foco no negócio, em função de alteração em apenas um item. Já nos níveis do
projeto e das aquisições, não houve problemas.
As maiores dificuldades para a verificação do impacto das aquisições no negó-
cio costumam ser o tempo e os custos envolvidos. Ao menos a primeira delas pode ser
contornada com a preparação de um sistema estruturado de pesquisa, apoiado por do-

cumentação padronizada.
O seguinte exemplo pode inspirar soluções nesse sentido: em aeronaves de pe-
queno porte, um importante item é a decoração interna. Um simples pedaço de tecido
não consegue representar bem como ficará o interior do futuro avião quando este te-
cido for aplicado à decoração. Também não é viável manter dezenas de aviões decora-
dos como mostruário. Nesses casos, o uso de realidade virtual 3D é uma solução até
certo ponto simples e muito eficaz.
Esse exemplo relata uma forma de mostrar ao cliente dezenas e até centenas de
decorações internas de um avião que ainda não existe. As decorações podem ser alte-
radas rapidamente e também combinadas entre si. Assim, investiu-se em um sistema
muito ágil para avaliar o impacto da mudança da especificação de um recurso (as cores
da tapeçaria) no nível do negócio.
8.4.2 Negociações, ajustes e correções

A administração de reclamações e reivindicações enfatizou a habilidade de ne-
gociação do gerente de projetos. Essa importância é reforçada no RBC (SANTOS;
CARVALHO, 2006), que menciona que o resultado de uma negociação pode ser um
consenso ou uma decisão. Ele também cita como principais instrumentos da negocia-
ção as reuniões e as discussões em grupo (mais recentemente, outras formas virtuais
também são comumente empregadas, tais como e-mails e chats).
Sobre o tema, o PMBOK® (PMI, 2013) aponta que fracassos em negociações re-
sultam em uma escalada da disputa para o nível da arbitragem ou mediação. Após es-
ses níveis, resta somente o processo judicial, que é a opção menos desejada.
Muitas técnicas de negociação são encontradas em livros de Direito e
Administração. Como não devem ser abordadas apenas superficialmente, recomenda-
-se a gerentes de projetos uma leitura atenta sobre o tema e a seleção das técnicas
mais adequadas para os projetos de seu interesse.
Um projeto gráfico necessita 20 mil folhas de papel especial por 18 meses. O fabricante aceita
encomendas mínimas de 100 mil folhas, por causa da preparação da máquina. Negociou-se au-
mentar o pedido de um outro comprador, de 250 mil para 270 mil folhas mensais, e assim aten-
der ao cliente.
8.4.3 Encerramento de contratos e documentação

Todo projeto necessita ser encerrado, sem exceção. Projetos não encerrados for-
malmente continuam gastando recursos e ficam sujeitos a todo tipo de exigibilidades.
O encerramento de um projeto exige o encerramento de todos seus contratos –
tanto os de entrega de produtos quanto os de aquisição de recursos. Alguns itens mais
relevantes, para a verificação desses contratos são ilustrados na tabela a seguir, a títu-
lo de exemplo. A tabela também indica itens de verificação para a avaliação das entre-
gas – dos produtos e das aquisições. Esses itens podem ser expandidos, em função das
necessidades específicas de cada projeto.
Verificações para encerramentos de projetos

Contratos de entrega dos produtos Contratos das aquisições
• Comparação das especificações do produto final • Comparação das especificações dos recursos
com a linha de base do escopo. contratados e recebidos.
• Comparação das condições do produto final com • Comparação das condições (prazos etc.) dos re-
os contratos iniciais (prazos etc.). cursos contratados e recebidos.
• Comparação das condições do produto final com • Comparação das quantidades contratadas e re-
o business case. cebidas.
• Comparação das funcionalidades do produto • Testes de conformidade dos recursos recebidos
com aquelas previstas em contrato. ou dispensa de testes.
• Testes de conformidade e funcionalidade do pro- • Quitação dos pagamento e demais obrigações de
duto final. todas as partes.
• Quitação dos pagamentos e demais obrigações
de ambas as partes.
Avaliação dos produtos Avaliação das aquisições
• Nível de satisfação dos clientes e demais stakeholders • Condições excepcionais em que foram recebidas.
(FREEMAN, 2013). • Nível de relacionamento com os fornecedores.
• Reclamações dos clientes e demais stakeholders • Vantagens de custo em relação ao mercado.
(TRENTIM, 2013).
• Autoavaliação pela equipe de projetos.
As verificações dos contratos procuram determinar se estes foram legalmente sa-

tisfeitos. Já as avaliações buscam determinar os resultados não necessariamente pre-
vistos em contratos, mas que determinam o sucesso do negócio e das aquisições (OGC,
2009). Como exemplo, considere-se o projeto de uma reforma residencial. Muito fre-
quentemente, não há um contrato formal entre empreiteiro e proprietário. Ao final da
reforma, não é raro o surgimento de conflitos, relativos aos itens contratados inicialmen-
te e aos itens adicionados posteriormente (em geral, estes são caros). Mesmo quando
existe um contrato, ele costuma descrever apenas o escopo dos trabalhos, mas não o ní-
vel da qualidade dos serviços executados. Como consequência, ambas as partes tendem
a achar que receberam menos do que foi combinado.
8.4.4 Um exemplo detalhado para pequenos projetos

Ilustra-se a seguir uma aplicação das gestões de Recursos Humanos, Comunicação,
Riscos e Aquisições, em um projeto de pequeno porte: o tele-lançamento de um livro.
Sendo um projeto pequeno, ele não emprega ferramentas sofisticadas de gestão, como
no caso de um projeto complexo; por outro lado, permite uma visão panorâmica sobre a
integração das diversas gestões.
A. Descrição do projeto
Descrição do projeto e suas condições (briefing)
O projeto trata do lançamento do livro Guia de Tecnologia com um evento em
tempo real na internet, durante 40 minutos. No final do evento, os participantes po-
dem encomendar o livro e recebê-lo pelo correio, autografado pelo autor.
O orçamento é R$ 50.000,00, sendo R$ 30.000,00 a fundo perdido, e o restante
captado pelo próprio projeto. O prazo de preparação do lançamento é seis meses. Da
coordenação do projeto participam o pessoal da editora, o próprio autor e uma equipe
externa contratada temporariamente.
O tele-lançamento é um conceito novo, idealizado e desenvolvido para este pro-
jeto. Ele pretende superar o modelo tradicional de lançamento de livros em livrarias,
nos quais comparecem poucas pessoas que adquirem o livro autografado pelo autor. O
tele-lançamento busca principalmente a “visibilidade” e esta é proporcionada de duas
maneiras: no ato do lançamento e nas fases pré e pós-lançamento. Para reforçar a vi-
sibilidade, conta-se com o serviço de mailing estratificado, com os sítios eletrônicos da
editora e com um sítio eletrônico criado exclusivamente para divulgar o lançamento.
Para motivar as pessoas a assistirem ao lançamento em tempo real, são previstos
três videoclipes: dois com shows musicais de artistas conhecidos e outro com a entre-
vista de um gerente de projetos da área de telefonia. O lançamento (inclusive os video-
clipes) é acessível apenas em tempo real. Essa restrição imprime mais autenticidade e
novidade ao evento e atrai mais público.
O livro resulta de um projeto também inovador: é uma obra cara, com todas as
páginas impressas em cores, que descreve os mais importantes conceitos de base tec-
nológica da atualidade (por exemplo: o que é nanotecnologia, bioinformática, robó-
tica, bioenergia, segurança da informação, armas e sistemas militares, inteligência
autônoma, técnicas de medição etc.). Ele tem cerca de 500 páginas e 1.000 fotos e de-
senhos coloridos. O público-alvo é composto por pessoas que presenteiam amigos e fi-
lhos em idade pré-universitária, bem como por bibliotecas de escolas e faculdades.
O negócio, o problema, a solução e o produto do projeto

O negócio do projeto consiste na visibilidade que o lançamento da obra propor-
cionará ao livro e à editora. Essa visibilidade será convertida em vendas de livros du-
rante o lançamento e também depois dele. Ela também beneficiará a boa imagem da
editora e seus objetivos comerciais com outros livros.
O problema do projeto é o lançamento do livro de forma a atingir um grande nú-
mero de participantes e alavancar as vendas iniciais.
A solução do problema do projeto é o lançamento baseado na plataforma eletrô-
nica e nas competências gerenciais da equipe (capabilidades). Ela proporciona ao parti-
cipante uma experiência marcante, inesquecível, e reforça a marca da editora.
O produto do projeto é o evento de lançamento, que dura cerca de 40 minutos
(o produto não é o livro) e resulta do esforço do projeto. Por outro lado, o trabalho do
projeto dura cerca de seis meses e resulta no livro lançado.
Business case
O business case do projeto (documento que justifica a realização do projeto) con-
tém os seguintes elementos:
Business case
Elementos Descrição
Objetivo do projeto Lançamento eletrônico de um livro.
Stakeholders Autor, clientes, editora, legislação, concorrentes, governança.
Interesses dos stakeholders Mencionados anteriormente.
Indicadores de sucesso Sucesso do projeto e sucesso do negócio.
Principais entregas Livro lançado conforme especificações e interesses.
Diretrizes da governança Imagem da editora reforçada, normas internas respeitadas.
Definição da solução Lançamento de livro com base em plataforma eletrônica.
Recursos e capabilidades Plataforma eletrônica contratada, pessoal capacitado.
Orçamento R$ 80.00000, sendo R$ 50.000,00 a fundo perdido.
Com base nesse business case, esboçam-se a seguir os planos de algumas gestões
do projeto. Os planos mais detalhados podem ser elaborados mediante a expansão
dos planos inicialmente esboçados.
B. Planos auxiliares do gerenciamento do projeto

Os planos auxiliares do projeto do tele-lançamento do livro, analisados nesse tó-
pico, abordam as gestões de: Recursos Humanos, Comunicação, Riscos e Aquisições
(os planos das gestões de Stakeholders, Escopo, Qualidade, Prazos e Custos já foram
mostrados em um outro ponto do texto).
Gestão de Recursos Humanos

Inclui a contratação e o engajamento de pessoas para:
• planejar o evento de lançamento em detalhes;
• ajustar e configurar a plataforma de transmissão do evento;
• editar e sincronizar os videoclipes e gravações prontas;
• ensaiar os participantes do evento ao vivo.
A estrutura organizacional do projeto é ilustrada a seguir:
1 Gerenciamento do projeto: coordenação geral do projeto
1.1 Aquisição dos recursos
1.1.1 Recursos existentes na editora
1.1.2 Recursos externos contratados no mercado
1.2 Gerenciamento dos riscos
1.3 Gerenciamento do desenvolvimento
1.3.1 Do evento
1.3.2 Da plataforma
1.3.3 Dos videoclipes e filmes
1.4 Gerenciamento da divulgação do evento
1.5 Monitoramento e controle das atividades integradas
Com base nessas funções, elabora-se a matriz de responsabilidades. Ela relaciona
as tarefas do projeto com as pessoas envolvidas nessas tarefas.
Gestão da Comunicação
A equipe do projeto é distribuída geograficamente e somente em casos excepcio-
nais se reúne fisicamente. Os fornecedores externos (plataforma, estúdio, pessoal es-
pecializado etc.) também preferem o trabalho remoto, quando possível.
A comunicação padrão emprega e-mail e software para mensagens. Ligações te-
lefônicas são evitadas porque dificultam o registro dos conteúdos. Reuniões presen-
ciais são realizadas nas fases: (1) definição do negócio, (2) abertura e apresentação,
(3) teste da solução e (4) encerramento do projeto.
Por motivo de sigilo sobre a nova solução para lançamento de livros, somente
uma pessoa da editora está autorizada a comentar o projeto com pessoas externas,
quando necessário. Ela analisa e filtra as informações sobre o tema.
A seguinte matriz de comunicação relaciona os processos do projeto.
Matriz de comunicação
Stakeholders Objetivos Providências Método Quando
Autor Apresentar a Apresentação, Res- Transmissão, No evento e pós
obra postas e-mail (depois) evento
Público do tele-lan- Participação, Participar do tele- Apresentação Hora do evento
çamento informação -lançamento com iteração
Editor Vendas, divul- Coordenação, Di- Reuniões, Todo o ciclo de
gação vulgação e-mails, telefone, vida do projeto
chat
Artista convidado Entretenimen- Apresentação de Transmissão em Hora do evento
to show pronto tempo real
Marketing Divulgação do Campanhas de di- Mala direta, web- Todo o ciclo de
evento vulgação site, rádio vida do projeto
Gerente do projeto Coordenação Coordenação, liga- Reuniões, Todo o ciclo de
supervisão, ção com o negócio, e-mails, telefone- vida do projeto
controle controle mas, relatórios,
website
Equipe do projeto Planejamento Planos do projeto, Reuniões, Todo o ciclo de
execução e execução e con- e-mails, telefone- vida do projeto
controle trole mas, relatórios,
website
Gestão de riscos
Identificam-se as principais variáveis do risco para o projeto. Em seguida, esses
riscos são analisados e tratados. Finalmente, eles são monitorados e controlados. Um
resumo desses procedimentos se encontra na tabela seguinte.
Análise de riscos no projeto do tele-lançamento do livro

Risco Análise Tratativas adotadas
Falha nos equipamentos Probabilidade média, Contratação de equipamento reser-
na hora da transmissão impacto alto va, duplicação de recursos
Ausência de um dos ar- Probabilidade baixa, im- Gravação de vídeo com a apresenta-
tistas ou mais de um pacto médio ção do artista (Plano B)
Ausência de patrocínios Probabilidade baixa, im- Simplificação do evento, uso de re-
pacto baixo cursos gravados
Falhas de conexão na Probabilidade alta, im- Contratação de dois sistemas para-
hora da transmissão pacto alto lelos e independentes
Atrasos na preparação Probabilidade média, Reserva de pessoal de reforço, capa-
do projeto impacto alto citado para substituir faltantes
Uma tratativa dos riscos muito comum não pôde ser empregada no projeto: a
contratação de seguros. O motivo principal é porque o produto do projeto é inovador
e não possui histórico suficiente para os cálculos atuariais. Além disso, o risco “falhas
de conexão na hora da transmissão”, por ter impacto alto e probabilidade alta, deveria
determinar o cancelamento do projeto. Contudo, optou-se pela sua continuidade em

função da oportunidade estratégica do e-lançamento.
Gestão de aquisições
O papel das aquisições é proporcionar o maior valor possível para o negócio do
projeto com base nos recursos a serem adquiridos (comprados, alugados, contratados,
emprestados, doados etc.). Alguns desses recursos do projeto do tele-lançamento são:
• Equipamentos – aparelhos para preparação e transmissão do evento.
• Pessoal – profissionais capacitados em informática, filmagem, comunicação
de massa e edição de filmes.
• Dinheiro – financiamento da editora e da captação de patrocínio.
• Infraestrutura – estúdio de gravação e salão da festa do evento.
• Informações – pesquisa de campo sobre o público-alvo (contratada).
Nas abordagens escolhidas para a qualidade (transcendental e baseada no pro-
duto), recursos com alta qualidade contribuem diretamente para o sucesso do pro-
jeto. A aquisição desses recursos se baseia em um criterioso processo de seleção de
fornecedores.
Algumas condições tiveram que ser negociadas entre o editor e o autor do livro. O
primeiro preferiu uma transmissão focada no entretenimento e nos shows musicais para
cativar o público. Já o autor exigia mais tempo para explicar o conteúdo da obra. A dis-
puta foi resolvida com a mediação do pessoal da produção artística em favor do autor.
Para o editor foi muito importante documentar a nova experiência meticulosa-
mente. E também avaliar a reação dos públicos atingidos. Ele pretende firmar sua no-
vidade no mercado, com projetos semelhantes.
A análise de desempenho foi dividida em dois blocos: a reação do público e a re-
lação custo-benefício. O primeiro bloco foi pesquisado pela equipe de marketing. O se-
gundo bloco foi analisado pelo editor, com base nas vendas no lançamento, nas vendas
posteriores devido ao lançamento e nos custos totais do lançamento. Embora o lucro
com as vendas no lançamento não pagasse os gastos, o déficit foi considerado um in-
vestimento para projetos similares, no futuro, com custos otimizados.
C. Análise
O exemplo descrito ilustra quatro tópicos do Gerenciamento da Integração (ges-
tões de Recursos Humanos, Comunicação, Riscos e Aquisições). O projeto descrito foi
intencionalmente escolhido por ser pequeno e simples. O objetivo desse exemplo é
mostrar que mesmo pequenos projetos podem se beneficiar com um gerenciamento
da integração realizado de modo sistemático e documentado.
Referências
06/02/2015.
BOWERSOX, D. J.; COOPER, B. C.; BOWERSOX, J. C. Gestão Logística de Cadeias de
Suprimentos. Porto Alegre: Bookman, 2006.
DORNIER, P. P et al. Logística e Operações Globais: textos e casos. São Paulo: Atlas,
2000.
21, n. 1, 2013.
HEDEMAN, B. et al. Project Management Based on PRINCE2®: an introduction.
2012.
KERZNER, H.; SALADIS, F. P. Value Driven Project Management. Nova Iorque: Wiley,
2009.

2006.
SANTOS, J. A. Agile resource management: creating competitive advantage.
Proceedings. In: 14th Internatcioal Product Development Management Conference,
2007, Lisboa, Bruxelas: EIASM, 2007, v. 1, p. 123-133.
2005.
VIEIRA, D. R.; ROUX, M. Auditoria Logística: uma abordagem prática para operações
de centros de distribuição. Rio de Janeiro: Campus, 2012.

Gestão de Projetos - Livro UP

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

Gestão de Projetos - Livro UP

Enviado por

Direitos autorais:

Formatos disponíveis

Gestão de

Dados Internacionais de Catalogação na Publicação (CIP)

S237 Santos, José Amaro dos

Sistema requerido: Adobe Acrobat Reader.

1. Administração de Projetos. 2. Planejamento estratégico.

Esta obra apresenta o gerenciamento de projetos segundo uma abordagem es-

Dedico àqueles leitores ávidos

Gerenciar projetos com enfoque no negócio exige primeiramente um claro enten-

1.1 Relevância dos projetos e análise do negócio

1.1.1 Projetos como motores da mudança

1.1.2 Áreas de aplicação

O problema do projeto: exemplos

Projetos estão em todos os lugares e as oportunidades para gerenciá-los não

1.1.3 Conceitos fundamentais

Projeto, subprojeto, programa e portfólio

A divisão de um projeto em subprojetos não permite que um deles seja eliminado

a quantidade de quilômetros expandidos na rede e divulga que o aumento de 25% é

1.1.4 Análise de negócios

Capabilidade é a habilidade de um processo ou sistema alcançar seus objetivos.

Considere-se um projeto já conhecido e administrado segundo o gerenciamento de projetos

1.2 Pesquisa de stakeholders

Stakeholders podem também ser denominados partes interessadas e intervenientes, no entan-

Como os stakeholders de um projeto usualmente são múltiplos e distintos

Exemplos de stakeholders típicos de projetos

Clientes Colegas Políticos

Design Gráfi co: Guilherme Rufatto

Para a pesquisa de stakeholders, a figura a seguir propõe uma classificação em

O PRINCE2 (OGC, 2009) emprega três categorias: usuário, negócio e fornecedor.

Classificação dos stakeholders de um projeto

Gestão estratégica do projeto

Essa classificação representa uma abordagem estratégica do gerenciamento do

(Clientes) Pesquisas de mercado,

(Concorrentes) Análise SWOT,

(Organização) Balanced scorecard,

(Ambiente) Análise de riscos,

estudo de leis e normas técnicas,

Para a identificação dos stakeholders, Trentim (2013) sugere as seguintes questões:

Embora o cliente procure valor no produto do projeto, a equipe de projetos se

A governança influencia também os parceiros do projeto. O produtor de alimen-

Os desafios de um projeto são medidos preferencialmente em relação a referências, a padrões

O produtor de alimentos citado anteriormente adota padrões realistas de se-

produtos concorrentes; mas também não devem ser demasiadamente exigentes a

total do projeto. Por exemplo, o respeito às normas técnicas, em um projeto de produ-

Para classificar muitas preferências coletadas sobre um produto, em um número reduzido de

1.2.4 Plano de gerenciamento dos stakeholders

1.3 O problema do projeto e pesquisa de soluções

1.3.1 O problema do projeto

O problema do projeto: exemplos

Alguns critérios para priorização de requisitos

Algumas técnicas para priorizar requisitos foram mencionadas no item sobre os

Validação dos requisitos

• a identificação dos requisitos seleciona-

© Sergey Nivens / / Fotolia

Os requisitos validados, acompanhados das premissas e restrições, fornecem

1.3.3 Pesquisa de soluções

1.3.4 Estudos de viabilidade e seleção de soluções

Um estudo de viabilidade pode tanto preceder quanto suceder o business case; na

Análise de viabilidade de um projeto ou empreendimento

Design Gráfico: Guilherme Rufatto

A avaliação da figura “Análise de viabilidade de um projeto ou empreendimento” pode ser re-

Um estudo de viabilidade pode conter os seguintes itens (KEELING, 2012):

• Dados existentes – projetos e experiências anteriores.

O processo de seleção resulta idealmente em uma única solução eleita ou adota-

1.4 Avaliação, validação e projeto da solução adotada