Conselho editorial  regiane burger; roberto paes; gladis linhares; karen bortoloti;

helcimara affonso de souza

Autoras do original  helcimara affonso de souza; marina sanches pagliarussi

Projeto editorial  roberto paes

Coordenação de produção  gladis linhares

Coordenação de produção EaD  karen fernanda bortoloti

Projeto gráfico  paulo vitor bastos

Diagramação  bfs media

Revisão linguística  amanda carla duarte aguiar

Imagem de capa  robert kneschke | dreamstime.com

Todos os direitos reservados. Nenhuma parte desta obra pode ser reproduzida ou transmitida
por quaisquer meios (eletrônico ou mecânico, incluindo fotocópia e gravação) ou arquivada em
qualquer sistema ou banco de dados sem permissão escrita da Editora. Copyright seses, 2016.

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

S729g Souza, Helcimara

Gestão da qualidade em projetos / Helcimara Souza; Marina Sanches
Pagliarussi
Rio de Janeiro : SESES, 2016.
168 p. : il.

isbn: 978-85-5548-208-3

1. Gestão da qualidade. 2. Gerenciamento de projetos. 3. PMI. 4. PMBOK.

I. SESES. II. Estácio. cdd 658.4013

Diretoria de Ensino — Fábrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus João Uchôa
Rio Comprido — Rio de Janeiro — rj — cep 20261-063
Sumário

Prefácio 7

1. Introdução ao Gerenciamento de Projetos 9

1.1  Introdução ao Gerenciamento de Projetos 12
1.2  Definindo Projeto 17
1.2.1  O que é um projeto bem-sucedido? 21
1.3  O PMI e sua certificação 25
1.4  Ciclo de Vida e da Organização de um Projeto 28
1.4.1  Características do ciclo de vida do projeto 30
1.4.1.1  Potencial de Adicionar Valor ao Projeto 30
1.4.1.2  Custo das Mudanças ou Correções 31
1.4.1.3  Capacidade de Adequação 31
1.4.1.4  Incerteza do Risco x Quantidade Arriscada 32
1.5  As Fases do Ciclo de Vida do Projeto 33
1.6  Principais Áreas de Conhecimento do
Projeto segundo PMBOK 38

2. Gerenciamento de Integração e
Gerenciamento de Escopo 51

2.1  Processo de Integração do Projeto 54

2.1.1  Desenvolver o termo de abertura do projeto 56
2.1.2  Desenvolver o plano de gerenciamento do projeto 59
2.1.3  Orientar e gerenciar a execução do projeto 59
2.1.4  Monitorar e controlar o trabalho do projeto 60
2.1.5  Realizar o controle integrado de mudanças 60
2.1.6  Encerrar o projeto ou fase 61
2.2  Gerenciamento de Escopo 61
2.2.1  Coletar os requisitos 63
3. Gerenciamento de Tempo,
de Custo e Gerenciamento de
Recursos Humanos 81

3.1  Gerenciamento de Tempo 83

3.2  Processos do Gerenciamento do Tempo 86
3.3  O Gerenciamento de Custo 102
3.3.1  Processos de Gerenciamento de Custos 104
3.3.1.1  Estimar os custos 104
3.3.1.2  Determinar o orçamento 104
3.3.1.3  Controlar os Custos 105
3.3.2  Fatores Importantes 105
3.3.3  Plano de Gerenciamento de Custos 106
3.4  O Gerenciamento de Recursos Humanos 106
3.4.1  O desenvolver o plano de recursos humanos 108
3.4.2  Mobilizar a equipe do projeto 108
3.4.3  Desenvolver a equipe do projeto 108
3.4.4  Gerenciar a equipe do projeto 109

4. Gerenciamento de Riscos, Comunicações,

da Qualidade, do Gerenciamento
de Aquisições e Partes Interessadas 113

4.1  Gerenciamento das Comunicações 115

4.1.1  O Processo de Comunicação 116
4.1.2  Como Identificar um bom plano de comunicação 117
4.1.3  Planejamento das Comunicações segundo o PMBOK 118
4.1.4  Processo de Gerenciamento da Comunicação 118
4.2  Gerenciamento de Riscos 121
4.2.1  Planejar o gerenciamento de riscos 122
4.2.2  Identificar os riscos 122
4.2.3  Realizar a análise qualitativa de riscos 122
4.2.4  Realizar a análise quantitativa de riscos 123
4.2.5  Planejar as respostas a riscos 123
4.2.6  Monitorar e Controlar os riscos 123
 4.3  Gerenciamento das Aquisições 123
4.3.1  Planejar as Aquisições 124
4.3.2  Conduzir as Aquisições 125
4.3.3  Administrar as Aquisições 125
4.3.4  Encerrar as Aquisições 125
4.4  Gerenciamento dos Stakeholders – Partes Interessadas 126
4.4.1  Identificar as partes Interessadas 127
4.4.2  Planejar o gerenciamento das partes interessadas 127
4.4.3  Gerenciar o envolvimento das partes interessadas 128
4.4.4  Controlar o nível de comprometimento das
partes Interessadas 128

5. A Qualidade Num Projeto e o

Processo de Gerenciamento da Qualidade 133

5.1  Visões da Qualidade 136

5.2  Conceitos de Qualidade segundo Deming 136
5.3  Eras da Qualidade 140
5.4  A Qualidade num Projeto, segundo PMI 144
5.4.1  Conceito de Qualidade 145
5.4.2  Princípios Básicos 145
5.4.3  Processo de Gerenciamento da Qualidade em
Projetos Segundo PMBOK 146
5.4.4  Planejamento da Qualidade 146
5.5  Plano de Gerenciamento da Qualidade 147
5.6  O que usamos para elaborar o plano 148
5.7  Controle da Qualidade 149
Prefácio
Prezados(as) alunos(as),

Bem-vindo a mais uma disciplina de seu curso! A disciplina de Gestão da

Qualidade em Projetos tem como pano de fundo as Boas práticas do PMI, uma
certificação que capacita e habilita profissionais da área de gerenciamento de
projetos e executar seus projetos com base numa lista de ações tidas como ar-
cabouço para o sucesso na execução de um projeto.
Sob um olhar mais amplo, qualquer atividade que executamos em nosso
dia a dia, mesmo que uma ida a um supermercado, pode ser tratada como um
projeto. A lista de compras é o objetivo do projeto, o tempo disponível para as
compras é o prazo, e o custo do projeto é o preço das compras. Se você planejar
bem, comprará o que precisa, poupará seu tempo nesta atividade de ida ao su-
permercado e, comprando somente o que precisa, economizará seu dinheiro.
Em outras palavras, sua ida ao supermercado foi um sucesso!
O gerenciamento de projetos também passa por essas etapas. Guardadas as
proporções de complexidade de cada projeto, as etapas que consiste um pro-
cesso de gestão de projeto são as mesmas.
Gerenciamento de projetos, por essência, existe em diferentes formas e há
muito tempo, mesmo quando não se conhecia com este nome. O uso sistemá-
tico de planejamento de projetos começou a se firmar em meados deste século.
Engenheiros civis resolveram que uma tarefa seria dividida em séries de opera-
ções; o esquema de operações seria decidido pelos responsáveis pela execução
e, a partir daí, uma sequência ordenada de execução se desenvolverá, resultan-
do em eficiência (VARGAS, 2009).
Com a atual onda de competitividade global, o desenvolvimento de um
novo produto, a implementação de uma nova tecnologia ou uma mudança or-
ganizacional obrigam as organizações a achar uma forma mais ágil e eficaz, de
atingir seus objetivos. Essas organizações estão promovendo a ideia de time,
que une qualidades interpessoais consideradas fundamentais em um projeto
de sucesso. E quando os projetos extrapolam as barreiras da empresa ou mes-
mo, quando se tornam internacionais, cria-se a necessidade de entender tam-
bém as barreiras culturais e o contato e a comunicação passa a ter como instru-
mento as ferramentas de tecnologia da informação, facilitando as interações
e promovendo reuniões virtuais, agregando valor ainda maior nas relações e
interações entre os profissionais envolvidos.

7
 Um programa de gerenciamento de projetos rigoroso pode proporcionar
os métodos, os processos e as qualidades necessárias para uma organização se
manter ativa e competitiva com as tendências e desafios do setor em que atua.
O gerenciamento de projetos, portanto, coincide, em parte, com o geren-
ciamento geral e com outras aplicações do conhecimento. O time responsável
pelo projeto deve entender sua relação com o ambiente de negócios, que envol-
ve meios maiores, como ciclos de vida, empreendedores, influência organiza-
cional, habilidades de gerenciamento e influências socioeconômicas. Muito do
conhecimento necessário para gerenciar projetos é exclusivo do gerenciamen-
to de projetos, e as técnicas se diferem das utilizadas para se gerenciar proje-
tos em curso ou operacionais. Um desafio para o gerenciamento de projetos e
para o gerente de projetos, portanto, é ajudar a organização a desenvolver uma
consciência dos temas globais e os mecanismos para responder efetivamente
a eles, assegurar que tecnologias facilitadoras são identificadas e usadas para
ir ao encontro das exigências para uma organização global e identificar meios
para o desenvolvimento e a disseminação dos produtos e serviços exigidos pelo
cliente global (VARGAS, 2009).

Bons estudos!
 1
Introdução ao
Gerenciamento de
Projetos
Várias são as razões que levam as organizações a buscar qualidade em suas ati-
vidades e no gerenciamento de projetos essa realidade não é diferente. A qua-
lidade hoje é tida como uma das principais razões de sucesso nos projetos or-
ganizacionais. São inúmeras as expectativas tanto dos executivos das empresas
quanto seus clientes, passando pelos seus colaboradores, fornecedores, socieda-
de de modo geral, ou seja, todos os stakeholders que fazem parte do negócio,
esperam bons resultados e eficácia das empresas. Este cenário por si só já é de-
safiador. Implantar qualquer ação ou estratégia sem um profundo estudo de seu
êxito, já é uma falha na gestão de uma organização. Estamos falando de projeto,
que é a fase que antecede a execução de um processo, seja ele estratégico, tático
ou operacional.
De todos os stakeholders, sabemos que o mais importante para as empre-
sas são sem dúvida, os clientes. Toda organização enfrenta a difícil tarefa de
executar projetos que atendam ou superem as expectativas de seus clientes. No
entanto, globalmente, inúmeros projetos são mal sucedidos e concluídos fora
do orçamento e prazos estabelecidos. Eles não cumprem as normas de quali-
dade e os requisitos esperados pelo cliente. Uma das causas para o seu fracas-
so pode ser atribuída a processos desalinhados e ineficientes resultantes de
uma combinação de problemas, tais como uma gestão do projeto debilitada,
estimativa de custos pobres, mal planejamento e programação, gerenciamento
de requisitos inadequado, planejamento de contingência inapropriado, bem
como muitos outros.
Vamos conhecer os conceitos essenciais desse assunto tão importante para
o sucesso organizacional!

Stakeholders: São indivíduos e organizações ativamente envolvidos direta ou indire-

tamente num projeto, cujos interesses são afetados (positiva ou negativamente) por
ele, ou que exercem influência sobre o mesmo. Incluem o gerente de projeto, o cliente,
a organização que fará o projeto, os membros da equipe de projeto, o sponsor/patro-
cinador (indivíduo/grupo interno ou externo que provê os recursos financeiros para o
projeto). Inclui também partes externas, como fundadores, vendedores, fornecedores,
agências governamentais, comunidades afetadas pelo projeto e a sociedade em geral.

10 • capítulo 1
 OBJETIVOS
Introdução ao Gerenciamento de Projetos
•  Definição de Projeto & Gerenciamento de Projetos
•  O PMI e a certificação PMP
•  Fases e Ciclos de Vida de Projetos de TI
•  Áreas de conhecimento do Gerenciamento de Projetos

capítulo 1 • 11
1.1  Introdução ao Gerenciamento de
Projetos

Para iniciar este capítulo, gostaríamos de colocar algumas questões para você
refletir. Mas não pense nessas questões de qualquer maneira, mas sim como
um gestor de negócios. É com esse olhar que deveremos encarar esta discipli-
na, como um executivo, administrador de uma corporação.
Vamos discutir um pouco as questões acima. Mas é importante lembrar que
aqui não há nenhum especialista em artes, esportes ou história japonesa e a
nossa discussão será superficial, apenas para introduzir a importância do estu-
do em gerenciamento de projetos.
Você consegue pintar quadros como Leonardo Da Vinci? Provavelmente
não, ele era um gênio e dominava a arte da pintura. Porém, com um bom curso
de pintura você poderá pintar bons quadros. Não é mesmo?
O que estamos tentando dizer é que a ciência pode desenvolver técnicas,
procedimentos e processos que servirão de meios (caminhos) para uma produ-
ção artística, e, em contrapartida, a arte pode servir de inspiração para o desen-
volvimento da ciência. (Borovik; Ramirez; Ramirez, 2010).

COMENTÁRIO
Reflita!!!
1. Qual é a diferença entre ciências e artes?
2. Por que o Japão conseguiu se reerguer tão rapidamente da Segunda Guerra Mundial?

Lógico que, somente com as técnicas artísticas desenvolvidas pela ciência,

dificilmente iremos criar vários “Leonardo Da Vinci”, pois, como vocês já de-
vem ter estudado, a competência não depende apenas do conhecimento, há,
ainda, a atitude e a habilidade cercando este conceito. Contudo, um arcabouço
de conhecimentos e técnicas é o começo para a construção dessa competência.
Agora vamos refletir nossa segunda pergunta: Por que os japoneses conse-
guiram se reerguer tão rapidamente após o terror da Segunda Guerra Mundial?
Óbvio que são vários os fatores que levaram o Japão a se reerguer tão rapida-
mente após a Segunda Guerra Mundial, mas gostaríamos de dar atenção a um

12 • capítulo 1
especial: a implantação nas empresas japonesas, principalmente nas empresas
automobilísticas, da técnica da qualidade total.
Essa técnica busca atuar principalmente no processo de produção dos bens
e serviços para conseguir produtos mais baratos e com maior qualidade, ou
seja, busca melhorar a qualidade do processo para, consequentemente, con-
seguir uma melhora na qualidade do produto. De forma resumida, a técnica de
qualidade total é um conjunto de metodologias e ferramentas que devem ser
aplicadas ao processo produtivo de forma sistemática, para que este torne-se
maduro o suficiente para produzir sempre produtos de qualidade.
Portanto, podemos pensar que o sucesso das empresas japonesas no pós-guerra
pode ser atribuído à sistematização do processo de produção (principalmente), para
que a qualidade do produto pudesse se repetir a cada unidade produzida, indepen-
dentemente do “heroísmo” das pessoas que estão produzindo cada unidade dessas.
Após refletirmos sobre essas duas questões tão distintas e que mostram
como o contexto, as técnicas e processos são importantes para o sucesso de
uma ideia. Mas você deve estar pensando o que essas reflexões têm a ver com
nossa disciplina? E a resposta é simples, porém ela vem também como uma
nova pergunta: “como você quer gerenciar os seus projetos?”
Fazendo analogia com a discussão que tivemos até aqui, para gerenciar
um projeto nós podemos agir pelo lado da arte, dependendo única e exclusiva-
mente da competência e do heroísmo dos gerentes de projetos e torcer, a cada
projeto que for realizado, para que tudo dê certo e também torcer para que os
gerentes que “saibam” gerenciar um projeto nunca saiam da sua empresa, pois
se isto acontecer, juntamente com a saída do seu gerente também irão sair os
conhecimentos dele em gerenciamento de projetos.
Ou, então, podemos atuar no processo de gerenciamento dos projetos de
forma a sistematizá-lo e sempre buscar repetir no projeto presente os sucessos
de projetos anteriores, por meio da utilização das melhores práticas, ferramen-
tas e metodologias de gerenciamento de projetos.
Na primeira forma, o gerenciamento de projetos pode dar certo para alguns
projetos, mas dificilmente os sucessos anteriores serão repetidos em projetos
presentes, pois quase sempre não há uma sistematização que indique o motivo
pelo qual o projeto anterior deu certo.
Já na segunda forma de se gerenciar um projeto, a instituição (ou a equipe,
ou a organização...) define um processo sistemático e formalizado por meio do
qual todos os gerentes de projeto devem gerenciar os seus projetos.

capítulo 1 • 13
 Dessa forma, é possível identificar nos projetos findados o que ocorreu de
errado, para que consertos no processo de gestão possam acontecer inibindo,
assim, a repetição da falha. E como todos os gerentes utilizam o mesmo proces-
so, todos eles irão usufruir desta melhoria.
Além do mais, utilizando a segunda forma, o conhecimento de “como ge-
renciar” fica também na instituição, tornando-se, assim, um ativo dela e não
somente um ativo da cabeça de cada gestor.
É óbvio que um gestor competente ainda é essencial para a boa execução
desse processo de gerenciamento. Contudo, o treinamento de gestores fica
mais facilitado, uma vez que o formalismo do processo de gestão permite a re-
produção deste conhecimento.
Esta facilidade de treinamento permite às empresas (instituições, organiza-
ções...) “produzir” ótimos gestores.
Então, pessoal, nesta disciplina iremos estudar o gerenciamento de proje-
tos de acordo com a segunda visão discutida, ou seja, iremos estudar as me-
lhores práticas, metodologias e habilidades de gerenciamento de projetos para
nos ajudar a estabelecer procedimentos que nos apoiem no gerenciamento dos
projetos das nossas empresas, instituições ou, por que não, de nossas vidas.
Mas, por que estudar gerenciamento de projetos?
Difícil encontrar projetos que tiveram total êxito, não é mesmo? Eles até
existem, mas são difíceis de serem encontrados. Isso porque são muitas as va-
riáveis que fazem com que um projeto tenha tanta complexidade.
Para confirmar essa dificuldade em encontrar projetos que terminaram
com sucesso, vamos analisar um exemplo simples, da área de tecnologia da in-
formação, de um relatório “Chaos Report”, realizado pelo Standish Group, em
1995, sobre projetos da área de TI e seus resultados.

PROJETOS DE TI
Terminam no prazo e no orçamento previstos 16,2%
Apresentam reinícios 94%
Aumento médio no custo 189%
Aumento médio do cronograma 239%

Tabela 1.1  –  Projetos de TI segundo o Standish Group. Fonte: www.pmi.org.br/benchmark.

Perceba, na tabela 1.1, que apenas 16,2% dos projetos terminam dentro
do orçamento e prazo predeterminados. Na mesma tabela, ainda podemos

14 • capítulo 1
verificar que, na média, os projetos de TI apresentam um acréscimo de 189%
nos custos e de 239% no prazo.
O mesmo relatório do Standish Group ainda diz que o custo de oportunida-
de perdido é algo imensurável, podendo atingir trilhões de dólares.
Vocês podem estar pensando: “mas lógico, construir software deve ser algo
complexo, de forma que em outras áreas isso não deve acontecer”. Se vocês es-
tão pensando assim, já aviso que este pensamento não traduz a realidade.
Veja a tabela 1.2, que mostra os números de um estudo de Benchmark reali-
zado em 2009 pelo PMI (Project Management Institute, que é uma organização
que iremos estudar mais à frente) no Brasil, com empresas das mais variadas
áreas de atuação.
Por meio dos números, é possível perceber que os projetos nas empresas pes-
quisadas, assim como os projetos de TI vistos acima, em sua maioria, apresen-
tam problemas de prazo e custo. E também é possível perceber que grande parte
dos projetos apresentam problemas de qualidade e de satisfação do cliente.

PROJETOS EM DIVERSAS ÁREAS – 2009

Projetos que não terminam dentro do custo estabelecido 62%
Projetos que não terminam dentro do prazo estabelecido 79%
Projetos com problemas de qualidade 41%
Projetos com problemas com a satisfação do cliente 34%

Tabela 1.2  –  Benchmarck realizado pelo PMI em 2009 (PMI, 2009).

Conseguiram perceber, por meio dos números mostrados acima, como é

complexo um projeto, ou seja, como o histórico dos projetos está repleto de
insucessos e com projetos estourando custos, prazos e sendo finalizado com a
geração de um produto/serviço que está muito aquém da qualidade esperada?
Neste momento, é bem possível que vocês estejam se perguntando: O que é
que faz com que os projetos falhem?
A mesma pesquisa de Benchmarck feita em 2009 pelo PMI também pesqui-
sou quais foram os problemas que ocorreram com mais frequência nos pro-
jetos das organizações pesquisadas. A tabela 1.3 a seguir, mostra os 10 princi-
pais problemas.

capítulo 1 • 15
 OS 10 PRINCIPAIS PROBLEMAS ENCONTRADOS NOS PROJETOS
1. Problemas de comunicação 76%
2. Não cumprimento dos prazos 71%
3. Mudanças de escopo constantes 70%
4. Escopo não definido adequadamente 61%
5. Concorrência entre o dia a dia e o projeto na utilização de recursos 52%
6. Estimativas incorretas e sem fundamentos 52%
7. Riscos não avaliados corretamente 50%
8. Não cumprimento do orçamento 50%
9. Problemas com fornecedores 37%
10. Retrabalho em função da falta de qualidade do produto 28%

Tabela 1.3  –  Benchmarck PMI 2009 – problemas que ocorrem com mais frequência nos
projetos da organização. Fonte: www.pmi.org.br/benchmark.

Perceba, no resultado da pesquisa, que os problemas encontrados perten-

cem às mais diversas áreas do projeto, ou seja, são problemas de prazos e cus-
tos mal estipulados, riscos mal avaliados, problema na qualidade do produto
final e no escopo do projeto.
Bom, até agora mostramos toda a complexidade envolvida no desenvolvi-
mento de projetos por meio de pesquisas feitas em empresas brasileiras e em-
presas do setor de TI no mundo todo. Vimos também os maiores problemas
encontrados nos projetos desenvolvidos nas empresas brasileiras e vimos que
esses problemas estão localizados nas mais diversas áreas.
Então, nos resta mais uma pergunta: Há alguma técnica científica e siste-
matizada que garanta que os esforços empreendidos em um projeto levem à
entrega de um produto/serviço de qualidade e que atenda, ou exceda, às expec-
tativas do solicitante?
Na verdade não existe uma “receita de bolo” única e mágica de como se ad-
ministrar esses esforços de forma a se ter 100% de sucesso na implementação
de um projeto.
Então quer dizer que não há ciência por trás da gerência desse esforço de
implantação ou desenvolvimento do software, ou a construção de um estádio
de futebol ou mesmo de um foguete espacial?
Bom, não é bem assim. O que temos na área são coleções/compilações que
apresentam práticas, conhecimentos e técnicas historicamente bem-sucedidas
quando aplicadas à gerência desses esforços e que, na maioria das vezes, quando
bem aplicadas, levam esse conjunto de esforços a entrega bem-sucedida de um
produto/serviço.

16 • capítulo 1
 A aplicação deste conjunto de técnicas é o que podemos chamar de geren-
ciamento de projetos e é por isso que é considerada um tema importante na
atualidade: para aprender algumas dessas técnicas em busca do melhor geren-
ciamento de projetos. Você com certeza precisará desse aprendizado um dia!
Portanto, estudando o gerenciamento de projetos você irá aprender técnicas,
procedimentos e habilidades que lhe permitirão gerenciar toda essa complexi-
dade de forma sistemática e repetível a ponto de aumentar as chances de imple-
mentar um projeto com sucesso e repetir este sucesso em outros projetos futuros.
Para fecharmos este tópico, gostaríamos que você fixasse que um projeto é
algo complexo e que no mundo há vários exemplos de projetos que não tiveram
um final feliz.
Contudo, há também projetos que foram finalizados com sucesso, entre-
gando produtos/serviços com qualidade, no tempo e no prazo corretos.

1.2  Definindo Projeto

Projetos, dentro de uma empresa, são utilizados como instrumentos para efe-
tuar mudanças ou produzir produtos e/ou serviços.
Normalmente, em organizações modernas, projetos surgem como resulta-
do do planejamento estratégico.
Resumindo: a organização declara a sua missão (objetivos atuais) e a sua vi-
são (objetivos a médio e longo prazos), então uma análise do ambiente externo
e interno é feita identificando ameaças e oportunidades, pontos fortes e fracos;
em seguida, levando em consideração a missão, visão e análise externa e inter-
na realizada, a organização formula metas e objetivos estratégicos que serão
implementados por meio de vários projetos na organização.
Alinhado à ideia do planejamento estratégico, o PMBOK (2008) diz que um
projeto pode surgir por meio de (mas não se limita a):
•  Desenvolvimento de um novo produto ou serviço;
•  Mudanças organizacionais: estruturais, RH ou estilo;
•  Aquisição ou implementação de sistemas de informações novos ou então
a modificação de sistemas de informações existentes;
•  Construção de imobilizados;
•  Implementação de procedimentos e processos de negócios.

capítulo 1 • 17
 CONCEITO
Um projeto é normalmente definido como um empreendimento colaborativo, frequentemen-
te envolvendo pesquisa ou desenho, que é cuidadosamente planejado para alcançar um
objetivo particular. Projetos podem ainda ser definidos como sistemas sociais tempo E uma
demanda de mercado, necessidade organizacional, solicitação de um cliente, avanço tecno-
lógico ou requisito legal.
A palavra projeto vem da palavra latina projectum do verbo em latim proicere, "antes de
uma ação", que por sua vez vem de pró-, que denota precedência, algo que vem antes de
qualquer outra coisa no tempo (em paralelo com o grego pró) e iacere, "fazer". Portanto, a
palavra "projeto", na verdade, significava originalmente "antes de uma ação".
Quando o idioma Português inicialmente adotou a palavra, ela se referia a um plano de
alguma coisa, não o ato de realmente levar esse plano a concretização. Algo realizado de
acordo com um projeto tornou-se conhecido como um "objetivo".
As principais características dos projetos são:
•  temporários, possuem um início e um fim definidos.
•  planejados, executado e controlado.
•  entregam produtos, serviços ou resultados exclusivos.
•  desenvolvidos em etapas e continuam por incremento com uma elaboração progressiva.
•  realizados por pessoas.
•  com recursos limitados.
Fonte: www.pmi.org.br

Mas, afinal de contas, o que é um projeto?

Um projeto é um esforço temporário empreendido para criar um produto,
serviço ou resultado exclusivo!
Um projeto é um empreendimento único, com início e fim determinados,
que utiliza recursos e é conduzido por pessoas, visando a atingir objetivos
predefinidos, caracterizando-se por ser temporário, exclusivo e progressivo.
(CAVALIERI, 2005).
De acordo com as definições acima, um projeto é algo que tem início e fim,
produz um produto ou serviço exclusivo e pode ser feito progressivamente.
Vamos entender cada um desses pontos:

18 • capítulo 1
 •  Temporário1 : quer dizer que o projeto tem um tempo no qual ele exis-
te, iniciando-se em um determinado momento e tendo um fim determinado.
Temporário não quer dizer de curta duração (há projetos que duram décadas),
e sim que se trata de um esforço finito.
Temporário também não se aplica ao produto/serviço gerado pelo projeto em
questão, e sim aos esforços necessários para a geração desses produtos e servi-
ços. Temporário também pode ser relativo à janela de tempo na qual é possível a
implementação do projeto. Por último, temporário também se aplica à equipe do
projeto. Quando o projeto termina, a equipe é liberada daquele projeto.
•  Produtos, serviços e resultados exclusivos2 : um produto/serviço gerado
por um projeto é diferente de um produto gerado por uma linha de montagem
em série. Os projetos geram produtos/serviços exclusivos e, por isso, diferentes
de outros produtos e serviços já gerados anteriormente.
Em uma organização, é importante diferenciar projetos do trabalho opera-
cional do dia a dia. Enquanto o primeiro trata de esforços correlacionados e
temporários para produzir algo único e exclusivo, o segundo trata da realização
de processos contínuos e repetitivos.

ATENÇÃO
Diferenciando: Projetos, Subprojetos, Programas e Portfólio
•  Subprojetos: Diversas vezes um projeto precisa ser subdividido em partes, de fácil geren-
ciamento e controle, essas diversas partes são as denominadas subprojetos. Os mesmos são
braços de um mesmo projeto e nunca deve ser tratado isolado desse.
•  Programa: Esse é um termo usado para identificar um grupo de projetos relacionados que
são gerenciados e coordenados de modo integrado, obtendo os benefícios e controles que
não existem ao gerenciá-los individualmente.
•  Portfólio: É um conjunto de projetos, programas e outros esforços que são agrupados para
facilitar o atingimento dos objetivos estratégicos do negócio.

1  Um belo exemplo da importância do fator “tempo” em um projeto: imaginem um projeto para desenvolver uma
luneta específica para a visualização do cometa Halley: esse projeto só tem sentido se acontecer antes da passagem
desse cometa pelo planeta Terra. Posterior a isso, perde-se a janela de oportunidade do projeto.
2  Tomem como exemplo dois prédios idênticos em seu design arquitetônico. Eles são produtos exclusivos ou não?
A resposta é sim, eles são exclusivos, pois apesar de serem iguais em seu design, eles podem ter sido construídos
em lugares diferentes, exigindo cálculos estruturais diferentes, o que poderia resultar em entregas diferentes,
principalmente ligadas à estrutura e à fundação. Ou, então, em épocas diferentes, contando, assim, com fornecedores
diferentes e com um ambiente macro e microeconômico diferente, também culminado em entregas diferentes. Ou
seja, com resultados exclusivos.

capítulo 1 • 19
 Todos esses objetos (Projetos, Programas e Outros esforços) são mensuráveis,
ordenáveis e priorizáveis.

Como dito anteriormente, os projetos dentro de uma organização têm por

objetivo (e não somente isso) atender ao planejamento estratégico da empresa,
sendo temporário e tratado por uma abordagem de gerenciamento de projetos.
Já um processo, ou então trabalho operacional do dia a dia, também muito
importante para uma organização, são esforços repetitivos e “permanentes”
necessários para manter o dia a dia operacional da organização. Esses proces-
sos devem ser tratados por uma metodologia de gerenciamento de processos
como um PDCA3 (SOUSA, 2006).
Muito embora não haja uma “receita de bolo” que leve o projeto ao triunfo,
o que temos são grandes compilações de boas práticas de gerenciamento de
projeto que, quando aplicadas, aumentarão a chance de sucesso dos projetos.

CONCEITO
O Gerenciamento de Projetos é um conjunto de ferramentas gerenciais que permitem
que a empresa desenvolva um conjunto de habilidades, incluindo conhecimento e capaci-
dades individuais, destinados ao controle de eventos não repetitivos, únicos e complexos,
dentro de um cenário de tempo, custo e qualidade predeterminados.

Há várias compilações existentes, mas há uma que vem se tornando quase

que um padrão no mundo. Esta compilação é o PMBOK, desenvolvido pelo PMI.
Os benefícios do gerenciamento de projetos são:
•  O gerenciamento de projetos proporciona inúmeras vantagens sobre as
demais formas de gerenciamento, tendo se mostrado eficaz em conseguir os
resultados desejados dentro do prazo e orçamento.
•  A principal vantagem do Gerenciamento de Projetos é que ele não é restri-
to a projetos gigantescos, ele pode ser aplicado em empreendimentos de qual-
quer complexidade, orçamento e tamanho.
3  PDCA: ciclo PDCA, ou Shewhart, ou Deming – É um ciclo de desenvolvimento que tem como foco a melhoria
contínua de processos. Foi introduzido primeiramente no Japão, após a Segunda Guerra Mundial, e tem as seguintes
fases: planejamento (plan), execução (do), controle (control) e ação (act). (WIKEPEDIA, 2010).

20 • capítulo 1
 Dentre os principais benefícios, podemos destacar:
•  Evita surpresas durante a execução dos trabalhos;
•  Permite desenvolver diferenciais competitivos e novas técnicas
•  Antecipa as situações desfavoráveis e permite ações preventivas
e corretivas.
•  Adapta os trabalhos ao mercado consumidor e ao cliente;
•  Disponibiliza os orçamentos antes do início dos gastos;
•  Agiliza a tomada de decisão já que as informações estão estruturadas
e disponibilizadas.
•  Aumenta o controle gerencial de todas as fases a serem implementadas.
•  Facilita e orienta as revisões de estrutura do projeto que forem decorrentes
de alterações do mercado, melhorando a capacidade de adaptação do projeto.
•  Otimiza a alocação de recursos.
•  Documenta e facilita as estimativas para futuros projetos.

1.2.1  O que é um projeto bem-sucedido?

Apesar de a resposta à questão parecer quase que intuitiva, pode ser que for-
malmente ela não seja tão simples.
Para provar o acima dito, desafiamos você a enumerar 3 grandes proje-
tos brasileiros que obtiveram sucesso e 3 grandes projetos brasileiros que fo-
ram fracassados.
Agora, você deve estar pensando em projetos que foram concluídos e dan-
do a eles o conceito de projetos bem-sucedidos, como, por exemplo, os Jogos
Panamericanos do Rio de Janeiro ou, então, o desfile de carnaval de São Paulo
de 2010.
Ou, então, você deve estar pensando em alguns projetos que não termina-
ram com a entrega do produto/serviço esperado e dando a eles o conceito de
projetos malsucedidos.
Mas será que é só isso mesmo? Ou seja, se o projeto entregou o produto
esperado, então ele e bem-sucedido e, se o projeto não entregou o produto/ser-
viço esperado, ele é malsucedido?

capítulo 1 • 21
 Segundo Vargas (2005) não é assim que se mede o sucesso de um projeto.
Na verdade, ainda segundo Vargas (2005), as pessoas tendem a fazer algumas
perguntas para verificar se o projeto foi bem-sucedido, como, por exemplo:
•  O projeto ficou abaixo do orçamento previsto?
•  O projeto terminou mais rápido do que o previsto?
•  O projeto consumiu menos materiais ou pessoas do que o previsto?
•  O cliente foi surpreendido pela qualidade do resultado do projeto?

Apesar de o senso comum pensar que respostas positivas às perguntas aci-

ma, quando feitas a um determinado projeto, levam a crer que este projeto ob-
teve sucesso, não é bem assim que as boas práticas de gerenciamento de pro-
jetos dizem.
Na verdade, um projeto termina com sucesso quanto ele é realizado dentro
do previamente planejado, Ou seja, no popular: “não pode nem faltar e nem
sobrar” daquilo que foi planejado.
Ou seja, o que queremos que você entenda é que um projeto bem- -sucedido
precisa ser bem planejado e executado dentro desse plano. E ter um projeto que
foi executado de forma a não utilizar todo o recurso planejado ou ter um produ-
to/serviço final muito superior ao planejado quer dizer um projeto sem sucesso.
Parece difícil de acreditar neste conceito, mas Vargas (2005) nos traz um
exemplo bastante interessante: imagine um projeto que tenha por objetivo o
lançamento de uma campanha publicitária que renda a venda de 10.000 produ-
tos em uma semana. Após a execução do projeto, conseguiu-se a demanda por
100.000 produtos na semana.
O projeto acima descrito foi um projeto bem-sucedido? Vamos analisar um
pouco mais a fundo a situação: imaginem que a empresa tenha uma capacida-
de de produzir 15.000 produtos semanais. A demanda, agora por 100.000, passa
a ser um grande problema para a empresa, não é verdade? Por isso, podemos
dizer que este projeto não foi bem-sucedido.
Para deixar mais claro ainda este conceito, vamos a outro exemplo. Imagine
uma empresa de tecnologia da informação que tem um projeto para o qual fo-
ram previstos US$1.000.000 para a sua execução. Ao finalizar o projeto, o geren-
te de projetos diz que sobraram US$700.000. Isso é bom?

22 • capítulo 1
 Na verdade, sobrar dinheiro é bom, mas não quer dizer que o projeto foi
bem-sucedido. A sobra de dinheiro no projeto nos leva a crer que este projeto
foi mal planejado.
Perceba como a situação deste projeto piora se você imaginar que no mo-
mento da aprovação deste projeto a diretoria da empresa tenha deixado de exe-
cutar um outro projeto importante por falta de recursos, e pelo motivo deste
segundo projeto não ter sido executado a empresa tenha perdido 50% de sua
participação no mercado.
Viu só como o projeto em questão não pode ser considerado bem-sucedido?
Por causa dele a empresa poderia ter falido e fechado suas portas.
Para ajudar você a identificar se um projeto foi bem sucedido, Vargas (2005)
sugere as seguintes questões:
•  O projeto deve ter sido concluído dentro do prazo previsto;
•  O projeto deve ter sido concluído dentro do orçamento previsto;
•  O projeto deve ter utilizado os recursos, materiais e humanos, com efi-
ciência e sem desperdícios;
•  O projeto deve ter sido concluído atingindo a qualidade e o desempe-
nho desejados;
•  O projeto deve ter sido concluído com o menor número possível de alte-
ração em seu escopo;
•  O projeto deve ter sido aceito sem restrições pelo contratante ou cliente;
•  O projeto deve ter sido executado sem interrupções ou prejuízos às ativi-
dades normais da instituição;
•  O projeto não pode ter agredido a cultura da organização.

COMENTÁRIO
Causas que levam o projeto ao fracasso
Em um de seus podcasts, Ricardo Vargas diz que para levar um projeto ao fracasso basta
não gerenciá-lo. Ou seja, de uma maneira bastante irônica, o normal de todo o projeto seria
o fracasso. Porém, para o projeto não fracassar, há o gerente de projetos tomando todas as
ações necessárias.
Mas às vezes, mesmo com todas as ações feitas, os projetos podem falhar ou, então, não
atingir o resultado esperado.
Vargas (2005) diz que projetos podem falhar por motivos que fogem do controle da or-
ganização (riscos do projeto) como, por exemplo:

capítulo 1 • 23
•  Mudança na estrutura organizacional da empresa;
•  Riscos elevados no meio ambiente;
•  Mudanças tecnológicas;
•  Evolução dos preços e prazos;
•  Cenários político-econômicos desfavoráveis.

Mesmo esses fatores poderiam ser evitados por meio de uma gerência de riscos eficien-
te e eficaz. Contudo, estes não são os principais pontos de atenção, uma vez que não são
esses os motivos mais frequentes que levam um projeto ao fracasso.
Na verdade, os motivos mais frequentes que levam os projetos ao fracasso estão ligados
a falhas gerenciais. Vargas (2005) enumera alguma delas, a saber:
•  As metas e os objetivos do projeto mal estabelecidos ou mal compreendidos.
•  Subestimação da complexidade do projeto.
•  Previsão de prazos e custos não realistas.
•  Planejamento baseado em informações históricas não confiáveis.
•  Projeto sem líder/gerente responsável ou com vários líderes/gerentes responsáveis, ge-
rando falta de liderança no projeto.
•  Pouco tempo destinado ao planejamento do projeto.
•  Expectativas do cliente referente à entrega do projeto foram mal-entendidas.
•  Planejamento de recursos humanos e materiais mal-feito.
•  Falta de experiência/conhecimento das pessoas envolvidas na execução do projeto.

Acima, enumeramos algumas das falhas gerenciais citadas por Vargas (2005) que levam
os projetos ao insucesso. Mas é bom lembrar que não são apenas estas acima citadas as
falhas gerenciais que levam os projetos ao insucesso.
Por isso, é sempre bom lembrar que o gerente de projetos deve definir e seguir uma
metodologia de gerenciamento de projetos que busque minimizar as chances desse tipo de
falha ocorrer.

Por isso, nesta disciplina, iremos aprender as melhores práticas de ges-

tão de projetos apresentadas no PMBOK e como aplicá-las. Para tanto, iremos
aprender um pouco mais sobre o PMBOK e o PMI e vamos começar a introduzir
conceitos importantes para entender o que é um projeto, o que é a gerência de
projeto e o que é o gerente de projetos.

24 • capítulo 1
1.3  O PMI e sua certificação
PMI – Project Management Institute (Instituto de Gerenciamento de Proje-
tos) – Fazendo o gerenciamento de projetos indispensável para os resultados
dos negócios.
O PMI é uma organização sem fins lucrativos, dedicada ao avanço do estado
da arte em gerenciamento de projetos, mantendo como compromisso promo-
ver o profissionalismo e a ética em gerenciamento de projetos.
Foi inicialmente criado na Pensilvânia (EUA), em 1969, por 5 voluntários e
hoje conta com uma comunidade de 265.000 associados e 140.000 certificados,
sendo considerada a maior e mais acreditada instituição de educação e desen-
volvimento de padrões em gerência de projetos.
Tente lembrar o que acontecia em 1969 no mundo e contextualize historica-
mente a criação do PMI e a sua importância para a época.
Para atingir esse número de pessoas, o PMI se internacionalizou e hoje está
presente em vários países por meio de seus capítulos (ou, em inglês: chapters),
que são filiais espalhadas geograficamente, e contribuem nas missões e obje-
tivos do PMI, promovendo o profissionalismo em gerência de projetos, sendo
que hoje o PMI está presente em mais de 170 países.

CURIOSIDADE
O PMI - Project Management Institute, juntamente com a Economist Intelligence Unit, realizou
uma pesquisa sobre o universo dos projetos e constatou que cerca de 12 trilhões de dólares
são hoje empregados em projetos. Isso significa aproximadamente 25% de toda a economia
mundial, empregando mais de 20 milhões de profissionais em atividades relacionadas à lide-
rança e ao gerenciamento de projetos. Isso confirma o que Tom Peters apresentou em seu
artigo “Você é o seu Projeto” em 1999. Ele afirmou que, nos próximos 20 anos, todo o traba-
lho será desenvolvido por meio de projetos. Pouco mais de 10 anos depois essa realidade é
evidentemente comprovada. David Cleland também afirma que, no futuro, o gerenciamento
de projetos será utilizado para gerenciar as mudanças em todas as infraestruturas sociais em
todos os países, desenvolvidos ou não (VARGAS, 2009), conforme figura a seguir.

capítulo 1 • 25
 302.364
350.000
325.000
300.000
275.000

208.660
250.000
225.000
200.000
175.000
150.000
125.000

70.035
100.000
75.000

17.069
50.000
5.272
1.000

25.000
1970

1975

1980

1985

1990

1995

2000

2005

2009
Figura 1.1  –  Evolução Mundial dos membros do PMI no mundo. Fonte: Vargas (2009)

O PMI® também oferta aos seus associados, e à população em geral, vários

produtos e serviços, entre eles:
•  Padrões profissionais:
O PMI® desenvolve padrões para a prática profissional de gerência de proje-
tos, sendo que um dos principais documentos produzidos é o PMBOK® Guide
ou “A Guide to the Project Manager Base of Knowledge” (Um guia para a base
de conhecimentos de gerência de projetos). Hoje, o PMBOK® se encontra em
sua quarta edição e é aprovado como um padrão nacional (ANS) pelo Instituto
de Padrões Nacional Americano (ANSI);
•  Certificação:
O PMI® também oferece programas de certificação profissional para pro-
mover o crescimento da profissão de gerenciamento de projetos, sendo que o
mais conhecido deles é a PMP ou “Project Manager Professional”.
Das principais iniciativas do PMI na difusão do conhecimento em geren-
ciamento de projetos, sendo as certificações a mais procurada e difundida
mundo afora, é a publicação de padrões globais de gerenciamento de pro-
jetos, programas e portfólio, sendo a mais popular delas o Guia do Conjunto
de Conhecimentos em Gerenciamento de Projetos (Guia PMBOK® - Project
Management Body of Knowledge). O PMBOK Guide.

26 • capítulo 1
 •  PMBOK
O PMBOK® Guide foi o primeiro padrão de práticas profissionais desenvol-
vido pelo PMI e abrange todo o conhecimento da profissão de gerenciamento
de projetos. Ele foi desenvolvido com a ajuda de praticantes e acadêmicos que
utilizam de fato essas práticas ou que as desenvolve. Ou seja, o que é apresenta-
do pelo PMBOK® Guide é amplamente testado pelos praticantes de gerência de
projetos e aprovado por eles, sendo consideradas boas práticas para a gerência
de projetos em muitos projetos na maior parte do tempo, sendo que existe um
consenso por parte dos praticantes sobre seus valores e aplicabilidade.

COMENTÁRIO
Seu histórico: Em 1983, na tentativa de documentar e padronizar as práticas que são normal-
mente aceitas na gerência de projetos, foi publicado o artigo "Ethics, Standards, and Accre-
ditation Committee Final Report". A primeira edição do "A Guide to the Project Management
Body of Knowledge (PMBOK Guide)" foi publicada pelo Project Management Institute (PMI)
foi publicada em 1996, seguida pela segunda edição em 2000.
Em 2004, o Guia PMBOK — Terceira Edição — foi publicado com maiores mudanças,
considerando as edições anteriores. A quarta edição (lançada em 2008) é normatizada pelas
normas ANSI/PMI 99-001-2008 e IEEE 1490-2011. A última versão do Guia PMBOK é a
quinta edição que foi publicada em 2013 em Inglês. Traduções estão disponíveis em Árabe,
Chinês, Francês, Alemão, Italiano, Japonês, Coreano, Português, Russo e Espanhol. (VAR-
GAS, 2009)

O PMBOK® Guide, além de trazer esse conjunto de boas práticas, também

busca estabelecer uma linguagem comum para o profissional de gerenciamen-
to de projeto. (PMBOK, 2008). O PMI® diz que o PMBOK® Guide não deve ser
considerado como um documento que contempla a totalidade de conhecimen-
to de gerenciamento de projetos, uma vez que essa profissão é muito dinâmica
e sofre atualizações a todo o momento.
O guia é baseado em processos e sub-processos para descrever de for-
ma organizada o trabalho a ser realizado durante o projeto. Essa abordagem
se assemelha à empregada por outras normas como a ISO 9000 e o Software
Engineering Institute's, CMMI.

capítulo 1 • 27
 Os processos descritos se relacionam e interagem durante a condução do
trabalho. A descrição de cada um deles é feita em termos de:
•  Entradas (documentos, planos, desenhos etc.);
•  Ferramentas e técnicas (que se aplicam às entradas);
•  Saídas (documentos, produtos etc.)

1.4 Ciclo de Vida e da Organização de um

Projeto
Todo projeto pode ser subdividido em determinadas fases4 de desenvolvimen-
to. O entendimento dessas fases permite ao time do projeto um melhor contro-
le do total de recursos gastos para atingir as metas estabelecidas. Esse conjunto
de fases é conhecido como ciclo de vida. O ciclo de vida possibilita que seja ava-
liada uma série de similaridades que podem ser encontradas em todos os pro-
jetos, independentemente de seu contexto, aplicabilidade ou área de atuação.
O ciclo de vida pode ser dividido em um conjunto de fases, normalmente
fixas para todos os tipos de projeto, contendo uma séria de passos principais do
processo de contextualizar, desenhar, desenvolver e colocar em operação uma
determinada necessidade do projeto. Essas fases, por sua vez, são subdivididas
em estágios, ou etapas específicas, de cada natureza de projeto (construção, de-
senvolvimento de produtos, etc.). Esses estágios são, então, subdivididos em
atividades, ou tarefas específicas de cada projeto.

Genérico para
FASES todos os projetos

MACROVISÃO

ESTÁGIOS Específicos da
natureza do projeto

MICROVISÃO

ATIVIDADES Específicos de
cada projeto

Figura 1.2 – Visão do ciclo de vida do projeto. Fonte: Vargas (2009).

4 Em muitos casos existem diferentes interpretações do conceito de fase e de grupo de processos. Neste
contexto, segundo Vargas (2009), o conceito de “fase” será utilizado para significar tanto os grupos de processo
do PMBOK Guide quanto os conceitos e fases específicas de um projeto (por exemplo: design, construção, testes).
Portanto, o termo “grupo de Processos de Iniciação” e “Fase de Iniciação” são considerados sinônimos neste material.

28 • capítulo 1
 Conhecer as fases do ciclo de vida proporciona uma séria de benefícios para
quaisquer tipos de projetos. Dentre eles, podem ser destacados os seguintes:
•  correta análise do ciclo de vida determina o que foi, ou não, feito
pelo projeto;
•  o ciclo de vida avalia como o projeto está progredindo até o momento;
•  o ciclo de vida permite que seja indicado que o ponto exato em que o pro-
jeto se encontra no momento.

Ao longo do ciclo de vida, diversas considerações podem ser feitas,

principalmente:
•  as características do projeto tendem a mudar com a conclusão de cada
fase do projeto;
•  incerteza relativa aos prazos e custos tende a diminuir com o término de
cada fase.

A descrição do ciclo de vida do projeto pode ser genérica, representada por

um único gráfico, ou detalhada incluindo vários gráficos, fluxogramas e tabe-
las, específicos de cada atividade.
Com relação à velocidade de desenvolvimento, o ciclo de vida dos projetos
pode ser caracterizado, na maioria das vezes, por um início lento seguido de um
progresso acelerado até atingir um pico e logo em seguida, um desaceleramen-
to até atingir seu término.

100
Final lento
% COMPLETO

Momento de velocidade

Início lento
0
TEMPO

Figura 1.3  –  Ciclo de vida do projeto segundo critérios de velocidade de desenvolvimento.

Fonte: Vargas (2009).

capítulo 1 • 29
 Outra consideração a ser analisada no ciclo de vida do projeto é o nível de
esforço. O nível de esforço destinado ao projeto inicia-se em praticamente zero
e vai crescendo até atingir um máximo e, logo após esse ponto, reduz-se brusca-
mente até atingir o valor zero, representante do término do projeto.
Entende-se, segundo Vargas (2009), por esforço, a quantidade de pessoas
envolvidas no projeto, o dispêndio de trabalho e dinheiro com o projeto, as
preocupações, as complicações, as horas-extras, etc. A localização do valor má-
ximo do gráfico pode variar de projeto para projeto. A suavidade desse ponto de
esforço máximo está diretamente relacionada à qualidade com que o planeja-
mento foi realizado. Quanto melhor é o plano, mais suave é a transposição do
ponto de esforço máximo.

Máximo
ESFORÇO

Início TEMPO Término

Figura 1.4  –  Variação do esforço com o tempo para o projeto. Fonte: Vargas (2009).

1.4.1  Características do ciclo de vida do projeto

A maioria dos ciclos de vida dos projetos compartilham algumas características

comuns, representadas a seguir (VARGAS, 2009).

1.4.1.1  Potencial de Adicionar Valor ao Projeto

O potencial de adicionar valor a um projeto, segundo Vargas (2009), é, obvia-
mente, alto no início do projeto, quando a maioria das definições ainda está no
papel, caindo até o término do projeto, quando o potencial de adicionar valor
ao projeto tende a ser mínimo.

30 • capítulo 1
 Potencial de adicionar valor

Baixo
Início Tempo Término

Figura 1.5  –  Potencial de adicionar valor ao projeto em função do desenrolar do projeto.

Fonte: Vargas (2009).

1.4.1.2  Custo das Mudanças ou Correções

O custo de promover mudanças no projeto é pequeno nas fases iniciais, cres-

cendo exponencialmente com o progresso do projeto até chegar ao seu custo
total, podendo até mesmo superá-lo.
Custo das mudanças / correções

Início Tempo Término

Figura 1.6  –  Custo das mudanças / correções em função do desenrolar do projeto. Fonte:
Vargas (2009).

1.4.1.3  Capacidade de Adequação

A capacidade de adequação do projeto quanto a novas necessidades, ou seja,

a capacidade de se alterarem as características finais do projeto é grande no

capítulo 1 • 31
início, caindo gradativamente com o passar do tempo. Quanto mais o projeto
se desenvolve, menor é a capacidade de adequação.
Alta

Capacidade de adequação

Baixa
Início Tempo Término

Figura 1.7  –  Capacidade de adequação do projeto a novas necessidades no seu desenrolar.

Fonte: Vargas (2009).

1.4.1.4  Incerteza do Risco x Quantidade Arriscada

No início do projeto a incerteza do Risco do projeto em questão é bastante ele-

vada, pois não se tem total visão do que poderá acontecer com o mesmo, entre-
tanto a quantidade arriscada é muito pouco pois o projeto ainda está no início.
Ao se comparar a incerteza do risco com a quantidade arriscada, tem-se que, no
início do projeto, o nível de incerteza é elevado, porém a quantidade arriscada
é pequena, uma vez que se está em uma fase inicial do projeto (VARGAS, 2009).
Com seu desenrolar, a incerteza a respeito do risco diminui enquanto a quanti-
dade arriscada aumenta, já que o projeto se encontra em fase avançada de exe-
cução. O período mais crítico é o período de transição, quando se tem o mais
alto impacto do risco (maior produto probabilidade x quantidade arriscada),
considerando que o impacto do risco pode ser dado como o produto da incerte-
za do risco pela quantidade arriscada. Essa região coincide exatamente com o
ponto máximo de esforço na relação esforço x tempo, descrita anteriormente,
indicando que o pico de esforço está exatamente, na região de maior impacto
dos riscos (VARGAS, 2009).

32 • capítulo 1
 Incerte
za do
risco

impacto do risco
Região de maior
Intensidade

iscada
ade arr
Quantid
Início Tempo Término

Figura 1.8 – Análise comparativa da incerteza dos riscos com a quantidade arriscada. Fon-
te: Vargas (2009).

1.5 As Fases do Ciclo de Vida do Projeto

As fases do ciclo de vida do projeto dependem, intimamente, da natureza do
projeto. Um projeto é desenvolvido a partir de uma ideia, progredindo para um
plano, que, por sua vez é executado e concluído. Cada fase do projeto, segundo
Vargas (2009), é caracterizada pela entrega, ou finalização, de um determina-
do trabalho. Toda entrega deve ser tangível e de fácil identificação, como, por
exemplo, um relatório confeccionado, um cronograma estabelecido, um con-
junto de atividades realizado.
O Guia PMBOK em sua 5° Edição provê diretrizes para gerência dos projetos
individualmente e define conceitos associados à gerência de projetos. Isto tam-
bém descreve o ciclo de vida do gerenciamento do projeto e seus processos rela-
cionados, assim como o ciclo de vida do projeto. O Guia PMBOK reconhece 47
processos que recaem em 5 grupos de processos e 10 áreas de conhecimento que
são típicas em quase todas áreas de projetos. Genericamente, o ciclo de vida de
um projeto pode ser dividido em fases características, conforme a figura a seguir.

capítulo 1 • 33
 Fase de encerramento
Fase de planejamento
Fase de iniciação

Fase de execução
Esforço

Fase de monitoramento
e controle
Tempo

Figura 1.9  –  Figura: O ciclo de vida do projeto subdividido em fases. Fonte: Vargas (2009).

Cada fase ou grupo do projeto normalmente define:

•  qual é o trabalho técnico que deve ser realizado;
•  quem deve estar envolvido.

O número de fases em um projeto é função de sua natureza, podendo variar

entre quatro e nove fases características. Porém para efeitos didáticos, serão
consideradas apenas cinco fazes características, as quais também são denomi-
nadas grupos de processos pelo PMBOK..
•  Fase de Iniciação: É a fase inicial do projeto, quando uma determinada
necessidade é identificada e transformada em um problema a ser resolvido. A
missão e o Objetivo do projeto são definidos , os documentos iniciais confec-
cionados e as melhores estratégias selecionadas.
•  Fase de Planejamento: É a fase responsável por detalhar tudo aquilo que
será realizado pelo projeto, incluindo cronograma, interdependência entre
atividades, alocação de recursos, analise de custos. Nessa fase, os planos de
escopo, custo, qualidade, recursos humanos, comunicação, risco e aquisição
são desenvolvidos.
•  Fase de Execução: É a fase que materializa tudo aquilo que foi planejado
anteriormente. Grande parte do orçamento do esforço do projeto é consumido
nessa fase.
•  Fase de Monitoramento e Controle: É a fase que acontece paralelamente
às demais fases do projeto. Tem como objetivo acompanhar e controlar aquilo
que está sendo realizado pelo projeto. O objetivo do controle é comparar o status
atual do projeto com o status previsto pelo planejamento.

34 • capítulo 1
 •  Fase de Encerramento: É a fase quando a execução dos trabalhos é ava-
liada através de uma auditoria interna ou externa, os documentos do projeto
são encerrados e todas as falhas ocorridas durante o projeto são discutidas e
analisadas para eu erros similares não ocorram em novos projetos. Esta fase
portanto, também é conhecida como fase de aprendizado.

Execução
Planejamento
Iniciação
Intensidade

Encerramento
Controle

Tempo

CONCEITO DESENVOLVIMENTO IMPLEMENTAÇÃO TREINAMENTO

FAZES DO CICLO DE VIDA DO PROJETO

Figura 1.10  –  Fases do ciclo de vida do projeto. Fonte: Vargas (2009).

Uma análise direta do gráfico mencionado anteriormente não é conclusi-

va quanto à interdependência e sobreposição de fases no projeto. Na verdade,
com o desenrolar do projeto, praticamente todas as fases e grupos de proces-
so são realizadas quase que simultaneamente, constituindo um ciclo, como é
mostrado na figura a seguir:

Planejamento
Controle

Iniciação Encerramento

Execução

Figura 1.11  –  Inter-relacionameto entre as fases/grupos de processo em um projeto. Fonte:

Vargas (2009).

capítulo 1 • 35
 Sob outro aspecto, pode-se considerar que a realização de uma fase do projeto
é também um projeto e, portanto, possui um determinado ciclo de vida e pode ser
subdividida em fases. Isso significa que existe uma iniciação da fase de iniciação, um
planejamento da fase de iniciação, uma execução e um controle da fase de iniciação e
uma finalização da fase de iniciação, partindo, então, para a fase de iniciação do pla-
nejamento, etc. Em outras palavras, vários subprojetos em um único projeto maior.
O PMBOK também evidencia esse inter-relacionamento entre as fases de
uma maneira bastante clara e intuitiva, representando, em um mesmo gráfico,
os ciclos de vida de todas as fases do projeto.

Ciclo de vida do
projeto

Execução
planejamento
Esforço

Iniciação Encerramento
Controle

Tempo

Figura 1.12  –  Sobreposição das fases em um projeto. Fonte: Vargas (2009).

REFLEXÃO
Em todo projeto existe uma relação estreita entre os fatores de desempenho ou performance
(escopo e qualidade), custo e tempo. Isso quer dizer que é impossível predeterminar todos os
fatores simultaneamente. É preciso que, com base em dois fatores, se determine o terceiro
como uma função interna do projeto, ou seja, o máximo que se pode fazer é predeterminar
dois fatores e calcular o terceiro como uma função dos dois anteriores. Em geral, é neces-
sário que se conheçam, detalhadamente, dois fatores e o escopo do projeto para que se
determine o terceiro fator, fechando todo o cenário do projeto.

36 • capítulo 1
 LEITURA
O guia Project Management Body of Knowledge (PMBOK) é um conjunto de práticas na
gestão de projetos organizado pelo instituto PMI e é considerado a base do conhecimento
sobre gestão de projetos por profissionais da área.
Histórico: Em 1983, na tentativa de documentar e padronizar as práticas que são normal-
mente aceitas na gerência de projetos, foi publicado o artigo "Ethics, Standards, and Accre-
ditation Committee Final Report". A primeira edição do "A Guide to the Project Management
Body of Knowledge (PMBOK Guide)" foi publicada pelo Project Management Institute (PMI)
foi publicada em 1996, seguida pela segunda edição em 2000.
Em 2004, o Guia PMBOK — Terceira Edição — foi publicado com maiores mudanças,
considerando as edições anteriores. A quarta edição (lançada em 2008) é normatizada pelas
normas ANSI/PMI 99-001-2008 e IEEE 1490-2011.
A última versão do Guia PMBOK é a quinta edição que foi publicada em 2013 em Inglês.
Traduções estão disponíveis em Árabe, Chinês, Francês, Alemão, Italiano, Japonês, Coreano,
Português, Russo e Espanhol.Houve um avanço nos processos e tópicos do guia PMBOK
de sua 4ª. Edição para sua última edição, como podemos observar no quadro a seguir. Esta
atualização se fez necessária para abarcar temas e atividades que passaram a ser importan-
tes nos projetos atuais.

GUIA PMBOK 4° EDIÇÃO (2008) GUIA PMBOK 5° EDIÇÃO (2013)

Estágios 5 grupos de processos 5 grupos de processos
Tópicos 9 áreas de conhecimento 10 áreas de conhecimento
Processos 42 processos 47 processos

Tabela 1.4  – 

Extensões do PMBOK
O PMBOK atualmente define extensões ao Guia PMBOK. São elas:
Extensão para Construção - Construction Extension to the PMBOK Guide — 3a Edição
Extensão para Governo - Government Extension to the PMBOK Guide — 3a Edição
O PMBOK também define padrões específicos ao Guia PMBOK. São eles:
•  Padrão para Gerenciamento de Programa - The Standard for Program Management — 2a
Edição (em inglês)
•  Padrão para Gerenciamento de Portifólio - The Standard for Portfolio Management — 3a
Edição (em inglês)

capítulo 1 • 37
 Modelo de Maturidade para Gerenciamento de Projetos Organizacionais - Organizational
Project Management Maturity Model (OPM3®) — 2a * Edição (em inglês)
Fonte: wikipedia.org/ Project_Management_Body_of_Knowledge.

1.6  Principais Áreas de Conhecimento do

Projeto segundo PMBOK

As áreas do gerenciamento de projetos descrevem o gerenciamento de projetos

em termos de seus processos componentes. Esses processos podem ser organi-
zados em dez grupos integrados, segundo PMBOK, conforme descritos a seguir:

•  Gerenciamento/Gestão de integração do projeto

A Gerência da integração do projeto é o núcleo do gerenciamento de proje-
tos, e é composto dos processos do dia a dia com os quais o gerente de projetos
conta para garantir que todas as partes do projeto funcionem juntas. É um pro-
cesso contínuo que o gerente executa para garantir que o projeto prossiga do
início ao fim – é a atividade diária de completar o trabalho do projeto.
O gerenciamento do projeto junta os planos de projeto, coordena ativida-
des, recursos, restrições e suposições do projeto, e os transforma em um mo-
delo funcional.
Gerenciar a integração do projeto é garantir que os componentes do projeto
precisam trabalhar juntos – e é papel do gerente de projetos fazer que isso acon-
teça. Exige habilidades em negociação e gerenciamento de conflitos de inte-
resses. Também exige habilidades gerais de gerenciamento, boa comunicação,
organização, familiaridade técnica com o produto, etc.
Pode ser dividido em três partes: o desenvolvimento do plano do projeto, a
execução do plano do projeto e o controle de mudanças no projeto.

•  Gerenciamento/Gestão do escopo do projeto

Gerenciamento do Escopo é composto dos processos para garantir que o
projeto inclua todo o trabalho exigido, e somente o trabalho exigido, para com-
pletar o projeto com sucesso.

38 • capítulo 1
 As finalidades do Gerenciamento do Escopo, conhecido também como
Âmbito do Projeto, incluem a definição do trabalho necessário para concluir o
projeto, servir como guia (ou ponto de referência) para determinar que traba-
lho não está incluído (ou não é necessário) no projeto.
O escopo é o foco do projeto. O escopo do projeto difere-se do escopo do
produto na medida em que o escopo do projeto define o trabalho necessário
para fazer o produto, e o escopo do produto define os recursos (atributos e com-
portamentos) do produto que está sendo criado.
Os projetos não desviam frequentemente do foco de negócios da empresa, e
geralmente estão relacionados à sua atividade fim.
O projeto de um sistema de informação, por exemplo, sempre tem por fina-
lidade cobrir uma necessidade estratégica de negócio ou viabilizar a execução
automatizada de um processo operacional dentro da empresa.

•  Gerenciamento/Gestão de tempo do projeto

O objetivo da gerência do tempo de projeto é descrever os processos requeri-
dos para o término do projeto, garantindo que o mesmo cumpra com os prazos
definidos em um cronograma de atividades.
Os principais processos desta gestão são: as Definições, Seqüenciamento,
Estimativa de Recurso e Estimativa de Duração das Atividades e o
Desenvolvimento e Controle do Cronograma destas Atividades.
•  Definições das Atividades: identificação das atividades específicas do
cronograma que necessitam ser executadas para produzir os diversos tangíveis
do projeto;
•  Sequenciar Atividades: identificação e documentação das dependências
entre as atividades do cronograma;
•  Estimativa de Recursos de Atividade: estimativa do tipo e das quantidades
dos recursos requeridos para executar cada atividade do cronograma;
•  Estimativa de Duração de Atividade: estimativa do período que será ne-
cessário para conclusão individual de cada atividade do cronograma;
•  Desenvolvimento do Cronograma: análise das sequências das atividades,
suas dependências, durações e recursos requeridos para criar o cronograma;
•  Controle do Cronograma: controle das alterações efetuadas
no cronograma;

capítulo 1 • 39
 A gerência do tempo de projeto e a gerência do custo do projeto são as
áreas de maior exigência dentro de um projeto, pois são as mais visíveis em
sua gestão.
Algumas das ferramentas clássicas de Gestão de Tempo de Projeto são o
PERT/CPM e o Diagrama de Gantt. Veremos essas ferramentas mais adiante
nos capítulos sobre gerenciamento do tempo.

•  Gerenciamento/Gestão de custos do projeto

A gerência do custo do projeto agrega os processos que envolvem planeja-
mento, estimativa, orçamento e controle de custos que serão necessários para
a conclusão do projeto a partir de uma previsão orçamentária.
Os processos de gerência do custo do projeto incluem:
•  Planejamento da gestão de custos: avaliar quais recursos e a quantidade
aproximada de cada um dentro do projeto;
•  Estimativa de custo: desenvolver uma aproximação dos gastos com os re-
cursos necessários para execução do projeto;
•  Orçamento de Custo: agregar os custos estimados de atividades ou de pa-
cotes individuais de trabalho para estabelecer uma base de custo;
•  Controle de Custo: influenciar nos fatores que geram uma variação de
custo e controlar as mudanças de orçamento do projeto.

A gestão de custos é um processo em que se utiliza um conjunto de técnicas

multidisciplinares, que nos permite compreender a origem dos custos. Este
processo pode conduzir ao aumento de proventos, reduções de custos e obten-
ção de melhores níveis de produtividade.
•  Gerenciamento/Gestão da qualidade do projeto
Como conceito, conhece-se a qualidade há milênios. No entanto, só recen-
temente ela adquiriu o status de função da gerência. Originalmente, tal função
era relativa e voltada para a inspeção; hoje, as atividades relacionadas com a
qualidade ampliaram-se bastante e são consideradas essenciais para o sucesso
estratégico do projeto.
A ampliação da abrangência da qualidade nas atividades organizacionais
pode também ser percebida em responsabilidades que se agregaram à área,
como qualidade ambiental e qualidade de vida, ética e valores hoje impres-
cindíveis e objeto de regulamentações nacionais e internacionais e de nor-
mas diversas.

40 • capítulo 1
 Isso significa que há uma crescente conscientização da sociedade
a esse respeito, o que impõe o surgimento de demandas e exerce pres-
sões complementares.
Há várias classificações para diversos períodos ou eras da qualidade. Garvin
(2002) estruturou-as assim:
•  Inspeção;
•  Controle estatístico da qualidade;
•  Garantia da qualidade;
•  Gestão estratégica da qualidade.

Independentemente da estruturação, quando se fala sobre qualidade, cabe

ressaltar que o gerenciamento da qualidade do projeto deve ser direcionado
tanto para os processos de gerenciamento do projeto quanto para seu produto
ou serviço final do projeto. Estes processos visam assegurar que o projeto será
concluído com a qualidade desejada, satisfazendo, portanto, as necessidades
do cliente e os requisitos do produto. Atualmente, a gestão da qualidade tem
como preocupação básica evitar falhas.

•  Gerenciamento/Gestão de recursos humanos do projeto

Gerenciamento de recursos humanos do projeto é uma das dez áreas de
conhecimento do PMBOK (versão 5), tem como base a identificação e docu-
mentação de funções, responsabilidades e relações hierárquicas do projeto em
relação aos recursos humanos envolvidos, além da criação do plano de geren-
ciamento de pessoal. Obtenção dos recursos humanos necessários para termi-
nar o projeto.
Desenvolve a equipe do projeto, melhorando as competências e interação
de membros da equipe para aprimorar o desempenho do projeto. Gerenciar a
equipe do projeto, acompanhar o desempenho de membros da equipe, forneci-
mento de feedback, resolução de problemas e coordenação de mudanças para
melhorar o desempenho do projeto e valorização dos profissionais envolvidos.

•  Gerenciamento/Gestão das comunicações do projeto

Inclui os processos necessários para assegurar que as informações do pro-
jeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e orga-
nizadas de maneira oportuna e apropriada. Os gerentes de projetos gastam a
maior parte do seu tempo se comunicando com os membros da equipe e outras

capítulo 1 • 41
partes interessadas do projeto, quer sejam internas (em todos os níveis da orga-
nização) ou externas à organização.
Uma comunicação eficaz cria uma ponte entre as diversas partes interessa-
das envolvidas no projeto.
Processos de gerenciamento das comunicações do projeto
•  Identificar as partes interessadas:
O processo de identificação de todas as pessoas ou organizações que podem
ser afetadas pelo projeto e de documentação das informações relevantes rela-
cionadas aos seus interesses, envolvimento e impacto no sucesso do projeto.
•  Planejar as comunicações: O processo de determinação das necessidades
de informação das partes interessadas no projeto e definição de uma aborda-
gem de comunicação.
•  Distribuir as informações: O processo de colocar as informações necessá-
rias à disposição das partes interessadas no projeto, conforme planejado.
•  Gerenciar as expectativas das partes interessadas: O processo de comuni-
cação e interação com as partes interessadas para atender às suas necessidades
e solucionar as questões à medida que ocorrerem.
•  Reportar o desempenho: O processo de coleta e distribuição de informa-
ções sobre o desempenho, incluindo relatórios de andamento, medições do
progresso e previsões.

•  Gerenciamento/Gestão de riscos do projeto

Os Riscos de projeto são um conjunto de eventos que podem ocorrer sob a
forma de ameaças ou de oportunidades que, caso se concretizem, influenciam
o objetivo do projeto, negativamente ou positivamente.
A noção de risco é diversa, e muda consoante o enquadramento que deu
origem à metodologia de gestão de risco em causa. Na metodologia Risk
Mangement Guide for DOD Acquisition (2002), o risco é definido como sendo
“… a atenção dirigida à ocorrência de eventos futuros, cujo exato resultado é
desconhecido, e com a forma de lidar com essa incerteza, i.e., a amplitude de
possíveis resultados. Inclui o planeamento, identificação e análise de áreas de
risco e o desenvolvimento de opções para lidar e controlar o risco.”. Porém outro
tipo de definições, igualmente abrangentes, podemos encontrar em manuais
publicados pela US Project Management Institute (PMI) e pela UK Association
for Project Management (APM), embora muito semelhantes entre si:

42 • capítulo 1
 •  Risco – evento ou condição incerta que, se ocorrer, terá um efeito positivo
ou negativo sobre pelo menos um objetivo do projeto, como tempo, custo, âm-
bito ou qualidade – PMI, PMBOK Guide 2004, pag. 238;
•  Risco – determinado evento ou conjunto de circunstâncias que, ao ocorre-
rem, terão efeito sobre a concretização dos objetivos do projeto.

A necessidade de gerenciar riscos decorre, principalmente, da consciência

de existência de fatores, internos ou externos ao projeto, cujo desencadeamen-
to, ao longo do seu ciclo de vida, podem fazer alterar o objetivo do mesmo. A
identificação desses fatores e/ou das suas causas, constitui uma das etapas fun-
damentais, de qualquer metodologia de gestão dos riscos. O tipo de risco, a sua
probabilidade de ocorrência, ou o seu impacto sobre o projeto, variam ao longo
do ciclo de vida do mesmo, sendo por isso necessário proceder-se à identifica-
ção dos riscos, em todas as suas fases.

•  Gerenciamento/Gestão de aquisições do projeto

O Gerenciamento de Aquisições do Projeto é responsável por cuidar das
compras e aquisições de produtos, serviços ou resultados necessários para a
realização do trabalho. A organização pode ser o comprador ou fornecedor do
produto, serviço ou resultado. O Gerenciamento de Aquisições do Projeto in-
clui os processos de gerenciamento de contratos e de controle de mudanças
necessários para administrar os contratos ou pedidos de compra. Este geren-
ciamento inclui, ainda, a administração de qualquer contrato emitido por uma
organização externa (o comprador) que está adquirindo o projeto de uma orga-
nização executora (o fornecedor) e a administração de obrigações contratuais
estabelecidas para a equipe do projeto pelos contratos.
•  Gerenciamento/Gestão de envolvidos do projeto ou Gerenciamento das
Partes Interessadas do Projeto (adicionada na 5a Edição)
O gerenciamento das partes envolvidas do projeto concentra-se em um dos
elementos mais importantes da gestão de projetos, e gerencia os interessados,
suas expectativas, e compromissos. Antes era parte de um processo simples
dentro da área de comunicação, mas agora, é muito mais elaborada e recebe a
atenção que merece. Formada por 4 partes:
•  Identificar as Partes Interessadas
•  Gerenciar o Engajamento das Partes Interessadas
•  Planejar o Gerenciamento das Partes Interessadas
•  Controlar o Engajamento das Partes Interessadas

capítulo 1 • 43
 A tabela a seguir resume as características de cada uma das 10 áreas
de conhecimento:

ÁREA CARACTERÍSTICAS

Atividades de identificação, definição, ajuste, unificação e

INTEGRAÇÃO coordenação entre as várias atividades da iniciação, planeja-
mento, execução/monitoramento e encerramento.

Monitoramento e definição do que de fato está ou não incluí-

ESCOPO do no projeto, abrangendo todo o trabalho necessário para o
término do projeto, sem exceder o seu escopo

Detém as atividades que consistem em administrar os pro-

TEMPO cessos necessários ao término do projeto no prazo.

Possui atividades que visam assegurar que o projeto seja

CUSTO concluído em consonância com o orçamento aprovado.

Atividades que visam assegurar a conformidade do produto/

QUALIDADE serviço do projeto em relação ao solicitado.

Refere-se às atividades que culminam na utilização efetiva

dos recursos humanos do projeto, incluindo o planejamen-
RECURSOS to dos recursos humanos necessários para cada fase do
HUMANOS projeto, mobilização desses recursos (incluindo contratação
externa, se necessário), desenvolvimento de competências e
o efetivo gerenciamento da equipe.

44 • capítulo 1
 ÁREA CARACTERÍSTICAS

Abrange as atividades que garantem que informações do

COMUNICAÇÕES projeto sejam planejadas, geradas, coletadas, distribuídas,
armazenadas, recuperadas e organizadas

Identificação, análise, planejamento de respostas e controle

de riscos de um projeto para reduzir a probabilidade e o
RISCOS impacto dos eventos negativos e aumentar o aproveitamento
das oportunidades

Contempla todas as atividades de compra ou aquisição de

produtos, serviços ou resultados externos à equipe do proje-
to. Quando a compra envolver licitação, o gerente de projeto
AQUISIÇÕES deve mostrar-se mais atento a essa área de conhecimento,
tendo em vista os riscos de atraso que podem envolver esse
tipo de ação

Identifica pessoas, grupos e organizações que podem impac-

tar ou ser impactadas pelo projeto, analisa as expectativas
das partes interessadas e auxilia na montagem de estra-
PARTES tégias de gerenciamento apropriadas para engajá-las no
INTERESSADAS processo decisório e execução. Preocupa-se também com a
efetiva comunicação, resolução de conflitos, identificação de
problemas e satisfação das partes

Nesta disciplina, iremos explicar cada uma dessas áreas de uma forma bas-
tante ampla, enfatizando a sua aplicação em projetos de qualquer contexto.
Dessa forma, pretendemos oferecer a vocês, futuros administradores de em-
presas, um ferramental bastante diversificado para ser aplicado nos projetos
que vocês virão a gerenciar.

capítulo 1 • 45
 ATIVIDADES
Desenvolvemos, abaixo, um conjunto de perguntas para que você possa fixar o conteúdo
aprendido nesta unidade.
Responda às perguntas abaixo utilizando como base tudo aquilo que você estudou nesta
unidade, nas conexões apresentadas e utilizando o conhecimento que você já possui de vi-
vências profissionais ou de estudos de módulos passados referentes ao mundo coorporativo.

01. É possível gerenciar um projeto dentro de uma organização por meio de boas práticas
e metodologias cientificamente testadas ou só é possível gerenciar projetos fazendo uso de
profissionais experientes que utilizam métodos “artísticos” para alcançar o sucesso do proje-
to? Explique a sua resposta.

02. O que é o PMI e qual é a principal função desta instituição?

03. Comente as principais ações do PMI no trabalho da profissionalização do gerenciamen-

to de projetos.

04. Abaixo, marque P para projetos ou TO para trabalhos operacionais do dia a dia de
uma instituição.
( ) Ações para o desfile de carnaval de um determinado ano.
( ) Construção de carros em série em uma linha de b) montagem.
( ) Ações para a criação de um novo modelo de carro de uma determinada montadora.
( ) Desenvolvimento de um novo d) software de ERP para uma determinada empresa.
( ) Ações do setor de RH para a emissão de pagamentos dos funcionários de uma
determinada empresa.
( ) Ações de uma empresa para determinar o processo de emissão de pagamentos
dos funcionários de uma determinada empresa.
( ) Tarefas associadas a um funcionário de uma lanchonete para a confecção de lan-
ches padrões desta lanchonete.

46 • capítulo 1
 REFLEXÃO
No seu desempenho profissional de um executivo, de um administrador, gestor, analista de
sistemas etc., por vários momentos você irá se deparar com projetos e processos, isso por
que, entre outras coisas, administrar uma empresa ou liderar uma equipe, ser encarregado
de um setor ou gestor de uma célula produtiva, tudo isso consiste em administrar o dia a dia
dos profissionais em suas atividades diárias, ou seja, nos trabalhos operacionais, e também
em dar rumo a instituições por meio de um plano estratégico que será contemplado pela
execução de vários projetos.
É importante que neste momento você saiba diferenciar trabalhos operacionais de pro-
jetos e saiba que para tratar cada um desses há uma abordagem científica e sistematizada
para auxiliá-lo.
Neste sentido, aprendemos neste capítulo sobre o que é um projeto e sobre o PMI, que é
uma instituição que luta pela profissionalização do gerente de projetos por meio da sistema-
tização de boas práticas de abordagem ao gerenciamento de projetos.
Dessa forma, sempre que você se deparar com projetos na sua vida profissional, você
terá condição de identificá-los e gerenciá-los por meio das definições de uma metodologia/
processo apoiada nas boas práticas estudadas e abordadas no PMBOK. Sendo assim, o es-
tudo desse capítulo se fez importante, porém não suficiente. Por isso, vamos em frente, ainda
temos muito mais para aprender sobre gerenciamento de projetos!!

LEITURA
Você pode melhorar um pouco mais o seu entendimento de gerenciamento de projetos ou-
vindo um pouco do que diz um dos mais reconhecidos profissionais de gerenciamento de
projetos no Brasil e no mundo, o Sr. Ricardo Vargas.
Nesta unidade, vamos recomendar que você ouça dois podcasts interessantes do Ricar-
do Vargas.
O primeiro, é um podcast que fala sobre os desafios do gerenciamento de projetos.
Neste, Vargas aborda as dificuldades de um projeto e parte da máxima de que não existe
projeto fácil e que todos os projetos terão seus desafios e por isso que há a necessidade de
um gerente de projetos. Esse podcast pode ser ouvido em: http://www.ricardo-vargas.com/
pt/podcasts/projectchallenges/
O segundo, é um podcast que fala sobre as leis de Murphy no gerenciamento de pro-
jetos. Por meio de uma alusão cômica a Murphy, Vargas explica que não há lugar para o

capítulo 1 • 47
pessimismo em projetos. Esse podcast pode ser ouvido em: http://www.ricardo-vargas.com/
wp-content/uploads/podcasts/2009/ricardo_vargas_2009_04_20_murphy_pt.mp3

O gerente de projetos
O gerente do projeto é a pessoa designada pela organização responsável pela condução do
projeto, com a missão de zelar para que os objetivos do projeto sejam atingidos. O geren-
te de projetos tem sido caracterizado por um perfil profissional com domínio e experiência
especializados nos processos e nas áreas de conhecimento do gerenciamento de projetos.
O trabalho do gerente de um projeto pode ser sintetizado em dois grandes elementos:
•  Planejar (antes) e Controlar (durante) as atividades do projeto e seu gerenciamento, con-
forme se pode constatar pela concentração de processos de gerenciamento de um projeto
abrangendo todas os aspectos envolvidos.
•  Comunicar: os gerentes de projetos passam a maior parte do seu tempo tratando com os
membros da equipe e outras partes interessadas do projeto.

Para obter eficácia no gerenciamento, em especial na comunicação, os gerentes de pro-

jetos devem dominar habilidades interpessoais. Isso significa um longo e contínuo processo
de crescimento pessoal e desenvolvimento gerencial.
Segundo a psicóloga Fela Moscovici [Moscovici 1981], competência interpessoal é a
habilidade de lidar eficazmente com relações interpessoais, de lidar com outras pessoas de
forma adequada às necessidades de cada um e às exigências da situação.
Competência interpessoal é resultante de percepção acurada e realística das situações
interpessoais e de habilidades comportamentais específicas que conduzem a consequências
significativas no relacionamento duradouro e autêntico, satisfatório para as pessoas envol-
vidas. Um terceiro componente dessa competência refere-se ao relacionamento em si, e
compreende a dimensão emocional-afetiva, predominantemente.
Lidar com situações interpessoais requer sensibilidade e flexibilidade perceptiva e com-
portamental, que significa procurar ver vários ângulos ou aspectos da mesma situação e
atuar de forma diferenciada, não rotineira, experimentando novas condutas percebidas como
alternativas de ação.
Destacam-se as seguintes habilidades interpessoais para o gerente de projetos:
•  Comprometimento, responsabilidade, ética e honestidade;
•  Transparência, franqueza, clareza e objetividade;
•  Liderança, agregação, motivação e entusiasmo;
•  Solução de conflitos e problemas;

48 • capítulo 1
•  Negociação, influência e persuasão;
•  Decisão, iniciativa e proatividade;
•  Organização e disciplina;
•  Autocontrole, equilíbrio e resiliência;
•  Empreendedorismo;
•  Eficácia.

O PMI mantém um Código de Ética e Conduta Profissional (Project Management Insti-

tute Code of Ethics and Professional Conduct), criado para incutir confiança à profissão de
gerenciamento de projetos e auxiliar os praticantes a se tornarem melhores profissionais.
Para isso, o código descreve as expectativas que os profissionais de gerenciamento de pro-
jetos têm de si e de seus colegas. Ele exige que os profissionais demonstrem compromisso
com a conduta ética e profissional, sendo específico quanto à obrigação básica de responsa-
bilidade, respeito, justiça e honestidade. Isso inclui respeitar as leis, regulamentos e políticas
organizacionais e profissionais.
Mais que ser um facilitador, o gerente de projetos deve fazer a diferença no bom anda-
mento e no sucesso dos projetos.
Saiba mais em: http://www.mhavila.com.br/topicos/gestao/pmbok.html

REFERÊNCIAS BIBLIOGRÁFICAS
BOROVIK,Cleide; RAMIREZ, Andrea; RAMIREZ, Fernanda. Tecnotopias: arte e ciências, imagens e contexto
Disponível em: <http://www.eca.usp.br/nucleos/njr/espiral/tecno34b.htm>. Acesso em: 16 mar. 2010.
CAVALIERI, Adriane. Como se tornar um profissional em gerenciamento de projetos. São Paulo:
QualityMark, 2007.
FREITAS, Carlos A. V. CAPM Credential Growing in Brazil. PMI Todays. Publicado em: mar. 2009.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania : s.n., 2004.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania : s.n., 2008.
PMI. Estudo de Benchmarking em Gerenciamento de projetos Brasil. Project Manager Institute. 2009.
PMI. Project Manager Institute. Disponível em: <www.pmi.org>. Acesso em: 1 jan. 2010.
SOUSA, Ciclo PDCA – Um instrumento para melhoria continua. Disponível em: <www.pmies.org.br/v2/
centraladm/artigos/arquivos/20-09_Ciclo_PDCA_-_Um_instrumento_para_melhoria_continua.pdf>.
Acesso em: 16 mar. 2009.
WIKIPEDIA. Ciclo PDCA. Disponível em: <http://pt.wikipedia.org/wiki/Ciclo_PDCA>. Acesso em: 16
mar. 2010.

capítulo 1 • 49
50 • capítulo 1
 2
Gerenciamento
de Integração e
Gerenciamento de
Escopo
Nas unidades anteriores, começamos falando sobre definição de projetos, ge-
renciamento de projetos e uma breve apresentação das áreas de conhecimento
de um projeto.
Vimos também, sobre os ciclos de vida de produto, projeto e de gerencia-
mento de projetos e a partir desta unidade começamos a tratar o gerenciamen-
to de projetos de forma mais prática, quero dizer, de forma mais aplicável, uma
vez que até então estávamos tratando de conceitos por meio dos quais cons-
truímos uma base sólida em cima da qual essa parte mais “prática” poderá
se sustentar.
A partir deste capítulo, vamos estudar um pouco sobre como os processos
dos grupos de processos já vistos anteriormente, que se dividem em 10 áreas de
conhecimento e vamos mostrar as principais técnicas de algumas dessas áreas.
Como visto anteriormente, o ciclo de vida de gerenciamento de projetos é
dividido em 5 grupos de processos, quais são:
1. Iniciação
2. Planejamento
3. Execução
4. Monitoramento e controle
5. Encerramento

Dentro de cada um desses grupos de processos, são definidos processos por

meio da descrição das entradas, ferramentas/técnicas e saídas desses proces-
sos, formando, assim, as boas práticas de gerenciamento de projetos indicadas
pelo PMBOK. Contudo, esses processos são organizados em 10 grandes áreas
de conhecimento, a saber: integração, escopo, tempo, custo, qualidade, recur-
sos humanos, aquisição, riscos e partes interessadas.
1. Sempre iniciaremos a explicação de cada área de conhecimento mos-
trando os seus objetivos e qual é a importância da área no gerenciamento
de projetos.
2. Na sequência, iremos mostrar quais são os processos que compõem a
área, classificando-os de acordo com o grupo de processos a que eles perten-
cem e fazendo uma breve descrição desses processos.
3. Por último, sempre que necessário, iremos explicar algumas das ferra-
mentas/técnicas que consideramos mais importantes na área abordada.

52 • capítulo 2
 A primeira área a ser abordada, abre a sequência do ciclo de vida de um pro-
jeto que é o gerenciamento da integração.
Vamos lá!

OBJETIVOS
Com o estudo deste capítulo, iniciaremos os conteúdos pertinentes às 10 áreas de conheci-
mento do gerenciamento de projetos. Este capítulo portanto, trará os conceitos e atividades
do gerenciamento da integração e do escopo, abrindo a lista de áreas do conhecimento
descritos no PMBOK.
Gerenciamento da Integração
1. Criação do Termo de Abertura
2. Ciclo padrão de planejamento e Integração do Plano de Projeto.
3. Controle e Monitoramento do Projeto
4. Controle de Mudanças
5. Encerramento de projetos

Gerenciamento do escopo de um projeto

1. Definição de escopo e gerenciamento de escopo
2. Coleta de Requisitos
3. Ferramentas
4. A Declaração de Escopo
5. Definição de EAP
6. Técnicas para gerar EAP
7. Verificação do escopo
8. Controle de Mudanças do escopo

capítulo 2 • 53
2.1  Processo de Integração do Projeto
O processo de integração do projeto consiste em garantir que todas as demais
áreas estejam integradas em um todo único. Seu objetivo é estruturar todo o
projeto de modo a garantir que as necessidades dos envolvidos sejam atendi-
das pelo projeto.
Segundo o Guia PMBOK®, o gerenciamento da integração do projeto inclui
os processos e as atividades necessárias para identificar, definir, combinar,
unificar e coordenar os vários processos e atividades dos grupos de processos
de gerenciamento.
O gerente do projeto age como integrador dos processos e das pessoas.

Escopo
Partes
Tempo
Interessadas

Aquisições Custos
Integração

Riscos Qualidade

Comunica- Recursos
ções Humanos

Figura 2.1  –  Gerenciamento da integração como área central do gerenciamento de proje-

tos. Fonte: Vargas (2009).

Para iniciar a explicação da área de conhecimento em gerenciamento de in-

tegração, vamos falar um pouco sobre alguns stakeholders do projeto e suas
principais funções.
•  Equipe de execução do projeto: concentra-se em completar todos os pa-
cotes de trabalho planejados para concluir o escopo do projeto e, dessa forma,
finalizá-lo.
•  Patrocinador do projeto: definir os objetivos, dar apoio financeiro, autori-
zar o projeto, delegar autoridade e defender o projeto contra perda de recursos.

54 • capítulo 2
 •  Gerente do projeto: gerenciar o projeto aplicando todas as boas práticas
reconhecidas e comprovadas no mercado profissional e acadêmico como prá-
ticas que funcionam na maioria dos projetos e na maior parte do tempo. No ge-
renciamento do projeto, o gerente de projetos também é responsável por reunir
todas as peças do projeto em uma unidade coesa.

Mas como o gerente de projetos consegue reunir “todas as peças” do projeto

em uma unidade coesa e integrada? O que tem para ser unido e controlado de
forma coesa e integrada?
Para isto que existe a área de conhecimento de gerência de integração. É de
responsabilidade dos processos dessa área de conhecimento identificar, definir,
combinar, unificar e coordenar os diversos processos e atividades de gerencia-
mento de projetos, ou seja, os diversos processos e atividades das outras áreas
de conhecimento. Portanto, o gerenciamento de integração é responsável por
integrar todas as demais áreas de conhecimento de gerenciamento de projetos.
Como vimos em unidades anteriores, as fases do ciclo de vida de gerencia-
mento de projetos se interagem intensamente. Então, podemos dizer que os pro-
cessos que compõem essas fases também estão se interagindo intensamente. A
coordenação da interação desses processos é de responsabilidade da gerência de
integração, uma vez que é nessa área de conhecimento que se decide como cada
área será planejada. Vamos a um exemplo trazido pelo PMBOK (2013):

A gerência de integração é quem irá compor o plano de gerenciamento do proje-

to que irá definir e coordenar todos os planos de gerenciamento auxiliares das ou-
tras áreas de conhecimento, inclusive das áreas de gerenciamento de custo, tempo
e risco, conforme citado no exemplo anterior. Por isso, voltamos a dizer que a ge-
rência de integração é responsável pela integração dos processos entre os gru-
pos de processos (fases) do ciclo de vida de gerenciamento de projetos para rea-
lizar os objetivos do projeto dentro dos procedimentos definidos da organização.

capítulo 2 • 55
 A gerência de integração é composta pelos seguintes processos:
1. Processos de iniciação:
Desenvolver o termo de abertura do projeto
2. Processos de planejamento:
Desenvolver o plano de gerenciamento do projeto
3. Processos de execução:
Orientar e gerenciar a execução do projeto
4. Processos de monitoramento e controle:
Monitorar e controlar o trabalho do projeto
Controle integrado de mudanças
5. Processos de encerramento
Encerrar o projeto

2.1.1  Desenvolver o termo de abertura do projeto

Este processo faz parte do grupo de processos de iniciação (ou fase de iniciação).
Na verdade, este processo e o processo “desenvolver a declaração do escopo
preliminar do projeto” são os únicos que compõem a fase de iniciação do ciclo
de vida de gerenciamento de projetos. E ambos os processos estão sob respon-
sabilidade da área de gerenciamento de integração.
O processo “Desenvolver o termo de abertura do projeto” tem como objetivo
desenvolver um documento chamado “Termo de Abertura de Projeto” ou TAP
(ou, no inglês, Project Charter).
Este documento serve para autorizar formalmente a abertura de um projeto
e para garantir ao gerente de projetos a autoridade para aplicar os recursos da
empresa no empreendimento do projeto.
Portanto, este é um documento que não é escrito pelo gerente de projetos,
mesmo por que é neste documento que o gerente de projetos é escolhido pelo
patrocinador do projeto.

56 • capítulo 2
 CONCEITO
Detalhamento desenvolvimento do termo de abertura do projeto.
Entradas
O processo de desenvolver o termo de abertura do projeto possui cinco entradas:
1. Declaração do trabalho do projeto: Esta entrada é uma descrição de todos os produtos e
serviços que serão fornecidos pelo projeto a ser criado. Nos projetos internos à organização
essa declaração pode ser feita pelo patrocinador com base nos requisitos das necessidades
dos negócios (por exemplo, uma demanda de mercado, avanço tecnológico, requisito legal
ou nova lei imposta pelo governo), produtos ou serviços. No entanto, para projetos externos
esta declaração pode ser concedida pelo cliente através de um documento de licitação, por
exemplo, solicitação de proposta, informações, preços, ou como parte de um contrato.
2. Business Case: Um business case é um documento que fornece informações necessá-
rias do ponto de vista de um negócio, para determinar se o projeto justifica ou não o inves-
timento. Neste documento temos a análise de custo benefício e necessidades de negócios
para justificar o projeto. O cliente é o responsável por escrever o business case. O business
case é criado devido a demanda de mercado onde uma empresa poderia ter verificado a
necessidade de um projeto para criar um produto melhor em resposta a alguma situação
imposta pelo mercado, ou devido a alguma necessidade organizacional, solicitação do cliente,
avanço tecnológico, etc.
3. Contrato: Neste caso um contrato será uma entrada apenas se o projeto estiver sendo
realizado por um cliente externo, assim normalmente a empresa cliente formaliza um contrato
contendo algumas restrições que devem ser aceitas pela organização executora do projeto.
4. Fatores Ambientais da empresa: Os fatores ambiente são situações que podem ocorrer
na organização interna ou externa que cercam ou influenciam o sucesso de um projeto. Estes
fatores ambientais podem aumentar ou restringir as opções de gerenciamento de projetos e
ainda podem influenciar positivamente ou negativamente no resultado deste projeto. Esses
fatores ambientais podem ser: padrões governamentais ou industriais, infraestrutura organi-
zacional, condições do mercado, entre outros.
5. Ativos de Processos Organizacionais: Os ativos de processos organizacionais são todos
os ativos relacionados a processos, de quaisquer ou todas as organizações envolvidas no
projeto que podem ser usados para influenciar o sucesso do projeto. Os ativos de processos
organizacionais que podem influenciar no termo de abertura podem ser: Processos organiza-
cionais padronizados, políticas e definições padronizadas de processos para uso na organiza-
ção, modelos (como modelos de termo de abertura previamente definidos pela organização),
informações históricas, base de conhecimento de lições aprendidas, etc.

capítulo 2 • 57
Ferramentas e Técnicas

O processo desenvolver o termo de abertura do projeto possui uma ferramenta e técnica:

1. Opinião Especializada: A opinião especializada é fornecida por qualquer grupo ou pessoa
que tenha conhecimento ou treinamento especializado e está disponível para ajudar na avaliação
das entradas necessárias para o desenvolvimento do termo de abertura do projeto. A opinião do
especialista é aplicada a qualquer detalhe que seja técnico ou de gerenciamento durante o pro-
cesso de termo de abertura. Essa opinião especializada pode estar disponível através de outras
unidades dentro da organização, consultores, clientes, especialistas no assunto, etc.

Saídas

O processo desenvolver o termo de abertura do projeto possui uma saída:

1. Termo de Abertura do Projeto: Como foi visto até o momento, o termo de abertura é onde
estão documentadas todas as necessidades do negócio, o entendimento das necessidades
do cliente, informações sobre o novo produto, serviço ou resultado a ser satisfeita pela orga-
nização executora.

O termo de abertura gerado pode conter:

1. Propósito ou justificativa do projeto;
2. Os objetivos mensuráveis do projeto e critérios de sucesso relacionados;
3. Requisitos de alto nível;
4. Descrição do projeto em alto nível;
5. Riscos de alto nível
6. Resumo do cronograma de marcos;
7. Resumo do orçamento;
8. Requisitos para aprovação do projeto;
9. Gerente de projeto designado, responsabilidade e nível de autoridade;
10. Nome e autoridade do patrocinador ou outra pessoa (ou pessoas) que autoriza(m) o
termo de abertura do projeto.
Pode-se notar também que o termo de abertura do projeto não possui nada muito de-
talhado, ele é um documento formal mais abstrato que autoriza o projeto e dá informações
importantes que servirão para guiar o restante do projeto.
Leia mais em: Gerenciamento da Integração segundo o PMBoK http://www.devmedia.
com.br/gerenciamento-da-integracao-segundo-o-pmbok/27359#ixzz3lplFrPmw

58 • capítulo 2
2.1.2  Desenvolver o plano de gerenciamento do projeto

Este processo pertence ao grupo de processos de planejamento e tem por ob-

jetivo definir, coordenar e integrar todos os planos auxiliares de planejamento
(os outros planos das outras 8 áreas de conhecimento) em um plano de geren-
ciamento do projeto que definirá como o projeto será executado, monitorado,
controlado e encerrado.
Nesta unidade, iremos explicar cada plano de gerenciamento que compõe o
plano de gerenciamento do projeto.
Então, é função deste processo organizar a confecção do plano de gerencia-
mento de cada grande área de conhecimento como planejamento de escopo,
custo, tempo, risco, recursos humanos, qualidade, aquisições e comunicações.

2.1.3  Orientar e gerenciar a execução do projeto

Este processo pertence ao grupo de processos de execução.

O trabalho determinado na declaração do escopo do projeto (documento
este que ainda não vimos, pois o processo responsável pela sua geração está na
área de conhecimento de gerência de escopo, porém podemos entender por
enquanto que este trabalho está declarado nos documentos de termo de aber-
tura do projeto e documento de declaração do escopo preliminar do projeto)
deve ser realizado. Então, realizar este trabalho é o objetivo deste processo de
integração. (VIEIRA, 2007).
O gerente deve tomar muito cuidado neste processo para que os membros
da equipe executora não implementem funcionalidades a mais do que aquelas
declaradas no escopo do projeto. Pois, aumentar o escopo do projeto significa
um acréscimo de custo e tempo que podem ser indesejados pelo patrocinador/
iniciador do projeto.
Para realizar este trabalho, algumas ações devem ser tomadas, a saber: execu-
tar as atividades planejadas; usar recursos financeiros para executar o objetivo do
projeto; formar, treinar e gerenciar os RH do projeto; obter cotações; selecionar
fornecedores; gerenciar e obter recursos; implementar normas e métodos plane-
jados; criar, controlar verificar e validar as entregas do projeto; gerenciar riscos;
gerenciar fornecedores; implementar alterações; coletar dados e relatar custos,
cronograma, progresso técnico e informações gerais sobre o andamento do pro-
jeto; coletar e documentar as lições aprendidas. (PMBOK, 2008).

capítulo 2 • 59
2.1.4  Monitorar e controlar o trabalho do projeto

Este é um processo do grupo de processos de monitoramento e controle e tem

por objetivo gerenciar as alterações no planejamento do projeto à medida em
que elas ocorrem.
São atividades desse processo: comparação do desempenho real do projeto
com o plano de gerenciamento do projeto (linhas base); avaliação do desempe-
nho do projeto; análise, acompanhamento e monitoramento de riscos; manu-
tenção de base de informações relativas ao produto do projeto; fornecimento de
informações para dar suporte a relatórios de andamento, medições de progres-
so e previsões; monitoramento de implementações de mudanças aprovadas.
Esse processo é particularmente importante, pois por meio dele é que as
mudanças solicitadas serão discutidas, controladas e aprovadas. Muitas vezes,
os stakeholders não conseguem visualizar o impacto que determinadas solici-
tações de alteração irão gerar no projeto. Então, este processo nos serve para
que essas solicitações de alteração sejam discutidas com a seriedade merecida
e, uma vez aprovadas, seja então comunicado a todos de forma efetiva e incluí-
da no planejamento do projeto.

2.1.5  Realizar o controle integrado de mudanças

Este processo faz parte do grupo de processos de monitoramento e controle e

define as atividades necessárias para a avaliação, aprovação/rejeição de todas e
quaisquer mudanças solicitadas no projeto.
Há algumas áreas de aplicação como, por exemplo, a área de tecnologia de
informação, na qual essas mudanças acontecem muito rapidamente e os im-
pactos, na grande maioria das vezes, são mal analisados. Então, o controle inte-
grado de mudanças se preocupa em analisar os motivos geradores das mudan-
ças para analisar se elas são realmente necessárias e, posteriormente, gerenciar
as alterações no momento em que elas acontecem.
São ações desse processo, entre outros: identificação da ocorrência ou ne-
cessidade de ocorrência de uma determinada mudança; revisão e aprovação
das mudanças solicitadas; gerenciamento das mudanças aprovadas; manuten-
ção da integridade das linhas de base; revisão e aprovação de todas as ações
preventivas e corretivas; controle e atualização de escopo, custo e tempo; docu-
mentação do impacto total das mudanças solicitadas; validação do reparo do
defeito; controle de qualidade do projeto.

60 • capítulo 2
2.1.6  Encerrar o projeto ou fase

Este processo faz parte do grupo de processos de encerramento.

O processo Encerrar o projeto envolve a realização da parte de encerramen-
to do projeto do plano de gerenciamento do projeto. Em projetos com várias
fases, o processo Encerrar o projeto encerra a parte do escopo do projeto e as
atividades associadas, aplicáveis a uma determinada fase. (PMBOK, 2004).
O encerramento do projeto é particularmente importante, pois é aqui que
as lições aprendidas são revistas e se faz um “balanço final” sobre o projeto que
está terminando (ou fase do projeto que está terminando).
Em projetos de TI, dada a sua característica de curto prazo de implemen-
tação e alta instabilidade de requisitos, consolidar as lições aprendidas e os
ativos conseguidos com o projeto é importantíssimo, principalmente quando
tratamos de reaproveitamento de códigos, padrões de desenvolvimento e ar-
quiteturas. Um bom encerramento de projeto significa a consolidação de todos
esses ativos para que eles possam ser recuperados e utilizados facilmente em
projetos futuros.
Este processo possui dois procedimentos administrativos: encerramento
administrativo e encerramento de contratos.

COMENTÁRIO
O processo de integração tem, portanto, o desafio de garantir que todas as demais áreas
estejam integradas em um todo único e deve estruturar todo o projeto de modo a garantir
que as necessidades dos envolvidos sejam atendidas pelo projeto.

2.2  Gerenciamento de Escopo

Logo após a aprovação do projeto e a formalização de sua abertura deve-se
perguntar: o que vamos ter que fazer para atingir estes objetivos? De fato, a de-
finição sobre o que fazer é de enorme relevância para que o projeto seja bem
sucedido em seus objetivos e deve ser feita adequadamente.
Na verdade, não só a definição de que tipo de trabalho deve ser realizado,
mas também como garantir que o trabalho seja feito é de responsabilidade da
área de gerenciamento de escopo.

capítulo 2 • 61
 O gerenciamento de escopo trata dos limites do projeto, estabelecendo tudo
o que está dentro do projeto e tudo o que está fora do projeto (às vezes, especifi-
car o que está fora é quase tão importante do que especificar o que está dentro,
por causa dos requisitos de contexto e requisitos não funcionais dos softwares).
Definir corretamente o escopo é uma das partes mais importantes do ge-
renciamento de projeto, pois se pensarmos em qualidade como um conceito
relacionado com o atendimento dos requisitos dos stakeholder, então determi-
nar muito bem esses requisitos é o primeiro passo para entregar um produto/
serviço de qualidade e ter sucesso no projeto.
A determinação do que exatamente faz parte ou não faz parte do projeto e
a identificação das necessidades do cliente e tradução dessas necessidades em
requisitos é uma atividade complexa (e dependendo da área do projeto, essa
complexidade pode ser realmente muito alta e se transformar em ponto crítico
de sucesso do projeto).

Gerenciamento do escopo em Tecnologia da Informação

Em TI, a determinação do que exatamente faz parte, ou não faz parte do projeto e
a identificação das necessidades do cliente e tradução dessas necessidades em
requisitos é uma atividade extremamente complexa, pois produtos de softwares são
abstratos, e definir algo abstrato logo nas primeiras fases do projeto (ponto em que se
faz necessário a definição do escopo) é realmente uma tarefa difícil.

Para garantir que o escopo do projeto estará bem documentado e prevendo

tudo o que o projeto deve conter para que o produto/serviço final exceda as ex-
pectativas do iniciador/patrocinador, a área de gerência de escopo conta com 3
processos de planejamento e 2 de monitoramento e controle, a saber:

PROCESSOS DE PLANEJAMENTO PROCESSOS DE MONITORAMENTO E

CONTROLE

Coletar os requisitos
Verificar o escopo
Definir o escopo
Controlar o escopo.
Criar EAP

Tabela 2.5  –  Processos de Gerenciamento de Escopo.

62 • capítulo 2
 No decorrer deste capítulo, detalharemos todos s processos de gerencia-
mento de escopo, a começar pela coleta de requisitos.

2.2.1  Coletar os requisitos

Este processo tem como objetivo: definir e documentar as necessidades das

partes interessadas para alcançar o objetivo do projeto. (PMBOK, 2008).
Porém, é necessário distinguir entre os dois tipos de escopo, quanto se trata
de gerenciamento de projetos. O escopo, em projetos, pode ser entendido de
duas formas:
1. Escopo do produto: descreve tudo o que o produto tem, ou seja, busca
definir o produto em termos de suas funcionalidades.
2. Escopo do projeto: delimita e define todo o trabalho que precisa ser fei-
to (principalmente em termos de gerenciamento) para que o escopo do produ-
to seja atendido.

Com esse entendimento sobre escopo, é necessário visualizar a definição

dada para este processo de uma forma mais ampla. Ou seja, o escopo objetiva
definir e documentar, junto às partes interessadas, as funções e funcionalida-
des do produto e do projeto. (PMBOK, 2008).
O processo de coleta de requisitos gera como resultado todos os requi-
sitos analisados do produto e do projeto e serve de base para a confecção da
Estrutura Analítica do Projeto e para a elaboração dos planejamentos de tem-
po, custo e qualidade.

Levantamento de Requisitos em Projetos de TI

Considerando a definição de escopo mais ampla como definir e documentar, junto às
partes interessadas, as funções e funcionalidades do produto e do projeto, o geren-
ciamento de escopo trata de tudo o que envolve a criação dos produtos e sobre todos
os processos utilizados para criá-los. Sendo que tudo deve ser baseado nos requisi-
tos do cliente. Em projetos de TI, a definição do escopo é razoavelmente complexa
principalmente em projetos de desenvolvimento de novos softwares, quando se faz
necessária a transformação das necessidades dos stakeholders em requisitos formais
que deverão ser implementados pelo software.

capítulo 2 • 63
 Para resolver essas complexidades, a engenharia de software propõe o processo de
engenharia de requisitos, que, segundo Sommerville (2003), é composto por quatro
atividades básicas: estudo de viabilidade, obtenção e análise de requisitos, especifica-
ção de requisitos, validação de requisitos.
Neste processo de engenharia de requisitos, no momento de determinação do esco-
po do software, é necessário se atentar aos seguintes pontos:
1. Contexto:
a) Em qual contexto o software se encaixa? Há um sistema maior que o
engloba?
b) As restrições impostas pelo contexto do software.
2. Objetivos da informação:
a) Os dados serão produzidos como saída do software e visto pelos usuários
finais.
b) Os dados que serão a entrada do sistema.
3. unções e desempenho
a) As funções que o software deverá ter para transformar as entradas em saí-
das interessantes para o usuário final (processar os dados).
b) Requisitos não funcionais como desempenho, usabilidade, manutenibilidade
e etc. (PRESSMAN, 2006).

Com o escopo bem definido e os requisitos do software claros e consistentes, forma-se

o primeiro passo para entregar um produto/serviço de qualidade, uma vez que o conceito
de qualidade esta relacionado em atender ou superar as expectativas e necessidades do
cliente por meio dos requisitos implementados no software. Então, entender os requisitos
do software é condição sine qua non para o desenvolvimento de um produto de qualidade.
Ainda, uma definição de escopo correta, também permite uma análise consistente do
tempo envolvido na conclusão do projeto, uma vez que os processos de gerenciamen-
to do tempo partem da EAP que contém todo o escopo do projeto.

Para coletar os requisitos de um produto e, consequentemente de um proje-

to, existem diversas técnicas (PMBOK, 2008):
•  Entrevistas;
•  Questionários;
•  Grupos focais (grupos de consumidores monitorados que são convidados
a debaterem as características de um determinado produto);
•  Conversas informais;

64 • capítulo 2
 •  Benchmarking com outros projetos (tomar por base requisitos que Foram
atendidos por outros projetos realizados anteriormente);
•  Técnica Delphi (um grupo seleto de especialistas responde questionários
e debate sobre os requisitos);
•  Opiniões técnicas especializadas.

Um aspecto de importante observação sobre a coleta de requisitos é que

os requisitos não têm origem somente nos clientes. É comum que os próprios
clientes não tenham consciência sobre que requisitos devem ser atendidos
para sucesso de um projeto. Dessa forma, é importante consultar outras fontes,
como membros experientes da equipe ou mesmo outros colaboradores que não
façam parte da equipe no projeto atual, mas tenham experiências anteriores.
Porém, independente da origem dos requisitos eles devem ser claramente
estabelecidos no projeto e é aconselhável que possam ser rastreados, associan-
do cada um a sua fonte. Para esse objetivo, um recurso interessante é a constru-
ção de uma matriz de rastreabilidade, representada na tabela 2.2.

STAKEHOLDER 1 STAKEHOLDER 2 STAKEHOLDER 3

REQUISITO 1 Conforto Segurança Preço baixo
REQUISITO 2 Potência Desempenho Conforto
REQUISITO 3 Aceleração Design Segurança
REQUISITO N
Tabela 2.6  –  Exemplo de matriz de rastreabilidade.

Uma matriz de rastreabilidade define e controla o que será incluído ou não no

projeto e inclui somente os artefatos para gerenciar o escopo do projeto e não do
produto. Além disso, é necessária uma verificação constante dessa matriz para
ter certeza que todo o trabalho necessário está sendo realizado e para impedir a
realização de trabalho extra que não faça parte do projeto (PMBOK, 2008).
A tabela 2.2 é um exemplo simplificado de uma matriz de rastreabilidade.
Este recurso pode apresentar outros itens, tais como:
•  Prioridade;
•  Fase do Projeto;
•  Descrição do Requisito;
•  Critérios de Aceitação;
•  Dependências Externas;

capítulo 2 • 65
 •  Data da Criação do Requisito;
•  Data da última alteração;
•  Responsável pela última alteração;
•  Motivo da última alteração;
•  Situação do requisito.

Além da matriz de rastreabilidade, o processo de coleta de requisitos tam-

bém possibilita a construção do documento de requisitos, que descreve como
cada requisito atende a(s) necessidade(s) do negócio e qual necessidade será
atendida dentro dos objetivos do projeto. Ainda, os requisitos devem ser des-
critos sem gerar dupla interpretação e sempre que possível, usar critérios de
aceitação mensuráveis retirando qualquer subjetividade da avaliação.
Na fase do planejamento do escopo do projeto, além da cultura organiza-
cional, infraestrutura, ferramentas, recursos humanos, políticas de pessoal e
condições de mercado, a sustentabilidade ambiental do projeto também deve
ser analisada. As questões que precisam ser levantadas nessa fase podem ser: o
projeto irá afetar o meio ambiente no seu entorno? Quais são as opções de mu-
danças no escopo do projeto o gerente poderá lançar mão, caso algum impacto
ambiental negativo afete sobremaneira o projeto? É fundamental que a área do
gerenciamento ambiental esteja prevista inclusive na EAP para que nenhum
dos processos dessa área seja esquecido
Este livro segue a metodologia sugerida pelo guia PMBOK, 2008. Tal Guia
de Gerenciamento de Projetos fornece as principais referências para o geren-
ciamento de projetos. Para tanto, ele mapeia as áreas de conhecimento indis-
pensáveis para atingir esse fim e desenvolve um capítulo para cada uma dessas
áreas. Porém, o Guia não desenvolve um capítulo para tratar do gerenciamento
ambiental nos projetos e, para, complementar as práticas do Guia, o Professor
Doutor Ricardo Vargas escreveu um artigo com orientações para observação
dos requisitos dessa natureza.

AUTOR
Ricardo Viana Vargas é um especialista em gerenciamento de projetos, portfólio e riscos
com diversas certificações. Foi, nos últimos 18 anos, responsável por mais de 80 projetos de
grande porte em diversos países, nas áreas de petróleo, energia, infraestrutura, telecomuni-

66 • capítulo 2
cações, informática e finanças, com um portfólio de investimentos gerenciado superior a 20
bilhões de dólares. Atualmente, é diretor do Grupo de Práticas de Projetos Sustentáveis do
Escritório de Serviços de Projetos das Nações Unidas (UNOPS, na sigla em inglês) em Co-
penhagen, na Dinamarca. Seu trabalho tem como foco a melhoria da gestão dos projetos hu-
manitários, de construção da paz e de desenvolvimento de infraestrutura em dezenas de paí-
ses, como Haiti, Afeganistão, Iraque e Sudão do Sul. Site: http://www.ricardo-vargas.com/pt/

Para reduzir custos e impactos negativos devem-se incorporar requisitos

ambientais desde o início de um projeto. Além disso, deve-se levar em conta
aspectos prioritários, tais como: características físicas e estruturais, condições
ambientais locais e regionais, requisitos legais, disponibilidade de recursos.
Para atender aos requisitos ambientais é necessário se perguntar:
1. O projeto está obrigado por lei a apresentar o Licenciamento Ambiental?
a) Como proceder em caso positivo?
2. Quais os procedimentos a serem adotados?
3. Quais os órgãos competentes para fiscalizar esses procedimentos?
4. Quais os prazos legais que devem ser observados?
5. Quem são os profissionais que têm competência legal e técnica para
desenvolver o EIA/RIMA?
6. Quanto custará ao projeto?

CONCEITO
Definição Licenciamento ambiental
Procedimento administrativo pelo qual o órgão ambiental competente licencia a localiza-
ção, instalação, ampliação e a operação de empreendimentos e atividades utilizadoras de re-
cursos ambientais, consideradas efetiva ou potencialmente poluidoras ou daquelas que, sob
qualquer forma, possam causar degradação ambiental, considerando as disposições legais e
regulamentares e as normas técnicas aplicáveis ao caso.

capítulo 2 • 67
 CONCEITO
Definição EIA/RIMA
Segundo o art. 3º da Resolução CONAMA nº 237/97, a Licença Ambiental para em-
preendimentos e atividades consideradas efetiva ou potencialmente causadoras de significa-
tiva degradação do meio dependerá de prévio Estudo de Impacto Ambiental e respectivo Re-
latório de Impacto sobre o Meio Ambiente (EIA/RIMA), ao qual se dará publicidade, garantida
a realização de audiências públicas, quando couber, de acordo com a regulamentação. Por
outro lado, o órgão ambiental competente, verificando que a atividade ou empreendimento
não é potencialmente causador de significativa degradação do meio ambiente, definirá os
estudos ambientais pertinentes ao respectivo processo de licenciamento.

ATENÇÃO
A área de conhecimento em gerenciamento ambiental do projeto inclui os processos internos
e externos e as consequentes atividades desses processos que são necessárias para que o
projeto cause o mínimo impacto possível ao Meio Ambiente onde ele será desenvolvido. O refe-
rencial teórico para a consolidação desse gerenciamento ambiental é o conceito de sustentabi-
lidade ambiental da Comissão Mundial Sobre Meio Ambiente e Desenvolvimento (Organização
das Nações Unidas – ONU), que no Relatório Brundtland de 1987 definiu o Desenvolvimento
Sustentável como sendo “O desenvolvimento que satisfaz as necessidades presentes, sem
comprometer a capacidade das gerações futuras de suprir suas próprias necessidades”. Deste
modo, o conceito de sustentabilidade ambiental é o foco desse gerenciamento, em que todas
as demais áreas do gerenciamento do projeto serão transversalmente afetadas.” (disponível em
http://www.ricardo-vargas.com/pt/articles/gerenciamento-ambiental)

Uma vez que a etapa de coleta de requisitos é encerrada, pode-se partir para a
etapa de definição de escopo.

Definir o escopo
A definição de escopo envolve a preparação de uma declaração de escopo
detalhada para o projeto, que envolve a identificação de qual o trabalho a ser
realizado e os responsáveis, o dimensionamento dos pacotes de trabalho, ou

68 • capítulo 2
work packages (WP) e a criação de um dicionário que explique os aspectos téc-
nicos da EAP. Entre os aspectos positivos da definição de escopo estão:
•  obriga os stakeholders a concordarem com as fronteiras do projeto;
•  durante a execução, permite identificar as mudanças que estão fora do
escopo do projeto e requerem renegociação do contrato original;
•  ajuda a estabelecer critérios que mensurem o sucesso do projeto,
•  de forma que todos os envolvidos os conheçam e estejam de acordo;
•  auxilia a compreensão da equipe de projeto sobre as abordagens e méto-
dos utilizados no projeto.

É importante destacar que como o escopo de projeto serve de base para vá-
rias decisões no projeto, deve-se ter muito cuidado com o que está incluído e o
que não está antes de iniciar a execução. A definição correta sobre o que deve
estar incluído no escopo do projeto e também seu gerenciamento é ilustrado na
história representada na figura 2.2:

Como o Como o Consultor

Como o cliente Como o lider de Como o analista
programador de negócios
explicou... projeto entedeu... projetou...
construiu... descreveu...

Como o projeto Que funcionalidades Como o cliente Como foi O que o cliente
foi documentado... foram instaladas... foi cobrado... mantido... realmete queria...

Figura 2.2  –  Exemplo do mau gerenciamento de escopo em um projeto de software. Fonte:

imagem cedida por Creative Commons, disponível em: http://www.projectcartoon.com

capítulo 2 • 69
 No exemplo da figura 2.2 é possível perceber que o mau gerenciamento do
escopo leva o projeto a desperdiçar recursos e não atingir seus objetivos, tor-
nando o cliente insatisfeito. Isto acontece porque o escopo de trabalho é o “co-
ração” do gerenciamento de projetos, sendo que todas as outras áreas, em al-
gum ponto dependem de sua correta definição.
A declaração de escopo deve estar clara inclusive em termos contratuais,
pois o cliente pode esperar que o projeto apresente mais do que está sendo feito
ou a equipe pode estar trabalhando em algo que não agrega valor e que o cliente
não precisa, por isso torna-se fundamental definir corretamente o escopo.
A definição de um escopo deve conter os fatores mostrados na figura 2.3

Objetos do Projeto;

Premissas e Retrições;

Lista das entregas e seus requisitos;

Estrutura Analítica do Projeto;

Fora do escopo do projeto (O que não incluido no projeto);

Critérios de aceitação do projeto.

Figura 2.3  –  Elementos da declaração do escopo.

Os objetivos do projeto são critérios quantificáveis que devem ser encon-

trados no projeto para que ele seja considerado um sucesso. Os objetivos do
projeto devem incluir, no mínimo, custo, cronograma e medidas de qualidade.
Os objetivos do projeto devem ter um atributo (por exemplo, custo), uma me-
dida (por exemplo, US$ dólar) e um valor absoluto ou relativo (por exemplo,
menos que 1,5 milhões). Objetivos não quantificáveis (por exemplo, “satisfação
dos clientes”) representam alto risco para um término do projeto com sucesso.
As restrições do projeto s restrições são fatores que limitarão as opções da
equipe de gerência do projeto. Por exemplo, um orçamento pré-definido é uma

70 • capítulo 2
restrição que na maioria das vezes limita as opções da equipe com relação a
escopo, pessoal e prazos.
Quando um projeto é desenvolvido sob contrato, as cláusulas contratuais
serão geralmente restrições. Outro exemplo é uma exigência de que o produto
do projeto seja sustentável do ponto de vista social, econômico e ambiental, o
que trará repercussões no escopo, na equipe e no prazo do projeto. Caso haja
quebra de contrato ou o projeto gaste mais que o orçamento previsto, há risco
de cancelamento do projeto.
Premissas ou suposições são fatores que, para os propósitos do planejamen-
to, são consideradas verdadeiros, reais, ou certos. As premissas afetam todos os
aspectos do planejamento do projeto e são parte da elaboração progressiva do
projeto. As equipes de projetos frequentemente identificam, documentam e
validam premissas como parte de seu processo de planejamento. Por exemplo,
se a data na qual uma pessoa chave estará disponível para o projeto é incerta, a
equipe pode assumir uma data de início específica. Podem ser organizacionais,
ambientais e externas.
Podem ser consideradas como as “cláusulas contratuais” que se não forem
cumpridas, comprometem o sucesso do projeto, ou aquilo que você quer exigir
das partes interessadas.
Por exemplo: Disponibilidade de 50% do tempo do cliente durante os testes.
Se o cliente não estiver disponível 50% do tempo, o prazo, provavelmente, não
será cumprido.
A lista das entregas e seus requisitos envolvem definição de subprodutos.
Subprodutos do projeto constituem uma lista de nível sumário dos subpro-
dutos que entregues total e satisfatoriamente indicam o término do projeto.
Por exemplo, os principais subprodutos para um projeto de desenvolvimento
de software devem conter o código de trabalho do computador, um manual
do usuário e um tutorial interativo. Quando conhecidas, exclusões devem
ser identificadas, mas alguma coisa não incluída explicitamente está excluí-
da implicitamente.
A estrutura analítica do projeto (EAP) será tratada detalhadamente
e separadamente.
Em projetos de tecnologia da informação, especificar o que está fora do es-
copo é quase tão importante quanto especificar o que está dentro, devido aos
requisitos de contexto e requisitos não funcionais dos softwares).

capítulo 2 • 71
 Por último, dentro da definição ou declaração de escopo, temos a definição
de critérios, inclusive requisitos de desempenho e condições essenciais, que
devem ser atendidos antes que as entregas do projeto sejam aceitas

Técnicas e ferramentas para definição do escopo

1. Análise do produto. A análise do produto envolve desenvolver um me-

lhor entendimento do produto do projeto. Isso inclui técnicas como a análise
de decomposição do produto, engenharia de sistemas, engenharia de valor,
análise de valor, análise de funções e desdobramento das funções de qualidade.
2. Análise de custo/benefício. A análise de custo/benefício envolve estimar
custos tangíveis e intangíveis (outlays – gastos) e benefícios (returns - receitas)
das várias alternativas de projeto e produto e, então, usar medidas financeiras
tais como retorno de investimento ou período de reembolso para avaliar a qua-
lidade relativa das alternativas identificadas.
3. Identificação de alternativas. Este é um termo genérico para qualquer
técnica usada para gerar diferentes abordagens do projeto. Existem várias téc-
nicas de gerenciamento freqüentemente usadas aqui, sendo as mais comuns o
brainstorming e o lateral thinking (pensamento lateral).
4. Avaliação especializada. Uma avaliação especializada é, frequente-
mente, requerida para avaliar as entradas desse processo. Tal habilidade pode
ser provida por um grupo ou indivíduo com conhecimento especializado ou
treinamento, e está disponível em várias fontes, por exemplo:
•  Outras unidades dentro da organização.
•  Consultores.
•  Partes envolvidas, incluindo clientes.
•  Associações profissionais e técnicas.
•  Grupos industriais.

Estrutura Analítica do Projeto – EAP

A EAP é a estrutura analítica do projeto. Embora em um primeiro momen-

to o nome em português desta ferramenta possa parecer estranho, quando
analisamos o nome em inglês fica mais fácil entender qual é a proposta des-
ta ferramenta.

72 • capítulo 2
 WBS é o termo em inglês referente a EAP e significa work breakdown struc-
ture, que quer dizer:
Work: esforço físico ou mental sustentável para transpor obstáculos e atin-
gir um objetivo;
Breakdown: divisão em partes ou categorias. Decompor em partes menores;
Structure: algo organizado de forma padronizada ou formalizada.
Assim fica mais fácil de entender que a EAP e a decomposição (breakdo-
wn) hierárquica (structure) orientada a entrega do trabalho (work) do escopo
do projeto.
Esses trabalhos devem ser executados pela equipe do projeto para atingir os
objetivos do projeto. A decomposição dos trabalhos em partes menores serve
para torná-los mais gerenciáveis.
A EAP é uma ferramenta gráfica, então a decomposição hierárquica do tra-
balho do projeto acontece por meio de retângulos e interligações desses retân-
gulos para formar a hierarquia de trabalho.
Para a criação de uma EAP é comum o uso da técnica de decomposição que
sugere a subdivisão das entregas de trabalhos em componentes menores e mais
facilmente gerenciáveis de forma que, em processos futuros do ciclo de vida de ge-
renciamento de projetos, o tempo e o custo possam ser estimados de forma con-
fiável. Este último nível de entrega de trabalho é chamado de pacote de trabalho.
Uma boa prática para se desenhar uma EAP é partir de um retângulo prin-
cipal que recebe o nome do projeto; em seguida, como filhos desse retângulo,
são desenhadas as fases do projeto, e, como filhos dessas fases, são desenhados
os pacotes de entregas intermediários e, por fim, como filhos dos pacotes in-
termediários, são desenhados os pacotes de trabalho que devem ser entregues,
como mostra a figura 2.2.
A decomposição do trabalho total do projeto normalmente envolve as se-
guintes atividades: identificar as entregas de trabalhos relacionadas; estrutu-
ração e organização da EAP; decomposição dos níveis mais altos da EAP em
níveis mais baixos; desenvolvimento e atribuição de códigos de identificação
aos componentes da EAP; verificar se o grau de decomposição é necessário
e suficiente.

capítulo 2 • 73
 CONEXÃO
Este vídeo, de Ricardo Vargas, explica a construção da EAP de maneira bastante didáti-
ca. Endereço: https://www.youtube.com/watch?v=TS9eciG-Ddw

Produto
Software Versão 5.0
Ciclo de Vida do Projeto

Gerenciamento Requisitos Projto Integração

Construção
do projeto do produto detalhado e teste

Planejamento Software Software Software Software

Documentação Documentação Documentação Documentação

Reuniões do usuário do usuário do usuário do usuário

Materiais dos Materiais dos Materiais dos Materiais dos

Administração programas de programas de programas de programas de
treinamentos treinamentos treinamentos treinamentos

Figura 2.4  –  Exemplo simplificado de uma EAP organizada por fases de um projeto de de-
senvilvimento de software (adaptado de PMBOK, 2008).

Entretanto, até onde se deve “quebrar” o trabalho do projeto na EAP, ou seja,

qual seria o tamanho ideal do pacote de trabalho, o quão específico ele pode ser?
Segundo Ricardo Vargas, há uma regra de ordem prática chamada “4/40 e
8/80” que significa que um pacote de trabalho deve ter no mínimo entre 4-8h e
no máximo entre 40-80h. Já para o professor Josué Silva, referenciado no link
de multimídia a seguir, o momento de parar de decompor a atividade é quando
é possível lhe atribuir uma pessoa responsável.
Outro ponto interessante de se notar é que há duas formas de se orientar a
construção de uma EAP: EAP orientada a entrega e EAP orientada a tarefas. A
primeira diz respeito a organizar a EAP orientada a pacotes de entrega, ou seja,
entregáveis. A segunda diz respeito a organizar a EAP orientada a tarefas, ou
seja, a atividades que devem ser executadas para entregar o projeto.

74 • capítulo 2
 CONEXÃO
Técnicas para geração da EAP - https://www.youtube.com/watch?v=qQQ5RHuDA6A

Para que não haja nenhum tipo de ambiguidade ou mais de uma interpre-
tação, quando da elaboração de uma EAP, é necessária a criação de um dicio-
nário, de forma que todos os termos descritos dentro das caixas da EAP sejam
claros. O dicionário da EAP pode servir como parte de um sistema de autoriza-
ção de trabalho descrevendo para os integrantes da equipe cada componente
da estrutura analítica do projeto e pode ser usado para controlar quando um
trabalho específico é realizado de modo a evitar aumento do escopo e aumento
da compreensão das partes interessadas sobre o esforço necessário para cada
pacote de trabalho. A figura 2.3 ilustra um exemplo de dicionário de EAP.

Processos de definição e documentação das deci-

1.1.6 Gestão de compras e aquisições sões de compras do projeto especificando a aborda-
gem e identificando fornecedores em potecial.
O gerenciamento de custos inclui processos envol-
vidos em estimativa, orçamentação e controle de
1.1.7 Gestão de custos
custos de modo que seja possível concluir o projeto
dentro do orçamento aprovado.
1.2 Execução do projeto Fase
Nessa etapa será realizada análise junto a usuários
1.2.1 Análise do sistema para definição da customização a ser realizada além
da definição de ferramentas e distribuição da equipe.
Etapa de desenvolvimento de rotinas e programas
1.2.2 Desenvolvimento e customização
definidos para customização do sistema.
1.2.3 Efetuar aquisições Compra de equipamentos e contratação de um DBA.
Nessa etapa será realizada a implantação e confi-
1.2.4 Montagem da infraestrutura guração de software e hardware para a implantação
do sistema.
Nessa etapa será realizado a implantação do novo
1.2.5 Implantação do controle de estoque
sistema.
Nessa etapa será definido o cronograma de treina-
1.2.3 Treinamento mentos, elaboração e distribuição dos manuais e a
execução dos treinamentos.
Auditoria dos processos e encerramento oficial do
1.2.4 Encerramento
projeto.
Planejamento e execução do controle do monitora-
1.3 Acompanhamento
mento do projeto.

Tabela 2.7  – 

capítulo 2 • 75
Verificação do escopo

Verificação do escopo é o processo de obter o aceite formal do escopo do proje-

to pelas partes envolvidas (patrocinador, cliente, freguês e etc.). Isto exige uma
revisão dos produtos e resultados do trabalho para garantir que tudo foi com-
pletado correta e satisfatoriamente. Se o projeto terminar mais cedo, o proces-
so de verificação do escopo deve estabelecer e documentar o nível e extensão
da complexidade. A verificação do escopo difere do controle da qualidade já
que é fundamentalmente relacionada com a aceitação do resultado do traba-
lho enquanto o controle da qualidade é fundamentalmente relacionado com a
exatidão dos resultados do trabalho. Assim para o mesmo trabalho executado
busca-se tanto a exatidão quanto a aceitação do escopo.

REFLEXÃO
A verificação do escopo é um processo contínuo que visa garantir que todas as atividades
sejam realizadas corretamente e satisfatoriamente.

Uma das técnicas utilizadas para verificação do escopo é a inspeção. Essa

técnica inclui atividades tais como medição, exames e testes incumbidos de
determinar se os resultados estão de acordo com as exigências. As inspeções
são, diferentemente, chamadas de revisões, revisões de produto, auditoria, e
ensaios (walk-throughs); em algumas áreas de aplicação esses diferentes ter-
mos têm significado estreito e específico.
A saída essencial da verificação do escopo é o documento de aceitação for-
mal, que consiste na documentação de que o cliente ou patrocinador aceitou
o produto do projeto ou da fase deve ser preparada e distribuída. Tal aceitação
pode ser condicional, especialmente no fim de uma fase.

Controle do Escopo

O controle de mudanças do escopo consiste em: influenciar os fatores que

criam mudanças no escopo para garantir que as mudanças sejam discutidas
e combinadas; determinar que uma mudança no escopo ocorreu, e gerenciar
as mudanças efetivas quando ocorrerem. O controle das mudanças do escopo

76 • capítulo 2
deve se integrar aos demais processos de controle (controle de prazo, controle
de custo, controle de qualidade, e outros) (PMBOK, 2008).
O controle de escopo geralmente faz uso do sistema de controle de mudan-
ças, que define os procedimentos necessários para efetuar mudanças no esco-
po do projeto e inclui a documentação e os níveis de aprovação necessários em
cada caso. Para realizar este tipo de controle é preciso ter uma clara visão sobre
os detalhes do escopo do projeto (envolvendo o plano de gerenciamento de es-
copo), de forma a entender de forma inequívoca a origem da mudança e seus
efeitos (MULCAHY, 2007).
O “controle” em qualquer área de conhecimento nada mais é do que a cor-
reção de desvios, ou seja, sempre que o trabalho se distanciar daquilo que foi
planejado anteriormente (linha de base ou baseline). Assim, sempre que neces-
sário o trabalho é refeito ou redirecionado.
Um sistema de controle de mudanças do escopo:
•  Define os procedimentos para efetuar mudanças no escopo do projeto e
no escopo do produto.
•  Inclui a documentação, os sistemas de acompanhamento e os níveis de
aprovação necessários para autorizar mudanças
•  Quando o projeto é gerenciado sob um contrato, o sistema de controle de
mudanças também fica de acordo com todas as cláusulas contratuais relevantes;

O sistema de controle de escopo depende também das seguin-

tes documentações
1. Estrutura de decomposição de trabalho, que define o baseline do esco-
po do projeto
2. Relatórios de desempenho. Os relatórios de desempenho fornecem
informações sobre o desempenho do escopo tais como quais produtos inter-
mediários foram completados e quais não o foram. Relatórios de desempenho
podem, também alertar a equipe do projeto para questões que podem causar
problemas no futuro.
3. Requisições de mudança. As requisições de mudanças podem ocorrer
de muitas maneiras – oral ou escrita, direta ou indireta, iniciada externa ou in-
ternamente, e legalmente imposta ou opcional. As mudanças podem exigir a
expansão do escopo ou podem permitir que seja reduzido. A maioria das de-
mandas de mudança é resultado de:

capítulo 2 • 77
 •  Um evento externo (por exemplo, uma mudança em uma regulamen-
tação governamental).
•  Um erro ou omissão no detalhamento do escopo do produto (por
exemplo, não incluir uma característica necessária no projeto de um siste-
ma de telecomunicação).
•  Um erro ou omissão no detalhamento do escopo do projeto (por
exemplo, usar uma lista de material (BOM) em vez de usar uma estrutura
analítica do projeto (EAP).
•  Uma mudança no valor agregado (por exemplo, um projeto de recu-
peração ambiental é capaz de reduzir custos através do uso de uma tecno-
logia que não estava disponível quando o escopo do projeto foi original-
mente definido).
•  Implementação de um plano de contingência, ou “workaround”, du-
rante a ocorrência de um evento de risco.

4. Plano de gerência do escopo. Como resultados do sistema de controle

de escopo podemos ter:
I. Mudanças do escopo. Uma mudança do escopo é qualquer modi-
ficação no escopo combinado do projeto, conforme definido pela EAP
aprovada. As mudanças do escopo do projeto, frequentemente, exigem
ajustes no custo, no prazo, na qualidade ou em outros objetivos do pro-
jeto. Mudanças do escopo são retornos (feedback) ao longo do processo
de planejar, os documentos técnicos e de planejamento são atualizados
conforme necessidade, e as partes envolvidas são informadas conforme
for apropriado.
II. Ações corretivas. A ação corretiva é tudo aquilo que é feito para com-
patibilizar o desempenho futuro da programação com o plano do projeto.
III. Lições aprendidas. As causas das variações, as razões por trás da
ações corretivas tomadas, e outros tipos de lições aprendidas do controle
de mudanças do escopo, devem ser documentadas para que estas infor-
mações se integrem a um banco de dados histórico tanto para o projeto
em andamento quanto para outros projetos da organização.
IV. Baseline ajustado. Dependendo da natureza da mudança, o baseli-
ne correspondente (prazo, custo, etc) pode ser revisado e re-emitido com
o objetivo de refletir a alteração aprovada e criar um novo baseline para
futuras mudanças.

78 • capítulo 2
 REFLEXÃO
É importante você ter em mente que um projeto gera um produto/serviço, e que depois que
esse produto/serviço é gerado, o projeto costuma findar (digo costuma, pois ainda pode
haver alguma fase de acompanhamento do produto/serviço antes do término).
Dessa forma, o ciclo de vida do projeto e o ciclo de vida de gerenciamento de projetos
também terminam, continuando, agora, o ciclo de vida do produto, o qual poderá gerar vários
outros projetos.
A confusão com o jogo de palavras acima já não deve mais ser problema para você
depois de tudo o que conversamos nesta unidade. Mas se ainda for, recomendamos que
você volte ao início da unidade e a leia novamente. E ainda recomendamos que você envie
mensagem ao professor e participe dos plantões para tirar suas dúvidas.

LEITURA
Desta vez, não iremos recomendar a você a leitura de um determinado texto ou recomendar
um determinado podcast. Vamos fazer um pouco diferente e um pouco mais divertido.
Gostaríamos, na verdade, de recomendar que você assista a dois filmes de grandes su-
cessos, a saber: Onze homens e um segredo e Vida de inseto.
Onze homens e um segredo é um filme de ação da Warner Bros. Estrelado por George
Clooney e Brad Pitt, que fazem papel de ladrões profissionais que empreendem, na ocasião,
u assalta a um casino em Las Vegas. O grande “barato” deste filme para nós, na disciplina
de gerenciamento de projetos, é que o assalto ao casino na verdade é um projeto muito bem
planejado e executado e vale a pena assistir com o olhar de um gerente de projetos.
Já o filme Vida de inseto é uma animação dos estúdios Disney e mostra o empreendi-
mento de uma pequena formiga contra grandes gafanhotos. Para nós, o filme é importante,
pois mostra como erros de comunicação podem trazer grandes prejuízos ao projeto.
Bom filme, pessoal!

ATIVIDADES
Desenvolvemos, a seguir, um conjunto de perguntas para que você possa fixar o conteúdo
aprendido neste capítulo. Responda às perguntas abaixo utilizando como base tudo aquilo
que você estudou neste capítulo, nas conexões apresentadas e utilizando o conhecimento

capítulo 2 • 79
que você já possui de vivências profissionais ou de estudos de módulos passados referentes
ao mundo coorporativo.

01. Os processos dos grupos de processos do ciclo de vida de gerenciamento de projetos

mostrados pelo PMBOK também podem ser classificados em áreas de conhecimento. Quais
são elas?

02. Qual é a importância da área de conhecimento de integração?

03. O que é gerenciamento do escopo e por que esse processo é importante?

04. O que pode incluir uma declaração de requisitos?

05. O que é uma EAP e como ela impacta no gerenciamento de projetos?

06. O que é um pacote de trabalho?

07. Quais são os aspectos positivos da definição de escopo?

08. O que são premissas de um projeto? Dê exemplos.

REFERÊNCIAS BIBLIOGRÁFICAS
PRESSMAN, R. S. Engenharia de software. USA: McGrawHill, 2006.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania:
s.n., 2004.
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania:
s.n., 2008.
SOMMERVILLE, I. Engenharia de software. Rio de Janeiro: Addison Wesley, 2003.
VARGAS, Ricardo.. Site do Ricardo Vargas. <www.ricardovargas.com.br>. Acesso em: Agosto 2015.
VIEIRA, Marconi Fábio.. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro:
Elsevier, 2007.

80 • capítulo 2
 3
Gerenciamento de
Tempo, de Custo e
Gerenciamento de
Recursos Humanos
Normalmente, os processos de gerenciamento do tempo do projeto trabalham
baseando-se nas saídas dos processos de escopo, portanto geralmente são execu-
tados após esses processos.
Isso por que o gerenciamento do tempo é determinado com base nas atividades
necessárias para a realização do projeto, que são baseadas nos pacotes de traba-
lho definidos na EAP na área de conhecimento de gerenciamento de escopo.
Em projetos de TI, o gerenciamento de tempo também se configura como uma
atividade complexa, uma vez que estimar/planejar tempo em atividades abstra-
tas, como implantação ou desenvolvimento de software, não é algo tão trivial,
muito embora a engenharia de software nos ofereça algumas técnicas, como
vamos ver a seguir.

OBJETIVOS
•  Conceituar gerenciamento de tempo, de custo e de recursos humanos
•  Identificação das atividades de cada área
•  Sequenciamento de atividades
•  Estimativas de Duração
•  Ferramentas e técnicas de refinamento e acompanhamento para elaboração do cronograma

82 • capítulo 3
3.1  Gerenciamento de Tempo
A grande demanda de projetos torna o mercado mais competitivo e complexo,
fazendo com que o gerenciamento de projetos seja uma ferramenta eficaz para
as organizações. Dentro dessa ferramenta, um dos conceitos mais importantes
é o Gerenciamento do Tempo, cuja função é controlá-lo eficientemente para
atingir os objetivos planejados pela organização. O tempo está diretamente li-
gado a três fatores: escopo, custo e qualidade. Dessa forma, qualquer mudança
em uma das variáveis citadas acima pode afetar as outras, i.e. qualquer atraso
em seu tempo de um projeto poderá influenciar na mudança de escopo.
Portanto, o gerenciamento do tempo, juntamente com o gerenciamento
de custos, segundo Vargas (2009), são as mais visíveis áreas do gerenciamento
de projeto. A grande maioria das pessoas que se interessam por projetos têm
como objetivo inicial controlar prazos, confeccionar cronogramas e redes, etc.
O principal objetivo dessa área é garantir que o projeto seja concluído dentro
do prazo determinado.
Como todos sabem, o tempo não espera! Especialmente por aquele gerente
que constrói cronogramas baseados em datas impossíveis. O cronograma do
projeto é sempre uma restrição, até mesmo quando a data de término não é crí-
tica. Se um projeto atrasa, na maioria das vezes ele irá consumir um capital que
ele não tinha provisionado, comprometendo, também, o seu custo, podendo
até mesmo causar consequências ao produto, serviço ou qualquer que seja o
resultado do projeto (VARGAS, 2009).

CURIOSIDADE
Cerca de 68% dos projetos de Tecnologia da Informação (TI) são entregues com atraso,
segundo o Standish Group. Na fase de Planejamento do Projeto são feitas as previsões,
que são baseadas em premissas, como visto no capítulo anterior. Premissas, dentro do ge-
renciamento de projetos são hipóteses admitidas como certas, sem fundamentação, para
fins de planejamento. Isso faz com que na prática o resultado não seja 100% exato. Assim,
a experiência auxiliada por melhores práticas são fatores que melhoram a proximidade da
estimativa com a realidade.

capítulo 3 • 83
 Para Valeriano (1998), uma das áreas de conhecimento de projetos que deve
ter uma administração mais rígida, é o tempo; sua gestão está diretamente li-
gada ao sincronismo das atividades envolvidas no projeto. Portanto, para que
esse possa ser concluído no tempo previsto é necessário se fazer um minucio-
so controle e acompanhamento de todas essas atividades com a elaboração de
um cronograma.
Em suma, o gerenciamento do tempo em projetos inclui os processos ne-
cessários para realizar o término do projeto no prazo previsto, o que requer
disciplina e controle eficientes, permitindo corrigir em tempo hábil os pos-
síveis problemas com prazos, objetivando impedir sua gravidade no decorrer
da execução.

Standish Group
A missão do Standish group é mudar o mundo dos projetos de software, voltado para
a maneira de como esse projetos são gerenciados. A proposta de gestão de desen-
volvimento de software resultará em um desenvolvimento de software mais rápido e
mais seguro. A filosofia do grupo é baseada em reflexão de grupos, pesquisa intensiva
e feedback constante.

Relatório CHAOS
Há 16 anos, o Standish Group estuda projetos de TI. Ao longo desse tempo, a pesqui-
sa CHAOS já estudou mais de 70 mil projetos de TI realizados.
O CHAOS Report é frequentemente citado em artigos e apresentações sobre ge-
renciamento de projetos de TI. Essa pesquisa classifica o resultado de cada projeto
de TI , de acordo com pesquisa realizada com gerentes de projeto, em uma destas
três situações:
Bem sucedido: O projeto é concluído dentro do prazo e orçamento planejados, com
todos os recursos e resultados originalmente especificados.
Deficitário: O projeto é concluído e operacionalizado, mas com atraso, acima do custo
estimado ou com menos recursos e resultados que o especificado.
Falho: O projeto é cancelado antes de ser concluído ou nunca é implementado.

84 • capítulo 3
 CONEXÃO
Consulte também a comunidade brasileira do Standish Group
Somos uma rede de informação que conecta profissionais que atuam na área de TI inte-
ressados no gerenciamento de projetos e no aprofundamento das questões práticas e teóri-
cas a ele relacionadas. O propósito dessa rede é proporcionar informações e permitir o dia-
logo sobre as pesquisas e serviços oferecidos pelo The Standish Group. The Standish Group
tem como missão apoiar você no desenvolvimento de conhecimentos e habilidades que au-
mentem suas chances de sucesso e proporcionem mais valor aos investimentos realizados
http://brazil.standishgroup.com/index.php?r=site/page&view=about

No relatório CHAOS divulgado em 2014, janelas de tempo pouco realistas e

expectativas irrealistas somam mais de 10% de fatores indicados como causas
para falhas nos projetos de TI.

FATORES QUE COMPROMETERAM OS PROJETOS % DE RESPOSTAS

Falta de dados de entrada do usuário 12,8%
Requisitos e especificações incompletas 12,3%
Mudanças em requisitos e especificações 11,8%
Falta de apoio executivo 7,5%
Incompetência tecnológica 7,0%
Falta de recursos 6,4%
Expectativas irrealistas 5,9%
Objetivos pouco claros 5,3%
Janelas de tempo irrealistas 4,3%
Nova Tecnologia 3,7%
Outras 23%

Tabela 3.1  –  Tabela relacionando a causa das falhas de projetos em TI, de acordo com rela-
tório CHAOS, 2014. Tradução livre da autora.

CURIOSIDADE
Mas por que há uma taxa tão baixa de projeto consegue ser finalizado dentro do prazo previsto?
Atrasos na conclusão comprometem o custo, retardam a entrega e consequentemente,
a disponibilidade de iniciar a utilização dos mesmos e/ou entrarem em operação. Atrasos
podem causar também em quebras de cláusulas contratuais e consequente falha do projeto.

capítulo 3 • 85
Dessa forma, o gerenciamento do tempo se mostra um processo muito importante para que
o projeto seja bem sucedido.

3.2  Processos do Gerenciamento do Tempo

Os processos de gerenciamento do tempo do projeto trabalham baseando-se
nas saídas dos processos de escopo, portanto geralmente são executados após
esses processos. Devido ao fato de quer que o gerenciamento do tempo é deter-
minado com base nas atividades necessárias para a realização do projeto, que
são baseadas nos pacotes de trabalho definidos na EAP, definida quando da
elaboração da declaração de escopo.
Em projetos de TI, o gerenciamento de tempo se configura como uma ativi-
dade complexa, uma vez que estimar e ou planejar tempo em atividades abstra-
tas, como implantação ou desenvolvimento de software, não é algo tão trivial,
muito embora a engenharia de software nos ofereça algumas técnicas, como os
pontos por função e os pontos por casos de uso.
Contudo, apesar das técnicas, uma empresa madura deve ter uma grande
base histórica de métricas para auxiliar no gerenciamento do tempo do projeto.
O gerenciamento do tempo em projetos é composto dos processos descritos na
figura 3.1.

• Definição de atividades

• Sequênciamento de atividades

• Estimativa das durações das atividades

• Desenvolvimento do cronograma

• Controle do crongrama

Figura 3.1  –  Processos de gerenciamento do tempo.

86 • capítulo 3
Definição de Atividades

O processo de definição de atividades envolve identificar e documentar as ativi-

dades específicas que devem ser realizadas para produzir os diversos níveis de
subprodutos identificados na Estrutura de Analítica do Projeto (EAP). Esse pro-
cesso deve englobar, portanto, a definição de atividades voltadas para o alcance
dos objetivos do projeto.
Além da EAP, a definição das atividades também depende da declaração do
escopo, informações histórias, restrições e as premissas. A justificativa e os ob-
jetivos do projeto contidos na declaração do escopo devem ser considerados,
explicitamente, durante a definição das atividades. As informações históricas
(que atividades foram realmente requeridas em projetos anteriores semelhan-
tes) devem ser consideradas na definição das atividades do projeto. Por último,
as restrições são fatores que limitarão as opções da equipe de gerência do proje-
to; um exemplo disso é o desejo de usar o máximo da duração de uma atividade.
Você se lembra do que é a EAP e a declaração de escopo? Em caso negativo,
consulte a seção 2.3 do Capítulo 2.

Técnicas e Ferramentas para a Definição das Atividades

A primeira ferramenta que trataremos neste capítulo é a Decomposição. Den-

tro do contexto do processo da Definição de Atividade a decomposição envolve
subdividir os pacotes de trabalho do projeto em componentes menores e mais
manejáveis para fornecer melhor controle do gerenciamento. A principal di-
ferença entre a decomposição aqui descrita e a do Detalhamento do Escopo é
que nesta as saídas são descritas como atividades (ações) em vez de subprodu-
tos (itens tangíveis). A estrutura analítica do projeto e a lista de atividades são
normalmente desenvolvidas sequencialmente, com a EAP começando as bases
para o desenvolvimento da lista de atividades final. Em algumas áreas de apli-
cação, a EAP e a lista de atividades são desenvolvidas paralelamente.
Outra ferramenta é a utilização de modelos. Uma lista de atividades, ou
uma parte de uma lista de atividades de projetos anteriores, é frequentemente
útil como modelo ou referência para um novo projeto. As atividades no modelo
também podem conter uma lista dos perfis de recursos e suas respectivas horas
de esforço, identificação dos riscos, produtos esperados e outras informações.

capítulo 3 • 87
 Uma vez definidas as atividades, deve-se ter como resultados:
•  Lista de atividades. A lista de atividades deve incluir todas as atividades
que serão realizadas no projeto. Deve ser organizada como uma extensão da
EAP para assegurar que esta está completa e que não inclui qualquer atividade
que não seja requerida como parte do escopo do projeto. Assim como na EAP, a
lista de atividades deve incluir descrições de cada atividade para garantir que os
membros da equipe do projeto entenderão como o trabalho será feito
•  Detalhamento do suporte. Os detalhes de suporte referentes à lista de ati-
vidades devem ser documentados e organizados de forma a facilitar seu uso por
outros processos da gerência do projeto. Os detalhes de suporte devem sem-
pre incluir a documentação de todas as premissas e restrições identificadas A
quantidade de detalhes adicionais varia de acordo com a área de aplicação.
•  Atualizações na EAP. Ao utilizar a EAP para identificar quais atividades
são necessárias, a equipe do projeto pode identificar a falta de algum subpro-
duto ou pode ainda determinar que a descrição dos subprodutos precisa ser
clareada ou corrigida. Qualquer uma destas atualizações deve ser refletida na
EAP e na respectiva documentação, como por exemplo a estimativa dos custos.
Estas atualizações são muitas vezes chamadas de refinamentos (refinements) e
ocorrem mais frequentemente quando o projeto envolve uma tecnologia nova
ou em desenvolvimento.

Sequenciamento de Atividades

Ao final do processo de definição de atividade, tem-se uma lista contendo to-

das as atividades planejadas que precisam ser executadas para a finalização
do projeto. Porém, essas atividades não estão cronologicamente organizadas,
ou seja, não há ainda nenhuma informação que diga qual atividade vem antes
ou depois.
Dessa forma, há a necessidade de se realizar o sequenciamento lógico das
atividades identificadas, sendo esse trabalho de responsabilidade deste proces-
so. Deve-se, primeiramente, definir qual o modelo de diagrama a ser utilizado
para fazer o sequenciamento das atividades. Independente do método escolhi-
do, é necessário determinar também o tipo de dependência entre as atividades,
que são dependência obrigatória, arbitrária e externa.
As dependências obrigatórias não podem ser mudadas, pois dependem da
natureza do trabalho. Exemplo: não se pode pintar uma parede sem rebocá-la

88 • capítulo 3
primeiramente. Já as dependências arbitrárias são baseadas em melhores prá-
ticas de mercado Exemplo: Devemos pintar a parede primeiramente e depois
instalar os carpetes, pois isso é o recomendável, uma vez que por qualquer des-
cuido poderíamos sujar os carpetes.
Por sua vez, a dependência externa depende de atividades fora do domínio
e controle do projeto. Exemplo: Contratação de quaisquer serviços de terceiros
que esteja relacionado a uma atividade do seu projeto. Uma dependência ex-
terna pode vir a provocar atrasos e problemas de qualidade no projeto se, por
exemplo, o fornecedor não for confiável e qualificado.

Estimar as durações das atividades

Uma vez definidos o planejamento de todas as atividades que deverão ser exe-
cutadas para o término do projeto e realizado o respectivo sequenciamento, os
recursos necessários para a execução das atividades estão prontos. O próximo
passo é planejar (estimar) a duração que cada atividade terá e depois colocar as
atividades dentro do calendário dos recursos montando, dessa forma, o cro-
nograma do projeto.
Estimar tempo em atividades planejadas é algo complexo em qualquer área,
mas na área de TI esta atividade é um pouco mais complicada pela característi-
ca abstrata das tarefas e seu cunho intelectual, em alguns casos quase “artísti-
cos” (por exemplo o desenvolvimento de um software científico como processa-
mento de imagem ou biotecnologia).
Por isso, é comum esse processo de estimativa de tempo das atividades seja
realizado por pessoas que estão mais acostumadas com o contexto e nature-
za do projeto (e que utilizam a experiência delas para realizar estimativas mais
confiáveis) e também é realizado em caráter progressivo, à medida que as infor-
mações necessárias para as estimativas vão ficando cada vez mais claras.
Mas, não só a “arte” e a experiência ou conhecimento tácito dos colaborado-
res são alternativas para este processo. Há técnicas sistematizadas como pontos
por função e pontos de caso de uso que podem ser utilizadas juntamente com
bases históricas para a determinação de estimativas de tamanho de software.
Para se realizar um planejamento das estimativas do projeto, deve-se: exa-
minar e consolidar bem o escopo antes de estimar os prazos do projeto; ser rea-
lista com a equipe quanto aos prazos; verificar lições aprendidas de projetos

capítulo 3 • 89
anteriores; envolver a equipe do projeto e também os clientes, se possível e con-
siderar riscos e planejar ações.
Para executar a estimativa das durações das atividades é necessário ter dis-
poníveis a lista de atividades, atributos das atividades, requisitos de ,recursos
das atividades, calendário do recurso e a declaração do Escopo do Projeto, fato-
res ambientais da empresa.

Técnicas e Ferramentas para sequenciamento de atividades

Uma das ferramentas utilizadas é a opinião de pessoas especializadas nas tare-

fas definidas. Outras técnicas passíveis de utilização são a estimativa análoga,
que admite que seja utilizada a duração real de atividades em projetos passados
como base para a estimativa de atividades parecidas no projeto atual. Por isso,
a base histórica de projetos e a opinião especializada são entradas importantes
para essa técnica. Já a estimativa paramétrica utiliza os valores unitários de pro-
dutividade por hora de trabalho (por exemplo, para se colocar o piso em uma
casa demora-se em média 10m2/dia) e os multiplica pela quantidade total do
trabalho (então, se temos 10m2 de piso para colocar em uma determinada ativi-
dade, estima-se que a atividade terá a duração de 10 dias);
A estimativa de três pontos considera três cenários para estimar o prazo. As
questões a serem feitas são:
•  Baseando-se em um cenário otimista (tudo dará certo), qual é o prazo es-
perado? Prazo otimista (Po)
•  Baseando-se em um cenário pessimista (tudo dará errado), qual é o prazo
esperado? Prazo pessimista (Pp)
•  Baseando-se em um cenário mais provável, qual é o prazo esperado? Prazo
mais provável (Pmp)
Po + 4Pmp + Pp
Prazo esperado =
6

Como dito anteriormente, o processo de estimativa é algo complexo. Por

isso, é comum a adição de reservas de tempo (ou buffers ou ainda reservas para
contingência) às estimativas para contingenciar o risco das incertezas do cro-
nograma. Essa técnica é chamada de análise de reservas.

90 • capítulo 3
 A quantidade desta reserva pode ser um número fixo por tarefa, uma por-
centagem por tarefa ou ainda pode ser adquirido por meio de uma análise utili-
zando métodos quantitativos.
O processo de estimativa das durações da atividades resulta em: estimativa
de duração das atividades e atualização dos documentos do projeto.

Desenvolvimento do cronograma

O desenvolvimento do cronograma objetiva atribuir datas (prazos) de início de

término para as atividades. Se tais datas não forem realistas, é improvável que
o projeto termine conforme planejado. O processo de desenvolvimento do cro-
nograma deve, frequentemente, ser repetido antes da determinação do cro-
nograma do projeto. Este processo é útil para definir quando cada atividade do
projeto se inicia e termina.
Para desenvolvimento do cronograma, é necessário ter disponíveis: lista de
atividades, diagrama de Rede do Cronograma do Projeto, calendários de dis-
ponibilidade de recursos, estimativa de duração das atividades; declaração do
Escopo do Projeto e fatores Ambientais da Empresa.

Ferramentas e técnicas para desenvolvimento do cronograma

•  Gráfico de Gantt
•  Método do caminho crítico – por meio dessa técnica é possível descobrir
em um gráfico de redes qual é o caminho de atividades mais longo que será
feito no projeto e aquele que terminará mais cedo. Com essa análise é possível
gerenciar o tempo de entrega do projeto aplicando então técnicas de parale-
lismo e compressão às atividades do caminho mais longo, ou seja, o caminho
crítico do projeto!
•  Aplicação de antecipações e esperas – durante o sequenciamento das ta-
refas antecipações e atrasos podem ocorrer e nesta técnica eles são ajustados.
•  Compressão do cronograma – técnicas para a redução do cronograma sem
reduzir o escopo do projeto: são analisadas as compensações entre custo e cro-
nograma em busca da redução do tempo de execução de uma dada atividade.
•  Paralelismo – descobrir no grafo de rede de atividades as atividades que
estão seriadas e tentar a execução das mesmas em paralelo para reduzir o tem-
po do caminho crítico.

capítulo 3 • 91
 •  Gráfico de Milestones
•  Baseline

Nesta disciplina, discutiremos com maior profundidade o Gráfico de

Gantt, o método do caminho crítico (CPM ou Critical Path Method), gráfico de
Milestones e a Baseline.

Gráfico de Gantt

O diagrama ou gráfico de Gantt é um gráfico usado para ilustrar o avanço das

diferentes etapas de um projeto. Os intervalos de tempo representando o início
e fim de cada fase aparecem como barras coloridas sobre o eixo horizontal do
gráfico. É possível utilizar essa ferramenta para determinar o início e o fim das
atividades individuais de um projeto.
Os passos para elaboração são: decompor o projeto em atividades discretas,
determinar a sequência destas atividades e ter uma estimativa de tempo para
cada atividade (suposta como determinística) e conhecida. Veja um exemplo de
gráfico de Gantt na figura 3.2.

Atividade Duração
5 10 15 20 25
A

Gráfico de Gantt planejado

realizado

Figura 3.2  –  Exemplo de um gráfico de Gantt.

A utilização do gráfico de Gantt tem vantagens e desvantagens, representa-

das na figura a seguir.

92 • capítulo 3
 Vantagens
- Visual/ Fácil construção
- Entendimento continuado
- Força um planejamento

Desvantagens
- Não são adequados para projetos
complexos de grande escala
- Não mostram claramente a
interdependência de atividades
- Não fornece indicador de prioridade
quando existem atividades que
concorrem por recursos

Figura 3.3  –  Vantagens e Desvantagens da utilização do gráfico de Gantt.

Método do caminho crítico (Critical Path Method – CPM)

Técnica usada para planejar e controlar as atividades necessárias para a execu-

ção de um projeto. Mostrando cada uma dessas atividades e o tempo associa-
do, é possível determinar o caminho crítico, identificando os elementos que
restringem o tempo total de projeto. Utiliza-se quando tiver que gerenciar pro-
jetos complexos e de longa duração. Mostrando cada uma dessas atividades e
o tempo associado, é possível determinar o caminho crítico, identificando os
elementos que restringem o tempo total de projeto.
Para utilização do método do caminho crítico é necessário identificar as ati-
vidades e montar o diagrama de rede do projeto, representado num grafo. Uma
atividade do Projeto é qualquer parte (discreta) deste que consome Tempo,
Recursos (capital, pessoal, materiais) ou ambos, para ser efetuada. No CPM a
duração das atividades é Determinística (variância nula). Grafo é onde as ativi-
dades do projeto são colocadas de acordo com relações de precedência
Primeiramente, vamos tratar da construção do diagrama de rede do projeto.

Método do diagrama de flecha (ADM - Arow Diagramming Method

ou Diagrama Activity on Arc - AOA).

Este é um método de construção de diagrama de rede que utiliza setas para repre-
sentar as atividades e as conecta por meio de nós que representam as dependên-

capítulo 3 • 93
cias um diagrama simples de rede lógica utilizando o ADM. Esta técnica é tam-
bém chama de atividade no arco (AOA - Activity-on-arc) . O ADM utiliza apenas
relações de dependência do tipo fim/início e pode requerer o uso de atividades
fantasmas (também chamadas de fictícias ou dummy) para definir corretamente
o relacionamento lógico. O ADM pode ser feito manualmente ou no computador.
No Diagrama de Rede, cada atividade possui um início e um fim, que são
pontos no tempo. Esses pontos no tempo são conhecidos como eventos. As ati-
vidades são representadas por setas e os eventos — ponto inicial e final — por
círculos (chamados também de nós). A seta aponta para o círculo que repre-
senta o evento final, para dar a idéia de progressão no tempo. As atividades são
representadas por números ou letras e os círculos são numerados, em ordem
crescente, da esquerda para a direita.
A B C
10 30 50

D E
F
G
1 40 70
H

I J K
20 60

Figura 3.4  –  Exemplo de um Diagrama de rede AOA.

Uma vez construído o diagrama de rede, é necessário determinar:

Tempo mais cedo de uma etapa: é o momento mais cedo em que ocorre a
conclusão de todas as atividades de que a etapa é Etapa Final ou é o momento
mais cedo em que pode ocorrer o início de qualquer das atividades de que a eta-
pa é Etapa Inicial. Utilizaremos a notação TE – time early. Para calcular o tempo
mais cedo de uma etapa j:
•  Iniciar o cálculo na etapa inicial do projeto com TE = 0;
•  Percorrer, no sentido direto, todos os arcos que de uma ou mais etapas
conduzem à etapa “j”;
•  Para cada um daqueles arcos, somar o TE da etapa-origem do arco com a
duração da atividade associada ao arco;
•  O TE da etapa “j” é igual à maior das somas calculadas.

94 • capítulo 3
 Tempo mais tarde de uma etapa: é o momento mais tarde em que ocorre a
conclusão de todas as atividades de que a etapa é Etapa Final ou é o momento
mais tarde em que pode ocorrer o início de qualquer das atividades de que a
etapa é Etapa Inicial. Utilizaremos a notação TL – time later. Para calcular o
tempo mais tarde de uma etapa “j”:
•  Iniciar o cálculo partindo do Tempo Mais Tarde da etapa final do projeto;
•  Percorrer, no sentido inverso, todos os arcos com extremo final em uma
ou mais etapas e extremo inicial na etapa “j”;
•  Para cada um daqueles arcos, subtrair ao TL da etapa de chegada do arco
a duração da atividade associada ao arco;
•  O TL da etapa “j” é igual à menor das diferenças calculadas.

Folga de uma etapa: é o intervalo de tempo em que ocorre a conclusão de to-

das as atividades de que a etapa é Etapa Final. A Folga da Etapa é igual a TL-TE.
Veja na figura 3.5 a representação gráfica dos elementos acima descritos.

Abreviatura utilizada neste livro: F;

A Folga da Etapa 10 é F10 = TL10 -TE10 = 17 – 12 = 5 unidades de tempo

TE TL 12 17

1 10 10

Figura 3.5  –  Representação gráfica de TE, TL e F.

Um exemplo muito simples de um Diagrama de Rede é o planejamento

de um jantar. A decisão de oferecer o jantar pode ser considerada a primei-
ra atividade no projeto "oferecer um jantar". O ofertante, tendo decidido po-
sitivamente pelo jantar, irá agora comprar os ingredientes e fazer uma lista
cuidadosa dos convidados. Essas duas atividades podem ocorrer ao mesmo
tempo, embora ambas só possam ter início após a decisão de oferecer o jan-
tar. Uma vez elaborada a lista de convidados, é possível enviar os convites. Por
outro lado, uma vez comprados os ingredientes, é possível preparar o jantar.
Uma vez preparado o jantar, pode-se deixar a casa em ordem para a recepção.
Segue-se a recepção aos convidados, que deve obrigatoriamente ocorrer após a
emissão dos convites e após se deixar a casa em ordem. Finalmente, recepcio-
nados os convidados, pode-se servir o jantar, e dar por encerrado o "projeto".

capítulo 3 • 95
A tabela 3.2 mostra as atividades descritas e a figura 3.5 ilustra o diagrama de
rede AOA correspondente:

ATIVIDADES
Decidir oferecer o jantar
Comprar ingredientes
Fazer lista de convidados
Fazer o jantar
Expedir os convites
Colocar casa em ordem
Recepcionar convidados
Servir o janta
ATIVIDADES
DESIGNAÇÃO
PRECEDENTES IMEDIATAS
A Nenhuma
B A
C A
D B
E C
F D
G E.F
H G

Tabela 3.2  –  Representação das atividades referentes ao planejamento de um jantar.

D
3 5

A F
1 2

G H
4 6 7 8

Figura 3.6  –  Diagrama de rede AOA representando as atividades de planejar um jantar.

Num Diagrama de Rede, denomina-se caminho a qualquer sequência de

atividades, que siga desde o nó inicial até o nó final. Na figura 3.5, por exemplo,
distinguimos dois caminhos, contendo as seguintes atividades:
Caminho 1: A B D F G H
Caminho 2: A C E G H

Chama-se de duração de um caminho à soma das durações de todas as ativida-

des que o compõem. Em um Diagrama de Rede, o caminho com a maior duração
é chamado de caminho crítico e governa o tempo de término do projeto: o tempo
de término de um projeto é igual à duração de seu caminho crítico. Qualquer atra-
so neste caminho, automaticamente determinará um atraso no projeto. As ativi-
dades do caminho crítico são chamadas de atividades críticas. Nenhuma dessas

96 • capítulo 3
atividades pode se atrasar, sem que o projeto também se atrase. Numa linguagem
típica, dizemos que essas atividades não têm folga ou, equivalentemente, que sua
folga é zero. Em outros caminhos que não o caminho crítico, as atividades podem
sofrer algum atraso sem que implicar em atraso do projeto.

EXERCÍCIO RESOLVIDO
01. Dado o Diagrama de Rede abaixo, determine:
a) os caminhos possíveis e a duração de cada um;
b) o caminho crítico e a duração esperada do projeto;
c) a folga de cada caminho, ou seja, o tempo total que as atividades do caminho podem se
atrasar sem interferir na duração do projeto.

6
C
s
ana 10
em
2 6s se
ma
H
na
A s 4s D s
ana em
ana
em s
1 8s 4
G
7
10 semanas
4 s
se B
E a na I
m s
an sem na
as 6 e ma
F 5s
3 5
12 semanas

Solução:
a) Caminhos e sua duração

Note que existem apenas quatro caminhos, cujas durações são dadas pela soma das
durações das atividades que os constituem:

CAMINHO DURAÇÃO
A–C–H 24 semanas
A–D–G 22 semanas
B–E–G 20 semanas
B–F–I 21 semanas

capítulo 3 • 97
b) Caminho, crítico e duração esperada do projeto
O caminho crítico é o de maior duração, portanto:
A —— C ——— H com 24 semanas, que é a duração esperada do projeto.

c) Folga de cada caminho

A folga de cada caminho é a diferença entre a duração do caminho crítico e a do pró-
prio caminho;

CAMINHO DURAÇÃO
A–C–H 24 – 24 = 0
A–D–G 24 – 22 = 2 semanas
B–E–G 24 – 20 = 4 semanas
B–F–I 24 – 21 = 3 semanas

Convenções para a Construção de Diagramas de Rede

O processo de construção do Diagrama de Rede para um projeto envolve, prelimi-

narmente, a especificação de todas as atividades que compõem o projeto. Esta é
uma etapa chave, que dá base à construção do Diagrama propriamente dito.
Na construção do Diagrama de Rede, cada atividade será representada por
uma seta, que se inicia e termina cm um nó. Existem diversas regras básicas
para se indicar as relações entre as atividades. Para que o seja possível reali-
zar os cálculos de TE, TL e F, é também necessário que sejam especificadas as
durações das atividades. Vejamos agora as convenções fundamentais para a
construção de um Diagrama de Rede:
1a. Cada atividade é representada por uma única seta, cujo comprimento
não precisa guardar relação com a duração da atividade.
2a. A direção da seta indica as progressões no tempo.
3a. Se uma atividade começa num evento (nó), ela só pode se iniciar depois
que todas as atividades terminando naquele evento tenham sido completadas.
4a. As atividades são identificadas, principalmente por programas de com-
putador, por seus nós inicial e final, devidamente numerados da esquerda para
a direita. Desta forma, é impróprio que duas atividades tenham os mesmos nós
inicial e final.

98 • capítulo 3
 A representação abaixo da figura 3.7, que está incorreta para efeitos práti-
cos, mostra que a atividade C só pode começar depois que tanto A quanto B
tenham sido concluídas. A representação é inconveniente, pois A e B têm os
mesmos nós inicial e final.

1 2

Figura 3.7  –  Exemplo de representação AOA incorreta.

Corrige-se tal situação criando uma atividade fantasma, com duração zero
e sem influência real no Diagrama de Rede. A atividade fantasma serve apenas
para auxiliar na individualização das atividades. Veja na figura 3.8 como a cria-
ção da atividade fantasma. C resolve o problema:
A
1 2

B 4
C

Figura 3.8  –  Rede AOA correta.

Note-se que C depende diretamente de A e de B, que por sua vez não pode se
iniciar antes que B esteja concluída. Logo, indiretamente, fica estabelecida a
relação de dependência entre C e B.
Dessa forma, a importância de se identificar o caminho crítico fundamenta-
se nos seguintes parâmetros: permitir saber, de imediato, se será possível ou
não cumprir o prazo anteriormente estabelecido para a conclusão do plano e
identificar as atividades críticas que não podem sofrer atrasos, permitindo um
controle mais eficaz das tarefas prioritárias.
Ainda, o método CPM permite priorizar as atividades cuja redução terá me-
nor impacto na antecipação da data final de término dos trabalhos, no caso de
ser necessária uma redução desta data final. Possibilita o estabelecimento da
primeira data do término da atividade e o estabelecimento da última data do
término da atividade.

capítulo 3 • 99
Gráfico de Milestones

O gráfico de milestones é uma ferramenta que permite o controle geren-

cial ao longo do projeto através da definição de pontos de checagem ou marcos
de desenvolvimento e é utilizado em conjunto e baseado no gráfico de Gantt.
Considera apenas eventos significativos de um projeto, chamados de eventos
cujas atividades tem duração zero e alocação de recurso zero.
Data
Atual
Evento Jan Fev Mar Abr Mai Jun Jul Ago
Subcontratos Assinados
Especificações Finalizadas

Projeto Revisto
Subsistema Testado
Primeira Unidade Entregue
Plano de Produção Completado

Planejado Realizado

Figura 3.9  –  Exemplo de gráfico de milestones.

Marcos ou eventos são acontecimentos significativos no desenvolvimento

do projeto e que servem de parâmetros para o controle gerencial, tais como:
1. Assinatura de contrato
2. Início de uma atividade
3. Conclusão de u ma etapa
4. Teste nos subprodutos ou no produto final.

Baseline

A linha de base do cronograma ou baseline é como uma fotografia retirada no

momento da aprovação do que foi planejado, similar a um congelamento do
cronograma planejado. É usada para avaliar a evolução do projeto monitoran-
do o prazo através da comparação do planejado com o realizado. O gerente de
projeto deve entender as causas das alterações do cronograma e influenciá-las
sempre que possível.
A linha de base do cronograma também ajuda o GP a negociar as mudanças
solicitadas demonstrando o impacto que ocorrerá no prazo do projeto.

100 • capítulo 3
Controle do cronograma

O controle do cronograma é uma função contínua e essencial na gestão do pro-

jeto durante toda sua trajetória. Isso possibilitará identificar-se a necessidade
de tomadas de ações corretivas, quando forem verificados desvios negativos ou
tendências dos mesmos virem a ocorrer, em relação ao que foi planejado.

Sistema de controle de mudanças do cronograma

O sistema de controle de mudanças do cronograma define os procedimentos

pelos quais o cronograma do projeto pode ser mudado. Isto inclui manuais,
sistemas de acompanhamento, e níveis de aprovação para que as mudanças
necessárias sejam autorizadas. O controle de mudanças do cronograma deve
estar integrado com o sistema integrado de controle de mudança. Ferramentas
para realizar o controle do cronograma de um projeto incluem:
Medição do desempenho. As técnicas de medição de desempenho ajudam
a determinar a magnitude de quaisquer variações que ocorram. Uma parte im-
portante do controle de mudanças no cronograma é decidir se a variação do
cronograma exige uma ação corretiva. Por exemplo: um grande atraso em uma
atividade que não é crítica pode ter um efeito pequeno no projeto total, enquan-
to pequenos atrasos em atividades críticas ou “quase” críticas podem requerer
ações imediatas.
Planejamento adicional. Poucos projetos se desenvolvem exatamente de
acordo com o plano. As mudanças em perspectiva podem requerer novas ou re-
visadas estimativas de duração das atividades, modificações na seqüência das
atividades ou análise de cronogramas alternativos.
Softwares de gerência de projeto. Os softwares de gerência de projeto estão
descritos A capacidade dos softwares de gerência de projetos para acompanhar
as datas planejadas versus as datas reais e prever os efeitos de mudanças no
cronograma, reais ou potenciais torna-os uma ferramenta útil para o controle
do cronograma.
Análise de variação. A execução do processo da análise de variação durante
a monitoração do cronograma é o elemento chave para o controle do tempo.
A comparação das datas alvos com as realizadas de início e fim, nos fornece
informações úteis para a detecção de desvios e para a implementação de ações
corretivas em caso de atraso. As etapas comuns são:

capítulo 3 • 101
 1. Verificar qualidade das informações coletadas;
2. Determinar variações entre real x linha de base;
3. Usar equações específicas para quantificar as variações;
4. Determinar impacto das variações nos custos e no cronograma;
5. Analisar tendências das variações e documentar quaisquer desco-
bertas sobre fontes de variação e área de impacto.

3.3  O Gerenciamento de Custo

O gerenciamento de custos tem como objetivo garantir que o capital disponí-
vel será suficiente para obter todos os recursos para se realizar os trabalhos do
projeto. Portanto, o gerenciamento de custos não pode considerar apenas os
cursos incorridos no próprio projeto. Muitas vezes, o projeto está desenvolven-
do um produto, ou serviço, com interesse comercial, e, esse produto, segundo
Vargas (2009), por sua vez, estará recompensando financeiramente a empresa,
retornando tanto o dinheiro investido quanto o lucro desejado, estabelecido na
concepção do projeto.
Fim das receitas ou
Morte do Produto

$k
empreendimento
Lucro final do

$w
Retorno acumulado

$x
al
ion
rac
Ope

l
ona
eita

aci
Rec

Início da Comercialização
per
O
ro
Luc

y meses z meses t meses

Investimento acumulado

Tempo
Breakeven
Inv

Fim da Vida Comercial

est

(tempo de retorno)= z meses

im

do Produto
en
to
noP

Investimento Total
roj
eto

no Projeto $x
$x

Figura 3.10  –  Ciclo financeiro de vida de um projeto Fonte: Vargas (2009).

102 • capítulo 3
 Na figura anterior, tem-se em um primeiro momento, o ciclo de investimen-
tos no projeto. O custo total do projeto é de $x e seu prazo de desenvolvimento é
de y meses. Após esse período, inicia-se, imediatamente, a comercialização, ob-
tendo uma receita conforme a curva superior do gráfico e um lucro operacional
dado pela segunda curva dos retornos acumulados. Quando o lucro operacio-
nal acumulado atinge $x, tem-se o Breakeven1 do projeto, ou seja, o tempo que
o projeto leva para se pagar, que é dado por z meses a partir do início do projeto,
ou z-y meses a partir do início da comercialização do produto (VARGAS, 2009).
Após esse período, o projeto passa a ter um lucro real, determinado pelo valor do
lucro operacional que superar $x. Porém o produto desenvolvido também tem um
ciclo de vida comercial e após um tempo t, o produto se deteriora comercialmente,
tendo alcançado uma receita operacional final de $k, um lucro operacional total de
$w e um lucro final do empreendimento (resultado) de $(w-x) (VARGAS, 2009).
Outro aspecto importante com relação ao gerenciamento de custos diz respeito
aos orçamentos. O orçamento não pode ser considerado simplesmente como uma
visão do plano. Ele é um mecanismo poderoso de controle. O orçamento serve como
parâmetro de comparação, uma linha de base da qual se extraem informações sobre
o desempenho financeiro do projeto. O orçamento precisa ser validado ao longo do
tempo, durante a execução do projeto (controle de custos), para que os eventuais pro-
blemas sejam identificados o mais cedo possível par que a solução possa ser anteci-
pada, evitando-se assim, danos mais graves ao orçamento (VARGAS, 2009).
Muitas vezes, o gerenciamento de custos propicia um processo de recom-
pensa para os envolvidos no projeto, através de participação nos seus resulta-
dos. Nesses casos, o controle de custos merece uma atenção especial, sendo
talvez alvo de um processo de orçamento paralelo, de modo a garantir que eles
reflitam o real resultado do projeto.
As maiores causas de falhas no gerenciamento de custos podem ser atribuí-
das a elementos externos ao processo isolado de custos, como por exemplo:
•  interpretação errada do trabalho a ser realizado;
•  omissão na definição do escopo do trabalho;
•  cronograma pobremente definido ou excessivamente otimista;
•  fracasso na avaliação de riscos;
•  estrutura analítica do projeto (WBS) mal definida;
•  parâmetros de qualidade mal estabelecidos;
•  fracasso na estimativa dos custos indiretos e administrativos do projeto.
1  Break Even do projeto:

capítulo 3 • 103
3.3.1  Processos de Gerenciamento de Custos

O gerenciamento do custo do projeto inclui os processos envolvidos em pla-

nejamento, estimativa, orçamentação e controle de custos de modo que seja
possível terminar o projeto dentro do orçamento aprovado. (PMI, 2012).
Segundo o PMBOK (2008), o gerenciamento de custos é responsável por ge-
renciar os custos dos recursos que são necessários para finalizar todas as ativi-
dades planejadas no gerenciamento de escopo e tempo.
Do que foi dito acima, podemos concluir que o gerenciamento de custo está
fortemente ligado a um bom gerenciamento de escopo e tempo.
Para realizar o gerenciamento de custo de projetos, o PMBOK (2008) traz 3
processos, sendo 2 de planejamento e 1 de monitoramento e controle, a saber:
1. Estimar os custos;
2. Determinar o orçamento;
3. Controlar os custos.

3.3.1.1  Estimar os custos

Este processo faz parte do grupo de processos de planejamento.

A estimativa dos custos da atividade do cronograma envolve o desenvolvi-
mento de uma aproximação dos custos dos recursos necessários para terminar
cada atividade do cronograma. (PMBOK, 2004).
Neste processo é que cada atividade do cronograma recebe uma estimativa
do custo necessário para a sua execução.
Assim como outras estimativas, a precisão da estimativa de custo aumen-
ta conforme as informações disponíveis vão aumentando, sendo que nas fases
iniciais de planejamento do projeto uma possível faixa de erro seria de –50% a
100% , e em fases posteriores essa faixa reduzir-se-ia para –10% a +15%.

3.3.1.2  Determinar o orçamento

Este processo faz parte do grupo de processos de planejamento

A orçamentação envolve a agregação dos custos estimados de atividades
do cronograma individuais ou pacote de trabalhos para estabelecer uma linha
base dos custos totais para a mediação de desempenho do projeto. (PMBOK,
2004 e 2008).

104 • capítulo 3
 Basicamente, a orçamentação é a soma dos custos das atividades indivi-
duais, já incluindo as reservas de contingências para formar a linha base de
custo do projeto.
Ainda, a orçamentação pode incluir as reservas de gerenciamento, que es-
tão fora da linha base do projeto e servem para contingenciar eventos “desco-
nhecidos, desconhecidos”.

3.3.1.3  Controlar os Custos

Este processo faz parte do grupo de processos de monitoramento e controle.

O controle de custos do projeto procura as causas das variações positivas e
negativas e faz parte do controle integrado de mudanças. (PMBOK, 2004 e 2008).
Esse processo tem como responsabilidade gerenciar todas as mudanças
que acontecem no baseline de custo do projeto, bem como gerenciar os fatores
que podem criar mudanças neste baseline.
As técnicas utilizadas para o controle de custos são bem avançadas e dignas de
um curso extra só para elas. No contexto desta disciplina, vamos apenas citá-las.

3.3.2  Fatores Importantes

No gerenciamento de custos, é importante que se atente para os seguintes

fatores:
•  em projetos sob contrato, é importante diferenciar estimativas de cus-
tos de precificação: custos são resultantes das necessidades de recursos,
etc., do projeto, enquanto o preço é uma decisão de estratégia de negócio
da organização;
•  qualquer estimativa de custos deve vir acompanhada por sua memória
de cálculo;
•  bancos de dados comerciais sempre podem ser utilizados na estimativa
de recursos e custos, bem como os registros obtidos em projetos anteriores;
•  muitas empresas patrocinam seus projetos, mesmo com os custos não
sendo recuperados, porque têm interesse em atingir uma meta de longo prazo
para a organização.

capítulo 3 • 105
3.3.3  Plano de Gerenciamento de Custos

O Plano de Gerenciamento de Custos é auxiliar ao plano de projeto que des-

creve os procedimentos que serão utilizados para gerenciar todos os custos do
projeto. No plano, segundo Vargas (2009), deve estar documentado:
•  título do projeto;
•  nome da pessoa que elaborou o documento;
•  descritivo dos processos de gerenciamento de custos (regras gerais);
•  descrição das reservas gerenciais e da autonomia em sua utilização;
•  sistema de controle de mudanças de prazos (Time Change Control System);
•  frequência de avaliação do orçamento do projeto e das reservas gerenciais;
•  alocação financeira das mudanças no orçamento;
•  nome do responsável pelo plano;
•  frequência de atualização do plano de gerenciamento de custos;
•  outros assuntos relacionados ao gerenciamento de custos não previstos
no plano;
•  registro de alterações no documento;
•  aprovações.

CONEXÃO
Conexão: Há um outro podcast do Ricardo Vargas chamado “Importância da Estrutura Ana-
lítica (EAP) no Gerenciamento de Custos do Projeto” e disponível em http://www.ricardo-
vargas.com/pt/podcasts/wbs_costmgmt/, que fala um pouco sobre a importância da EAP
na orçamentação do projeto. É uma conexão interessante a partir do momento que Ricardo
Vargas chama a atenção para a interligação de dois processos do PMBOK.

3.4  O Gerenciamento de Recursos Humanos

O gerenciamento dos recursos humanos do projeto inclui os processos que
organizam e gerenciam a equipe do projeto que é composta por pessoas com
funções e responsabilidades atribuídas e que contribuirão para o término do
projeto. (PMBOK, 2004 e 2008).
Assim, o gerenciamento dos recursos humanos tem como objetivo central fa-
zer o melhor uso dos indivíduos envolvidos no projeto. Como se sabe, as pessoas

106 • capítulo 3
são o elo central dos projetos e seu recurso mais importante. Eles definem as me-
tas, os planos, organizam o trabalho, produzem os resultados, direcionam, coor-
denam e controlam as atividades do projeto, utilizando suas habilidades técnicas
e sociais. Todos os resultados do projeto podem ser vistos como fruto das relações
humanas e das habilidades interpessoais dos envolvidos, uma vez que a satisfação
pessoal e a qualidade de vida estão se tornando um dos fatores-chave da motivação
de qualquer profissional (VARGAS, 2009). No passado, a maioria dos projetos se
preocupou unicamente com aspectos técnicos, que foram altamente desenvolvi-
dos. Porém, os aspectos humanos, que poderiam conduzir o projeto aos mesmos
ganhos do desenvolvimento técnico, foram relegados a um segundo plano. Agora,
são eles o foco dos principais estudos e trabalhos na área, de modo a compensar
essa desproporcionalidade. O sucesso ou o fracasso do projeto dependem direta-
mente do gerenciamento dos recursos humanos. Isso porque são as pessoas que
podem mudar os rumos de um projeto, levando-o ao sucesso ou ao fracasso, de-
pendendo de seu grau de envolvimento, motivação e engajamento com a equipe.
Como os custos e o fluxo de caixa variam significativamente através do ciclo
de vida do projeto, os recursos humanos são necessários em vários níveis de es-
pecialidade e experiência, dependendo da natureza do trabalho a ser realizado,
do nível de maturidade do time do projeto e das restrições internas e externas.
Quanto ao conceito de equipe, segundo o PMBOK (2008), um projeto é com-
posto basicamente por dois tipos de equipes: a equipe do projeto, que é respon-
sável pela execução do projeto; e a equipe de gerenciamento de projeto (que tam-
bém pode ser chamada de equipe principal, executiva ou líder), que é responsável
pelo ciclo de vida de gerenciamento de projeto planejando-o e controlando-o.
Normalmente, essa separação de equipes é vista em grandes projetos, nos
quais os papéis são muito bem definidos e quase sempre vivenciados por indi-
víduos diferentes. Já nos pequenos projetos e em pequenas empresas, os vários
papéis dessas duas equipes podem ser executados pelas mesmas pessoas.
Nesta área de conhecimento, o gerente de projetos deverá:
•  definir a hierarquia de comando do projeto;
•  criar um plano de gerenciamento das equipes dizendo como os RH serão
contratados, desenvolvidos, motivados e outros;
•  realizar a contratação e mobilização do RH;
•  executar os treinamentos e desenvolvimentos dos RH; e
•  acompanhamento de todos os RH do projeto.

capítulo 3 • 107
 Essas atividades são realizadas por meio de 4 processos, que perfazem o ci-
clo de planejamento, de execução e de monitoramento e controle, a saber:
1. Desenvolver o plano de recursos humanos.
2. Mobilizar a equipe do projeto;
3. Desenvolver a equipe do projeto.
4. Gerenciar a equipe do projeto.

3.4.1  O desenvolver o plano de recursos humanos

Este processo faz parte do grupo de processos de planejamento.

O planejamento de recursos humanos determina funções, responsabilidades
e relações hierárquicas e cria o plano de gerenciamento de pessoal. (PMI, 2012).
Neste processo é que será realizado o plano de recursos humanos, que é um
planejamento consolidado em um documento que mostra toda a hierarquia de
pessoas do projeto e ainda traz informações sobre contratação e mobilização
dos membros da equipe do projeto, critérios para o desligamento dessas pes-
soas do projeto, planos de treinamento, motivação e segurança.

3.4.2  Mobilizar a equipe do projeto

Este processo faz parte do grupo de processos de execução.

É o processo de confirmação da disponibilidade e obtenção dos recursos hu-
manos necessários para terminar o projeto, sendo que a equipe de gerenciamen-
to de projeto pode ter, ou não, controle sobre essas seleções. (PMBOK, 2012).
Este processo é responsável por contratar, se necessário, e mobilizar os re-
cursos humanos necessários para a execução das atividades que irão compor o
trabalho do projeto (VARGAS, 2009).
É bom lembrar que o gerente de projetos pode (ou não) ter controle sobre
o processo de contratação dessas pessoas. Ou seja, nem sempre o gerente de
projetos é responsável pela seleção dos membros da equipe. Isso por que as or-
ganizações que estão executando o projeto podem ter acordos coletivos, podem
utilizar estrutura matricial ou por outros motivos.

3.4.3  Desenvolver a equipe do projeto

Este processo faz parte do grupo de processos de execução.

108 • capítulo 3
 Melhorar as competências e a interação de membros da equipe para apri-
morar o desempenho do projeto. (VARGAS, 2009). Os principais objetivos desse
processo é aumentar a capacidade dos membros da equipe do projeto e termi-
nar as atividades por meio do aprimoramento de suas competências, aumento
da coesão dos membros e melhoria do trabalho em equipe.

3.4.4  Gerenciar a equipe do projeto

Este processo faz parte do grupo de processos de monitoramento e controle.

Envolve o acompanhamento do desempenho de membros da equipe, o for-
necimento de feedback, a resolução de problemas e a coordenação de mudan-
ças para melhorar o desempenho do projeto. (PMI, 2012).
Além do descrito no quadro acima, neste processo também temos a obser-
vação do comportamento da equipe executora, gerenciamento de conflitos,
resolução de problemas e avaliação do desempenho dos membros da equipe.
Basicamente, nesse processo todas as medições relativas à equipe do pro-
jeto são realizadas, alterações do plano de gerenciamento são solicitadas e as
lições aprendidas são consolidadas (VARGAS, 2009).
Ainda segundo Vargas (2009), no gerenciamento de recursos humanos, é
importante que se atente para os seguintes aspectos:
•  O trabalho em time é vital para o sucesso do projeto;
•  O espírito de corpo contribui para o sucesso;
•  Conflitos podem ocorrer entre o projeto e a organização;
•  Qualquer promessa feita durante o recrutamento deve ser documentada;
•  Os níveis de equipes são muito mais variáveis em um ambiente de projeto
que em um ambiente funcional;
•  Treinamento e desenvolvimento são mais complexos e críticos durante o
projeto, se comparados com o trabalho tradicional da organização.

ATIVIDADES
01. De que forma o gerenciamento de tempo é importante para o sucesso de projetos?

02. Quais são os cinco processos do gerenciamento de tempo em projetos?

03. Uma vez definidas as atividades, quais devem ser os resultados?

capítulo 3 • 109
04. Porque é mais difícil estimar os tempos das atividades planejadas na área de TI?

05. Quais são as principais ferramentas para desenvolvimento do cronograma?

06. Faça o diagrama AOA para a seguinte escala de atividades:

ATIVIDADE DEPENDÊNCIA

A –

B A,D

C B,F

D –

E A,D

F E,G,I

G –

H E,G,I

I –

J I

K H,J

07. Qual é o elemento chave para controle do tempo, dentro do processo de monitoramento
e controle?

REFLEXÃO
Podemos notar até este ponto do nosso material, que todos os tipos de gerenciamento, seja
de pessoas, de custos, de escopo – como vimos no capítulo anterior – são importantes, inter-
dependentes e interdisciplinares, de modo que uma área mal planejada, pode comprometer
todo um projeto, de modo que um olhar especial em todos os gerenciamentos e na sua eficaz
gestão, pode ser o caminho para o sucesso!

110 • capítulo 3
 LEITURA
Gestão de Custos em Projetos da Secretaria de Defesa Social de Minas Gerais, de
Luiza Hermeto Coutinho Campos. Disponível em:
Resumo do artigo: Este artigo dispõe sobre o gerenciamento de projetos no âmbito da
Administração Pública, tendo em vista a escassez de material científico acerca desta meto-
dologia gerencial sob a perspectiva não privada. Assim, o cerne do trabalho é o programa
governamental Choque de Gestão, que trouxe a Gestão de Projetos ao Estado de Minas
Gerais, no qual foram estabelecidas rotinas de monitoramento e instrumentos para gestão,
baseados na Metodologia Estruturada de Planejamento e Controle de Projetos (MEPCP)
para diversas áreas de conhecimento delimitadas pelo Project Management Body of Know-
ledge (PMBOK). Inserido neste contexto, o gerenciamento de custos é uma área basilar e
complexa da gestão de projetos e, ao lidar com as diversas peculiaridades típicas da gestão
orçamentária no setor público, a dificuldade é majorada. Para a pesquisa foi desenvolvido um
estudo retrospectivo dos custos de um projeto da Secretaria de Estado de Defesa Social.
Leia o artigo na íntegra pelo endereço: http://www.revistagep.org/ojs/index.php/
gep/article/view/242

LEITURA
Modelo PMBOK/PMI para gestão de projetos nas micro e pequenas empresas: um estudo
de caso, de Verônica Trentin Sella e Denize Grzybovski, 2011.
Resumo: O objetivo deste artigo é analisar a possibilidade de empresas de micro e pe-
queno porte, no Brasil, adotarem o modelo de gestão de projetos PMBOK/PMI, com vistas
a melhorar o desempenho e reduzir o índice de mortalidade dessas empresas. O mode-
lo PMBOK/PMI fornece terminologia comum à gestão de projetos e inclui conhecimentos
comprovados por práticas tradicionais, assim como conhecimentos por práticas inovadoras
com aplicação limitada. Em termos metodológicos, esta é uma pesquisa exploratória, do tipo
estudo multicaso e abordagem quanti/qualitativa dos dados coletados em entrevista e plani-
lha de dados. Os dados revelam que as empresas pesquisadas possuem sistema superficial
de gestão implantado, sem monitoramento das atividades e indicadores de resultados e sem
as informações necessárias para gerir o negócio. Isso é uma dificuldade para a implanta-
ção do PMBOK/PMI, mas pode ser uma vantagem por criar controles e disciplina utilizando
ferramentas de gestão, como cronograma e orçamentos. Também por projetos envolverem

capítulo 3 • 111
atividades não contínuas na empresa, existe o risco de o gestor “confundir” estas com as
atividades do cotidiano e não conseguir avaliar o que pode ser gerido por projeto.
Leia o artigo na íntegra pelo endereço: http://www.spell.org.br/documentos/
download/3028.

REFERÊNCIAS BIBLIOGRÁFICAS
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). Pennsylvânia:
[s.n.], v. 3, 2004.
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4ª. ed.
Pennsylvânia: [s.n.], 2008.
Pons, R. (2009). Fundamentos em gerenciamento de projetos: módulo básico do curso de formação
em gerenciamento de projetos. [Apostila de aula]. Rio de Janeiro: Projectlab.
PRESSMAN, R. S. Engenharia de Software. USA: McGrawHill, 2006.
SOMMERVILLE, I. Engenharia de Software. Rio de Janeiro: Addison Wesley, 2003.
STANDISH GROUP, website acesso em setembro de 2015. http://www.standishgroup.com/about
Valeriano, D. L. (1998). Gerência em projetos: pesquisa, desenvolvimento e engenharia. São Paulo:
Makron Books.
VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: Elsevier, 2007.

112 • capítulo 3
 4
Gerenciamento
de Riscos,
Comunicações,
da Qualidade, do
Gerenciamento de
Aquisições e Partes
Interessadas
O conceito de comunicação, atualmente, certamente um novo momento, de
destaque, pois é um dos principais requisitos exigidos para os profissionais no
mercado de trabalho. Capacidade de se comunicar claramente, saber passar e
até mesmo administrar a informação são atitudes muito valorizadas Na área de
Gestão de Projetos vemos essa característica mais claramente, onde o gestor
precisa dominar tal artifício para que a informação possa ser recebida pela sua
equipe ou cliente de forma clara e objetiva.
É precisa considerar que a ideia de “comunicação” pode ter sofrido varia-
ções com o decorrer dos anos, antigamente a escrita era vista como a principal
forma de comunicação. Hoje levamos em conta a comunicação corporal, co-
municação oral, comunicação digital e é claro a escrita, todas essas formas de
comunicação podem ser vistas, por exemplo, no gerenciamento de projetos o
qual é o foco deste artigo.
Dando continuidade aos tipos de gerenciamento de projetos com base nas
áreas de conhecimento, neste capítulo vamos ver os gerenciamentos de riscos,
comunicações, aquisições, qualidade e partes interessadas.
Vamos lá!

OBJETIVOS
•  Conceituar as áreas de riscos, aquisições, stakeholders e comunicações
•  Apresentar o detalhamento de cada uma dessas áreas de conhecimento do PMI;
•  Conhecer as técnicas e ferramentas desses tipos de gerenciamento.

114 • capítulo 4
4.1  Gerenciamento das Comunicações
O gerenciamento de comunicação do projeto é a área de conhecimento que em-
prega os processos necessários para garantir a geração, coleta, distribuição, ar-
mazenamento, recuperação e destinação final das informações sobre o projeto
de forma oportuna e adequada. (PMBOK, 2008 e 2012).
Há quem diga que o gerente de projetos gasta 90% do seu tempo se comu-
nicando. Ele deve se comunicar com todos os stakeholders do projeto, mos-
trando o desempenho do projeto, relatórios de acompanhamento, definindo
escopo entre outros.
A arte da comunicação, competência necessária no gerenciamento de pro-
jetos, é algo que vai além do escopo do ciclo de gerenciamento de projetos e in-
clui atividades como: modelos emissor-receptor, escolha dos meios de comuni-
cação, estilo de redação, técnicas de apresentação, técnicas de gerenciamento
de reuniões e outros.
Sempre que pensamos em gerenciamento de projetos, logo, pensamos em
administração de tempo, escopo e qualidade, na verdade, a administração de
todas estas áreas requer do gerente de projeto uma gama de habilidades e téc-
nicas efetivas, pois muitos elementos precisam ser coordenados. Manter um
time unido e sólido, e atender as expectativas dos stakeholders é um dos gran-
des desafios que um gerente de projeto enfrenta.
Um bom plano de comunicação pode ser chave para que a execução e o con-
trole do projeto tenham sucesso.
O desenvolvimento de um plano de comunicação envolve vários fatores
como eles administração de informação, expectativa dos stakeholders, a preci-
são das informações entre outros.
Durante todo o ciclo de vida de um projeto, é produzida ou recebida, uma
grande quantidade de informações. A administração desta informação é a res-
ponsabilidade do gerente de projeto. Em um plano de comunicação, é necessá-
rio identificar de forma clara como uma informação será gerada e distribuída.
Portanto, é responsabilidade desta área de conhecimento fornecer as liga-
ções entre pessoas e informações adequadas, sendo que entenderemos como
pessoas todos os stakeholders do projeto, como partes interessadas, cliente
e patrocinador.
Um efetivo processo de comunicação é necessário para garantir que todas
as informações desejadas cheguem às pessoas corretas no tempo certo e de

capítulo 4 • 115
uma maneira economicamente viável. O gerente de projeto utiliza-se da comu-
nicação para assegurar que o time do projeto trabalhe de maneira integrada
para resolver os problemas do projeto e aproveitar suas oportunidades. Vargas
(2009), define a comunicação como um processo pelo qual a informação é
transferida entre os indivíduos através de símbolos, sinais e outros. Além dis-
so, a comunicação é um processo de duas vias, onde participam ativamente o
emissor e o receptor da informação, com os envolvidos atuando, na maioria das
vezes, como emissores e receptores simultaneamente.
Então, para buscar a efetiva comunicação entre os stakeholders do projeto e
o trânsito adequado de informações, o ciclo de vida de projetos prevê 4 proces-
sos de gerência de comunicação, sendo 1 de iniciação, 1 de planejamento, 1 de
execução e 2 de monitoramento e controle, a saber:
1. Iniciação
a) Identificar as partes interessadas;
2. Planejamento
a) Planejar as comunicações;
3. Execução
a) Distribuir as informações;
b) Gerenciar as expectativas das partes interessadas.
4. Monitoramento e controle
a) Reportar o desempenho.

4.1.1  O Processo de Comunicação

O processo de comunicação é composto de três etapas subdivididas:

1. Emissor: é a pessoa que pretende comunicar uma mensagem, pode ser
chamada de fonte ou de origem.
a) Conceito: corresponde à ideia, ao significado que o emissor dese-
ja comunicar.
b) Codificação: é constituído pelo mecanismo vocal para decifrar
a mensagem.

2. Mensagem: é a ideia em que o emissor deseja comunicar.

a) Canal: também chamado de veículo, é o espaço situado entre o
emissor e o receptor.
b) Ruído: é a perturbação dentro do processo de comunicação.

116 • capítulo 4
 3. Receptor: é a etapa que recebe a mensagem, a quem é destinada.
a) Descodificação: é estabelecido pelo mecanismo auditivo para deci-
frar a mensagem, para que o receptor a compreenda.
b) Compreensão: é o entendimento da mensagem pelo receptor.
c) Reação: o receptor confirmar a mensagem recebida do emissor re-
presenta a volta da mensagem enviada pelo emissor (Feedback).

Com base nos trabalhos de Mintzberg sobre as estruturas das organizações,

podem ser estabelecidos alguns fluxos no processo de trabalho provocados por
diferentes mecanismos de comunicação entre as pessoas dentro de uma orga-
nização. São eles:
•  Fluxo da Autoridade Formal - Onde a informação flui segundo uma hie-
rarquia instituída dentro da organização ou projeto, realçando o fluxo do poder
formal.
•  Fluxo da Atividade Regulamentada – Onde a informação flui segundo um
mecanismo padronizado de informação independente da hierarquia dos en-
volvidos. O foco desse fluxo é a padronização do processo de comunicação.
•  Fluxo das Comunicações Informais – Onde o processo de comunicação
se dá sem a presença de nenhuma estrutura reguladora. As pessoas se agregam
em grupos sociais ou de relacionamento e neles não existe hierarquia ou padro-
nização. É o mais veloz e o mais arriscado mecanismo de comunicação.
•  Conjunto das Constelações de Trabalho – Onde o processo de comuni-
cação se dá através de objetivos claros e adequados a cada nível hierárquico da
estrutura. Normalmente, as constelações de trabalho são os melhores modelos
para o desenvolvimento do processo de comunicação em projetos.
•  Fluxo do Processo Decisório Específico – Onde o processo de comunica-
ção é necessário para decisões específicas, partindo da geração do problema
até chegar à decisão específica a ser tomada.

4.1.2  Como Identificar um bom plano de comunicação

Devemos identificar de forma clara como uma informação será gerada e distri-
buída. Este plano deveria identificar os tipos de relatórios (relatórios formais,
status do projeto, memorandos, etc.), a frequência que os relatórios serão gera-
dos, e em que momento deverá acontecer às reuniões.

capítulo 4 • 117
4.1.3  Planejamento das Comunicações segundo o PMBOK

“O processo Planejamento das Comunicações determina as necessidades de

informações e comunicações das partes interessadas; por exemplo, quem pre-
cisa de qual informação, quando precisarão dela, como ela será fornecida e por
quem. Embora todos os projetos compartilhem a necessidade de comunicar
as informações sobre o projeto, as necessidades de informações e os métodos
de distribuição variam muito. Um fator importante para o sucesso do projeto é
identificar as necessidades de informações das partes interessadas e determi-
nar uma maneira adequada para atender a essas necessidades.”[...]“O planeja-
mento das comunicações está, muitas vezes, estreitamente ligado aos fatores
ambientais da empresa e às influências organizacionais, pois a estrutura orga-
nizacional do projeto terá um efeito importante nos requisitos de comunica-
ções do projeto.(PMBOK, 2012).

4.1.4  Processo de Gerenciamento da Comunicação

O processo de gerenciar a comunicação pode ser considerado tão importan-

te quanto qualquer outro processo dentro da empresa. Os gerentes gastam a
maior parte do seu tempo em comunicação e muitas vezes nem percebem o
impacto que uma comunicação bem feita implica positivamente no projeto.
O avanço da tecnologia da informação permite que as empresas registrem
de forma eficiente as informações de seus projetos. Mas, o que fazer com tanta
informação? O fato de registrar bem os dados do projeto não garante sua utili-
dade. Perdidos em meio a tantos registros, saber usá-los de forma eficaz não
é tarefa fácil se não houver um bom planejamento e uma forma de gestão da
comunicação implementada.
As empresas preocupam-se com seus processos. Buscam formas de medir
seus desempenhos, estabelecem rotinas de reuniões gerenciais, criam formu-
lários e relatórios extensos e “bem estruturados”. Com tudo isto, somando à fa-
cilidade de preservar as informações em formato eletrônico gera um acúmulo
de dados cada vez maior. Mas, quando necessário uma consulta, o resgate da
informação pode ser uma missão quase impossível.

Planejar as comunicações
Este processo faz parte do grupo de processos de planejamento.

118 • capítulo 4
 Determina as necessidades de informações das partes interessadas.
(PMBOK, 2008).
Este processo tem por responsabilidade determinar as necessidades de in-
formações no que diz respeito a definição de quem precisa da informação, em
que formato ela deve ser provida e em que tempo ela deve estar disponível. Ou
seja, em relação às informações, busca responder às seguintes questões:
Quem precisa?
Quando precisa?
Como precisa?
Quem deve informar?

Distribuir as informações
Este processo faz parte do grupo de processos de execução.
Envolve colocar as informações à disposição das partes interessadas e no
momento oportuno. (PMBOK, 2004 e 2008).
Este processo tem por responsabilidade principal colocar em prática o pla-
no de comunicações do projeto, disponibilizando as informações para as pes-
soas corretas, no momento correto e no nível adequado.

Gerenciar as expectativas dos stakeholders do projeto

Este processo faz parte do grupo de processo de execução.
Como dito acima, no processo de identificar as partes interessadas, é fun-
ção do gerente de projetos influenciar as partes interessadas afim de aumentar
a probabilidade de sucesso do projeto.
Dessa forma, este processo cuida exatamente desta influência e tem por
objetivo a execução de comunicações e interações com as partes interessadas,
visando a atender as expectativas dessas partes e solucionar questões proble-
máticas, conforme elas venham a ocorrer. (PMBOK, 2008).
Esse gerenciamento pode se dar de várias formas:
•  Gerenciamento ativo das partes interessadas, no qual o gerente de proje-
tos deve negociar e influenciar o desejo dessas partes de forma a diminuir a não
aceitação (quando ela existir).
•  Prever possíveis problemas que essas partes interessadas podem trazer e
efetuar a análise de riscos.
•  Buscar a solução de problemas identificados com as partes interessadas.

capítulo 4 • 119
 De fato, o grande objetivo deste processo é utilizar a identificação e o enten-
dimento sobre as partes interessadas para antever suas reações a certas ques-
tões do projeto e, com isso, buscar alternativas preventivas para conseguir o
apoio (ou minimizar obstáculos) dessas partes interessadas frente a essas ques-
tões. (PMBOK, 2008).

Reportar o Desempenho
Este processo faz parte do grupo de processos de monitoramento e controle.
Envolve a coleta de todos os dados de linha de base e a distribuição das in-
formações sobre o desempenho às partes interessadas. (PMBOK, 2004 e 2008).
Este processo tem por responsabilidade gerar relatórios de desempenho
sobre várias áreas do projeto, como, por exemplo: escopo, cronograma, custo
e qualidade.
Também, este processo informa as pessoas corretas com os documentos
corretos e no nível de detalhe correto (entenda correto como planejado).

REFLEXÃO
No gerenciamento das comunicações, é importante que se atente para os aspectos a seguir:
•  As pessoas dão o melhor de si quando compreendem completamente as decisões que as
afetam e suas razões. Elas precisam perceber o que têm de fazer e o porquê, o seu desem-
penho em relação ao esperado e a sua situação profissional;
•  se a base do gerenciamento de projetos é a formalização de processos para alcançar
melhor desempenho, a informação e a comunicação não podem ser relegadas ao improviso
e à intuição;
•  a decisão sobre o que comunicar, para quem e como deve ser incorporada a todas as fases
do planejamento;
•  os diferentes veículos de comunicação se complementam, combinando mensagens gerais
e específicas para atingir diversos públicos;
•  informe sempre, em ocasiões regulares e com honestidade. Isso cria credibilidade para o
processo;
•  nas situações de crise, seja ágil. Informe a posição atual, ainda que não seja a definitiva.
Ninguém gosta de saber por último, e a falta de informações é fonte para boatos, criando
instabilidade no projeto;
•  as pessoas não têm de concordar para cooperar com uma decisão, mas têm de compreen-
der como e por que ela foi tomada.

120 • capítulo 4
4.2  Gerenciamento de Riscos
Segundo Vargas (2009), na maioria dos projetos, os riscos associados com gran-
des empreendimentos têm merecido uma atenção especial dos gerentes de
projeto, devido não só às grandes somas de dinheiro que estão em suas mãos,
como também à reputação do time e dos patrocinadores do projeto.
Gerenciamento de riscos possibilita a chance de melhor compreender a na-
tureza do projeto, envolvendo os membros do time de modo a identificar as
potenciais forças e riscos do projeto e responder a eles, geralmente associados
a tempo, qualidade e custos. Portanto, a sobrevivência de qualquer empreendi-
mento, atualmente, está intimamente vinculada ao conceito de aproveitar uma
oportunidade, dentro de um espectro de incertezas. O que torna a gestão dos
riscos se tornar tão importante são fatores diversos, como o aumento da com-
petitividade, o avanço tecnológico e as condições econômicas, que fazem com
que os riscos assumam proporções muitas vezes incontroláveis.
O gerenciamento de riscos do projeto inclui os processos que tratam da rea-
lização de identificação, análise, respostas, monitoramento e controle, e plane-
jamento do gerenciamento de riscos em um projeto. (PMBOK, 2008).
Segundo o PMBOK (2008), quando se trata de riscos é importante identificar
a probabilidade e o impacto de um determinado evento acontecer. Também é
importante determinar se o evento será negativo ou positivo para o projeto.
Isso por que há alguns riscos que trazem impactos positivos para o projeto
e o gerente de projetos deve buscar aumentar a probabilidade disso acontecer.
Por isso, os processos envolvidos nesta área de conhecimento têm por ob-
jetivos principais aumentar a probabilidade e o impacto de eventos positivos e
diminuir a probabilidade e o impacto dos eventos negativos.
Para atingir a esses objetivos, o gerenciamento de riscos conta com 6 pro-
cessos, sendo 5 processos de planejamento e 1 de monitoramento e controle,
a saber:
1. Planejar o gerenciamento de riscos
2. Identificar os riscos
3. Realizar a análise qualitativa de riscos
4. Realizar a análise quantitativa de riscos
5. Planejar as respostas a riscos
6. Monitorar e controlar os riscos.

Vamos a cada um deles!

capítulo 4 • 121
4.2.1  Planejar o gerenciamento de riscos

Este processo faz parte do grupo de processos de planejamento.

É o processo de decidir como conduzir as atividades de gerenciamento de
riscos de um projeto. (PMBOK, 2008).
Neste processo é que será planejado como os riscos serão tratados durante
todo o projeto. Por isso, os outros 5 processos de gerenciamento de riscos de-
pendem do bom desenvolvimento deste processo.
Este processo é importante para garantir que o tratamento do risco no pro-
jeto esteja de acordo com o nível estratégico que o projeto tem para a organiza-
ção, pois somente dessa maneira, tempo e recursos adequados serão desviados
de forma coerente para as ações de gerenciamento de riscos do projeto.

4.2.2  Identificar os riscos

Este processo faz parte do grupo de processos de planejamento.

Determina e documenta as características dos riscos que podem afetar o
projeto. (PMBOK, 2008). Este processo é responsável por gerar uma listagem
contendo todos os riscos identificados, possíveis respostas para os riscos e cau-
sas / raízes dos riscos.

4.2.3  Realizar a análise qualitativa de riscos

Este processo faz parte do grupo de processos de execução.

Este processo inclui métodos de priorização dos riscos identificados (por
meio de análise de probabilidade e impacto) para ação adicional, como análise
quantitativa dos riscos ou planejamento de repostas a riscos. (PMBOK, 2008).
Por meio principalmente da probabilidade do risco acontecer e de seu im-
pacto, este processo tem por finalidade priorizar os riscos configurando-se
como uma maneira bastante barata de fazê-lo. Esses riscos priorizados servirão
de entrada para o processo de planejamento de respostas aos riscos.
O processo de análise quantitativa e o processo de resposta a riscos são pro-
cessos mais morosos e caros, e por isso o processo de realizar a análise quali-
tativa de riscos funciona como um filtro afim de escolher os processos que são
realmente problemáticos para o projeto.

122 • capítulo 4
4.2.4  Realizar a análise quantitativa de riscos

Este processo faz parte do grupo de processos de planejamento.

Este processo analisa o efeito dos eventos de riscos e atribui uma classifica-
ção numérica a esses riscos. (PMBOK, 2004 e 2008).
Este processo deve ser aplicado apenas para os riscos que foram priorizados
pelo processo de análise qualitativa dos riscos e é responsável por quantificar
esses riscos.

4.2.5  Planejar as respostas a riscos

Este processo faz parte do grupo de processos de planejamento.

É o processo de desenvolver opções e determinar ações para aumentar as
oportunidades e reduzir as ameaças aos objetivos do projeto e segue os proces-
sos de análise qualitativa e quantitativa dos riscos do projeto. (PMBOK, 2008).
Este processo busca “soluções” para os riscos identificados e designa pes-
soas que serão responsáveis por cada resposta a esses riscos.

4.2.6  Monitorar e Controlar os riscos

Este processo faz parte do grupo de processos de monitoramento e controle.

É o processo responsável por colocar em prática os planos de resposta aos
riscos e monitorar os resíduos dos riscos que já acontecem, acompanhar os ris-
cos que ainda não aconteceram e identificar novos riscos durante todo o ciclo
de vida do projeto. (PMBOK, 2008).
Portanto, este processo tem o objetivo de monitorar as respostas aos ris-
cos bem como o surgimento de novos riscos e os riscos residuais de riscos que
já ocorreram.

4.3  Gerenciamento das Aquisições

O gerenciamento das aquisições tem como objetivo dar garantia ao projeto de
que todo elemento externo participante do projeto irá garantir o fornecimento
de seu produto, ou serviço, para o projeto.

capítulo 4 • 123
 A relação entre o fornecedor e o projeto é determinada usualmente pela
quantidade de riscos incorridos pelas partes. Normalmente, o custo de um de-
terminado suprimento, ou contrato, está diretamente relacionado com o risco
associado àquele trabalho. Por causa desse fator de risco, muitas vezes o cus-
to não é o único elemento a ser analisado na negociação. O tipo de contrato
também passa a determinar um papel fundamental no processo. Cada tipo de
contrato representa certo grau de incerteza e riscos para o gerente de projeto
(VARGAS, 2009)
O gerenciamento de aquisições do projeto inclui os processos para comprar
ou adquirir os produtos, serviços ou resultados necessários para o projeto, mas
de fora da equipe do projeto, sendo que a organização executora do projeto
pode ser o comprador ou fornecedor do produto. (PMBOK, 2008).
Como dito acima, o gerenciamento de aquisições é o responsável por geren-
ciar os contratos e alterações de contrato que a organização executora tem com
fornecedores ou que a organização executora tem com clientes para os quais
ela fornece o projeto (ou seus produtos) que está sendo executado (no caso da
organização executora ser contratada externa para a execução do projeto).
Para realizar a gerência desses contratos, a área de conhecimento de geren-
ciamento de aquisições contém 4 processos, sendo 1 de planejamento, 1 de
execução, 1 de monitoramento e controle e 1 de encerramento, a saber:
1. Planejar aquisições
2. Conduzir as aquisições
3. Administração as aquisições
4. Encerrar as aquisições

Vamos a cada um deles:

4.3.1  Planejar as Aquisições

Este processo faz parte do grupo de processos de planejamento

Foca as decisões de compra do projeto de forma a documentá-las, especifi-
car a abordagem utilizada para a compra e identificar os potenciais fornecedo-
res que poderá oferecer o produto/serviço. (PMBOK, 2008).
Além disso, este processo busca nas atividades do projeto àquelas que po-
deriam ser melhores atendidas por meio de aquisição externa de produtos e/
ou serviços.

124 • capítulo 4
 Concluindo, este processo é utilizado para determinar quais apoios exter-
nos serão contratados e de que forma essa contratação irá ocorrer. Dessa for-
ma, esse processo também acaba englobando a seleção de fornecedores.

4.3.2  Conduzir as Aquisições

Este processo continua o processo anterior buscando respostas de fornecedo-

res selecionados e selecionando um fornecedor, com o qual o contrato será as-
sinado, para a execução da aquisição em questão. (PMBOK, 2008).
De forma bastante resumida, este processo é responsável por negociar as
aquisições com todos os fornecedores e, por meio de um critério sistematizado,
buscar a seleção de um fornecedor (para cada aquisição) assinando contrato
com o mesmo

4.3.3  Administrar as Aquisições

Este processo faz parte do grupo de processos de monitoramento e controle.

O comprador e o fornecedor administram contrato com objetivos seme-
lhantes. Cada uma das partes garante que tanto ela quanto a outra parte aten-
dam às suas obrigações contratuais e que seus próprios direitos legais estejam
protegidos. (PMBOK, 2008).
Este processo busca garantir que o fornecedor atenda ao contrato bem
como o comprador.

4.3.4  Encerrar as Aquisições

Este processo faz parte do grupo de processos de encerramento.

Busca realizar a finalização de cada aquisição feita no projeto. Por isso, aca-
ba dando suporte ao processo Encerrar o projeto, pois envolve a confirmação
de que todo o trabalho e as entregas foram aceitas. (PMBOK, 2008).
Este processo é responsável pela finalização de todos os contratos e regis-
tros de informações em bases históricas sobre os contratos e fornecedores.
Este processo também trata sobre a rescisão de contratos.

capítulo 4 • 125
4.4  Gerenciamento dos Stakeholders –
Partes Interessadas

O Gerenciamento das partes interessadas do projeto inclui os processos exigi-

dos para identificar todas as pessoas, grupos ou organizações que podem im-
pactar ou serem impactados pelo projeto, analisar as expectativas das partes
interessadas e seu impacto no projeto, além de desenvolver estratégias de ge-
renciamento apropriadas para o envolvimento eficaz das partes interessadas
nas decisões e execução do projeto (MARTINS, 2013).
O gerenciamento das partes interessadas também se concentra na comu-
nicação contínua com as partes interessadas para entender suas necessidades
e expectativas, abordando as questões conforme elas ocorrem, gerenciando os
interesses conflitantes e incentivando o comprometimento das partes interes-
sadas com as decisões e atividades do projeto (MARTINS, 2013). Os processos e
principais produtos de Gerenciamento das partes interessadas são:

PROCESSOS PRINCIPAIS PRODUTOS

•  Identificar as partes interessadas. •  Estratégias para gerenciamento das

partes interessadas.

•  Planejar o gerenciamento das partes •  Plano de gerenciamento das partes

interessadas. interessadas.

•  Gerenciar o envolvimento das partes •  Sistema de informações gerenciais.

interessadas.

•  Controlar o envolvimento das partes •  Estratégia e planos para o envolvimen-

interessadas. to das partes interessadas.

126 • capítulo 4
4.4.1  Identificar as partes Interessadas

As partes interessadas são pessoas e organizações, tais como clientes, patroci-

nadores, a organização executora e o público, que estão ativamente envolvidas
no projeto ou cujos interesses podem ser positiva ou negativamente afetados
pela execução ou pelo término do projeto(MARTINS, 2013).
Envolver as partes interessadas no início do projeto aumenta a probabilida-
de de aceitação das entregas do projeto, haja vista que as partes interessadas
são utilizadas para mapear o escopo do projeto e os requisitos do produto.
A maioria dos projetos tem um grande número de partes interessadas.
Como o tempo do gerente de projetos é limitado e precisa ser usado com a
maior eficiência possível, essas partes interessadas devem ser classificadas de
acordo com o interesse, a influência e o envolvimento no projeto. Isso permite
que o gerente de projetos se concentre nos relacionamentos necessários para
garantir o sucesso do projeto.
Também podem exercer influência sobre o projeto e suas entregas. As par-
tes interessadas podem estar em diversos níveis da organização e ter diferen-
tes níveis de autoridade, ou ser externas à organização executora do projeto
(MARTINS, 2013).

4.4.2  Planejar o gerenciamento das partes interessadas

Planejar o gerenciamento das partes interessadas é o processo de desenvolver es-

tratégias apropriadas de gerenciamento para envolver as partes interessadas de
maneira eficaz no decorrer de todo o ciclo de vida do projeto, com base na análise
das suas necessidades, interesses, e impacto potencial no êxito do projeto.
O gerenciamento das partes interessadas significa mais do que melhorar as
comunicações e requer mais do que gerenciar uma equipe, envolve a criação e
manutenção de relacionamentos entre a equipe do projeto e as partes interes-
sadas, com o objetivo de satisfazer suas respectivas necessidades e requisitos
dentro dos limites do projeto (MARTINS, 2013).
À medida em que o projeto avança, a comunidade das partes interessadas e
o nível exigido de envolvimento podem mudar.
O nível de envolvimento das partes interessadas pode ser classificado como:
•  Desinformado: sem conhecimento do projeto e impactos potenciais.
•  Resistente: ciente do projeto e dos impactos potenciais e resistente à
mudança.

capítulo 4 • 127
 •  Neutro: ciente do projeto e mesmo assim não dá apoio ou resiste.
•  Dá apoio: ciente do projeto e dos impactos potenciais e dá apoio à
mudança.
•  Lidera: ciente do projeto e dos impactos potenciais e ativamente engajado
em garantir o êxito do projeto.

4.4.3  Gerenciar o envolvimento das partes interessadas

O processo Gerenciar o envolvimento das partes interessadas envolve as ativi-

dades de comunicação dirigidas às partes interessadas para influenciar suas
expectativas, abordar as preocupações e solucionar as questões, tais como:
•  Gerenciar ativamente as expectativas das partes interessadas para au-
mentar a probabilidade de aceitação do projeto, negociando e influenciando
seus desejos para alcançar e manter as metas do projeto.
•  Envolver as partes interessadas nas etapas apropriadas do projeto para
obter ou confirmar seu compromisso continuado com o êxito do projeto.
•  Abordar as preocupações que ainda não se tornaram questões, geralmen-
te relacionadas com a prevenção de futuros problemas. Essas preocupações
precisam ser reveladas e analisadas e os riscos precisam ser avaliados.
•  Esclarecer e solucionar as questões que foram identificadas. A solução
pode resultar em uma solicitação de mudança ou pode ser tratada fora do pro-
jeto como, por exemplo, ser adiada para outro projeto ou fase, ou transferida
para outra entidade organizacional.

O gerenciamento do envolvimento das partes interessadas ajuda a aumen-

tar a probabilidade de sucesso do projeto, garantindo que as partes interessa-
das entendam claramente as metas, os objetivos, os benefícios e os riscos do
projeto (MARTINS, 2013).
Em geral, o gerente de projetos é responsável pelo gerenciamento das par-
tes interessadas.

4.4.4  Controlar o nível de comprometimento das partes Interessadas

Controlar o nível de comprometimento das partes interessadas é o processo

de monitorar os relacionamentos das partes interessadas no projeto em geral
e ajustar as estratégias e planos para o engajamento das mesmas. O principal

128 • capítulo 4
benefício desse processo é a manutenção ou aumento da eficiência e eficácia
das atividades de engajamento das partes interessadas à medida que o projeto
se desenvolve e o seu ambiente muda (MARTINS, 2013). As informações usadas
no processo Controlar o nível de comprometimento das partes interessadas in-
cluem, entre outras:
•  Como o trabalho será executado para completar os objetivos do projeto.
•  Como os requisitos de recursos humanos serão cumpridos, como os pa-
péis e responsabilidades, a estrutura hierárquica e o gerenciamento do pessoal
serão abordados e estruturados para o projeto.
•  Um plano de gerenciamento de mudanças que documenta como as mu-
danças serão monitoradas e controladas.
•  Necessidades e técnicas para a comunicação entre as partes.

ATIVIDADES
01. Quais as diferenças na aplicação da análise qualitativa e quantitativa de riscos?

02. Explique qual a importância do gerenciamento de riscos?

03. Por que devemos nos preocupar com a comunicação entre os envolvidos no projeto? O
que pode ocorrer que comprometa o processo de comunicação, por exemplo?

04. Cite alguns sujeitos que são considerados stakeholders do processo de gerenciamento
de projetos e explique por que eles são importantes para o sucesso do projeto?

05. Explique os elementos 5W e 2H para a criação do plano de comunicação do projeto.

REFLEXÃO
Como já foi dito em outros momentos do livro, gerenciar projetos buscando seu sucesso e
eficácia, não possui receita de bolo, que fará com que o projeto ocorra e finalize exatamen-
te como foi previsto e conforme foi escrito. Intercorrências acontecem, e quanto maior for
o grau de complexidade de um projeto, maior a probabilidade de intercorrências ele terá.
Assim, ter muito claramente a necessidade de um acompanhamento e monitoramento mi-
nucioso do projeto, seja por parte do gerente de projeto, seja por parte dos envolvidos, pode

capítulo 4 • 129
não assegurar sucesso garantido, mas com certeza, dará muito mais segurança em buscar
esse resultado no final do processo. E todas as áreas são importantes, cada qual com sua
influência no projeto como um todo!

LEITURA
IMPLANTAÇÃO DE PROJETOS DE SISTEMAS NA ÁREA DE SERVIÇOS:
AVALIAÇÃO DA GESTÃO DE STAKEHOLDERS. Autores: Elisabete Cecília Januário Cha-
ves, Rosemeire Oikawa,
Napoleão Verard Galegale, Marília Macorin de AzevedoArtigo
Resumo: A área de conhecimento “Gestão de Stakeholders” em ambientes de implantação
de projetos de sistemas na área de serviços vem ganhando espaço entre os gestores de
projeto. Este artigo visa avaliar os benefícios trazidos por essa área de conhecimento se-
gundo opiniões de especialistas em gestão de projetos. Para essa avaliação utilizou-se uma
pesquisa com o método Delphi, além de considerar referências bibliográficas e melhores
frameworks em Gerenciamento de Projetos. Nessa nova área de conhecimento, os grupos
de processos recomendam boas práticas em procedimentos para a gestão dos interessados
buscando contribuir para o sucesso na implementação de projetos.
Disponível no endereço: interessadas, recomendo fortemente que abra.
http://repositorio.enap.gov.br/handle/1/1098.

REFERÊNCIAS BIBLIOGRÁFICAS
MARTINS, Carlos Eduardo. 2013. Gerência de Projetos – Teoria e Prática. Disponível em:
http://repositorio.enap.gov.br/bitstream/handle/1/1098/GerenciaDeProjeos_modulo_4_final_.
pdf?sequence=1&isAllowed=y – acesso setembro de 2015
PMBOK. Um guia do conjunto de conhecimentos em gerenciamento de projetos. Pennsylvania:
s.n., 2008.
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4ª. ed.
Pennsylvânia: [s.n.], 2008.
PRESSMAN, R. S. Engenharia de Software. USA: McGrawHill, 2006.
SOMMERVILLE, Ian.. Engenharia de software. Rio de Janeiro: Addison Wesley, 2003.
VARGAS, Ricardo.. Site do Ricardo Vargas. <www.ricardovargas.com.br>. Acesso em:16 mar. 2010.

130 • capítulo 4
VIEIRA, Marconi Fábio.. Gerenciamento de projetos de tecnologia da informação. Rio de Janeiro:
Elsevier, 2007.
Pons, R. (2009). Fundamentos em gerenciamento de projetos: módulo básico do curso de
formação em gerenciamento de projetos. [Apostila de aula]. Rio de Janeiro: Projectlab.
VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informação. Rio de Janeiro: Elsevier, 2007.

capítulo 4 • 131
132 • capítulo 4
 5
A Qualidade
Num Projeto e
o Processo de
Gerenciamento da
Qualidade
O gerenciamento da qualidade do projeto inclui todas as atividades da organiza-
ção executora que determinam as responsabilidades, os objetivos e as políticas de
qualidade de modo que o projeto atenda às necessidades que motivaram sua reali-
zação. Porém, antes de falarmos de qualidade em projetos, precisamos entender o
conceito de Qualidade, suas origens, os chamados gurus da qualidade, para depois
disso, poder compreender sua importância no gerenciamento de projetos.
Vimos que gerenciamento da qualidade é, portanto, uma das 10 áreas de co-
nhecimento do processo de gerenciamento de projetos do guia PMBOK e será,
neste capítulo, trabalhado de forma isolada, devido seu grau de importância
para o projeto como um todo.
Veremos que o conceito de qualidade está ligado ao atendimento dos requi-
sitos dos stakeholders do projeto. Esses requisitos podem ser do produto ou
do projeto.

OBJETIVOS
•  Definir termos e conceitos da qualidade;
•  Reconhecer as diferentes visões de qualidade;
•  Identificar o contexto de aplicabilidade das diferentes contribuições dos autores
da qualidade;
•  Entender a evolução da qualidade nas organizações.
•  Discutir a relação que se estabelece entre qualidade e as especificações de um projeto.
•  Apresentar as etapas necessárias para se construir um plano de gerenciamento da quali-
dade aplicada ao desenvolvimento de um projeto
•  Compreender os passos necessários para a elaboração de um plano de gerenciamento da
qualidade de um projeto.

COMENTÁRIO
Qualidade é um termo que está incorporado ao nosso dia a dia, sendo empregado na compra,
venda e uso de produtos e serviços, embora nem sempre com o mesmo significado. Há uma
grande subjetividade em torno da palavra, que pode ser conceituada de diferentes manei-
ras, como por exemplo: ausência de defeitos, melhor desempenho, capacidade de atender
a uma necessidade específica, capacidade de personalização, diversidade de atributos de
um produto/serviço, entre outras. Dada a amplitude do termo, é conveniente defini-lo ao

134 • capítulo 5
interlocutor sempre que o mesmo for utilizado para que não haja confusão na compreensão
de seu significado.
Observa-se que a polêmica em torno da ideia de qualidade vem de longa data. Os pri-
meiros registros estão relacionados ao Império Grego. Os filósofos gregos discutiram a ideia
de qualidade ligada ao conceito de excelência ou superioridade moral, intelectual e física
(MAXIMIANO, 2006).
Posteriormente, já bem mais tarde, no século XVIII, vamos encontrar a sociedade funda-
mentada na ideia noção de qualidade associada a valor, ligando o conceito a produtos caros
de luxo e alto desempenho, que poucas pessoas podem comprar (GARVIN, 1992).
Com a Revolução Industrial e o advento da Administração Científica, Taylor, trouxe para
as empresas uma série de inovações do ponto de vista técnico: divisão do trabalho, padro-
nização das atividades executadas na produção do produto, simplificação dos movimentos
requeridos pelo trabalhador para a execução de uma determinada tarefa, estabelecimento de
um tempo padrão para realização de cada atividade, definição de uma meta de produção para
cada trabalhador, melhoria dos métodos e das ferramentas de trabalho (MAXIMIANO, 2006).
Seguindo a linha de pensamento de Taylor, Ford investiu na produtividade da linha de
produção, através da especialização total do trabalho (CERTO, 2003), na criação do sistema
de produção em massa (RIBEIRO, 2003) e da simplificação das peças utilizadas na mon-
tagem do automóvel, tornando-as padronizadas e intercambiáveis (LACOMBE; HEILBORN,
2003). Com esses incrementos, muda-se o foco sobre o conceito de qualidade que passa
a ser relacionado ao processo de produção, adquirindo um caráter quantitativo, inerente aos
erros e as falhas dos processos produtivos.
Atualmente, a qualidade pode ser definida como um critério estratégico de diferenciação
competitiva, no qual a organização tem como objetivo oferecer ao mercado produtos/servi-
ços melhores do que os concorrentes (SLACK, 1997).

capítulo 5 • 135
5.1  Visões da Qualidade
Desde a Revolução Industrial, vários autores tentaram definir qualidade.
A conclusão que se chegou é que o conceito de qualidade é subjetivo, ou
seja, não pode ser expresso, numa frase única, dada a sua complexidade e seu
caráter multidimensional. Assim, alguns autores se ocuparam em sintetizar as
diversas maneiras pelas quais a qualidade pode ser vista.
Talvez essa diversidade de definições sobre o assunto, seja consequência
da própria evolução da gestão da qualidade ao longo deste século (TOLEDO;
CARPINETTI, 2000). O importante é lembrar que elas se complementam entre si!
Garvin (1992) destaca cinco dimensões para definir qualidade:
•  Transcendental – conceitua qualidade como excelência nata, constituin-
do-se numa propriedade absoluta e universalmente reconhecível;
•  Baseada no produto – define qualidade como uma variável precisa, men-
surável e diretamente relacionada aos atributos do produto, podendo ser ava-
liada objetivamente. Nessa abordagem, um maior nível de qualidade exige
maior custo, portanto produtos de maior qualidade estão associados a produ-
tos com maior preço;
•  Baseada no usuário – associa qualidade a preferências pessoais. Portanto,
quanto maior a satisfação do cliente maior o nível de qualidade;
•  Baseada na produção– tem como foco a engenharia, desta forma, qualida-
de significa conformidade com às especificações;
•  Baseada no valor – conceitua qualidade como o equilíbrio entre custo e
preço, ou seja, um produto de qualidade deve apresentar o desempenho espe-
rado a um custo e preço aceitável.

5.2  Conceitos de Qualidade segundo

Deming

Deming foi um dos principais precursores do conceito e do desmembramento

da qualidade na história da gestão de negócios. Suas contribuições já ensina-
das e aplicadas até hoje pelo seu caráter inovador e moderno.
Willian Edwards Deming nasceu em 1900, em Sioux City, Iowa, Estados
Unidos. Em 1921 licenciou-se em Física, na Universidade do Wyoming e, em

136 • capítulo 5
1928, doutorou-se em Matemática pela Yale University. Em 1950, foi convidado
pela JUSE (Japan Union of Scientists and Engineers) para dirigir ações de forma-
ção em estatística e controle de qualidade no Japão (SPINER, 2008). O impacto
das suas ideias junto ao empresariado japonês foi tão grande, que Deming é
considerado um dos responsáveis pela retomada do desenvolvimento do país
pós Segunda Guerra mundial (CARAVANTES; PANNO; KLOECKNER, 2005).
A década de 1970 foi marcada pela expansão da economia japonesa e sua
penetração nos mercados ocidentais, especialmente através das indústrias ele-
trônica e automobilística. Esse crescimento despertou o interesse por parte dos
ocidentais em entender as razões do “milagre” japonês. A reação foi de perple-
xidade quando se descobriu que muitos japoneses atribuíam a um americano,
desconhecido em seu próprio país – Deming – grande parte das razões de seu
sucesso. Somente a partir daí, é que os Estados Unidos passaram a valorizar os
ensinamentos de Deming (MAXIMIANO, 2006).
Em 1982, Deming publicou o livro Quality, productivity and competitive
position (Qualidade, produtividade e posição competitiva), que discorre sobre
como administrar a qualidade (RIBEIRO, 2003).
Em 1986, Reagan atribuiu a Deming a National Medal of Technology
(Medalha Nacional de Tecnologia), e nesse mesmo ano, o estudioso lançou o
livro Out of Crisis (Saia da Crise), a obra que o consagrou como o grande mes-
tre da qualidade, definindo os 14 princípios para o desenvolvimento de um
programa de gestão da qualidade, que estão descritos um pouco mais à frente
(MAXIMIANO, 2006).
Durante mais de 40 anos, Deming trabalhou como consultor, escritor e
professor da Stern School of Business (Nova Iorque), morrendo aos 93 anos
(SPINER, 2008).
Deming estruturou sua filosofia de administração da qualidade baseada nos
seguintes fatores críticos à competitividade de uma empresa (TOLEDO 2000):
Falta de envolvimento dos setores da administração com os problemas
da produção;
•  A qualidade era encarada como responsabilidade exclusiva da produção;
•  O treinamento do pessoal era completamente inadequado para tratar
problemas relacionados com a qualidade;
•  Utilização da inspeção como forma prioritária de garantia da qualidade.
Com base nestes aspectos críticos, Deming estabeleceu um conjunto de 14
princípios que serviram de base para o estabelecimento de um programa da
qualidade (MAXIMIANO, 2006):

capítulo 5 • 137
 •  Princípio 1 – melhoria contínua de produtos e serviços, com base na ela-
boração de um plano para tornar o negócio mais competitivo;
•  Princípio 2 – adoção de uma filosofia de trabalho moderna, não acei-
tando a convivência com atrasos, erros, materiais defeituosos e mão de
obra inadequada;
•  Princípio 3 – eliminação da dependência da inspeção em massa, o foco
deve ser na garantia da qualidade do processo;
•  Princípio 4 – consideração da qualidade ao selecionar fornecedores de
produtos e serviços;
•  Princípio 5 – antecipação às consequências da falta da qualidade, através
da identificação de problemas e de suas causas;
•  Princípio 6 – estabelecimento de métodos atualizados de treinamento
no trabalho;
•  Princípio 7 – introdução de métodos de supervisão e criação de condições
para realização adequada do trabalho;
•  Princípio 8 – criação de um clima de confiança e respeito mútuo, afastan-
do o medo;
•  Princípio 9 – eliminação das barreiras entre departamentos e conheci-
mento das necessidades dos clientes;
•  Princípio 10 – eliminação das metas numéricas, cartazes e rótulos que
apenas pedem maiores níveis de produtividade para os trabalhadores, sem in-
dicar métodos ou ideias para atingi-los.

O estabelecimento das metas deve ter clara indicação de como elas podem
ser atingidas;
•  Princípio 11 – padrões de trabalho inconsistentes não devem ser impos-
tos. Padrões numéricos devem ser utilizados como instrumentos para que to-
dos tenham consciência de sua situação e do resultado de seus esforços;
•  Princípio 12 – estabelecimento de um programa de educação e treina-
mento para todos, a fim de afastar o medo e as barreiras que impedem que as
pessoas se sintam responsáveis pelo seu trabalho;
•  Princípio 13 – manter a equipe atualizada em relação às mudanças de mo-
delo, estilo, materiais, métodos e novas máquinas;
•  Princípio 14 – organizar a empresa de tal forma que os princípios opera-
cionais anteriormente apresentados passem a orientar as decisões no dia a dia.

138 • capítulo 5
 Outra contribuição de Deming foi sua busca pelo controle efetivo dos pro-
cessos. Para isso o autor destacou a necessidade de se estabilizar o processo por
meio da eliminação dos fatores que afetam negativamente as características de
qualidade desejadas e da identificação das causas comuns e especiais na varia-
ção destes processos (MOTTA; VASCONCELOS, 2002).
Uma causa comum pode ser conceituada como uma variação natural de um
processo, que, individualmente, contribuí pouco para a variação total do pro-
cesso (MARTINS, 2002).
Por ser inerente ao processo, a remoção das causas comuns requer mudan-
ças na concepção e/ou na operação do processo, implicando em investimento
na melhoria ou troca do processo (TOLEDO, 2000).
Estudos revelam que as causas comuns representam por volta de 85% dos
problemas existentes num processo, porém a remoção delas depende de uma
ação da gerência sobre o sistema. Por exemplo, se uma máquina está desgasta-
da e apresenta inúmeras folgas, somente uma decisão da alta gerência poderá
trocá-la ou consertá-la (MARTINS, 2002).
Já as causas especiais representam por volta de 15% dos problemas existen-
tes num processo e a remoção delas pode ser feita no próprio local de trabalho
por operários treinados ou por equipes de manutenção. Por exemplo, a troca
de uma ferramenta desgastada pode ser detectada pelo próprio operário e ele
mesmo poderá trocar a ferramenta gasta (MARTINS, 2002).
Finalizando as contribuições de Deming, é importante destacar que ele foi
criador do ciclo PDCA (Plan, Do, Check, Act), que é uma ferramenta da quali-
dade, voltada ao planejamento e gestão estratégica, utilizada para direcionar
e priorizar os esforços de melhoria do desempenho em cada nível hierárquico,
de forma que a empresa alcance seus objetivos estratégicos de longo e médio
prazo (LEE; DALE, 1998).
O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995):
•  Plan (planejar) – identificar os problemas-chave a partir de critérios analí-
ticos e quantitativos, determinando como eles podem ser corrigidos;
•  Do (executar) – implementar o plano;
•  Check (verificar) – confirmar quantitativa e analiticamente se houve me-
lhoria no desempenho e
•  Act (atuar) – atuar corretivamente caso o desempenho esteja fora do padrão
determinado. Modificar, documentar e utilizar o processo adequadamente.

capítulo 5 • 139
5.3  Eras da Qualidade
Garvin (1992) identificou quatro estágios da gestão da qualidade:
•  Controle do produto ou inspeção,
•  Controle do processo ou controle estatístico;
•  Garantia da qualidade;
•  Gestão estratégica da qualidade.

Vamos aprender sobre cada um desses estágios?

Controle do produto ou inspeção

O controle do produto formalizou-se com a produção em massa e a necessi-
dade de peças intercambiáveis, sendo executado através da criação de um siste-
ma de medidas, gabaritos e acessórios, cujo foco principal era a verificação de
erros (MAXIMIANO, 2006).
A conformidade em relação ao padrão e a uniformidade dos produtos eram
as preocupações primordiais, e não a resolução de problemas. Além disso, nes-
se período, a quantidade produzida de produtos era mais importante do que a
qualidade, reforçando a mentalidade de praticar o controle para encontrar os
defeitos ao invés de evitá-los (GARVIN, 1992).
Havia empresas que preferiam arcar com os custos dos produtos deficien-
tes, por acreditarem que esta atitude era mais barata do que tentar aprimorar a
qualidade (RIBEIRO, 2003).
Vale também comentar, que a ênfase na inspeção, mesmo que fosse mais
barata não era capaz de atuar na causa verdadeira dos problemas!

Controle estatístico ou do processo

O controle do processo deu à qualidade um caráter científico através da
utilização de técnicas estatísticas para verificar a uniformidade dos produtos
(SILVA, 2002).
A preocupação passa a ser o nível de variabilidade do processo e a inspeção
passa a ocorrer por amostragem (MOTTA; VASCONCELOS, 2002).
Com o crescimento das empresas e da expansão da produção em massa,
tornou-se impraticável inspecionar a totalidade dos produtos, surgindo, assim
o controle estatístico da qualidade (MAXIMIANO, 2006)

140 • capítulo 5
 Em lugar de se inspecionar todos os produtos, seleciona-se uma amostra de
produtos para inspeção. O resultado da análise dessa amostra é estendido ao
lote (GARVIN, 1992).
Apenas como curiosidade, o pioneiro da aplicação da estatística ao controle
da qualidade foi Walter A. Shewhart, dos Laboratórios Bell, que em 1924 prepa-
rou o primeiro rascunho do que viria a ser conhecido como carta ou gráfico de
controle. (MAXIMIANO, 2006).
Os gráficos de controle indicam o desempenho do processo, em termos de
sua variação, mediante o controle estatístico de uma variável ou atributo rela-
cionado a uma característica da qualidade do produto, subconjunto ou peça
(SILVA, 2002).
É importante observar que essa ferramenta funciona como um termôme-
tro, ou seja, apenas indica o estado do processo. Não resolve o problema.
É preciso diagnóstico e ação sistemática sobre o processo para que o proble-
ma seja efetivamente resolvido. Por isto, será imprescindível o conhecimento
do processo que está sendo controlado (MARTINS, 2002).
O Controle Estatístico de Processo (CEP) mede justamente o nível de varia-
ção desses duas componentes. A ideia é eliminar as causas especiais e deixar
em um nível tolerável as causas comuns, de forma que esta variação não in-
fluencie de forma negativa a qualidade do produto ou serviço, aumentando a
sensação de risco do consumidor (MARTINS, 2002).
Quando somente causas comuns agem em um processo, ele apresenta-
rá um comportamento previsível, sendo possível prever seu comportamento.
Isto implica que os parâmetros estimados para o processo são confiáveis uma
vez que não existem causas especiais perturbando a variação natural do pro-
cesso. Neste caso, é possível dizer que o processo está sob controle estatístico
(MONTGOMERY, 1991).
Os principais benefícios da utilização do CEP são (MONTGOMERY, 1991):
•  Controle da variação dos processos;
•  Redução do refugo e retrabalho com consequente diminuição dos custos;
•  Melhoria da qualidade de conformação;
•  Autocontrole por parte dos operadores dos processos (quem faz a
“qualidade”);
•  Aumento da produtividade e motivação dos operadores dos processos;
•  Redução para o mínimo ou eliminação das necessidades de inspeção;

capítulo 5 • 141
 •  Possibilidade de sistematização das informações geradas nos gráficos de
controle para futuros estudos de melhoria dos processos.

Vale observar que o CEP não é a solução de todos os problemas de qualidade

e produtividade de uma empresa, mas com certeza é parte de uma estratégia
coordenada para a melhoria contínua do desempenho (MARTINS, 2002).
O importante é exercer o controle de forma a avaliar os desvios com o pen-
samento probabilístico e não determinístico, ou seja, conhecendo a variação
do processo, agir somente quando houver indícios de mudança brusca ou de
tendência de mudança (WHEELER, 2001).
Após verificar se um processo está sob controle estatístico, ou não, é pos-
sível analisar a capabilidade do processo, que demonstra, por meio de índices
numéricos, quanto um processo é capaz de produzir um produto atendendo a
dada especificação (MARTINS, 2002).
De posse do índice de capabilidade de um processo é possível avaliar se
ele irá satisfazer ou não as especificações de uma característica da qualidade
(WHEELER, 2001).
A análise de capabilidade é feita comparando-se a “voz do cliente”, expressa
pelas especificações do produto, e a “voz do processo”, expressa pelas estimati-
vas do parâmetro do processo (JURAN, GRYNA, 1991).
Esta é parte fundamental do processo de melhoria da qualidade, uma vez que
ela pode direcionar os esforços de melhoria no seguinte sentido (MARTINS, 2002):
•  Predizer quão bem um processo pode atender às exigências do cliente;
•  Auxiliar ou mesmo guiar engenheiros a escolherem um processo
de produção;
•  Auxiliar no estabelecimento da frequência de amostragem do processo;
•  Especificar as necessidades de desempenho de um equipamento;
•  Auxiliar na seleção de fornecedores;
•  Auxiliar no projeto de tolerâncias;
•  Guiar o processo de redução da variação dos processos.

Uma vez que o processo tem um índice de capabilidade que atende às

exigências da empresa, então, os gráficos de controle poderão ser utilizados
como uma ferramenta poderosa para controlar a qualidade dos processos
(WHEELER, 2001).

142 • capítulo 5
Garantia da Qualidade

Na era da garantia da qualidade, o foco deixa de ser a fábrica e passa para o ge-
renciamento de todo o processo, da matéria-prima ao consumidor final, desta-
cando-se a prevenção de problemas (GARVIN, 1992). Com essa nova dimensão, a
qualidade deixa de ser atributo apenas do produto ou serviço. Deixa de ser tam-
bém responsabilidade exclusiva do departamento da qualidade. A qualidade é
problema de todos e envolve todos os aspectos da operação da empresa. A quali-
dade exige visão sistêmica, para integrar as ações das pessoas, as máquinas, in-
formações e todos os outros recursos envolvidos na administração da qualidade.
Esta ideia implica a existência de um sistema da qualidade (TOLEDO, 2000).
A qualidade passa a ser vista de forma sistêmica e as empresas passam a exi-
gir que os fornecedores assegurem a qualidade dos insumos (JURAN; GRYNA,
1991). Para colocar essa ideia em prática, as empresas compradoras passaram a
fazer a auditoria do sistema da qualidade de seus fornecedores, em vez de fazer
a inspeção de seus produtos no momento da entrega (MAXIMIANO, 2006).
Os métodos de controle e melhoria da qualidade não ficam mais restritos
à produção, pelo contrário, são estendidos a todas às áreas organizacionais
(SHIBA et al, 1997).
Para isso são utilizados os seguintes conhecimentos (GARVIN, 1992):
•  Custos da Qualidade – preocupação em identificar os custos evitáveis e os
custos inevitáveis, eliminando os primeiros e reduzindo os segundos. Foco nos
custos de prevenção, em detrimento dos custos de inspeção.
•  Controle Total da Qualidade (CTQ) – o controle da qualidade vai desde o
projeto do produto/serviço até à entrega ao cliente, envolvendo todas as áreas
funcionais, expandindo-se muitas vezes até os fornecedores. A principal preo-
cupação é equilibrar custo e qualidade.
•  Engenharia da Confiabilidade – preocupação em garantir o desempe-
nho do produto ao longo do tempo, de forma que este desempenhe sua função
sem falhas.
•  Zero Defeito – filosofia que tem como foco a motivação e a conscientiza-
ção sobre qualidade, dando menos ênfase a técnicas específicas de solução de
problemas. O lema é fazer o trabalho certo da primeira vez.

capítulo 5 • 143
Gestão Estratégica da Qualidade

Finalmente, a qualidade é elevada ao nível estratégico, transformando-se na

base para enfrentar a concorrência (GARVIN, 1992). Dentro deste contexto, a
qualidade adquire status de sistema de gestão, ligando-se aos objetivos estra-
tégicos e tendo como foco a lucratividade da organização, através da melhoria
contínua (SHIBA et al, 1997).
Para expressar essa nova condição surge o termo Total Quality Management
(TQM), Gestão pela Qualidade Total. Desde, então, a Gestão pela Qualidade
Total, tornou-se uma “febre”, sendo adotada por muitas empresas, o que à pri-
meira vista é bastante positivo. No entanto, infelizmente muitas organizações
não foram bem sucedidas nessa empreitada, pois muitos consultores passa-
ram a vender a ideia de que a TQM seria a panacéia para todos os males das
organizações, a implantação do sistema seria fácil e os resultados seriam ob-
tidos rapidamente. A atitude inconsequente desses profissionais levou muitos
empresários a criarem um movimento de resistência em relação à adoção dos
conceitos e métodos relacionados à TQM, impedindo as empresas de se torna-
rem mais competitivas (MARTINS, 1999).

5.4  A Qualidade num Projeto, segundo PMI

Para que um projeto seja considerado bem sucedido, deverá haver uma cor-
respondência entre o seu Escopo, Custo, Prazo e o nível de confiança nos seus
produtos, ou seja, na sua qualidade. A qualidade, portanto, faz parte do trio
de restrições encontradas em todos os projetos. É uma das vias para se che-
gar a um projeto bem-sucedido e, normalmente, determina se as expectativas
dos stakeholders foram atendidas. Por exemplo, um projeto pode ser concluí-
do rapidamente com investimento mínimo em gerenciamento da qualida-
de, contudo o nível de confiança no que ele produziu pode ter sido afetado,
significativamente.
O processo de Planejamento da Qualidade visa ao cumprimento de padrões
de qualidade relevantes para o projeto em questão, elaborando, para tanto,
um plano. O plano de Gerenciamento da Qualidade especifica como a polí-
tica de qualidade será implementada pela equipe do projeto no decorrer das

144 • capítulo 5
atividades. Assim, este processo é responsável por identificar e definir como
fazer para obter a satisfação daquilo que o projeto considera como qualidade.
Perceba que todo o conteúdo discutido neste capítulo será usado para aju-
dar a desenvolver o plano de gerenciamento da qualidade aplicada ao desenvol-
vimento de projetos.

5.4.1  Conceito de Qualidade

O guia PMBOK conceitua Qualidade como: “a totalidade de características de

uma entidade que a torna capaz de satisfazer necessidades declaradas ou im-
plícitas”. Em outras palavras, para se ter qualidade, o produto ou serviço deverá
atender aos seguintes critérios:
•  Adequação ao uso (o produto ou serviço pode ser usado?);
•  Adequação ao propósito (o produto ou serviço atende aos objeti-
vos propostos?);
•  Satisfação do cliente (o produto ou serviço atende as expectativas
do cliente?);
•  Conformidade com as especificações (o produto ou serviço está de acordo
com os requisitos estabelecidos?).

5.4.2  Princípios Básicos

Os princípios definidos para o gerenciamento da qualidade do projeto são ba-

sicamente os seguintes:
•  Satisfação do cliente – entender, gerenciar e influenciar necessidades de
forma com que as expectativas do cliente sejam satisfeitas ou excedidas. Isto
exige a combinação de conformidade com especificação (ou seja, o projeto deve
produzir o que foi dito que produziria) e conveniência para o uso (o produto ou
serviço produzido deve satisfazer às necessidades reais).
•  Prevenção ao invés de inspeção – o custo destinado a evitar erros é sempre
muito menor que o custo para corrigi-los.
•  Responsabilidade do gerente – o sucesso exige a participação de todos os
membros da equipe, mas permanece a responsabilidade do gerente em forne-
cer os recursos necessários para o êxito.

capítulo 5 • 145
5.4.3  Processo de Gerenciamento da Qualidade em Projetos
Segundo PMBOK

O gerenciamento da qualidade segundo PMI, fornece os métodos e ferramen-

tas visando assegurar-se com que o projeto alcance seus objetivos de modo a
satisfazer as necessidades para as quais ele foi empreendido. Este processo
desempenha um papel importante no planejamento do projeto, e estabelece
as principais funções do gerente, durante a fase de Execução das atividades
do projeto.
Os objetivos do gerenciamento da qualidade, neste caso, são:
•  Aumentar o grau de confiabilidade nos produtos gerados pelo projeto;
•  Reduzir o risco de falhas; e
•  Aproveitar as oportunidades de melhoria contínua.

O Gerenciamento da Qualidade deve incorporar técnicas e ferramentas de

controle de forma a garantir com que os produtos gerados apresentem as carac-
terísticas para as quais foram concebidos.
Esta parte do gerenciamento de projetos envolve também os processos para
gerenciar mudanças, problemas e incidentes emergentes.
O Gerenciamento da qualidade é realizado a partir de três estágios:
•  Planejamento da qualidade;
•  Controle da Qualidade; e
•  Ações corretivas

5.4.4  Planejamento da Qualidade

O objetivo desta atividade é identificar quais padrões de qualidade são rele-

vantes para o projeto e a forma de satisfazê-los. Elaborar o Plano da Qualidade
pode exigir ajustes no custo ou no cronograma para incorporar as atividades
de prevenção, além de análise detalhada de risco para problemas identificados
pelo controle da qualidade.
A elaboração do plano de gerenciamento da qualidade é responsabilidade
do gerente do projeto. Os principais passos na elaboração do plano são:
•  Definição das características e atributos dos produtos gerados pelo projeto;

146 • capítulo 5
 •  Definição das normas, padrões e procedimentos que serão usados para
comparar as características esperadas dos produtos com as características efe-
tivamente alcançadas durante a execução projeto;
•  Seleção de pontos de controle das características e elaboração das
checklists bem como dos critérios pelos quais os produtos gerados serão acei-
tos ou rejeitados;
•  Comunicação aos envolvidos no projeto acerca dos mecanismos que se-
rão adotados para assegurar a qualidade. É importante que os interessados se-
jam informados com relação à forma como a qualidade será alcançada.

As habilidades e a experiência das pessoas que irão elaborar o plano da qua-

lidade no projeto são fatores determinantes na efetividade deste processo. O
plano da qualidade deve definir com clareza em que pontos as características
dos produtos gerados pelo projeto serão medidas. Estes pontos são chamados
de pontos de controle ou pontos de verificação.
As fases do projeto devem ser estruturadas de forma a permitir com que as
características dos produtos gerados sejam facilmente medidas e comparadas
como o especificado.

5.5  Plano de Gerenciamento da Qualidade

O plano da qualidade estabelece as políticas, responsabilidades e procedimen-
tos que serão usados para assegurar um adequado nível de qualidade aos pro-
dutos ou serviços que devem ser seguidos por todos os participantes no pro-
jeto. Este documento resume o sistema de decisões e instruções com relação
à garantia e ao controle da qualidade. A elaboração do plano da qualidade é
baseada no entendimento das expectativas do cliente, esclarecidas nas fases
iniciais do projeto.
Na terminologia ISO 9000, o plano deve descrever o sistema de qualidade do
projeto: “a estrutura organizacional, responsabilidades, procedimentos, pro-
cessos e os recursos necessários para implementar a gerência da qualidade”.
Além da Garantia de Qualidade e do Controle da Qualidade, o plano de
Gerenciamento da Qualidade aborda também os critérios de aceitação dos pro-
dutos gerados pelo projeto.

capítulo 5 • 147
 A equipe do projeto e os principais stakeholders estabelecem, previamente,
os critérios para definir o aceite de cada produto ou serviço a ser entregue.
No momento da entrega, os produtos ou serviços são avaliados com relação
a estes critérios antes que sejam formalmente aprovados.
É comum acordar que haja um documento para cada entrega principal, o
qual necessite de aprovação e de um documento que defina os critérios da acei-
tação para o projeto como um todo.
Os critérios de aceite variam de acordo com o que está sendo produzido.
Ao criar um formulário de aceite, a equipe deve prever uma coluna para cada
critério do aceite, uma coluna para expectativas do cliente, e uma outra para os
resultados reais. Se a entrega atingir os critérios indicados, o cliente assina no
campo apropriado, significando que ele aceita o produto e atesta conformida-
de com os requisitos.
É essencial que o gerente e a equipe do projeto entendam claramente os
requisitos e expectativas do cliente (usuário) com relação à qualidade do pro-
duto principal e dos produtos intermediários do projeto, ao preparar ou revisar
o plano da qualidade.

5.6  O que usamos para elaborar o plano

Política da qualidade:
Uma declaração que descreve se a abordagem que a equipe do projeto irá
adotar para garantir com que os produtos gerados pelo projeto estão em con-
formidade com as especificações. A equipe poderá adotar a política da qualida-
de da organização que conduz o projeto, ou formular uma política própria, caso
não exista a política da empresa.

Especificações – expectativas do cliente:

A qualidade é baseada na percepção do cliente sobre os produtos gerados e
como eles atendem às suas expectativas. A adequação dos produtos do projeto
aos objetivos para os quais foram criados fornecem o seu nível de qualidade. A
equipe do projeto deverá identificar e documentar (se necessário negociar) as
expectativas (características, atributos) e assegurar com que a equipe e o cliente
tenham entendimento comum sobre eles.

148 • capítulo 5
 Normas, padrões e procedimentos:
As normas e os procedimentos relevantes para o projeto devem ser identi-
ficados e documentados. Isto inclui todas as regulamentações específicas da
natureza do projeto em trabalho. Mecanismos devem ser colocados em práti-
ca para assegurar com que as normas e procedimentos sejam completamente
atendidos pelos produtos gerados a partir do projeto.

Outros procedimentos internos da empresa:

Procedimentos internos podem ser considerados importantes para o plane-
jamento da qualidade do projeto. Exemplos destes procedimentos podem ser
os processos relativos ao gerenciamento do risco ou ao suprimento.

5.7  Controle da Qualidade

As atividades de controle da qualidade são realizadas continuamente durante a
execução do projeto, e em pontos definidos, para avaliar se o gerenciamento, e
se os produtos ou serviços entregues atendem aos critérios de aceite, estabele-
cidos na fase de planejamento, além de identificar formas para eliminar causas
de resultados insatisfatórios em decorrência do projeto.
O controle da qualidade é, portanto, o processo contínuo de revisão e testes,
realizado em pontos de controle pré-definidos onde o progresso e as caracterís-
ticas dos produtos gerados pelo projeto são examinados em detalhe.
O controle da qualidade adequadamente aplicado faz com que a equipe do
projeto seja mais eficaz, uma vez que previne situações nas quais o trabalho
resulte em produtos que possam vir a ser rejeitados por não atenderem aos cri-
térios estabelecidos.
Neste caso, a equipe deve monitorar (medir) os resultados do projeto, e deter-
minar se eles estão de acordo com os padrões de qualidade estabelecidos, além
de identificar as formas para eliminar as causas de desempenhos insatisfatórios.
Assim, a equipe identifica desvios e sugere ações corretivas para saná-los.
Os métodos utilizados podem ser:
•  Teste dos produtos para determinar o nível de conformidade com
as especificações;
•  Avaliação da satisfação dos stakeholders com os produtos do projeto;

capítulo 5 • 149
 O patrocinador do projeto deve receber, regularmente, relatórios que resu-
mam o andamento do controle da qualidade do projeto.
Estes relatórios podem incluir dados estatísticos como, por exemplo, o nú-
mero de não conformidades encontradas bem como ações corretivas tomadas.

ATIVIDADES
01. Qual a importância dos 14 princípios da qualidade, criados por Deming, para uma orga-
nização que deseja desenvolver um programa de qualidade?

02. Para que serve o ciclo PDCA?

03. Caracterize os quatro estágios da gestão da qualidade: controle do produto ou inspeção,

controle do processo ou controle estatístico; garantia da qualidade; e gestão estratégica da
qualidade. Aponte os pontos positivos e as limitações de cada um deles.

REFLEXÃO
Chegamos ao final do nosso livro de Gestão da Qualidade em Projetos. Este último ca-
pítulo teve como tema principal, a abordagem do conceito de Qualidade, sua evolução e
principais características. A ideia não foi esgotar o assunto, mesmo porque ele é bastante
amplo e abrangente (sendo trabalhado na maioria dos cursos de graduação, em todas as
áreas de conhecimento, profissão e segmento), mas sim mostrar sua importância para o
sucesso gerenciamento de projetos nas organizações. Vimos que quanto maior for o projeto,
mais importante se torna seu gerenciamento e acompanhamento de todas as etapas e áreas
de conhecimento que o Gui PMBOK orienta.
Esperamos que este conteúdo tenha sido compreendido e que ele de fato faça a diferen-
ça em seus estudos e na sua formação. Sucesso!

LEITURA
Deming e os 14 princípios de qualidade
Para você avançar nos conhecimentos sobre qualidade, recomendamos a leitura do texto
abaixo, que é um resumo dos 14 princípios da qualidade postulados por Deming no livro Saia
da Crise. No Brasil, este livro foi publicado pela Editora Futura em 2003.

150 • capítulo 5
 “Os 14 princípios da qualidade são a base para a transformação da indústria. Não basta
resolver problemas, sejam eles grandes ou pequenos. Os 14 pontos aplicam-se a todos os
tipos de organizações, grandes ou pequenas, de bens ou de serviços. Também se aplicam
às divisões de uma empresa. A adoção e a prática desses 14 pontos indicam que uma em-
presa tem a intenção de sobreviver por muito tempo, protegendo os investidores e crian-
do empregos.
Há dois tipos de problemas para as empresas resolverem: (1) os problemas de hoje; e
(2) os problemas do futuro.
Os problemas de hoje incluem manutenção da qualidade dos bens produzidos, controle
da produção (para que ela não seja muito maior do que as vendas previstas para o futuro
imediato), orçamentos, empregos, lucros, vendas, serviços, relações públicas, estimativas e
assim por diante.
É muito fácil deixarmo-nos consumir pelos problemas do presente, tornando-nos cada
vez mais eficientes na resolução deles, porém, negligenciando os problemas do futuro.
Os problemas do futuro requerem, antes de mais nada, firmeza de propósito e dedicação
no sentido de melhorar a qualidade dos produtos e dos serviços. Assim, a empresa fortale-
cerá sua posição competitiva, se firmará no mercado e criará novos empregos. Para isso no
entanto, é fundamental que o presidente e a diretoria da empresa estejam comprometidas
com as seguintes obrigações:
•  Inovar
•  locar recursos para o planejamento de longo prazo;
•  Oferecer serviços e produtos que contribuam para o bem-estar do consumidor;
•  Buscar novos insumos;
•  Melhorar os métodos de produção;
•  Investir em treinamento de pessoal.

Não podemos mais tolerar os níveis normalmente aceitos de erros, defeitos, insumos
inadequados, profissionais que não sabem o que devem fazer e que têm medo de perguntar,
danos causados por manuseio impróprio de mercadorias, métodos antiquados de treinamen-
to no ambiente de trabalho, supervisão inadequada e ineficaz, administradores descompro-
missados com a empresa.
Não depender dos mecanismos de inspeção para garantir qualidade. Contar o tempo
todo com mecanismos de inspeção para garantir qualidade equivale a contar com a incidên-
cia de defeitos e admitir que o processo de produção não está à altura das especificações.
A inspeção vem tarde demais, os defeitos já estão lá. Além disso, é ineficaz e dispendiosa.
Quando um produto transpõe os portões de uma fábrica, já é tarde demais para fazer alguma
coisa acerca de sua qualidade. A qualidade não vem da inspeção, mas do aperfeiçoamento

capítulo 5 • 151
do processo de produção. Inspeção, retrabalho, degradação e sucateamento de produtos não
constituem medidas de correção do processo de produção. O retrabalho custa dinheiro. É im-
portante que a inspeção seja feita no momento exato para que o custo total seja minimizado.
É preciso também abandonar a prática de escolher fornecedores com base apenas no
preço. Não podemos mais abrir mão da qualidade dos produtos e serviços exclusividade aos
sabores da competição por preços mais baixos – não nos dias de hoje, quando a demanda
por uniformidade e confiabilidade é maior do nunca. Preços não significam nada sem uma
medida exata da qualidade daquilo que é comprado. Na ausência de medidas de qualidade
adequadas, as concorrências são vencidas pelas ofertas de preço menor e o resultado inevi-
tável disso é qualidade inferior e custos altos.
Os departamentos de compra das organizações devem mudar de enfoque e considerar,
em vez do custo inicial mais baixo, o custo total mais baixo dos materiais a ser comprados. Isso
requer preparo. Também é preciso compreender que as especificações que acompanham os
produtos à venda não contam toda a história a respeito do desempenho desses produtos.
Materiais e componentes podem funcionar muito bem isoladamente, mas apresentar
problemas quando agregados na linha de produção ou no produto final. Portanto, é preciso
observar uma amostra desses materiais ao longo de todo o processo e avaliar seu desempe-
nho, tanto na montagem de estruturas complexas quanto junto ao consumidor.
Um relacionamento de longo prazo entre compradores e fornecedores é essencial para a ob-
tenção de economia. Há vantagens operacionais nessa parceria. Muito embora dois fornecedores
produzam materiais de excelente qualidade, sempre haverá diferenças. Todos os profissionais de
produção sabem que a troca de fornecedores implica em perda de tempo. Esse tempo pode ser de
apenas 15 minutos. Ou pode ser de oito horas numa mineradora. Ou pode ser de semanas. As va-
riações entre os lotes de um único fornecedor são suficientes para causar problemas na produção.
Não é difícil supor que as variações entre os lotes de diferentes fornecedores causem
problemas ainda maiores”.
Fonte: Adaptado: DEMING, W. E. Saia da crise. São Paulo: Editora Futura, 2003.

REFERÊNCIAS BIBLIOGRÁFICAS
ABNT. NBR ISO 9000: 2000.
ATTADIA, L.; MARTINS, R. Medição de desempenho como base para a evolução da melhoria
contínua. Revista Produção, ABEPRO, v.13, n.2, pp. 33-41. 2003.
BESSANT, J., CAFFYN, S; GALLAGHER, M. An evolucionary model of continous improvement
behaviour. Technovation. March, 2000.

152 • capítulo 5
BESSANT, J.; CAFFYN, S.; GILBERT, J.; HARDING R & WEBB, S. Rediscovering continous
improvement. Technovation. v. 14. n.1, 1994.
CARAVANTES, G.; PANNO, C.; KLOECKNER, M. Administração: teorias e processo. São Paulo:
Pearson Prentice Hall, 2005.
CARONA, N. Os prêmios de excelência da qualidade brasileiro e europeu. Anais. V SIMPOI. São
Paulo: FGV-EAESP, 2002.
CARVALHO, M. M et. al. Gestão da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005.
DEMING, W. E. Saia da crise. São Paulo: Editora Futura, 2003.
FQN. Critérios de Excelência. Fundação Nacional da Qualidade (FQN). Disponível em http://www.
fnq.org.br. Acesso em: 01/05/ 2008.
GARVIN, D. A. Gerenciando a qualidade: a visão estratégica e competitiva. Rio de Janeiro:
Qualitymark, 1992.
GRONROOS, C.: Marketing: gerenciamento e serviços. 13. ed. Rio de Janeiro: Campus, 1993.
JURAN, J. M; GRYNA, F. M. Controle da qualidade: handbook. São Paulo: Makron Books, 1991. (vol.6)
JURAN, J. M. Mangerial breakthrough. New York: McGrawHill, 1995.
KANO. N. A perspective on quality activities in american firms. In:
COLE, R. E. (ed.) The death and life of american quality movement. New York, Oxford University
Press, 1995, p. 215-235.
LACOMBE, F.; HEILBORN, G. Administração: princípios e tendências. São Paulo: Saraiva, 2003.
LEE, R.; DALE, B. Policy Deployment: an examination of the theory. International Journal of Quality.
MCB University Press, v.15, n. 5. 1998.
LIMA, S.A.; MARTINS, M. F. A gestão da qualidade na indústria de calçados de Franca-SP. V
SIMPOI (Simpósio de Administração da Produção, Logística e Operações Internacionais).
Anais. ISSN 15186539. São Paulo: FGV- EASP, 2002.
MARTINS, R. Controle Estatístico de Processo. Material didático da Disciplina Estatística
Industrial e Controle da Qualidade. Curso de Graduação em Engenharia de Produção: UFSCar, 2002.
MARTINS, R. Modelo para avaliação da evolução da gestão da qualidade em empresas industriais:
proposta e Aplicação em Pequenas e Médias Empresas Industriais da Cidade de São Carlos.
Dissertação de mestrado apresentada ao Programa de pós Graduação em Engenharia de Produção da
UFSCar. 1999.
MARTINS, R.; TOLEDO, J. Proposta de modelo para elaboração de programas de gestão para a
qualidade total. Revista de Administração, São Paulo v.33, n.2, pp.52-59, abril/junho 1998.
MAXIMIANO, A. Teoria geral da administração: da revolução urbana à revolução digital. 6. ed.
São Paulo: Atlas, 2006.
MERLI, G. The tqm approach to capturing global markets. Ifs, uk, 1993.

capítulo 5 • 153
MORAES, E. uma análise crítica sobre o impacto dos fundamentos nos critérios de excelência do PNQ.
Anais. V SIMPOI. São Paulo: FGV-EAESP, 2002.
MONTGOMERY, D. C. Statistical quality control. 2. ed. New York, John Wiley & Sons, 1991.
MOTTA, F.; VASCONCELOS, I. Teoria Geral da Administração. São Paulo: Pioneira Thompson
Learning, 2002.
RIBEIRO, A. Teorias da Administração. São Paulo: Saraiva, 2003.
ROBLES JR, A. Custos da Qualidade: uma estratégia para a competição global. São Paulo:
Atlas, 1994.
SAVOLAINEN, T. Cycles of continuous improvement: realizing competitive advantages through
quality. International Journal of Operations & Production Management. v. 19. n.11, 1999.
SHIBA, S. et al. A new american tqm. Capítulos 1 e 2. Editora Productivy. 1993.
SHIBA, S. ET. al. Introduction to hoshin management. Center for Quality of Management Journal.
v.4. n.3 Fall, 1995.
SHIBA, S et al.. TQM: quatro revoluções na gestão da qualidade. Artes Médicas. Porto Alegre: 1997.
SILVA, R. Teorias da Administração. São Paulo: Pioneira Thompson Learning, 2002.
SLACK, N. et. Al. Administração da Produção. Editora Atlas, 1997.
TOLEDO, J. C. Enfoque dos principais autores para a gestão da
qualidade. Apostila da Disciplina Planejamento e Gestão da Qualidade
do Departamento de Engenharia de Produção da Universidade Federal de São Carlos. 2000.
TOLEDO, J. C; CARPINETTI, L. C. Gestão da Qualidade. Capítulo13. Fábrica do Futuro, NUMA,
Editora Banas. 2000.

GABARITO
Capítulo 1

01. Sim, é possível e recomendado. Uma vez que um processo sistematizado seja seguido
e ganhe maturidade, resultados de sucessos conseguidos em um determinado projeto po-
derão ser reproduzidos em outros projetos que sigam o mesmo processo de gestão. Lógico
que o ideal é termos pessoas sensacionais trabalhando em processos sistematizados, "repe-
tíveis" e maduros. Contudo, apenas pessoas sensacionais não garantem que um sucesso de
agora possa ser repetido em outros projetos, mesmo com as mesmas pessoas
02. PMI é uma instituição sem fins lucrativos cujas siglas representam Project Management
Institute que tem por objetivo estabelecer o estado da arte de gestão de projetos e também
a profissionalização da gestão do projeto no mundo.

154 • capítulo 5
03.
Certificação
O PMI oferece seis certificações que atestam conhecimento e competência, dentre as quais,
a de Profissional em Gerenciamento de Projetos (PMP)®, que conta com mais de 370.000
profissionais certificados em todo mundo. Os salários e oportunidades de carreiras dos pro-
fissionais certificados demonstram que os empregadores reconhecem o valor agregado por
aqueles que possuem essas certificações.
Padrões Globais
Os 12 padrões para gerenciamento projetos, programa e de portfolio do PMI são os padrões
com mais alto reconhecimento na profissão – e que, cada vez mais, vêm se tornando o mo-
delo para o gerenciamento de projetos em empresas e governos.
Esses padrões são desenvolvidos pelos milhares de voluntários qualificados e atualizados do
PMI, com experiência em todos os tipos de projetos, e estabelecem uma linguagem comum
para o gerenciamento de projetos em todo o mundo.
Treinamento e Educação
O PMI oferece uma ampla gama de oportunidades de desenvolvimento profissional, desde
nossos SeminarsWorld® e cursos de ensino a distância (e-learning) para congressos mun-
diais e outros eventos do PMI.
Você também pode se dirigir a um dos mais de 1400 Provedores Registrados de Educação
(REPs) para formação e desenvolvimento continuado em gerenciamento de projetos. Aque-
les que estudam em instituições de ensino superior podem contar com os mais de 60 pro-
gramas de graduação e pós-graduação já reconhecidos pelo Centro de Acreditação Global
do PMI para Programas de Educação em Gerenciamento de Projetos.
Pesquisa
O Programa de Pesquisa do PMI, o mais extenso na área, promove a ciência, a prática e a
profissão de gerenciamento de projetos. O Programa promove o conhecimento em gerencia-
mento por meio de projetos de pesquisa, simpósios e pesquisas, divulgando essas informa-
ções através de publicações, conferências de pesquisa e sessões de trabalho.
04.
( P ) Ações para o desfile de carnaval de um determinado ano.
( TO ) Construção de carros em série em uma linha de b) montagem.
( P ) Ações para a criação de um novo modelo de carro de uma determinada montadora.
( P ) Desenvolvimento de um novo d) software de ERP para uma determinada empresa.
( TO ) Ações do setor de RH para a emissão de pagamentos dos funcionários de uma de-
terminada empresa.

capítulo 5 • 155
( P ) Ações de uma empresa para determinar o processo de emissão de pagamentos dos
funcionários de uma determinada empresa.
( TO ) Tarefas associadas a um funcionário de uma lanchonete para a confecção de lanches
padrões desta lanchonete.

Capítulo 2

01.
•  Gerenciamento/Gestão de integração do projeto: A Gerência da integração do proje-
to é o núcleo do gerenciamento de projetos, e é composto dos processos do dia a dia com
os quais o gerente de projetos conta para garantir que todas as partes do projeto funcionem
juntas. É um processo contínuo que o gerente executa para garantir que o projeto prossiga
do início ao fim.
•  Gerenciamento/Gestão do escopo do projeto: Gerenciamento do Escopo é composto
dos processos para garantir que o projeto inclua todo o trabalho exigido, e somente o traba-
lho exigido, para completar o projeto com sucesso.
•  Gerenciamento/Gestão de tempo do projeto: O objetivo da gerência do tempo de pro-
jeto é descrever os processos requeridos para o término do projeto, garantindo que o mesmo
cumpra com os prazos definidos em um cronograma de atividades.
•  Gerenciamento/Gestão de custos do projeto: A gerência do custo do projeto agrega
os processos que envolvem planejamento, estimativa, orçamento e controle de custos que
serão necessários para a conclusão do projeto a partir de uma previsão orçamentária.
•  Gerenciamento/Gestão da qualidade do projeto: Originalmente, tal função era relativa
e voltada para a inspeção; hoje, as atividades relacionadas com a qualidade ampliaram-se
bastante e são consideradas essenciais para o sucesso estratégico do projeto.
•  Gerenciamento/Gestão de recursos humanos do projeto: Gerenciamento de recur-
sos humanos do projeto tem como base a identificação e documentação de funções, respon-
sabilidades e relações hierárquicas do projeto em relação aos recursos humanos envolvidos,
além da criação do plano de gerenciamento de pessoal. Obtenção dos recursos humanos
necessários para terminar o projeto.
•  Gerenciamento/Gestão das comunicações do projeto: Inclui os processos necessá-
rios para assegurar que as informações do projeto sejam geradas, coletadas, distribuídas,
armazenadas, recuperadas e organizadas de maneira oportuna e apropriada. Os gerentes de
projetos gastam a maior parte do seu tempo se comunicando com os membros da equipe e
outras partes interessadas do projeto, quer sejam internas (em todos os níveis da organiza-
ção) ou externas à organização.

156 • capítulo 5
•  Gerenciamento/Gestão de riscos do projeto: Os Riscos de projeto são um conjunto
de eventos que podem ocorrer sob a forma de ameaças ou de oportunidades que, caso se
concretizem, influenciam o objetivo do projeto, negativamente ou positivamente.
•  Gerenciamento/Gestão de aquisições do projeto: O Gerenciamento de Aquisições
do Projeto é responsável por cuidar das compras e aquisições de produtos, serviços ou re-
sultados necessários para a realização do trabalho. A organização pode ser o comprador ou
fornecedor do produto, serviço ou resultado.
•  Gerenciamento das Partes Interessadas do Projeto: O gerenciamento das partes
envolvidas do projeto concentra-se em um dos elementos mais importantes da gestão de
projetos, e gerencia os interessados, suas expectativas, e compromissos.
02. As fases do ciclo de vida de gerenciamento de projetos se interagem intensamente.
Então, podemos dizer que os processos que compõem essas fases também estão se intera-
gindo intensamente. A coordenação da interação desses processos é de responsabilidade
da gerência de integração, uma vez que é nessa área de conhecimento que se decide como
cada área será planejada. Ex.: A gerência de integração é quem irá compor o plano de geren-
ciamento do projeto que irá definir e coordenar todos os planos de gerenciamento auxiliares
das outras áreas de conhecimento, inclusive das áreas de gerenciamento de custo, tempo e
risco, conforme citado no exemplo anterior. Por isso, voltamos a dizer que a gerência de in-
tegração é responsável pela integração dos processos entre os grupos de processos (fases)
do ciclo de vida de gerenciamento de projetos para realizar os objetivos do projeto dentro dos
procedimentos definidos da organização.
03. O gerenciamento de escopo trata dos limites do projeto, estabelecendo tudo o que está
dentro do projeto e tudo o que está fora do projeto (às vezes, especificar o que está fora
é quase tão importante do que especificar o que está dentro, por causa dos requisitos de
contexto e requisitos não funcionais dos softwares). Definir corretamente o escopo é uma
das partes mais importantes do gerenciamento de projeto, pois se pensarmos em qualidade
como um conceito relacionado com o atendimento dos requisitos dos stakeholder, então
determinar muito bem esses requisitos é o primeiro passo para entregar um produto/serviço
de qualidade e ter sucesso no projeto.
04. Na fase de definição de escopo, temos a etapa de preparação de uma declaração de
escopo detalhada para o projeto. Ela envolve a identificação de qual o trabalho a ser realiza-
do e os responsáveis, o dimensionamento dos pacotes de trabalho, ou work packages (WP)
e a criação de um dicionário que explique os aspectos técnicos da EAP.
05. A EAP é a estrutura analítica do projeto. Embora em um primeiro momento o nome em
português desta ferramenta possa parecer estranho, quando analisamos o nome em inglês
fica mais fácil entender qual é a proposta desta ferramenta.

capítulo 5 • 157
WBS é o termo em inglês referente a EAP e significa work breakdown structure, que
quer dizer:
Work: esforço físico ou mental sustentável para transpor obstáculos e atingir um objetivo;
Breakdown: divisão em partes ou categorias. Decompor em partes menores;
Structure: algo organizado de forma padronizada ou formalizada.
Assim fica mais fácil de entender que a EAP e a decomposição (breakdown) hierárquica
(structure) orientada a entrega do trabalho (work) do escopo do projeto.
Esses trabalhos devem ser executados pela equipe do projeto para atingir os objeti-
vos do projeto. A decomposição dos trabalhos em partes menores serve para torná-los
mais gerenciáveis.
A EAP é uma ferramenta gráfica, então a decomposição hierárquica do trabalho do projeto
acontece por meio de retângulos e interligações desses retângulos para formar a hierarquia
de trabalho.
06. É a técnica de decomposição do trabalho, que sugere a subdivisão das entregas de
trabalhos em componentes menores e mais facilmente gerenciáveis de forma que, em pro-
cessos futuros do ciclo de vida de gerenciamento de projetos, o tempo e o custo possam
ser estimados de forma confiável. O nível mais baixo da EAP. Cada pacote de trabalho deve
buscar atender às seguintes características:
•  Pode ser estimado de forma realista e confiável;
•  Não permite uma nova subdivisão lógica;
•  Pode ser concluído “rapidamente”;
•  Sua execução pode ser atribuída a uma pessoa ou grupo de pessoas (internos ou externos)
•  Possui um término significativo, produzindo uma entrega
07. A definição de escopo envolve a preparação de uma declaração de escopo detalhada
para o projeto, que envolve a identificação de qual o trabalho a ser realizado e os responsá-
veis, o dimensionamento dos pacotes de trabalho, ou work packages (WP) e a criação de
um dicionário que explique os aspectos técnicos da EAP. Entre os aspectos positivos da
definição de escopo estão:
•  obriga os stakeholders a concordarem com as fronteiras do projeto;
•  durante a execução, permite identificar as mudanças que estão fora do escopo do projeto
e requerem renegociação do contrato original;
•  ajuda a estabelecer critérios que mensurem o sucesso do projeto,
•  de forma que todos os envolvidos os conheçam e estejam de acordo;
•  auxilia a compreensão da equipe de projeto sobre as abordagens e métodos utilizados
no projeto.

158 • capítulo 5
08. Premissas ou suposições são fatores que, para os propósitos do planejamento, são con-
sideradas verdadeiros, reais, ou certos. As premissas afetam todos os aspectos do planeja-
mento do projeto e são parte da elaboração progressiva do projeto. As equipes de projetos
freqüentemente identificam, documentam e validam premissas como parte de seu processo
de planejamento. Por exemplo, se a data na qual uma pessoa chave estará disponível para
o projeto é incerta, a equipe pode assumir uma data de início específica. Podem ser organi-
zacionais, ambientais e externas. Podem ser consideradas como as “cláusulas contratuais”
que se não forem cumpridas, comprometem o sucesso do projeto, ou aquilo que você quer
exigir das partes interessadas. Por exemplo: Disponibilidade de 50% do tempo do cliente
durante os testes. Se o cliente não estiver disponível 50% do tempo, o prazo, provavelmente,
não será cumprido.

Capítulo 3

01. Atrasos na conclusão comprometem o custo, retardam a entrega e consequentemente,

a disponibilidade de iniciar a utilização dos mesmos e/ou entrarem em operação. Atrasos
podem causar também em quebras de cláusulas contratuais e consequente falha do projeto.
Dessa forma, o gerenciamento do tempo se mostra um processo muito importante para que
o projeto seja bem sucedido.
02. Definição de atividades, sequenciamento de atividades, estimativa das durações das ati-
vidades, desenvolvimento do cronograma, controle do cronograma.
03. Lista de atividades. A lista de atividades deve incluir todas as atividades que serão reali-
zadas no projeto. Deve ser organizada como um extensão da EAP para assegurar que esta está
completa e que não inclui qualquer atividade que não seja requerida como parte do escopo do
projeto. Assim como na EAP, a lista de atividades deve incluir descrições de cada atividade para
garantir que os membros da equipe do projeto entenderão como o trabalho será feito.
Detalhamento do suporte; Os detalhes de suporte referentes à lista de atividades devem
ser documentados e organizados de forma a facilitar seu uso por outros processos da ge-
rência do projeto. Os detalhes de suporte devem sempre incluir a documentação de todas
as premissas e restrições identificadas A quantidade de detalhes adicionais varia de acordo
com a área de aplicação.
Atualizações na EAP. Ao utilizar a EAP para identificar quais atividades são necessárias,
a equipe do projeto pode identificar a falta de algum subproduto ou pode ainda determinar
que a descrição dos subprodutos precisa ser clareada ou corrigida. Qualquer uma destas
atualizações deve ser refletida na EAP e na respectiva documentação, como por exemplo a
estimativa dos custos. Estas atualizações são muitas vezes chamadas de refinamentos (re-

capítulo 5 • 159
finements) e ocorrem mais frequentemente quando o projeto envolve uma tecnologia nova
ou em desenvolvimento.
04. Estimar tempo em atividades planejadas é algo complexo em qualquer área, mas na área
de TI esta atividade é um pouco mais complicada pela característica abstrata das tarefas e
seu cunho intelectual, em alguns casos quase “artísticos” (por exemplo o desenvolvimento
de um software científico como processamento de imagem ou biotecnologia). Por isso, é
comum esse processo de estimativa de tempo das atividades seja realizado por pessoas que
estão mais acostumadas com o contexto e natureza do projeto (e que utilizam a experiência
delas para realizar estimativas mais confiáveis) e também é realizado em caráter progressivo,
à medida que as informações necessárias para as estimativas vão ficando cada vez mais cla-
ras. Mas, não só a “arte” e a experiência ou conhecimento tácito dos colaboradores são alter-
nativas para este processo. Há técnicas sistematizadas como pontos por função e pontos de
caso de uso que podem ser utilizadas juntamente com bases históricas para a determinação
de estimativas de tamanho de software.
05. Gráfico de Gantt
Método do caminho crítico – por meio dessa técnica é possível descobrir em um gráfico
de redes qual é o caminho de atividades mais longo que será feito no projeto e aquele que
terminará mais cedo. Com essa análise é possível gerenciar o tempo de entrega do projeto
aplicando então técnicas de paralelismo e compressão às atividades do caminho mais longo,
ou seja, o caminho crítico do projeto!
Aplicação de antecipações e esperas – durante o sequenciamento das tarefas antecipações
e atrasos podem ocorrer e nesta técnica eles são ajustados.
Compressão do cronograma – técnicas para a redução do cronograma sem reduzir o escopo
do projeto: são analisadas as compensações entre custo e cronograma em busca da redução
do tempo de execução de uma dada atividade.
Paralelismo – descobrir no grafo de rede de atividades as atividades que estão seriadas e
tentar a execução das mesmas em paralelo para reduzir o tempo do caminho crítico.
Gráfico de Milestones
Baseline

160 • capítulo 5
06.

Executar
1o Passo
Desenhar: Etapa inicial do projeto e as atividades sem dependência (A, D, G, I)

Atividade Depedência
A -
A
B A, D
C B, F D
D -
G
E A, D
F E, G, I
G - I
H E, G, I
I -
J I
K H, J
Não complete o arco enquanto não tiver clarificado as dependências

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A -
B A, D A B
C B, F
D - E
D
E A, D
G
F E, G, I
G -
H E, G, I I
I -
J I
K H, J

capítulo 5 • 161
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A -
B A, D A
C B, F
D - D
E A, D G
F E, G, I
G -
I
H E, G, I
I -
J I
Convergir na mesma etapa com A e D para iniciar B e E
K H, J
(atenção que A e D começam na mesma etapa...)

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A -
B A, D
C B, F A B
D -
E
E A, D D F
F E, G, I G
H
G -
H E, G, I
I J
I -
J I
K H, J

162 • capítulo 5
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A -
B A, D B
A
C B, F
D E
D -
E A, D G
F E, G, I
G -
I
H E, G, I
I -
J I
K H, J
Juntar E, G, I para iniciar F e H (atenção que J só depende de I ...)

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A - A B
B A, D
C B, F E
D F
D -
G
E A, D H
F E, G, I
G - I J
H E, G, I
I -
J I
Junte B e F para iniciar C; Idem com H e J para iniciar K
K H, J

capítulo 5 • 163
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A - A B
B A, D C
C B, F E
D F
D -
G
E A, D H
F E, G, I
G - I J K
H E, G, I
I -
J I
K H, J

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que já estão desenhadas?

Atividade Depedência
A - A B
B A, D C
C B, F E
D F
D -
G
E A, D H
F E, G, I
G - I J K
H E, G, I
I -
J I
K H, J

Todas as atividades desenhadas.

Não há dependência de C e K que estas convergem na Etapa Final do Projeto

07. Análise de variação. A execução do processo da análise de variação durante a monitora-

ção do cronograma é o elemento chave para o controle do tempo. A comparação das datas
alvos com as realizadas de início e fim, nos fornece informações úteis para a detecção de
desvios e para a implementação de ações corretivas em caso de atraso. As etapas comuns são:
Verificar qualidade das informações coletadas;
Determinar variações entre real x linha de base;
Determinar impacto das variações nos custos e no cronograma;

164 • capítulo 5
Analisar tendências das variações e documentar quaisquer descobertas sobre fontes de va-
riação e área de impacto.

Capítulo 4

01. A análise quantitativa de riscos mensura números e dados tangíveis do projeto, já a aná-
lise qualitativa, envolve subjetividade dos sujeitos envolvidos, que terão percepção distintas
quanto a qualidade do projeto e seus desmembramentos.
02. Gerenciamento de riscos possibilita a chance de melhor compreender a natureza do
projeto, envolvendo os membros do time de modo a identificar as potenciais forças e riscos
do projeto e responder a eles, geralmente associados a tempo, qualidade e custos. Portanto,
a sobrevivência de qualquer empreendimento, atualmente, está intimamente vinculada ao
conceito de aproveitar uma oportunidade, dentro de um espectro de incertezas. O que torna
a gestão dos riscos se tornar tão importante são fatores diversos, como o aumento da com-
petitividade, o avanço tecnológico e as condições econômicas, que fazem com que os riscos
assumam proporções muitas vezes incontroláveis.
03. Um efetivo processo de comunicação é necessário para garantir que todas as informa-
ções desejadas cheguem às pessoas corretas no tempo certo e de uma maneira economi-
camente viável.
Sempre que pensamos em gerenciamento de projetos, logo, pensamos em administra-
ção de tempo, escopo e qualidade, na verdade, a administração de todas estas áreas requer
do gerente de projeto uma gama de habilidades e técnicas efetivas, pois muitos elementos
precisam ser coordenados. Manter um time unido e sólido, e atender as expectativas dos
stakeholders é um dos grandes desafios que um gerente de projeto enfrenta.
Um bom plano de comunicação pode ser chave para que a execução e o controle do pro-
jeto tenham sucesso. Portanto, é responsabilidade desta área de conhecimento fornecer as
ligações entre pessoas e informações adequadas, sendo que entenderemos como pessoas
todos os stakeholders do projeto, como partes interessadas, cliente e patrocinador.
04. Stakedolders de um projeto: acionistas da organização, diretoria, clientes, colaboradores,
fornecedores de produtos e serviços, comunidade em que a organização esteja inserida etc.

Capítulo 5

01. Tais princípios são ferramentas norteadoras para um eficaz monitoramento de um pro-
jeto, seu eficaz desenvolvimento e efetividade nas respostas. Com base nos princípios da

capítulo 5 • 165
qualidade, segundo Deming é possível o acompanhamento de qualquer projeto ou processo,
de modo que ele venha atender aos objetivos propostos.
02. Trata-se de uma ferramenta da qualidade, voltada ao planejamento e gestão estratégica,
utilizada para direcionar e priorizar os esforços de melhoria do desempenho em cada nível
hierárquico, de forma que a empresa alcance seus objetivos estratégicos de longo e médio
prazo (LEE; DALE, 1998).
O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995):
•  Plan (planejar) – identificar os problemas-chave a partir de critérios analíticos e quantitati-
vos, determinando como eles podem ser corrigidos;
•  Do (executar) – implementar o plano;
•  Check (verificar) – confirmar quantitativa e analiticamente se houve melhoria no desem-
penho e
•  Act (atuar) – atuar corretivamente caso o desempenho esteja fora do padrão determinado.
Modificar, documentar e utilizar o processo adequadamente.
03.
Controle do produto ou inspeção
O controle do produto formalizou-se com a produção em massa e a necessidade de peças
intercambiáveis, sendo executado através da criação de um sistema de medidas, gabaritos e
acessórios, cujo foco principal era a verificação de erros (MAXIMIANO, 2006).
A conformidade em relação ao padrão e a uniformidade dos produtos eram as preocupa-
ções primordiais, e não a resolução de problemas. Além disso, nesse período, a quantidade
produzida de produtos era mais importante do que a qualidade, reforçando a mentalidade de
praticar o controle para encontrar os defeitos ao invés de evitá-los (GARVIN, 1992).
Controle estatístico ou do processo
O controle do processo deu à qualidade um caráter científico através da utilização de técni-
cas estatísticas para verificar a uniformidade dos produtos
(SILVA, 2002).
A preocupação passa a ser o nível de variabilidade do processo e a inspeção passa a ocorrer
por amostragem (MOTTA; VASCONCELOS, 2002).
Com o crescimento das empresas e da expansão da produção em massa, tornou-se im-
praticável inspecionar a totalidade dos produtos, surgindo, assim o controle estatístico da
qualidade (MAXIMIANO, 2006).
Garantia da Qualidade
Na era da garantia da qualidade, o foco deixa de ser a fábrica e passa para o gerenciamento
de todo o processo, da matéria-prima ao consumidor final, destacando-se a prevenção de
problemas (GARVIN, 1992). Com essa nova dimensão, a qualidade deixa de ser atributo ape-

166 • capítulo 5
nas do produto ou serviço. Deixa de ser também responsabilidade exclusiva do departamento
da qualidade. A qualidade é problema de todos e envolve todos os aspectos da operação da
empresa. A qualidade exige visão sistêmica, para integrar as ações das pessoas, as máqui-
nas, informações e todos os outros recursos envolvidos na administração da qualidade. Esta
ideia implica a existência de um sistema da qualidade (TOLEDO, 2000).
Gestão Estratégica da Qualidade
Nesta fase, a qualidade é elevada ao nível estratégico, transformando-se na base para en-
frentar a concorrência (GARVIN, 1992). Dentro deste contexto, a qualidade adquire status
de sistema de gestão, ligando-se aos objetivos estratégicos e tendo como foco a lucrativida-
de da organização, através da melhoria contínua (SHIBA et al, 1997).

capítulo 5 • 167