GESTO DA QUALIDADE

EM PROJETOS

autoras
HELCIMARA AFFONSO DE SOUZA
MARINA SANCHES PAGLIARUSSI

1 edio
SESES
rio de janeiro 2016
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

Coordenao de produo gladis linhares

Coordenao de produo EaD karen fernanda bortoloti

Projeto grfico paulo vitor bastos

Diagramao bfs media

Reviso lingustica 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 (eletrnico ou mecnico, incluindo fotocpia e gravao) ou arquivada em
qualquer sistema ou banco de dados sem permisso escrita da Editora. Copyright seses, 2016.

Dados Internacionais de Catalogao na Publicao (cip)

S729g Souza, Helcimara

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

isbn: 978-85-5548-208-3

1. Gesto da qualidade. 2. Gerenciamento de projetos. 3. PMI. 4. PMBOK.

I. SESES. II. Estcio. cdd 658.4013

Diretoria de Ensino Fbrica de Conhecimento

Rua do Bispo, 83, bloco F, Campus Joo Ucha
Rio Comprido Rio de Janeiro rj cep 20261-063
Sumrio

Prefcio 7

1. Introduo ao Gerenciamento de Projetos 9

1.1 Introduo 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 certificao 25
1.4 Ciclo de Vida e da Organizao de um Projeto 28
1.4.1 Caractersticas do ciclo de vida do projeto 30
1.4.1.1 Potencial de Adicionar Valor ao Projeto 30
1.4.1.2 Custo das Mudanas ou Correes 31
1.4.1.3 Capacidade de Adequao 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 Integrao e
Gerenciamento de Escopo 51

2.1 Processo de Integrao 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 execuo do projeto 59
2.1.4 Monitorar e controlar o trabalho do projeto 60
2.1.5 Realizar o controle integrado de mudanas 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 oramento 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, Comunicaes,

da Qualidade, do Gerenciamento
de Aquisies e Partes Interessadas 113

4.1 Gerenciamento das Comunicaes 115

4.1.1 O Processo de Comunicao 116
4.1.2 Como Identificar um bom plano de comunicao 117
4.1.3 Planejamento das Comunicaes segundo o PMBOK 118
4.1.4 Processo de Gerenciamento da Comunicao 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 anlise qualitativa de riscos 122
4.2.4 Realizar a anlise 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 Aquisies 123
4.3.1 Planejar as Aquisies 124
4.3.2 Conduzir as Aquisies 125
4.3.3 Administrar as Aquisies 125
4.3.4 Encerrar as Aquisies 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 nvel de comprometimento das
partes Interessadas 128

5. A Qualidade Num Projeto e o

Processo de Gerenciamento da Qualidade 133

5.1 Vises 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 Princpios Bsicos 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
Prefcio
Prezados(as) alunos(as),

Bem-vindo a mais uma disciplina de seu curso! A disciplina de Gesto da

Qualidade em Projetos tem como pano de fundo as Boas prticas do PMI, uma
certificao que capacita e habilita profissionais da rea de gerenciamento de
projetos e executar seus projetos com base numa lista de aes tidas como ar-
cabouo para o sucesso na execuo 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 disponvel para as
compras o prazo, e o custo do projeto o preo 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 tambm passa por essas etapas. Guardadas as
propores de complexidade de cada projeto, as etapas que consiste um pro-
cesso de gesto de projeto so as mesmas.
Gerenciamento de projetos, por essncia, existe em diferentes formas e h
muito tempo, mesmo quando no se conhecia com este nome. O uso sistem-
tico de planejamento de projetos comeou a se firmar em meados deste sculo.
Engenheiros civis resolveram que uma tarefa seria dividida em sries de opera-
es; o esquema de operaes seria decidido pelos responsveis pela execuo
e, a partir da, uma sequncia ordenada de execuo se desenvolver, resultan-
do em eficincia (VARGAS, 2009).
Com a atual onda de competitividade global, o desenvolvimento de um
novo produto, a implementao de uma nova tecnologia ou uma mudana or-
ganizacional obrigam as organizaes a achar uma forma mais gil e eficaz, de
atingir seus objetivos. Essas organizaes esto 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-
bm as barreiras culturais e o contato e a comunicao passa a ter como instru-
mento as ferramentas de tecnologia da informao, facilitando as interaes
e promovendo reunies virtuais, agregando valor ainda maior nas relaes e
interaes entre os profissionais envolvidos.

7
 Um programa de gerenciamento de projetos rigoroso pode proporcionar
os mtodos, os processos e as qualidades necessrias para uma organizao se
manter ativa e competitiva com as tendncias e desafios do setor em que atua.
O gerenciamento de projetos, portanto, coincide, em parte, com o geren-
ciamento geral e com outras aplicaes do conhecimento. O time responsvel
pelo projeto deve entender sua relao com o ambiente de negcios, que envol-
ve meios maiores, como ciclos de vida, empreendedores, influncia organiza-
cional, habilidades de gerenciamento e influncias socioeconmicas. Muito do
conhecimento necessrio para gerenciar projetos exclusivo do gerenciamen-
to de projetos, e as tcnicas 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 organizao a desenvolver uma
conscincia dos temas globais e os mecanismos para responder efetivamente
a eles, assegurar que tecnologias facilitadoras so identificadas e usadas para
ir ao encontro das exigncias para uma organizao global e identificar meios
para o desenvolvimento e a disseminao dos produtos e servios exigidos pelo
cliente global (VARGAS, 2009).

Bons estudos!
 1
Introduo ao
Gerenciamento de
Projetos
Vrias so as razes que levam as organizaes a buscar qualidade em suas ati-
vidades e no gerenciamento de projetos essa realidade no diferente. A qua-
lidade hoje tida como uma das principais razes de sucesso nos projetos or-
ganizacionais. So inmeras 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 negcio,
esperam bons resultados e eficcia das empresas. Este cenrio por si s j de-
safiador. Implantar qualquer ao ou estratgia sem um profundo estudo de seu
xito, j uma falha na gesto de uma organizao. Estamos falando de projeto,
que a fase que antecede a execuo de um processo, seja ele estratgico, ttico
ou operacional.
De todos os stakeholders, sabemos que o mais importante para as empre-
sas so sem dvida, os clientes. Toda organizao enfrenta a difcil tarefa de
executar projetos que atendam ou superem as expectativas de seus clientes. No
entanto, globalmente, inmeros projetos so mal sucedidos e concludos fora
do oramento e prazos estabelecidos. Eles no cumprem as normas de quali-
dade e os requisitos esperados pelo cliente. Uma das causas para o seu fracas-
so pode ser atribuda a processos desalinhados e ineficientes resultantes de
uma combinao de problemas, tais como uma gesto do projeto debilitada,
estimativa de custos pobres, mal planejamento e programao, gerenciamento
de requisitos inadequado, planejamento de contingncia inapropriado, bem
como muitos outros.
Vamos conhecer os conceitos essenciais desse assunto to importante para
o sucesso organizacional!

Stakeholders: So indivduos e organizaes ativamente envolvidos direta ou indire-

tamente num projeto, cujos interesses so afetados (positiva ou negativamente) por
ele, ou que exercem influncia sobre o mesmo. Incluem o gerente de projeto, o cliente,
a organizao que far o projeto, os membros da equipe de projeto, o sponsor/patro-
cinador (indivduo/grupo interno ou externo que prov os recursos financeiros para o
projeto). Inclui tambm partes externas, como fundadores, vendedores, fornecedores,
agncias governamentais, comunidades afetadas pelo projeto e a sociedade em geral.

10 captulo 1
 OBJETIVOS
Introduo ao Gerenciamento de Projetos
Definio de Projeto & Gerenciamento de Projetos
O PMI e a certificao PMP
Fases e Ciclos de Vida de Projetos de TI
reas de conhecimento do Gerenciamento de Projetos

captulo 1 11
1.1 Introduo ao Gerenciamento de
Projetos

Para iniciar este captulo, gostaramos de colocar algumas questes para voc
refletir. Mas no pense nessas questes de qualquer maneira, mas sim como
um gestor de negcios. com esse olhar que deveremos encarar esta discipli-
na, como um executivo, administrador de uma corporao.
Vamos discutir um pouco as questes acima. Mas importante lembrar que
aqui no h nenhum especialista em artes, esportes ou histria japonesa e a
nossa discusso ser superficial, apenas para introduzir a importncia do estu-
do em gerenciamento de projetos.
Voc consegue pintar quadros como Leonardo Da Vinci? Provavelmente
no, ele era um gnio e dominava a arte da pintura. Porm, com um bom curso
de pintura voc poder pintar bons quadros. No mesmo?
O que estamos tentando dizer que a cincia pode desenvolver tcnicas,
procedimentos e processos que serviro de meios (caminhos) para uma produ-
o artstica, e, em contrapartida, a arte pode servir de inspirao para o desen-
volvimento da cincia. (Borovik; Ramirez; Ramirez, 2010).

COMENTRIO
Reflita!!!
1. Qual a diferena entre cincias e artes?
2. Por que o Japo conseguiu se reerguer to rapidamente da Segunda Guerra Mundial?

Lgico que, somente com as tcnicas artsticas desenvolvidas pela cincia,

dificilmente iremos criar vrios Leonardo Da Vinci, pois, como vocs j de-
vem ter estudado, a competncia no depende apenas do conhecimento, h,
ainda, a atitude e a habilidade cercando este conceito. Contudo, um arcabouo
de conhecimentos e tcnicas o comeo para a construo dessa competncia.
Agora vamos refletir nossa segunda pergunta: Por que os japoneses conse-
guiram se reerguer to rapidamente aps o terror da Segunda Guerra Mundial?
bvio que so vrios os fatores que levaram o Japo a se reerguer to rapida-
mente aps a Segunda Guerra Mundial, mas gostaramos de dar ateno a um

12 captulo 1
especial: a implantao nas empresas japonesas, principalmente nas empresas
automobilsticas, da tcnica da qualidade total.
Essa tcnica busca atuar principalmente no processo de produo dos bens
e servios 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 tcnica de
qualidade total um conjunto de metodologias e ferramentas que devem ser
aplicadas ao processo produtivo de forma sistemtica, para que este torne-se
maduro o suficiente para produzir sempre produtos de qualidade.
Portanto, podemos pensar que o sucesso das empresas japonesas no ps-guerra
pode ser atribudo sistematizao do processo de produo (principalmente), para
que a qualidade do produto pudesse se repetir a cada unidade produzida, indepen-
dentemente do herosmo das pessoas que esto produzindo cada unidade dessas.
Aps refletirmos sobre essas duas questes to distintas e que mostram
como o contexto, as tcnicas e processos so importantes para o sucesso de
uma ideia. Mas voc deve estar pensando o que essas reflexes tm a ver com
nossa disciplina? E a resposta simples, porm ela vem tambm como uma
nova pergunta: como voc quer gerenciar os seus projetos?
Fazendo analogia com a discusso que tivemos at aqui, para gerenciar
um projeto ns podemos agir pelo lado da arte, dependendo nica e exclusiva-
mente da competncia e do herosmo dos gerentes de projetos e torcer, a cada
projeto que for realizado, para que tudo d certo e tambm torcer para que os
gerentes que saibam gerenciar um projeto nunca saiam da sua empresa, pois
se isto acontecer, juntamente com a sada do seu gerente tambm iro sair os
conhecimentos dele em gerenciamento de projetos.
Ou, ento, 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 utilizao das melhores prticas, 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 sero repetidos em projetos
presentes, pois quase sempre no h uma sistematizao que indique o motivo
pelo qual o projeto anterior deu certo.
J na segunda forma de se gerenciar um projeto, a instituio (ou a equipe,
ou a organizao...) define um processo sistemtico e formalizado por meio do
qual todos os gerentes de projeto devem gerenciar os seus projetos.

captulo 1 13
 Dessa forma, possvel identificar nos projetos findados o que ocorreu de
errado, para que consertos no processo de gesto possam acontecer inibindo,
assim, a repetio da falha. E como todos os gerentes utilizam o mesmo proces-
so, todos eles iro usufruir desta melhoria.
Alm do mais, utilizando a segunda forma, o conhecimento de como ge-
renciar fica tambm na instituio, tornando-se, assim, um ativo dela e no
somente um ativo da cabea de cada gestor.
bvio que um gestor competente ainda essencial para a boa execuo
desse processo de gerenciamento. Contudo, o treinamento de gestores fica
mais facilitado, uma vez que o formalismo do processo de gesto permite a re-
produo deste conhecimento.
Esta facilidade de treinamento permite s empresas (instituies, organiza-
es...) produzir timos gestores.
Ento, pessoal, nesta disciplina iremos estudar o gerenciamento de proje-
tos de acordo com a segunda viso discutida, ou seja, iremos estudar as me-
lhores prticas, metodologias e habilidades de gerenciamento de projetos para
nos ajudar a estabelecer procedimentos que nos apoiem no gerenciamento dos
projetos das nossas empresas, instituies ou, por que no, de nossas vidas.
Mas, por que estudar gerenciamento de projetos?
Difcil encontrar projetos que tiveram total xito, no mesmo? Eles at
existem, mas so difceis de serem encontrados. Isso porque so muitas as va-
riveis 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-
formao, de um relatrio 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 oramento previstos 16,2%
Apresentam reincios 94%
Aumento mdio no custo 189%
Aumento mdio 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 oramento e prazo predeterminados. Na mesma tabela, ainda podemos

14 captulo 1
verificar que, na mdia, os projetos de TI apresentam um acrscimo de 189%
nos custos e de 239% no prazo.
O mesmo relatrio do Standish Group ainda diz que o custo de oportunida-
de perdido algo imensurvel, podendo atingir trilhes de dlares.
Vocs podem estar pensando: mas lgico, construir software deve ser algo
complexo, de forma que em outras reas isso no deve acontecer. Se vocs es-
to pensando assim, j aviso que este pensamento no traduz a realidade.
Veja a tabela 1.2, que mostra os nmeros de um estudo de Benchmark reali-
zado em 2009 pelo PMI (Project Management Institute, que uma organizao
que iremos estudar mais frente) no Brasil, com empresas das mais variadas
reas de atuao.
Por meio dos nmeros, possvel 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 tambm possvel perceber que grande parte
dos projetos apresentam problemas de qualidade e de satisfao do cliente.

PROJETOS EM DIVERSAS REAS 2009

Projetos que no terminam dentro do custo estabelecido 62%
Projetos que no terminam dentro do prazo estabelecido 79%
Projetos com problemas de qualidade 41%
Projetos com problemas com a satisfao do cliente 34%

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

Conseguiram perceber, por meio dos nmeros mostrados acima, como

complexo um projeto, ou seja, como o histrico dos projetos est repleto de
insucessos e com projetos estourando custos, prazos e sendo finalizado com a
gerao de um produto/servio que est muito aqum da qualidade esperada?
Neste momento, bem possvel que vocs estejam se perguntando: O que
que faz com que os projetos falhem?
A mesma pesquisa de Benchmarck feita em 2009 pelo PMI tambm pesqui-
sou quais foram os problemas que ocorreram com mais frequncia nos pro-
jetos das organizaes pesquisadas. A tabela 1.3 a seguir, mostra os 10 princi-
pais problemas.

captulo 1 15
 OS 10 PRINCIPAIS PROBLEMAS ENCONTRADOS NOS PROJETOS
1. Problemas de comunicao 76%
2. No cumprimento dos prazos 71%
3. Mudanas de escopo constantes 70%
4. Escopo no definido adequadamente 61%
5. Concorrncia entre o dia a dia e o projeto na utilizao de recursos 52%
6. Estimativas incorretas e sem fundamentos 52%
7. Riscos no avaliados corretamente 50%
8. No cumprimento do oramento 50%
9. Problemas com fornecedores 37%
10. Retrabalho em funo da falta de qualidade do produto 28%

Tabela 1.3 Benchmarck PMI 2009 problemas que ocorrem com mais frequncia nos
projetos da organizao. 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, so 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 tambm os maiores problemas
encontrados nos projetos desenvolvidos nas empresas brasileiras e vimos que
esses problemas esto localizados nas mais diversas reas.
Ento, nos resta mais uma pergunta: H alguma tcnica cientfica e siste-
matizada que garanta que os esforos empreendidos em um projeto levem
entrega de um produto/servio de qualidade e que atenda, ou exceda, s expec-
tativas do solicitante?
Na verdade no existe uma receita de bolo nica e mgica de como se ad-
ministrar esses esforos de forma a se ter 100% de sucesso na implementao
de um projeto.
Ento quer dizer que no h cincia por trs da gerncia desse esforo de
implantao ou desenvolvimento do software, ou a construo de um estdio
de futebol ou mesmo de um foguete espacial?
Bom, no bem assim. O que temos na rea so colees/compilaes que
apresentam prticas, conhecimentos e tcnicas historicamente bem-sucedidas
quando aplicadas gerncia desses esforos e que, na maioria das vezes, quando
bem aplicadas, levam esse conjunto de esforos a entrega bem-sucedida de um
produto/servio.

16 captulo 1
 A aplicao deste conjunto de tcnicas o que podemos chamar de geren-
ciamento de projetos e por isso que considerada um tema importante na
atualidade: para aprender algumas dessas tcnicas 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 tcnicas,
procedimentos e habilidades que lhe permitiro gerenciar toda essa complexi-
dade de forma sistemtica e repetvel a ponto de aumentar as chances de imple-
mentar um projeto com sucesso e repetir este sucesso em outros projetos futuros.
Para fecharmos este tpico, gostaramos que voc fixasse que um projeto
algo complexo e que no mundo h vrios exemplos de projetos que no tiveram
um final feliz.
Contudo, h tambm projetos que foram finalizados com sucesso, entre-
gando produtos/servios com qualidade, no tempo e no prazo corretos.

1.2 Definindo Projeto

Projetos, dentro de uma empresa, so utilizados como instrumentos para efe-
tuar mudanas ou produzir produtos e/ou servios.
Normalmente, em organizaes modernas, projetos surgem como resulta-
do do planejamento estratgico.
Resumindo: a organizao declara a sua misso (objetivos atuais) e a sua vi-
so (objetivos a mdio e longo prazos), ento uma anlise do ambiente externo
e interno feita identificando ameaas e oportunidades, pontos fortes e fracos;
em seguida, levando em considerao a misso, viso e anlise externa e inter-
na realizada, a organizao formula metas e objetivos estratgicos que sero
implementados por meio de vrios projetos na organizao.
Alinhado ideia do planejamento estratgico, o PMBOK (2008) diz que um
projeto pode surgir por meio de (mas no se limita a):
Desenvolvimento de um novo produto ou servio;
Mudanas organizacionais: estruturais, RH ou estilo;
Aquisio ou implementao de sistemas de informaes novos ou ento
a modificao de sistemas de informaes existentes;
Construo de imobilizados;
Implementao de procedimentos e processos de negcios.

captulo 1 17
 CONCEITO
Um projeto normalmente definido como um empreendimento colaborativo, frequentemen-
te envolvendo pesquisa ou desenho, que cuidadosamente planejado para alcanar um
objetivo particular. Projetos podem ainda ser definidos como sistemas sociais tempo E uma
demanda de mercado, necessidade organizacional, solicitao de um cliente, avano tecno-
lgico ou requisito legal.
A palavra projeto vem da palavra latina projectum do verbo em latim proicere, "antes de
uma ao", que por sua vez vem de pr-, que denota precedncia, 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 ao".
Quando o idioma Portugus inicialmente adotou a palavra, ela se referia a um plano de
alguma coisa, no o ato de realmente levar esse plano a concretizao. Algo realizado de
acordo com um projeto tornou-se conhecido como um "objetivo".
As principais caractersticas dos projetos so:
temporrios, possuem um incio e um fim definidos.
planejados, executado e controlado.
entregam produtos, servios ou resultados exclusivos.
desenvolvidos em etapas e continuam por incremento com uma elaborao progressiva.
realizados por pessoas.
com recursos limitados.
Fonte: www.pmi.org.br

Mas, afinal de contas, o que um projeto?

Um projeto um esforo temporrio empreendido para criar um produto,
servio ou resultado exclusivo!
Um projeto um empreendimento nico, com incio e fim determinados,
que utiliza recursos e conduzido por pessoas, visando a atingir objetivos
predefinidos, caracterizando-se por ser temporrio, exclusivo e progressivo.
(CAVALIERI, 2005).
De acordo com as definies acima, um projeto algo que tem incio e fim,
produz um produto ou servio exclusivo e pode ser feito progressivamente.
Vamos entender cada um desses pontos:

18 captulo 1
 Temporrio1 : quer dizer que o projeto tem um tempo no qual ele exis-
te, iniciando-se em um determinado momento e tendo um fim determinado.
Temporrio no quer dizer de curta durao (h projetos que duram dcadas),
e sim que se trata de um esforo finito.
Temporrio tambm no se aplica ao produto/servio gerado pelo projeto em
questo, e sim aos esforos necessrios para a gerao desses produtos e servi-
os. Temporrio tambm pode ser relativo janela de tempo na qual possvel a
implementao do projeto. Por ltimo, temporrio tambm se aplica equipe do
projeto. Quando o projeto termina, a equipe liberada daquele projeto.
Produtos, servios e resultados exclusivos2 : um produto/servio gerado
por um projeto diferente de um produto gerado por uma linha de montagem
em srie. Os projetos geram produtos/servios exclusivos e, por isso, diferentes
de outros produtos e servios j gerados anteriormente.
Em uma organizao, importante diferenciar projetos do trabalho opera-
cional do dia a dia. Enquanto o primeiro trata de esforos correlacionados e
temporrios para produzir algo nico e exclusivo, o segundo trata da realizao
de processos contnuos e repetitivos.

ATENO
Diferenciando: Projetos, Subprojetos, Programas e Portflio
Subprojetos: Diversas vezes um projeto precisa ser subdividido em partes, de fcil geren-
ciamento e controle, essas diversas partes so as denominadas subprojetos. Os mesmos so
braos de um mesmo projeto e nunca deve ser tratado isolado desse.
Programa: Esse um termo usado para identificar um grupo de projetos relacionados que
so gerenciados e coordenados de modo integrado, obtendo os benefcios e controles que
no existem ao gerenci-los individualmente.
Portflio: um conjunto de projetos, programas e outros esforos que so agrupados para
facilitar o atingimento dos objetivos estratgicos do negcio.

1 Um belo exemplo da importncia do fator tempo em um projeto: imaginem um projeto para desenvolver uma
luneta especfica para a visualizao 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 prdios idnticos em seu design arquitetnico. Eles so produtos exclusivos ou no?
A resposta sim, eles so exclusivos, pois apesar de serem iguais em seu design, eles podem ter sido construdos
em lugares diferentes, exigindo clculos estruturais diferentes, o que poderia resultar em entregas diferentes,
principalmente ligadas estrutura e fundao. Ou, ento, em pocas diferentes, contando, assim, com fornecedores
diferentes e com um ambiente macro e microeconmico diferente, tambm culminado em entregas diferentes. Ou
seja, com resultados exclusivos.

captulo 1 19
 Todos esses objetos (Projetos, Programas e Outros esforos) so mensurveis,
ordenveis e priorizveis.

Como dito anteriormente, os projetos dentro de uma organizao tm por

objetivo (e no somente isso) atender ao planejamento estratgico da empresa,
sendo temporrio e tratado por uma abordagem de gerenciamento de projetos.
J um processo, ou ento trabalho operacional do dia a dia, tambm muito
importante para uma organizao, so esforos repetitivos e permanentes
necessrios para manter o dia a dia operacional da organizao. Esses proces-
sos devem ser tratados por uma metodologia de gerenciamento de processos
como um PDCA3 (SOUSA, 2006).
Muito embora no haja uma receita de bolo que leve o projeto ao triunfo,
o que temos so grandes compilaes de boas prticas de gerenciamento de
projeto que, quando aplicadas, aumentaro 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 no repetitivos, nicos e complexos,
dentro de um cenrio de tempo, custo e qualidade predeterminados.

H vrias compilaes existentes, mas h uma que vem se tornando quase

que um padro no mundo. Esta compilao o PMBOK, desenvolvido pelo PMI.
Os benefcios do gerenciamento de projetos so:
O gerenciamento de projetos proporciona inmeras vantagens sobre as
demais formas de gerenciamento, tendo se mostrado eficaz em conseguir os
resultados desejados dentro do prazo e oramento.
A principal vantagem do Gerenciamento de Projetos que ele no restri-
to a projetos gigantescos, ele pode ser aplicado em empreendimentos de qual-
quer complexidade, oramento e tamanho.
3 PDCA: ciclo PDCA, ou Shewhart, ou Deming um ciclo de desenvolvimento que tem como foco a melhoria
contnua de processos. Foi introduzido primeiramente no Japo, aps a Segunda Guerra Mundial, e tem as seguintes
fases: planejamento (plan), execuo (do), controle (control) e ao (act). (WIKEPEDIA, 2010).

20 captulo 1
 Dentre os principais benefcios, podemos destacar:
Evita surpresas durante a execuo dos trabalhos;
Permite desenvolver diferenciais competitivos e novas tcnicas
Antecipa as situaes desfavorveis e permite aes preventivas
e corretivas.
Adapta os trabalhos ao mercado consumidor e ao cliente;
Disponibiliza os oramentos antes do incio dos gastos;
Agiliza a tomada de deciso j que as informaes esto estruturadas
e disponibilizadas.
Aumenta o controle gerencial de todas as fases a serem implementadas.
Facilita e orienta as revises de estrutura do projeto que forem decorrentes
de alteraes do mercado, melhorando a capacidade de adaptao do projeto.
Otimiza a alocao de recursos.
Documenta e facilita as estimativas para futuros projetos.

1.2.1 O que um projeto bem-sucedido?

Apesar de a resposta questo parecer quase que intuitiva, pode ser que for-
malmente ela no seja to 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 concludos e dan-
do a eles o conceito de projetos bem-sucedidos, como, por exemplo, os Jogos
Panamericanos do Rio de Janeiro ou, ento, o desfile de carnaval de So Paulo
de 2010.
Ou, ento, voc deve estar pensando em alguns projetos que no termina-
ram com a entrega do produto/servio 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, ento ele e bem-sucedido e, se o projeto no entregou o produto/ser-
vio esperado, ele malsucedido?

captulo 1 21
 Segundo Vargas (2005) no 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 oramento previsto?
O projeto terminou mais rpido 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, no bem assim que as boas prticas de gerenciamento de pro-
jetos dizem.
Na verdade, um projeto termina com sucesso quanto ele realizado dentro
do previamente planejado, Ou seja, no popular: no 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 no utilizar todo o recurso planejado ou ter um produ-
to/servio final muito superior ao planejado quer dizer um projeto sem sucesso.
Parece difcil de acreditar neste conceito, mas Vargas (2005) nos traz um
exemplo bastante interessante: imagine um projeto que tenha por objetivo o
lanamento de uma campanha publicitria que renda a venda de 10.000 produ-
tos em uma semana. Aps a execuo 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 situao: 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, no verdade? Por isso, podemos
dizer que este projeto no foi bem-sucedido.
Para deixar mais claro ainda este conceito, vamos a outro exemplo. Imagine
uma empresa de tecnologia da informao que tem um projeto para o qual fo-
ram previstos US$1.000.000 para a sua execuo. Ao finalizar o projeto, o geren-
te de projetos diz que sobraram US$700.000. Isso bom?

22 captulo 1
 Na verdade, sobrar dinheiro bom, mas no 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 situao deste projeto piora se voc imaginar que no mo-
mento da aprovao 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 no ter sido executado a empresa tenha perdido 50% de sua
participao no mercado.
Viu s como o projeto em questo no 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 questes:
O projeto deve ter sido concludo dentro do prazo previsto;
O projeto deve ter sido concludo dentro do oramento previsto;
O projeto deve ter utilizado os recursos, materiais e humanos, com efi-
cincia e sem desperdcios;
O projeto deve ter sido concludo atingindo a qualidade e o desempe-
nho desejados;
O projeto deve ter sido concludo com o menor nmero possvel de alte-
rao em seu escopo;
O projeto deve ter sido aceito sem restries pelo contratante ou cliente;
O projeto deve ter sido executado sem interrupes ou prejuzos s ativi-
dades normais da instituio;
O projeto no pode ter agredido a cultura da organizao.

COMENTRIO
Causas que levam o projeto ao fracasso
Em um de seus podcasts, Ricardo Vargas diz que para levar um projeto ao fracasso basta
no gerenci-lo. Ou seja, de uma maneira bastante irnica, o normal de todo o projeto seria
o fracasso. Porm, para o projeto no fracassar, h o gerente de projetos tomando todas as
aes necessrias.
Mas s vezes, mesmo com todas as aes feitas, os projetos podem falhar ou, ento, no
atingir o resultado esperado.
Vargas (2005) diz que projetos podem falhar por motivos que fogem do controle da or-
ganizao (riscos do projeto) como, por exemplo:

captulo 1 23
 Mudana na estrutura organizacional da empresa;
Riscos elevados no meio ambiente;
Mudanas tecnolgicas;
Evoluo dos preos e prazos;
Cenrios poltico-econmicos desfavorveis.

Mesmo esses fatores poderiam ser evitados por meio de uma gerncia de riscos eficien-
te e eficaz. Contudo, estes no so os principais pontos de ateno, uma vez que no so
esses os motivos mais frequentes que levam um projeto ao fracasso.
Na verdade, os motivos mais frequentes que levam os projetos ao fracasso esto ligados
a falhas gerenciais. Vargas (2005) enumera alguma delas, a saber:
As metas e os objetivos do projeto mal estabelecidos ou mal compreendidos.
Subestimao da complexidade do projeto.
Previso de prazos e custos no realistas.
Planejamento baseado em informaes histricas no confiveis.
Projeto sem lder/gerente responsvel ou com vrios lderes/gerentes responsveis, ge-
rando falta de liderana 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 experincia/conhecimento das pessoas envolvidas na execuo do projeto.

Acima, enumeramos algumas das falhas gerenciais citadas por Vargas (2005) que levam
os projetos ao insucesso. Mas bom lembrar que no so 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 prticas de ges-

to de projetos apresentadas no PMBOK e como aplic-las. Para tanto, iremos
aprender um pouco mais sobre o PMBOK e o PMI e vamos comear a introduzir
conceitos importantes para entender o que um projeto, o que a gerncia de
projeto e o que o gerente de projetos.

24 captulo 1
1.3 O PMI e sua certificao
PMI Project Management Institute (Instituto de Gerenciamento de Proje-
tos) Fazendo o gerenciamento de projetos indispensvel para os resultados
dos negcios.
O PMI uma organizao sem fins lucrativos, dedicada ao avano 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 Pensilvnia (EUA), em 1969, por 5 voluntrios e
hoje conta com uma comunidade de 265.000 associados e 140.000 certificados,
sendo considerada a maior e mais acreditada instituio de educao e desen-
volvimento de padres em gerncia de projetos.
Tente lembrar o que acontecia em 1969 no mundo e contextualize historica-
mente a criao do PMI e a sua importncia para a poca.
Para atingir esse nmero de pessoas, o PMI se internacionalizou e hoje est
presente em vrios pases por meio de seus captulos (ou, em ingls: chapters),
que so filiais espalhadas geograficamente, e contribuem nas misses e obje-
tivos do PMI, promovendo o profissionalismo em gerncia de projetos, sendo
que hoje o PMI est presente em mais de 170 pases.

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 trilhes de dlares
so hoje empregados em projetos. Isso significa aproximadamente 25% de toda a economia
mundial, empregando mais de 20 milhes de profissionais em atividades relacionadas lide-
rana 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 prximos 20 anos, todo o traba-
lho ser desenvolvido por meio de projetos. Pouco mais de 10 anos depois essa realidade
evidentemente comprovada. David Cleland tambm afirma que, no futuro, o gerenciamento
de projetos ser utilizado para gerenciar as mudanas em todas as infraestruturas sociais em
todos os pases, desenvolvidos ou no (VARGAS, 2009), conforme figura a seguir.

captulo 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 Evoluo Mundial dos membros do PMI no mundo. Fonte: Vargas (2009)

O PMI tambm oferta aos seus associados, e populao em geral, vrios

produtos e servios, entre eles:
Padres profissionais:
O PMI desenvolve padres para a prtica profissional de gerncia 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 gerncia de projetos). Hoje, o PMBOK se encontra em
sua quarta edio e aprovado como um padro nacional (ANS) pelo Instituto
de Padres Nacional Americano (ANSI);
Certificao:
O PMI tambm oferece programas de certificao profissional para pro-
mover o crescimento da profisso de gerenciamento de projetos, sendo que o
mais conhecido deles a PMP ou Project Manager Professional.
Das principais iniciativas do PMI na difuso do conhecimento em geren-
ciamento de projetos, sendo as certificaes a mais procurada e difundida
mundo afora, a publicao de padres globais de gerenciamento de pro-
jetos, programas e portflio, 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 captulo 1
 PMBOK
O PMBOK Guide foi o primeiro padro de prticas profissionais desenvol-
vido pelo PMI e abrange todo o conhecimento da profisso de gerenciamento
de projetos. Ele foi desenvolvido com a ajuda de praticantes e acadmicos que
utilizam de fato essas prticas ou que as desenvolve. Ou seja, o que apresenta-
do pelo PMBOK Guide amplamente testado pelos praticantes de gerncia de
projetos e aprovado por eles, sendo consideradas boas prticas para a gerncia
de projetos em muitos projetos na maior parte do tempo, sendo que existe um
consenso por parte dos praticantes sobre seus valores e aplicabilidade.

COMENTRIO
Seu histrico: Em 1983, na tentativa de documentar e padronizar as prticas que so normal-
mente aceitas na gerncia de projetos, foi publicado o artigo "Ethics, Standards, and Accre-
ditation Committee Final Report". A primeira edio 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 edio em 2000.
Em 2004, o Guia PMBOK Terceira Edio foi publicado com maiores mudanas,
considerando as edies anteriores. A quarta edio (lanada em 2008) normatizada pelas
normas ANSI/PMI 99-001-2008 e IEEE 1490-2011. A ltima verso do Guia PMBOK a
quinta edio que foi publicada em 2013 em Ingls. Tradues esto disponveis em rabe,
Chins, Francs, Alemo, Italiano, Japons, Coreano, Portugus, Russo e Espanhol. (VAR-
GAS, 2009)

O PMBOK Guide, alm de trazer esse conjunto de boas prticas, tambm

busca estabelecer uma linguagem comum para o profissional de gerenciamen-
to de projeto. (PMBOK, 2008). O PMI diz que o PMBOK Guide no deve ser
considerado como um documento que contempla a totalidade de conhecimen-
to de gerenciamento de projetos, uma vez que essa profisso muito dinmica
e sofre atualizaes 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.

captulo 1 27
 Os processos descritos se relacionam e interagem durante a conduo do
trabalho. A descrio de cada um deles feita em termos de:
Entradas (documentos, planos, desenhos etc.);
Ferramentas e tcnicas (que se aplicam s entradas);
Sadas (documentos, produtos etc.)

1.4 Ciclo de Vida e da Organizao 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 srie de similaridades que podem ser encontradas em todos os pro-
jetos, independentemente de seu contexto, aplicabilidade ou rea de atuao.
O ciclo de vida pode ser dividido em um conjunto de fases, normalmente
fixas para todos os tipos de projeto, contendo uma sria de passos principais do
processo de contextualizar, desenhar, desenvolver e colocar em operao uma
determinada necessidade do projeto. Essas fases, por sua vez, so subdivididas
em estgios, ou etapas especficas, de cada natureza de projeto (construo, de-
senvolvimento de produtos, etc.). Esses estgios so, ento, subdivididos em
atividades, ou tarefas especficas de cada projeto.

Genrico para
FASES todos os projetos

MACROVISO

ESTGIOS Especficos da
natureza do projeto

MICROVISO

ATIVIDADES Especficos de
cada projeto

Figura 1.2 Viso do ciclo de vida do projeto. Fonte: Vargas (2009).

4 Em muitos casos existem diferentes interpretaes 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 especficas de um projeto (por exemplo: design, construo, testes).
Portanto, o termo grupo de Processos de Iniciao e Fase de Iniciao so considerados sinnimos neste material.

28 captulo 1
 Conhecer as fases do ciclo de vida proporciona uma sria de benefcios para
quaisquer tipos de projetos. Dentre eles, podem ser destacados os seguintes:
correta anlise do ciclo de vida determina o que foi, ou no, 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 consideraes podem ser feitas,

principalmente:
as caractersticas do projeto tendem a mudar com a concluso de cada
fase do projeto;
incerteza relativa aos prazos e custos tende a diminuir com o trmino de
cada fase.

A descrio do ciclo de vida do projeto pode ser genrica, representada por

um nico grfico, ou detalhada incluindo vrios grficos, fluxogramas e tabe-
las, especficos de cada atividade.
Com relao velocidade de desenvolvimento, o ciclo de vida dos projetos
pode ser caracterizado, na maioria das vezes, por um incio lento seguido de um
progresso acelerado at atingir um pico e logo em seguida, um desaceleramen-
to at atingir seu trmino.

100
Final lento
% COMPLETO

Momento de velocidade

Incio lento
0
TEMPO

Figura 1.3 Ciclo de vida do projeto segundo critrios de velocidade de desenvolvimento.

Fonte: Vargas (2009).

captulo 1 29
 Outra considerao a ser analisada no ciclo de vida do projeto o nvel de
esforo. O nvel de esforo destinado ao projeto inicia-se em praticamente zero
e vai crescendo at atingir um mximo e, logo aps esse ponto, reduz-se brusca-
mente at atingir o valor zero, representante do trmino do projeto.
Entende-se, segundo Vargas (2009), por esforo, a quantidade de pessoas
envolvidas no projeto, o dispndio de trabalho e dinheiro com o projeto, as
preocupaes, as complicaes, as horas-extras, etc. A localizao do valor m-
ximo do grfico pode variar de projeto para projeto. A suavidade desse ponto de
esforo mximo est diretamente relacionada qualidade com que o planeja-
mento foi realizado. Quanto melhor o plano, mais suave a transposio do
ponto de esforo mximo.

Mximo
ESFORO

Incio TEMPO Trmino

Figura 1.4 Variao do esforo com o tempo para o projeto. Fonte: Vargas (2009).

1.4.1 Caractersticas do ciclo de vida do projeto

A maioria dos ciclos de vida dos projetos compartilham algumas caractersticas

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 incio do projeto, quando a maioria das definies ainda est no
papel, caindo at o trmino do projeto, quando o potencial de adicionar valor
ao projeto tende a ser mnimo.

30 captulo 1
 Potencial de adicionar valor

Baixo
Incio Tempo Trmino

Figura 1.5 Potencial de adicionar valor ao projeto em funo do desenrolar do projeto.

Fonte: Vargas (2009).

1.4.1.2 Custo das Mudanas ou Correes

O custo de promover mudanas 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 mudanas / correes

Incio Tempo Trmino

Figura 1.6 Custo das mudanas / correes em funo do desenrolar do projeto. Fonte:
Vargas (2009).

1.4.1.3 Capacidade de Adequao

A capacidade de adequao do projeto quanto a novas necessidades, ou seja,

a capacidade de se alterarem as caractersticas finais do projeto grande no

captulo 1 31
incio, caindo gradativamente com o passar do tempo. Quanto mais o projeto
se desenvolve, menor a capacidade de adequao.
Alta

Capacidade de adequao

Baixa
Incio Tempo Trmino

Figura 1.7 Capacidade de adequao do projeto a novas necessidades no seu desenrolar.

Fonte: Vargas (2009).

1.4.1.4 Incerteza do Risco x Quantidade Arriscada

No incio do projeto a incerteza do Risco do projeto em questo bastante ele-

vada, pois no se tem total viso do que poder acontecer com o mesmo, entre-
tanto a quantidade arriscada muito pouco pois o projeto ainda est no incio.
Ao se comparar a incerteza do risco com a quantidade arriscada, tem-se que, no
incio do projeto, o nvel de incerteza elevado, porm 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 avanada de exe-
cuo. O perodo mais crtico o perodo de transio, 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 regio coincide exatamente com o
ponto mximo de esforo na relao esforo x tempo, descrita anteriormente,
indicando que o pico de esforo est exatamente, na regio de maior impacto
dos riscos (VARGAS, 2009).

32 captulo 1
 Incerte
za do
risco

impacto do risco
Regio de maior
Intensidade

iscada
ade arr
Quantid
Incio Tempo Trmino

Figura 1.8 Anlise 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 concludo. Cada fase do projeto, segundo
Vargas (2009), caracterizada pela entrega, ou finalizao, de um determina-
do trabalho. Toda entrega deve ser tangvel e de fcil identificao, como, por
exemplo, um relatrio confeccionado, um cronograma estabelecido, um con-
junto de atividades realizado.
O Guia PMBOK em sua 5 Edio prov diretrizes para gerncia dos projetos
individualmente e define conceitos associados gerncia de projetos. Isto tam-
bm 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
so tpicas em quase todas reas de projetos. Genericamente, o ciclo de vida de
um projeto pode ser dividido em fases caractersticas, conforme a figura a seguir.

captulo 1 33
 Fase de encerramento
Fase de planejamento
Fase de iniciao

Fase de execuo
Esforo

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 tcnico que deve ser realizado;
quem deve estar envolvido.

O nmero de fases em um projeto funo de sua natureza, podendo variar

entre quatro e nove fases caractersticas. Porm para efeitos didticos, sero
consideradas apenas cinco fazes caractersticas, as quais tambm so denomi-
nadas grupos de processos pelo PMBOK..
Fase de Iniciao: a fase inicial do projeto, quando uma determinada
necessidade identificada e transformada em um problema a ser resolvido. A
misso e o Objetivo do projeto so definidos , os documentos iniciais confec-
cionados e as melhores estratgias selecionadas.
Fase de Planejamento: a fase responsvel por detalhar tudo aquilo que
ser realizado pelo projeto, incluindo cronograma, interdependncia entre
atividades, alocao de recursos, analise de custos. Nessa fase, os planos de
escopo, custo, qualidade, recursos humanos, comunicao, risco e aquisio
so desenvolvidos.
Fase de Execuo: a fase que materializa tudo aquilo que foi planejado
anteriormente. Grande parte do oramento do esforo 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 captulo 1
 Fase de Encerramento: a fase quando a execuo dos trabalhos ava-
liada atravs de uma auditoria interna ou externa, os documentos do projeto
so encerrados e todas as falhas ocorridas durante o projeto so discutidas e
analisadas para eu erros similares no ocorram em novos projetos. Esta fase
portanto, tambm conhecida como fase de aprendizado.

Execuo
Planejamento
Iniciao
Intensidade

Encerramento
Controle

Tempo

CONCEITO DESENVOLVIMENTO IMPLEMENTAO TREINAMENTO

FAZES DO CICLO DE VIDA DO PROJETO

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

Uma anlise direta do grfico mencionado anteriormente no conclusi-

va quanto interdependncia e sobreposio de fases no projeto. Na verdade,
com o desenrolar do projeto, praticamente todas as fases e grupos de proces-
so so realizadas quase que simultaneamente, constituindo um ciclo, como
mostrado na figura a seguir:

Planejamento
Controle

Iniciao Encerramento

Execuo

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

Vargas (2009).

captulo 1 35
 Sob outro aspecto, pode-se considerar que a realizao de uma fase do projeto
tambm um projeto e, portanto, possui um determinado ciclo de vida e pode ser
subdividida em fases. Isso significa que existe uma iniciao da fase de iniciao, um
planejamento da fase de iniciao, uma execuo e um controle da fase de iniciao e
uma finalizao da fase de iniciao, partindo, ento, para a fase de iniciao do pla-
nejamento, etc. Em outras palavras, vrios subprojetos em um nico projeto maior.
O PMBOK tambm evidencia esse inter-relacionamento entre as fases de
uma maneira bastante clara e intuitiva, representando, em um mesmo grfico,
os ciclos de vida de todas as fases do projeto.

Ciclo de vida do
projeto

Execuo
planejamento
Esforo

Iniciao Encerramento
Controle

Tempo

Figura 1.12 Sobreposio das fases em um projeto. Fonte: Vargas (2009).

REFLEXO
Em todo projeto existe uma relao estreita entre os fatores de desempenho ou performance
(escopo e qualidade), custo e tempo. Isso quer dizer que impossvel predeterminar todos os
fatores simultaneamente. preciso que, com base em dois fatores, se determine o terceiro
como uma funo interna do projeto, ou seja, o mximo que se pode fazer predeterminar
dois fatores e calcular o terceiro como uma funo dos dois anteriores. Em geral, neces-
srio que se conheam, detalhadamente, dois fatores e o escopo do projeto para que se
determine o terceiro fator, fechando todo o cenrio do projeto.

36 captulo 1
 LEITURA
O guia Project Management Body of Knowledge (PMBOK) um conjunto de prticas na
gesto de projetos organizado pelo instituto PMI e considerado a base do conhecimento
sobre gesto de projetos por profissionais da rea.
Histrico: Em 1983, na tentativa de documentar e padronizar as prticas que so normal-
mente aceitas na gerncia de projetos, foi publicado o artigo "Ethics, Standards, and Accre-
ditation Committee Final Report". A primeira edio 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 edio em 2000.
Em 2004, o Guia PMBOK Terceira Edio foi publicado com maiores mudanas,
considerando as edies anteriores. A quarta edio (lanada em 2008) normatizada pelas
normas ANSI/PMI 99-001-2008 e IEEE 1490-2011.
A ltima verso do Guia PMBOK a quinta edio que foi publicada em 2013 em Ingls.
Tradues esto disponveis em rabe, Chins, Francs, Alemo, Italiano, Japons, Coreano,
Portugus, Russo e Espanhol.Houve um avano nos processos e tpicos do guia PMBOK
de sua 4. Edio para sua ltima edio, como podemos observar no quadro a seguir. Esta
atualizao se fez necessria para abarcar temas e atividades que passaram a ser importan-
tes nos projetos atuais.

GUIA PMBOK 4 EDIO (2008) GUIA PMBOK 5 EDIO (2013)

Estgios 5 grupos de processos 5 grupos de processos
Tpicos 9 reas de conhecimento 10 reas de conhecimento
Processos 42 processos 47 processos

Tabela 1.4

Extenses do PMBOK
O PMBOK atualmente define extenses ao Guia PMBOK. So elas:
Extenso para Construo - Construction Extension to the PMBOK Guide 3a Edio
Extenso para Governo - Government Extension to the PMBOK Guide 3a Edio
O PMBOK tambm define padres especficos ao Guia PMBOK. So eles:
Padro para Gerenciamento de Programa - The Standard for Program Management 2a
Edio (em ingls)
Padro para Gerenciamento de Portiflio - The Standard for Portfolio Management 3a
Edio (em ingls)

captulo 1 37
 Modelo de Maturidade para Gerenciamento de Projetos Organizacionais - Organizational
Project Management Maturity Model (OPM3) 2a * Edio (em ingls)
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/Gesto de integrao do projeto

A Gerncia da integrao do projeto o ncleo 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 contnuo que o gerente executa para garantir que o projeto prossiga do
incio ao fim a atividade diria de completar o trabalho do projeto.
O gerenciamento do projeto junta os planos de projeto, coordena ativida-
des, recursos, restries e suposies do projeto, e os transforma em um mo-
delo funcional.
Gerenciar a integrao do projeto garantir que os componentes do projeto
precisam trabalhar juntos e papel do gerente de projetos fazer que isso acon-
tea. Exige habilidades em negociao e gerenciamento de conflitos de inte-
resses. Tambm exige habilidades gerais de gerenciamento, boa comunicao,
organizao, familiaridade tcnica com o produto, etc.
Pode ser dividido em trs partes: o desenvolvimento do plano do projeto, a
execuo do plano do projeto e o controle de mudanas no projeto.

Gerenciamento/Gesto 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 captulo 1
 As finalidades do Gerenciamento do Escopo, conhecido tambm como
mbito do Projeto, incluem a definio do trabalho necessrio para concluir o
projeto, servir como guia (ou ponto de referncia) para determinar que traba-
lho no est includo (ou no necessrio) 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 necessrio
para fazer o produto, e o escopo do produto define os recursos (atributos e com-
portamentos) do produto que est sendo criado.
Os projetos no desviam frequentemente do foco de negcios da empresa, e
geralmente esto relacionados sua atividade fim.
O projeto de um sistema de informao, por exemplo, sempre tem por fina-
lidade cobrir uma necessidade estratgica de negcio ou viabilizar a execuo
automatizada de um processo operacional dentro da empresa.

Gerenciamento/Gesto de tempo do projeto

O objetivo da gerncia do tempo de projeto descrever os processos requeri-
dos para o trmino do projeto, garantindo que o mesmo cumpra com os prazos
definidos em um cronograma de atividades.
Os principais processos desta gesto so: as Definies, Seqenciamento,
Estimativa de Recurso e Estimativa de Durao das Atividades e o
Desenvolvimento e Controle do Cronograma destas Atividades.
Definies das Atividades: identificao das atividades especficas do
cronograma que necessitam ser executadas para produzir os diversos tangveis
do projeto;
Sequenciar Atividades: identificao e documentao das dependncias
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 Durao de Atividade: estimativa do perodo que ser ne-
cessrio para concluso individual de cada atividade do cronograma;
Desenvolvimento do Cronograma: anlise das sequncias das atividades,
suas dependncias, duraes e recursos requeridos para criar o cronograma;
Controle do Cronograma: controle das alteraes efetuadas
no cronograma;

captulo 1 39
 A gerncia do tempo de projeto e a gerncia do custo do projeto so as
reas de maior exigncia dentro de um projeto, pois so as mais visveis em
sua gesto.
Algumas das ferramentas clssicas de Gesto de Tempo de Projeto so o
PERT/CPM e o Diagrama de Gantt. Veremos essas ferramentas mais adiante
nos captulos sobre gerenciamento do tempo.

Gerenciamento/Gesto de custos do projeto

A gerncia do custo do projeto agrega os processos que envolvem planeja-
mento, estimativa, oramento e controle de custos que sero necessrios para
a concluso do projeto a partir de uma previso oramentria.
Os processos de gerncia do custo do projeto incluem:
Planejamento da gesto de custos: avaliar quais recursos e a quantidade
aproximada de cada um dentro do projeto;
Estimativa de custo: desenvolver uma aproximao dos gastos com os re-
cursos necessrios para execuo do projeto;
Oramento 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 variao de
custo e controlar as mudanas de oramento do projeto.

A gesto de custos um processo em que se utiliza um conjunto de tcnicas

multidisciplinares, que nos permite compreender a origem dos custos. Este
processo pode conduzir ao aumento de proventos, redues de custos e obten-
o de melhores nveis de produtividade.
Gerenciamento/Gesto da qualidade do projeto
Como conceito, conhece-se a qualidade h milnios. No entanto, s recen-
temente ela adquiriu o status de funo da gerncia. Originalmente, tal funo
era relativa e voltada para a inspeo; hoje, as atividades relacionadas com a
qualidade ampliaram-se bastante e so consideradas essenciais para o sucesso
estratgico do projeto.
A ampliao da abrangncia da qualidade nas atividades organizacionais
pode tambm ser percebida em responsabilidades que se agregaram rea,
como qualidade ambiental e qualidade de vida, tica e valores hoje impres-
cindveis e objeto de regulamentaes nacionais e internacionais e de nor-
mas diversas.

40 captulo 1
 Isso significa que h uma crescente conscientizao da sociedade
a esse respeito, o que impe o surgimento de demandas e exerce pres-
ses complementares.
H vrias classificaes para diversos perodos ou eras da qualidade. Garvin
(2002) estruturou-as assim:
Inspeo;
Controle estatstico da qualidade;
Garantia da qualidade;
Gesto estratgica da qualidade.

Independentemente da estruturao, 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 servio final do projeto. Estes processos visam assegurar que o projeto ser
concludo com a qualidade desejada, satisfazendo, portanto, as necessidades
do cliente e os requisitos do produto. Atualmente, a gesto da qualidade tem
como preocupao bsica evitar falhas.

Gerenciamento/Gesto de recursos humanos do projeto

Gerenciamento de recursos humanos do projeto uma das dez reas de
conhecimento do PMBOK (verso 5), tem como base a identificao e docu-
mentao de funes, responsabilidades e relaes hierrquicas do projeto em
relao aos recursos humanos envolvidos, alm da criao do plano de geren-
ciamento de pessoal. Obteno dos recursos humanos necessrios para termi-
nar o projeto.
Desenvolve a equipe do projeto, melhorando as competncias e interao
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, resoluo de problemas e coordenao de mudanas para
melhorar o desempenho do projeto e valorizao dos profissionais envolvidos.

Gerenciamento/Gesto das comunicaes do projeto

Inclui os processos necessrios para assegurar que as informaes do pro-
jeto sejam geradas, coletadas, distribudas, 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

captulo 1 41
partes interessadas do projeto, quer sejam internas (em todos os nveis da orga-
nizao) ou externas organizao.
Uma comunicao eficaz cria uma ponte entre as diversas partes interessa-
das envolvidas no projeto.
Processos de gerenciamento das comunicaes do projeto
Identificar as partes interessadas:
O processo de identificao de todas as pessoas ou organizaes que podem
ser afetadas pelo projeto e de documentao das informaes relevantes rela-
cionadas aos seus interesses, envolvimento e impacto no sucesso do projeto.
Planejar as comunicaes: O processo de determinao das necessidades
de informao das partes interessadas no projeto e definio de uma aborda-
gem de comunicao.
Distribuir as informaes: O processo de colocar as informaes necess-
rias disposio das partes interessadas no projeto, conforme planejado.
Gerenciar as expectativas das partes interessadas: O processo de comuni-
cao e interao com as partes interessadas para atender s suas necessidades
e solucionar as questes medida que ocorrerem.
Reportar o desempenho: O processo de coleta e distribuio de informa-
es sobre o desempenho, incluindo relatrios de andamento, medies do
progresso e previses.

Gerenciamento/Gesto de riscos do projeto

Os Riscos de projeto so um conjunto de eventos que podem ocorrer sob a
forma de ameaas ou de oportunidades que, caso se concretizem, influenciam
o objetivo do projeto, negativamente ou positivamente.
A noo de risco diversa, e muda consoante o enquadramento que deu
origem metodologia de gesto de risco em causa. Na metodologia Risk
Mangement Guide for DOD Acquisition (2002), o risco definido como sendo
a ateno dirigida ocorrncia de eventos futuros, cujo exato resultado
desconhecido, e com a forma de lidar com essa incerteza, i.e., a amplitude de
possveis resultados. Inclui o planeamento, identificao e anlise de reas de
risco e o desenvolvimento de opes para lidar e controlar o risco.. Porm outro
tipo de definies, 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 captulo 1
 Risco evento ou condio 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 circunstncias que, ao ocorre-
rem, tero efeito sobre a concretizao dos objetivos do projeto.

A necessidade de gerenciar riscos decorre, principalmente, da conscincia

de existncia 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
identificao desses fatores e/ou das suas causas, constitui uma das etapas fun-
damentais, de qualquer metodologia de gesto dos riscos. O tipo de risco, a sua
probabilidade de ocorrncia, ou o seu impacto sobre o projeto, variam ao longo
do ciclo de vida do mesmo, sendo por isso necessrio proceder-se identifica-
o dos riscos, em todas as suas fases.

Gerenciamento/Gesto de aquisies do projeto

O Gerenciamento de Aquisies do Projeto responsvel por cuidar das
compras e aquisies de produtos, servios ou resultados necessrios para a
realizao do trabalho. A organizao pode ser o comprador ou fornecedor do
produto, servio ou resultado. O Gerenciamento de Aquisies do Projeto in-
clui os processos de gerenciamento de contratos e de controle de mudanas
necessrios para administrar os contratos ou pedidos de compra. Este geren-
ciamento inclui, ainda, a administrao de qualquer contrato emitido por uma
organizao externa (o comprador) que est adquirindo o projeto de uma orga-
nizao executora (o fornecedor) e a administrao de obrigaes contratuais
estabelecidas para a equipe do projeto pelos contratos.
Gerenciamento/Gesto de envolvidos do projeto ou Gerenciamento das
Partes Interessadas do Projeto (adicionada na 5a Edio)
O gerenciamento das partes envolvidas do projeto concentra-se em um dos
elementos mais importantes da gesto de projetos, e gerencia os interessados,
suas expectativas, e compromissos. Antes era parte de um processo simples
dentro da rea de comunicao, mas agora, muito mais elaborada e recebe a
ateno 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

captulo 1 43
 A tabela a seguir resume as caractersticas de cada uma das 10 reas
de conhecimento:

REA CARACTERSTICAS

Atividades de identificao, definio, ajuste, unificao e

INTEGRAO coordenao entre as vrias atividades da iniciao, planeja-
mento, execuo/monitoramento e encerramento.

Monitoramento e definio do que de fato est ou no inclu-

ESCOPO do no projeto, abrangendo todo o trabalho necessrio para o
trmino do projeto, sem exceder o seu escopo

Detm as atividades que consistem em administrar os pro-

TEMPO cessos necessrios ao trmino do projeto no prazo.

Possui atividades que visam assegurar que o projeto seja

CUSTO concludo em consonncia com o oramento aprovado.

Atividades que visam assegurar a conformidade do produto/

QUALIDADE servio do projeto em relao ao solicitado.

Refere-se s atividades que culminam na utilizao efetiva

dos recursos humanos do projeto, incluindo o planejamen-
RECURSOS to dos recursos humanos necessrios para cada fase do
HUMANOS projeto, mobilizao desses recursos (incluindo contratao
externa, se necessrio), desenvolvimento de competncias e
o efetivo gerenciamento da equipe.

44 captulo 1
 REA CARACTERSTICAS

Abrange as atividades que garantem que informaes do

COMUNICAES projeto sejam planejadas, geradas, coletadas, distribudas,
armazenadas, recuperadas e organizadas

Identificao, anlise, 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 aquisio de

produtos, servios ou resultados externos equipe do proje-
to. Quando a compra envolver licitao, o gerente de projeto
AQUISIES deve mostrar-se mais atento a essa rea de conhecimento,
tendo em vista os riscos de atraso que podem envolver esse
tipo de ao

Identifica pessoas, grupos e organizaes que podem impac-

tar ou ser impactadas pelo projeto, analisa as expectativas
das partes interessadas e auxilia na montagem de estra-
PARTES tgias de gerenciamento apropriadas para engaj-las no
INTERESSADAS processo decisrio e execuo. Preocupa-se tambm com a
efetiva comunicao, resoluo de conflitos, identificao de
problemas e satisfao das partes

Nesta disciplina, iremos explicar cada uma dessas reas de uma forma bas-
tante ampla, enfatizando a sua aplicao em projetos de qualquer contexto.
Dessa forma, pretendemos oferecer a vocs, futuros administradores de em-
presas, um ferramental bastante diversificado para ser aplicado nos projetos
que vocs viro a gerenciar.

captulo 1 45
 ATIVIDADES
Desenvolvemos, abaixo, um conjunto de perguntas para que voc possa fixar o contedo
aprendido nesta unidade.
Responda s perguntas abaixo utilizando como base tudo aquilo que voc estudou nesta
unidade, nas conexes apresentadas e utilizando o conhecimento que voc j possui de vi-
vncias profissionais ou de estudos de mdulos passados referentes ao mundo coorporativo.

01. possvel gerenciar um projeto dentro de uma organizao por meio de boas prticas
e metodologias cientificamente testadas ou s possvel gerenciar projetos fazendo uso de
profissionais experientes que utilizam mtodos artsticos para alcanar o sucesso do proje-
to? Explique a sua resposta.

02. O que o PMI e qual a principal funo desta instituio?

03. Comente as principais aes do PMI no trabalho da profissionalizao do gerenciamen-

to de projetos.

04. Abaixo, marque P para projetos ou TO para trabalhos operacionais do dia a dia de
uma instituio.
( ) Aes para o desfile de carnaval de um determinado ano.
( ) Construo de carros em srie em uma linha de b) montagem.
( ) Aes para a criao de um novo modelo de carro de uma determinada montadora.
( ) Desenvolvimento de um novo d) software de ERP para uma determinada empresa.
( ) Aes do setor de RH para a emisso de pagamentos dos funcionrios de uma
determinada empresa.
( ) Aes de uma empresa para determinar o processo de emisso de pagamentos
dos funcionrios de uma determinada empresa.
( ) Tarefas associadas a um funcionrio de uma lanchonete para a confeco de lan-
ches padres desta lanchonete.

46 captulo 1
 REFLEXO
No seu desempenho profissional de um executivo, de um administrador, gestor, analista de
sistemas etc., por vrios 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 clula produtiva, tudo isso consiste em administrar o dia a dia
dos profissionais em suas atividades dirias, ou seja, nos trabalhos operacionais, e tambm
em dar rumo a instituies por meio de um plano estratgico que ser contemplado pela
execuo de vrios projetos.
importante que neste momento voc saiba diferenciar trabalhos operacionais de pro-
jetos e saiba que para tratar cada um desses h uma abordagem cientfica e sistematizada
para auxili-lo.
Neste sentido, aprendemos neste captulo sobre o que um projeto e sobre o PMI, que
uma instituio que luta pela profissionalizao do gerente de projetos por meio da sistema-
tizao de boas prticas de abordagem ao gerenciamento de projetos.
Dessa forma, sempre que voc se deparar com projetos na sua vida profissional, voc
ter condio de identific-los e gerenci-los por meio das definies de uma metodologia/
processo apoiada nas boas prticas estudadas e abordadas no PMBOK. Sendo assim, o es-
tudo desse captulo se fez importante, porm no 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 oua 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 mxima de que no existe
projeto fcil e que todos os projetos tero 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 aluso cmica a Murphy, Vargas explica que no h lugar para o

captulo 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 organizao responsvel pela conduo do
projeto, com a misso de zelar para que os objetivos do projeto sejam atingidos. O geren-
te de projetos tem sido caracterizado por um perfil profissional com domnio e experincia
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 concentrao 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 eficcia no gerenciamento, em especial na comunicao, os gerentes de pro-

jetos devem dominar habilidades interpessoais. Isso significa um longo e contnuo processo
de crescimento pessoal e desenvolvimento gerencial.
Segundo a psicloga Fela Moscovici [Moscovici 1981], competncia interpessoal a
habilidade de lidar eficazmente com relaes interpessoais, de lidar com outras pessoas de
forma adequada s necessidades de cada um e s exigncias da situao.
Competncia interpessoal resultante de percepo acurada e realstica das situaes
interpessoais e de habilidades comportamentais especficas que conduzem a consequncias
significativas no relacionamento duradouro e autntico, satisfatrio para as pessoas envol-
vidas. Um terceiro componente dessa competncia refere-se ao relacionamento em si, e
compreende a dimenso emocional-afetiva, predominantemente.
Lidar com situaes interpessoais requer sensibilidade e flexibilidade perceptiva e com-
portamental, que significa procurar ver vrios ngulos ou aspectos da mesma situao e
atuar de forma diferenciada, no rotineira, experimentando novas condutas percebidas como
alternativas de ao.
Destacam-se as seguintes habilidades interpessoais para o gerente de projetos:
Comprometimento, responsabilidade, tica e honestidade;
Transparncia, franqueza, clareza e objetividade;
Liderana, agregao, motivao e entusiasmo;
Soluo de conflitos e problemas;

48 captulo 1
 Negociao, influncia e persuaso;
Deciso, iniciativa e proatividade;
Organizao e disciplina;
Autocontrole, equilbrio e resilincia;
Empreendedorismo;
Eficcia.

O PMI mantm um Cdigo de tica e Conduta Profissional (Project Management Insti-

tute Code of Ethics and Professional Conduct), criado para incutir confiana profisso de
gerenciamento de projetos e auxiliar os praticantes a se tornarem melhores profissionais.
Para isso, o cdigo descreve as expectativas que os profissionais de gerenciamento de pro-
jetos tm de si e de seus colegas. Ele exige que os profissionais demonstrem compromisso
com a conduta tica e profissional, sendo especfico quanto obrigao bsica de responsa-
bilidade, respeito, justia e honestidade. Isso inclui respeitar as leis, regulamentos e polticas
organizacionais e profissionais.
Mais que ser um facilitador, o gerente de projetos deve fazer a diferena no bom anda-
mento e no sucesso dos projetos.
Saiba mais em: http://www.mhavila.com.br/topicos/gestao/pmbok.html

REFERNCIAS BIBLIOGRFICAS
BOROVIK,Cleide; RAMIREZ, Andrea; RAMIREZ, Fernanda. Tecnotopias: arte e cincias, imagens e contexto
Disponvel 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. So 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. Disponvel em: <www.pmi.org>. Acesso em: 1 jan. 2010.
SOUSA, Ciclo PDCA Um instrumento para melhoria continua. Disponvel 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. Disponvel em: <http://pt.wikipedia.org/wiki/Ciclo_PDCA>. Acesso em: 16
mar. 2010.

captulo 1 49
50 captulo 1
 2
Gerenciamento
de Integrao e
Gerenciamento de
Escopo
Nas unidades anteriores, comeamos falando sobre definio de projetos, ge-
renciamento de projetos e uma breve apresentao das reas de conhecimento
de um projeto.
Vimos tambm, sobre os ciclos de vida de produto, projeto e de gerencia-
mento de projetos e a partir desta unidade comeamos a tratar o gerenciamen-
to de projetos de forma mais prtica, quero dizer, de forma mais aplicvel, uma
vez que at ento estvamos tratando de conceitos por meio dos quais cons-
trumos uma base slida em cima da qual essa parte mais prtica poder
se sustentar.
A partir deste captulo, 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 tcnicas de algumas dessas reas.
Como visto anteriormente, o ciclo de vida de gerenciamento de projetos
dividido em 5 grupos de processos, quais so:
1. Iniciao
2. Planejamento
3. Execuo
4. Monitoramento e controle
5. Encerramento

Dentro de cada um desses grupos de processos, so definidos processos por

meio da descrio das entradas, ferramentas/tcnicas e sadas desses proces-
sos, formando, assim, as boas prticas de gerenciamento de projetos indicadas
pelo PMBOK. Contudo, esses processos so organizados em 10 grandes reas
de conhecimento, a saber: integrao, escopo, tempo, custo, qualidade, recur-
sos humanos, aquisio, riscos e partes interessadas.
1. Sempre iniciaremos a explicao de cada rea de conhecimento mos-
trando os seus objetivos e qual a importncia da rea no gerenciamento
de projetos.
2. Na sequncia, iremos mostrar quais so os processos que compem a
rea, classificando-os de acordo com o grupo de processos a que eles perten-
cem e fazendo uma breve descrio desses processos.
3. Por ltimo, sempre que necessrio, iremos explicar algumas das ferra-
mentas/tcnicas que consideramos mais importantes na rea abordada.

52 captulo 2
 A primeira rea a ser abordada, abre a sequncia do ciclo de vida de um pro-
jeto que o gerenciamento da integrao.
Vamos l!

OBJETIVOS
Com o estudo deste captulo, iniciaremos os contedos pertinentes s 10 reas de conheci-
mento do gerenciamento de projetos. Este captulo portanto, trar os conceitos e atividades
do gerenciamento da integrao e do escopo, abrindo a lista de reas do conhecimento
descritos no PMBOK.
Gerenciamento da Integrao
1. Criao do Termo de Abertura
2. Ciclo padro de planejamento e Integrao do Plano de Projeto.
3. Controle e Monitoramento do Projeto
4. Controle de Mudanas
5. Encerramento de projetos

Gerenciamento do escopo de um projeto

1. Definio de escopo e gerenciamento de escopo
2. Coleta de Requisitos
3. Ferramentas
4. A Declarao de Escopo
5. Definio de EAP
6. Tcnicas para gerar EAP
7. Verificao do escopo
8. Controle de Mudanas do escopo

captulo 2 53
2.1 Processo de Integrao do Projeto
O processo de integrao 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 integrao do projeto inclui
os processos e as atividades necessrias para identificar, definir, combinar,
unificar e coordenar os vrios 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

Aquisies Custos
Integrao

Riscos Qualidade

Comunica- Recursos
es Humanos

Figura 2.1 Gerenciamento da integrao como rea central do gerenciamento de proje-

tos. Fonte: Vargas (2009).

Para iniciar a explicao da rea de conhecimento em gerenciamento de in-

tegrao, vamos falar um pouco sobre alguns stakeholders do projeto e suas
principais funes.
Equipe de execuo 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 captulo 2
 Gerente do projeto: gerenciar o projeto aplicando todas as boas prticas
reconhecidas e comprovadas no mercado profissional e acadmico como pr-
ticas que funcionam na maioria dos projetos e na maior parte do tempo. No ge-
renciamento do projeto, o gerente de projetos tambm responsvel por reunir
todas as peas do projeto em uma unidade coesa.

Mas como o gerente de projetos consegue reunir todas as peas 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 gerncia de integrao. 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 integrao responsvel 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. Ento, podemos dizer que os pro-
cessos que compem essas fases tambm esto se interagindo intensamente. A
coordenao da interao desses processos de responsabilidade da gerncia de
integrao, uma vez que nessa rea de conhecimento que se decide como cada
rea ser planejada. Vamos a um exemplo trazido pelo PMBOK (2013):

A gerncia de integrao 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-
rncia de integrao responsvel pela integrao 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 organizao.

captulo 2 55
 A gerncia de integrao composta pelos seguintes processos:
1. Processos de iniciao:
Desenvolver o termo de abertura do projeto
2. Processos de planejamento:
Desenvolver o plano de gerenciamento do projeto
3. Processos de execuo:
Orientar e gerenciar a execuo do projeto
4. Processos de monitoramento e controle:
Monitorar e controlar o trabalho do projeto
Controle integrado de mudanas
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 iniciao (ou fase de iniciao).
Na verdade, este processo e o processo desenvolver a declarao do escopo
preliminar do projeto so os nicos que compem a fase de iniciao do ciclo
de vida de gerenciamento de projetos. E ambos os processos esto sob respon-
sabilidade da rea de gerenciamento de integrao.
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 ingls, 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 no escrito pelo gerente de projetos,
mesmo por que neste documento que o gerente de projetos escolhido pelo
patrocinador do projeto.

56 captulo 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. Declarao do trabalho do projeto: Esta entrada uma descrio de todos os produtos e
servios que sero fornecidos pelo projeto a ser criado. Nos projetos internos organizao
essa declarao pode ser feita pelo patrocinador com base nos requisitos das necessidades
dos negcios (por exemplo, uma demanda de mercado, avano tecnolgico, requisito legal
ou nova lei imposta pelo governo), produtos ou servios. No entanto, para projetos externos
esta declarao pode ser concedida pelo cliente atravs de um documento de licitao, por
exemplo, solicitao de proposta, informaes, preos, ou como parte de um contrato.
2. Business Case: Um business case um documento que fornece informaes necess-
rias do ponto de vista de um negcio, para determinar se o projeto justifica ou no o inves-
timento. Neste documento temos a anlise de custo benefcio e necessidades de negcios
para justificar o projeto. O cliente o responsvel 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 situao
imposta pelo mercado, ou devido a alguma necessidade organizacional, solicitao do cliente,
avano tecnolgico, 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 restries que devem ser aceitas pela organizao executora do projeto.
4. Fatores Ambientais da empresa: Os fatores ambiente so situaes que podem ocorrer
na organizao interna ou externa que cercam ou influenciam o sucesso de um projeto. Estes
fatores ambientais podem aumentar ou restringir as opes de gerenciamento de projetos e
ainda podem influenciar positivamente ou negativamente no resultado deste projeto. Esses
fatores ambientais podem ser: padres governamentais ou industriais, infraestrutura organi-
zacional, condies do mercado, entre outros.
5. Ativos de Processos Organizacionais: Os ativos de processos organizacionais so todos
os ativos relacionados a processos, de quaisquer ou todas as organizaes 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, polticas e definies padronizadas de processos para uso na organiza-
o, modelos (como modelos de termo de abertura previamente definidos pela organizao),
informaes histricas, base de conhecimento de lies aprendidas, etc.

captulo 2 57
Ferramentas e Tcnicas

O processo desenvolver o termo de abertura do projeto possui uma ferramenta e tcnica:

1. Opinio Especializada: A opinio especializada fornecida por qualquer grupo ou pessoa
que tenha conhecimento ou treinamento especializado e est disponvel para ajudar na avaliao
das entradas necessrias para o desenvolvimento do termo de abertura do projeto. A opinio do
especialista aplicada a qualquer detalhe que seja tcnico ou de gerenciamento durante o pro-
cesso de termo de abertura. Essa opinio especializada pode estar disponvel atravs de outras
unidades dentro da organizao, consultores, clientes, especialistas no assunto, etc.

Sadas

O processo desenvolver o termo de abertura do projeto possui uma sada:

1. Termo de Abertura do Projeto: Como foi visto at o momento, o termo de abertura onde
esto documentadas todas as necessidades do negcio, o entendimento das necessidades
do cliente, informaes sobre o novo produto, servio ou resultado a ser satisfeita pela orga-
nizao executora.

O termo de abertura gerado pode conter:

1. Propsito ou justificativa do projeto;
2. Os objetivos mensurveis do projeto e critrios de sucesso relacionados;
3. Requisitos de alto nvel;
4. Descrio do projeto em alto nvel;
5. Riscos de alto nvel
6. Resumo do cronograma de marcos;
7. Resumo do oramento;
8. Requisitos para aprovao do projeto;
9. Gerente de projeto designado, responsabilidade e nvel 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 tambm que o termo de abertura do projeto no possui nada muito de-
talhado, ele um documento formal mais abstrato que autoriza o projeto e d informaes
importantes que serviro para guiar o restante do projeto.
Leia mais em: Gerenciamento da Integrao segundo o PMBoK http://www.devmedia.
com.br/gerenciamento-da-integracao-segundo-o-pmbok/27359#ixzz3lplFrPmw

58 captulo 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 compe o
plano de gerenciamento do projeto.
Ento, funo deste processo organizar a confeco do plano de gerencia-
mento de cada grande rea de conhecimento como planejamento de escopo,
custo, tempo, risco, recursos humanos, qualidade, aquisies e comunicaes.

2.1.3 Orientar e gerenciar a execuo do projeto

Este processo pertence ao grupo de processos de execuo.

O trabalho determinado na declarao do escopo do projeto (documento
este que ainda no vimos, pois o processo responsvel pela sua gerao est na
rea de conhecimento de gerncia de escopo, porm podemos entender por
enquanto que este trabalho est declarado nos documentos de termo de aber-
tura do projeto e documento de declarao do escopo preliminar do projeto)
deve ser realizado. Ento, realizar este trabalho o objetivo deste processo de
integrao. (VIEIRA, 2007).
O gerente deve tomar muito cuidado neste processo para que os membros
da equipe executora no implementem funcionalidades a mais do que aquelas
declaradas no escopo do projeto. Pois, aumentar o escopo do projeto significa
um acrscimo de custo e tempo que podem ser indesejados pelo patrocinador/
iniciador do projeto.
Para realizar este trabalho, algumas aes 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 cotaes; selecionar
fornecedores; gerenciar e obter recursos; implementar normas e mtodos plane-
jados; criar, controlar verificar e validar as entregas do projeto; gerenciar riscos;
gerenciar fornecedores; implementar alteraes; coletar dados e relatar custos,
cronograma, progresso tcnico e informaes gerais sobre o andamento do pro-
jeto; coletar e documentar as lies aprendidas. (PMBOK, 2008).

captulo 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 alteraes no planejamento do projeto medida em
que elas ocorrem.
So atividades desse processo: comparao do desempenho real do projeto
com o plano de gerenciamento do projeto (linhas base); avaliao do desempe-
nho do projeto; anlise, acompanhamento e monitoramento de riscos; manu-
teno de base de informaes relativas ao produto do projeto; fornecimento de
informaes para dar suporte a relatrios de andamento, medies de progres-
so e previses; monitoramento de implementaes de mudanas aprovadas.
Esse processo particularmente importante, pois por meio dele que as
mudanas solicitadas sero discutidas, controladas e aprovadas. Muitas vezes,
os stakeholders no conseguem visualizar o impacto que determinadas solici-
taes de alterao iro gerar no projeto. Ento, este processo nos serve para
que essas solicitaes de alterao sejam discutidas com a seriedade merecida
e, uma vez aprovadas, seja ento comunicado a todos de forma efetiva e inclu-
da no planejamento do projeto.

2.1.5 Realizar o controle integrado de mudanas

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

define as atividades necessrias para a avaliao, aprovao/rejeio de todas e
quaisquer mudanas solicitadas no projeto.
H algumas reas de aplicao como, por exemplo, a rea de tecnologia de
informao, na qual essas mudanas acontecem muito rapidamente e os im-
pactos, na grande maioria das vezes, so mal analisados. Ento, o controle inte-
grado de mudanas se preocupa em analisar os motivos geradores das mudan-
as para analisar se elas so realmente necessrias e, posteriormente, gerenciar
as alteraes no momento em que elas acontecem.
So aes desse processo, entre outros: identificao da ocorrncia ou ne-
cessidade de ocorrncia de uma determinada mudana; reviso e aprovao
das mudanas solicitadas; gerenciamento das mudanas aprovadas; manuten-
o da integridade das linhas de base; reviso e aprovao de todas as aes
preventivas e corretivas; controle e atualizao de escopo, custo e tempo; docu-
mentao do impacto total das mudanas solicitadas; validao do reparo do
defeito; controle de qualidade do projeto.

60 captulo 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 realizao da parte de encerramen-
to do projeto do plano de gerenciamento do projeto. Em projetos com vrias
fases, o processo Encerrar o projeto encerra a parte do escopo do projeto e as
atividades associadas, aplicveis a uma determinada fase. (PMBOK, 2004).
O encerramento do projeto particularmente importante, pois aqui que
as lies aprendidas so revistas e se faz um balano final sobre o projeto que
est terminando (ou fase do projeto que est terminando).
Em projetos de TI, dada a sua caracterstica de curto prazo de implemen-
tao e alta instabilidade de requisitos, consolidar as lies aprendidas e os
ativos conseguidos com o projeto importantssimo, principalmente quando
tratamos de reaproveitamento de cdigos, padres de desenvolvimento e ar-
quiteturas. Um bom encerramento de projeto significa a consolidao 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.

COMENTRIO
O processo de integrao 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 aps a aprovao do projeto e a formalizao de sua abertura deve-se
perguntar: o que vamos ter que fazer para atingir estes objetivos? De fato, a de-
finio sobre o que fazer de enorme relevncia para que o projeto seja bem
sucedido em seus objetivos e deve ser feita adequadamente.
Na verdade, no s a definio de que tipo de trabalho deve ser realizado,
mas tambm como garantir que o trabalho seja feito de responsabilidade da
rea de gerenciamento de escopo.

captulo 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 to importante do que especificar o que est dentro,
por causa dos requisitos de contexto e requisitos no 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, ento determi-
nar muito bem esses requisitos o primeiro passo para entregar um produto/
servio de qualidade e ter sucesso no projeto.
A determinao do que exatamente faz parte ou no faz parte do projeto e
a identificao das necessidades do cliente e traduo 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 crtico
de sucesso do projeto).

Gerenciamento do escopo em Tecnologia da Informao

Em TI, a determinao do que exatamente faz parte, ou no faz parte do projeto e
a identificao das necessidades do cliente e traduo dessas necessidades em
requisitos uma atividade extremamente complexa, pois produtos de softwares so
abstratos, e definir algo abstrato logo nas primeiras fases do projeto (ponto em que se
faz necessrio a definio do escopo) realmente uma tarefa difcil.

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

tudo o que o projeto deve conter para que o produto/servio final exceda as ex-
pectativas do iniciador/patrocinador, a rea de gerncia 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 captulo 2
 No decorrer deste captulo, detalharemos todos s processos de gerencia-
mento de escopo, a comear pela coleta de requisitos.

2.2.1 Coletar os requisitos

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

partes interessadas para alcanar o objetivo do projeto. (PMBOK, 2008).
Porm, necessrio 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, necessrio visualizar a definio

dada para este processo de uma forma mais ampla. Ou seja, o escopo objetiva
definir e documentar, junto s partes interessadas, as funes 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 confeco da
Estrutura Analtica do Projeto e para a elaborao dos planejamentos de tem-
po, custo e qualidade.

Levantamento de Requisitos em Projetos de TI

Considerando a definio de escopo mais ampla como definir e documentar, junto s
partes interessadas, as funes e funcionalidades do produto e do projeto, o geren-
ciamento de escopo trata de tudo o que envolve a criao 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 definio do escopo razoavelmente complexa
principalmente em projetos de desenvolvimento de novos softwares, quando se faz
necessria a transformao das necessidades dos stakeholders em requisitos formais
que devero ser implementados pelo software.

captulo 2 63
 Para resolver essas complexidades, a engenharia de software prope o processo de
engenharia de requisitos, que, segundo Sommerville (2003), composto por quatro
atividades bsicas: estudo de viabilidade, obteno e anlise de requisitos, especifica-
o de requisitos, validao de requisitos.
Neste processo de engenharia de requisitos, no momento de determinao do esco-
po do software, necessrio se atentar aos seguintes pontos:
1. Contexto:
a) Em qual contexto o software se encaixa? H um sistema maior que o
engloba?
b) As restries impostas pelo contexto do software.
2. Objetivos da informao:
a) Os dados sero produzidos como sada do software e visto pelos usurios
finais.
b) Os dados que sero a entrada do sistema.
3. unes e desempenho
a) As funes que o software dever ter para transformar as entradas em sa-
das interessantes para o usurio final (processar os dados).
b) Requisitos no 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/servio 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. Ento, entender os requisitos
do software condio sine qua non para o desenvolvimento de um produto de qualidade.
Ainda, uma definio de escopo correta, tambm permite uma anlise consistente do
tempo envolvido na concluso do projeto, uma vez que os processos de gerenciamen-
to do tempo partem da EAP que contm todo o escopo do projeto.

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

to, existem diversas tcnicas (PMBOK, 2008):
Entrevistas;
Questionrios;
Grupos focais (grupos de consumidores monitorados que so convidados
a debaterem as caractersticas de um determinado produto);
Conversas informais;

64 captulo 2
 Benchmarking com outros projetos (tomar por base requisitos que Foram
atendidos por outros projetos realizados anteriormente);
Tcnica Delphi (um grupo seleto de especialistas responde questionrios
e debate sobre os requisitos);
Opinies tcnicas especializadas.

Um aspecto de importante observao sobre a coleta de requisitos que

os requisitos no tm origem somente nos clientes. comum que os prprios
clientes no tenham conscincia 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 no
faam parte da equipe no projeto atual, mas tenham experincias anteriores.
Porm, independente da origem dos requisitos eles devem ser claramente
estabelecidos no projeto e aconselhvel 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 Segurana Preo baixo
REQUISITO 2 Potncia Desempenho Conforto
REQUISITO 3 Acelerao Design Segurana
REQUISITO N
Tabela 2.6 Exemplo de matriz de rastreabilidade.

Uma matriz de rastreabilidade define e controla o que ser includo ou no no

projeto e inclui somente os artefatos para gerenciar o escopo do projeto e no do
produto. Alm disso, necessria uma verificao constante dessa matriz para
ter certeza que todo o trabalho necessrio est sendo realizado e para impedir a
realizao de trabalho extra que no faa 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;
Descrio do Requisito;
Critrios de Aceitao;
Dependncias Externas;

captulo 2 65
 Data da Criao do Requisito;
Data da ltima alterao;
Responsvel pela ltima alterao;
Motivo da ltima alterao;
Situao do requisito.

Alm da matriz de rastreabilidade, o processo de coleta de requisitos tam-

bm possibilita a construo do documento de requisitos, que descreve como
cada requisito atende a(s) necessidade(s) do negcio e qual necessidade ser
atendida dentro dos objetivos do projeto. Ainda, os requisitos devem ser des-
critos sem gerar dupla interpretao e sempre que possvel, usar critrios de
aceitao mensurveis retirando qualquer subjetividade da avaliao.
Na fase do planejamento do escopo do projeto, alm da cultura organiza-
cional, infraestrutura, ferramentas, recursos humanos, polticas de pessoal e
condies de mercado, a sustentabilidade ambiental do projeto tambm deve
ser analisada. As questes que precisam ser levantadas nessa fase podem ser: o
projeto ir afetar o meio ambiente no seu entorno? Quais so as opes de mu-
danas no escopo do projeto o gerente poder lanar mo, 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 referncias para o geren-
ciamento de projetos. Para tanto, ele mapeia as reas de conhecimento indis-
pensveis para atingir esse fim e desenvolve um captulo para cada uma dessas
reas. Porm, o Guia no desenvolve um captulo para tratar do gerenciamento
ambiental nos projetos e, para, complementar as prticas do Guia, o Professor
Doutor Ricardo Vargas escreveu um artigo com orientaes para observao
dos requisitos dessa natureza.

AUTOR
Ricardo Viana Vargas um especialista em gerenciamento de projetos, portflio e riscos
com diversas certificaes. Foi, nos ltimos 18 anos, responsvel por mais de 80 projetos de
grande porte em diversos pases, nas reas de petrleo, energia, infraestrutura, telecomuni-

66 captulo 2
caes, informtica e finanas, com um portflio de investimentos gerenciado superior a 20
bilhes de dlares. Atualmente, diretor do Grupo de Prticas de Projetos Sustentveis do
Escritrio de Servios de Projetos das Naes Unidas (UNOPS, na sigla em ingls) em Co-
penhagen, na Dinamarca. Seu trabalho tem como foco a melhoria da gesto dos projetos hu-
manitrios, de construo da paz e de desenvolvimento de infraestrutura em dezenas de pa-
ses, como Haiti, Afeganisto, Iraque e Sudo do Sul. Site: http://www.ricardo-vargas.com/pt/

Para reduzir custos e impactos negativos devem-se incorporar requisitos

ambientais desde o incio de um projeto. Alm disso, deve-se levar em conta
aspectos prioritrios, tais como: caractersticas fsicas e estruturais, condies
ambientais locais e regionais, requisitos legais, disponibilidade de recursos.
Para atender aos requisitos ambientais necessrio 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 rgos competentes para fiscalizar esses procedimentos?
4. Quais os prazos legais que devem ser observados?
5. Quem so os profissionais que tm competncia legal e tcnica para
desenvolver o EIA/RIMA?
6. Quanto custar ao projeto?

CONCEITO
Definio Licenciamento ambiental
Procedimento administrativo pelo qual o rgo ambiental competente licencia a localiza-
o, instalao, ampliao e a operao de empreendimentos e atividades utilizadoras de re-
cursos ambientais, consideradas efetiva ou potencialmente poluidoras ou daquelas que, sob
qualquer forma, possam causar degradao ambiental, considerando as disposies legais e
regulamentares e as normas tcnicas aplicveis ao caso.

captulo 2 67
 CONCEITO
Definio EIA/RIMA
Segundo o art. 3 da Resoluo CONAMA n 237/97, a Licena Ambiental para em-
preendimentos e atividades consideradas efetiva ou potencialmente causadoras de significa-
tiva degradao do meio depender de prvio Estudo de Impacto Ambiental e respectivo Re-
latrio de Impacto sobre o Meio Ambiente (EIA/RIMA), ao qual se dar publicidade, garantida
a realizao de audincias pblicas, quando couber, de acordo com a regulamentao. Por
outro lado, o rgo ambiental competente, verificando que a atividade ou empreendimento
no potencialmente causador de significativa degradao do meio ambiente, definir os
estudos ambientais pertinentes ao respectivo processo de licenciamento.

ATENO
A rea de conhecimento em gerenciamento ambiental do projeto inclui os processos internos
e externos e as consequentes atividades desses processos que so necessrias para que o
projeto cause o mnimo impacto possvel ao Meio Ambiente onde ele ser desenvolvido. O refe-
rencial terico para a consolidao desse gerenciamento ambiental o conceito de sustentabi-
lidade ambiental da Comisso Mundial Sobre Meio Ambiente e Desenvolvimento (Organizao
das Naes Unidas ONU), que no Relatrio Brundtland de 1987 definiu o Desenvolvimento
Sustentvel como sendo O desenvolvimento que satisfaz as necessidades presentes, sem
comprometer a capacidade das geraes futuras de suprir suas prprias necessidades. Deste
modo, o conceito de sustentabilidade ambiental o foco desse gerenciamento, em que todas
as demais reas do gerenciamento do projeto sero transversalmente afetadas. (disponvel 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 definio de escopo.

Definir o escopo
A definio de escopo envolve a preparao de uma declarao de escopo
detalhada para o projeto, que envolve a identificao de qual o trabalho a ser
realizado e os responsveis, o dimensionamento dos pacotes de trabalho, ou

68 captulo 2
work packages (WP) e a criao de um dicionrio que explique os aspectos tc-
nicos da EAP. Entre os aspectos positivos da definio de escopo esto:
obriga os stakeholders a concordarem com as fronteiras do projeto;
durante a execuo, permite identificar as mudanas que esto fora do
escopo do projeto e requerem renegociao do contrato original;
ajuda a estabelecer critrios que mensurem o sucesso do projeto,
de forma que todos os envolvidos os conheam e estejam de acordo;
auxilia a compreenso da equipe de projeto sobre as abordagens e mto-
dos utilizados no projeto.

importante destacar que como o escopo de projeto serve de base para v-

rias decises no projeto, deve-se ter muito cuidado com o que est includo e o
que no est antes de iniciar a execuo. A definio correta sobre o que deve
estar includo no escopo do projeto e tambm seu gerenciamento ilustrado na
histria representada na figura 2.2:

Como o Como o Consultor

Como o cliente Como o lider de Como o analista
programador de negcios
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, disponvel em: http://www.projectcartoon.com

captulo 2 69
 No exemplo da figura 2.2 possvel perceber que o mau gerenciamento do
escopo leva o projeto a desperdiar recursos e no atingir seus objetivos, tor-
nando o cliente insatisfeito. Isto acontece porque o escopo de trabalho o co-
rao do gerenciamento de projetos, sendo que todas as outras reas, em al-
gum ponto dependem de sua correta definio.
A declarao 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 no agrega valor e que o cliente
no precisa, por isso torna-se fundamental definir corretamente o escopo.
A definio de um escopo deve conter os fatores mostrados na figura 2.3

Objetos do Projeto;

Premissas e Retries;

Lista das entregas e seus requisitos;

Estrutura Analtica do Projeto;

Fora do escopo do projeto (O que no incluido no projeto);

Critrios de aceitao do projeto.

Figura 2.3 Elementos da declarao do escopo.

Os objetivos do projeto so critrios quantificveis que devem ser encon-

trados no projeto para que ele seja considerado um sucesso. Os objetivos do
projeto devem incluir, no mnimo, custo, cronograma e medidas de qualidade.
Os objetivos do projeto devem ter um atributo (por exemplo, custo), uma me-
dida (por exemplo, US$ dlar) e um valor absoluto ou relativo (por exemplo,
menos que 1,5 milhes). Objetivos no quantificveis (por exemplo, satisfao
dos clientes) representam alto risco para um trmino do projeto com sucesso.
As restries do projeto s restries so fatores que limitaro as opes da
equipe de gerncia do projeto. Por exemplo, um oramento pr-definido uma

70 captulo 2
restrio que na maioria das vezes limita as opes da equipe com relao a
escopo, pessoal e prazos.
Quando um projeto desenvolvido sob contrato, as clusulas contratuais
sero geralmente restries. Outro exemplo uma exigncia de que o produto
do projeto seja sustentvel do ponto de vista social, econmico e ambiental, o
que trar repercusses no escopo, na equipe e no prazo do projeto. Caso haja
quebra de contrato ou o projeto gaste mais que o oramento previsto, h risco
de cancelamento do projeto.
Premissas ou suposies so fatores que, para os propsitos do planejamen-
to, so consideradas verdadeiros, reais, ou certos. As premissas afetam todos os
aspectos do planejamento do projeto e so parte da elaborao 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 disponvel para o projeto incerta, a
equipe pode assumir uma data de incio especfica. Podem ser organizacionais,
ambientais e externas.
Podem ser consideradas como as clusulas contratuais que se no 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 no estiver disponvel 50% do tempo, o prazo, provavelmente, no
ser cumprido.
A lista das entregas e seus requisitos envolvem definio de subprodutos.
Subprodutos do projeto constituem uma lista de nvel sumrio dos subpro-
dutos que entregues total e satisfatoriamente indicam o trmino do projeto.
Por exemplo, os principais subprodutos para um projeto de desenvolvimento
de software devem conter o cdigo de trabalho do computador, um manual
do usurio e um tutorial interativo. Quando conhecidas, excluses devem
ser identificadas, mas alguma coisa no includa explicitamente est exclu-
da implicitamente.
A estrutura analtica do projeto (EAP) ser tratada detalhadamente
e separadamente.
Em projetos de tecnologia da informao, especificar o que est fora do es-
copo quase to importante quanto especificar o que est dentro, devido aos
requisitos de contexto e requisitos no funcionais dos softwares).

captulo 2 71
 Por ltimo, dentro da definio ou declarao de escopo, temos a definio
de critrios, inclusive requisitos de desempenho e condies essenciais, que
devem ser atendidos antes que as entregas do projeto sejam aceitas

Tcnicas e ferramentas para definio do escopo

1. Anlise do produto. A anlise do produto envolve desenvolver um me-

lhor entendimento do produto do projeto. Isso inclui tcnicas como a anlise
de decomposio do produto, engenharia de sistemas, engenharia de valor,
anlise de valor, anlise de funes e desdobramento das funes de qualidade.
2. Anlise de custo/benefcio. A anlise de custo/benefcio envolve estimar
custos tangveis e intangveis (outlays gastos) e benefcios (returns - receitas)
das vrias alternativas de projeto e produto e, ento, usar medidas financeiras
tais como retorno de investimento ou perodo de reembolso para avaliar a qua-
lidade relativa das alternativas identificadas.
3. Identificao de alternativas. Este um termo genrico para qualquer
tcnica usada para gerar diferentes abordagens do projeto. Existem vrias tc-
nicas de gerenciamento freqentemente usadas aqui, sendo as mais comuns o
brainstorming e o lateral thinking (pensamento lateral).
4. Avaliao especializada. Uma avaliao especializada , frequente-
mente, requerida para avaliar as entradas desse processo. Tal habilidade pode
ser provida por um grupo ou indivduo com conhecimento especializado ou
treinamento, e est disponvel em vrias fontes, por exemplo:
Outras unidades dentro da organizao.
Consultores.
Partes envolvidas, incluindo clientes.
Associaes profissionais e tcnicas.
Grupos industriais.

Estrutura Analtica do Projeto EAP

A EAP a estrutura analtica do projeto. Embora em um primeiro momen-

to o nome em portugus desta ferramenta possa parecer estranho, quando
analisamos o nome em ingls fica mais fcil entender qual a proposta des-
ta ferramenta.

72 captulo 2
 WBS o termo em ingls referente a EAP e significa work breakdown struc-
ture, que quer dizer:
Work: esforo fsico ou mental sustentvel para transpor obstculos e atin-
gir um objetivo;
Breakdown: diviso em partes ou categorias. Decompor em partes menores;
Structure: algo organizado de forma padronizada ou formalizada.
Assim fica mais fcil de entender que a EAP e a decomposio (breakdo-
wn) hierrquica (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 decomposio dos trabalhos em partes menores serve
para torn-los mais gerenciveis.
A EAP uma ferramenta grfica, ento a decomposio hierrquica do tra-
balho do projeto acontece por meio de retngulos e interligaes desses retn-
gulos para formar a hierarquia de trabalho.
Para a criao de uma EAP comum o uso da tcnica de decomposio que
sugere a subdiviso das entregas de trabalhos em componentes menores e mais
facilmente gerenciveis 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-
fivel. Este ltimo nvel de entrega de trabalho chamado de pacote de trabalho.
Uma boa prtica para se desenhar uma EAP partir de um retngulo prin-
cipal que recebe o nome do projeto; em seguida, como filhos desse retngulo,
so desenhadas as fases do projeto, e, como filhos dessas fases, so desenhados
os pacotes de entregas intermedirios e, por fim, como filhos dos pacotes in-
termedirios, so desenhados os pacotes de trabalho que devem ser entregues,
como mostra a figura 2.2.
A decomposio do trabalho total do projeto normalmente envolve as se-
guintes atividades: identificar as entregas de trabalhos relacionadas; estrutu-
rao e organizao da EAP; decomposio dos nveis mais altos da EAP em
nveis mais baixos; desenvolvimento e atribuio de cdigos de identificao
aos componentes da EAP; verificar se o grau de decomposio necessrio
e suficiente.

captulo 2 73
 CONEXO
Este vdeo, de Ricardo Vargas, explica a construo da EAP de maneira bastante didti-
ca. Endereo: https://www.youtube.com/watch?v=TS9eciG-Ddw

Produto
Software Verso 5.0
Ciclo de Vida do Projeto

Gerenciamento Requisitos Projto Integrao

Construo
do projeto do produto detalhado e teste

Planejamento Software Software Software Software

Documentao Documentao Documentao Documentao

Reunies do usurio do usurio do usurio do usurio

Materiais dos Materiais dos Materiais dos Materiais dos

Administrao 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 quo especfico ele pode ser?
Segundo Ricardo Vargas, h uma regra de ordem prtica chamada 4/40 e
8/80 que significa que um pacote de trabalho deve ter no mnimo entre 4-8h e
no mximo entre 40-80h. J para o professor Josu Silva, referenciado no link
de multimdia a seguir, o momento de parar de decompor a atividade quando
possvel lhe atribuir uma pessoa responsvel.
Outro ponto interessante de se notar que h duas formas de se orientar a
construo 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,
entregveis. A segunda diz respeito a organizar a EAP orientada a tarefas, ou
seja, a atividades que devem ser executadas para entregar o projeto.

74 captulo 2
 CONEXO
Tcnicas para gerao da EAP - https://www.youtube.com/watch?v=qQQ5RHuDA6A

Para que no haja nenhum tipo de ambiguidade ou mais de uma interpre-

tao, quando da elaborao de uma EAP, necessria a criao de um dicio-
nrio, de forma que todos os termos descritos dentro das caixas da EAP sejam
claros. O dicionrio da EAP pode servir como parte de um sistema de autoriza-
o de trabalho descrevendo para os integrantes da equipe cada componente
da estrutura analtica do projeto e pode ser usado para controlar quando um
trabalho especfico realizado de modo a evitar aumento do escopo e aumento
da compreenso das partes interessadas sobre o esforo necessrio para cada
pacote de trabalho. A figura 2.3 ilustra um exemplo de dicionrio de EAP.

Processos de definio e documentao das deci-

1.1.6 Gesto de compras e aquisies ses de compras do projeto especificando a aborda-
gem e identificando fornecedores em potecial.
O gerenciamento de custos inclui processos envol-
vidos em estimativa, oramentao e controle de
1.1.7 Gesto de custos
custos de modo que seja possvel concluir o projeto
dentro do oramento aprovado.
1.2 Execuo do projeto Fase
Nessa etapa ser realizada anlise junto a usurios
1.2.1 Anlise do sistema para definio da customizao a ser realizada alm
da definio de ferramentas e distribuio da equipe.
Etapa de desenvolvimento de rotinas e programas
1.2.2 Desenvolvimento e customizao
definidos para customizao do sistema.
1.2.3 Efetuar aquisies Compra de equipamentos e contratao de um DBA.
Nessa etapa ser realizada a implantao e confi-
1.2.4 Montagem da infraestrutura gurao de software e hardware para a implantao
do sistema.
Nessa etapa ser realizado a implantao do novo
1.2.5 Implantao do controle de estoque
sistema.
Nessa etapa ser definido o cronograma de treina-
1.2.3 Treinamento mentos, elaborao e distribuio dos manuais e a
execuo dos treinamentos.
Auditoria dos processos e encerramento oficial do
1.2.4 Encerramento
projeto.
Planejamento e execuo do controle do monitora-
1.3 Acompanhamento
mento do projeto.

Tabela 2.7

captulo 2 75
Verificao do escopo

Verificao do escopo o processo de obter o aceite formal do escopo do proje-

to pelas partes envolvidas (patrocinador, cliente, fregus e etc.). Isto exige uma
reviso 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 verificao do escopo deve estabelecer e documentar o nvel e extenso
da complexidade. A verificao do escopo difere do controle da qualidade j
que fundamentalmente relacionada com a aceitao do resultado do traba-
lho enquanto o controle da qualidade fundamentalmente relacionado com a
exatido dos resultados do trabalho. Assim para o mesmo trabalho executado
busca-se tanto a exatido quanto a aceitao do escopo.

REFLEXO
A verificao do escopo um processo contnuo que visa garantir que todas as atividades
sejam realizadas corretamente e satisfatoriamente.

Uma das tcnicas utilizadas para verificao do escopo a inspeo. Essa

tcnica inclui atividades tais como medio, exames e testes incumbidos de
determinar se os resultados esto de acordo com as exigncias. As inspees
so, diferentemente, chamadas de revises, revises de produto, auditoria, e
ensaios (walk-throughs); em algumas reas de aplicao esses diferentes ter-
mos tm significado estreito e especfico.
A sada essencial da verificao do escopo o documento de aceitao for-
mal, que consiste na documentao de que o cliente ou patrocinador aceitou
o produto do projeto ou da fase deve ser preparada e distribuda. Tal aceitao
pode ser condicional, especialmente no fim de uma fase.

Controle do Escopo

O controle de mudanas do escopo consiste em: influenciar os fatores que

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

76 captulo 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 necessrios para efetuar mudanas no esco-
po do projeto e inclui a documentao e os nveis de aprovao necessrios em
cada caso. Para realizar este tipo de controle preciso ter uma clara viso sobre
os detalhes do escopo do projeto (envolvendo o plano de gerenciamento de es-
copo), de forma a entender de forma inequvoca a origem da mudana e seus
efeitos (MULCAHY, 2007).
O controle em qualquer rea de conhecimento nada mais do que a cor-
reo de desvios, ou seja, sempre que o trabalho se distanciar daquilo que foi
planejado anteriormente (linha de base ou baseline). Assim, sempre que neces-
srio o trabalho refeito ou redirecionado.
Um sistema de controle de mudanas do escopo:
Define os procedimentos para efetuar mudanas no escopo do projeto e
no escopo do produto.
Inclui a documentao, os sistemas de acompanhamento e os nveis de
aprovao necessrios para autorizar mudanas
Quando o projeto gerenciado sob um contrato, o sistema de controle de
mudanas tambm fica de acordo com todas as clusulas contratuais relevantes;

O sistema de controle de escopo depende tambm das seguin-

tes documentaes
1. Estrutura de decomposio de trabalho, que define o baseline do esco-
po do projeto
2. Relatrios de desempenho. Os relatrios de desempenho fornecem
informaes sobre o desempenho do escopo tais como quais produtos inter-
medirios foram completados e quais no o foram. Relatrios de desempenho
podem, tambm alertar a equipe do projeto para questes que podem causar
problemas no futuro.
3. Requisies de mudana. As requisies de mudanas podem ocorrer
de muitas maneiras oral ou escrita, direta ou indireta, iniciada externa ou in-
ternamente, e legalmente imposta ou opcional. As mudanas podem exigir a
expanso do escopo ou podem permitir que seja reduzido. A maioria das de-
mandas de mudana resultado de:

captulo 2 77
 Um evento externo (por exemplo, uma mudana em uma regulamen-
tao governamental).
Um erro ou omisso no detalhamento do escopo do produto (por
exemplo, no incluir uma caracterstica necessria no projeto de um siste-
ma de telecomunicao).
Um erro ou omisso no detalhamento do escopo do projeto (por
exemplo, usar uma lista de material (BOM) em vez de usar uma estrutura
analtica do projeto (EAP).
Uma mudana no valor agregado (por exemplo, um projeto de recu-
perao ambiental capaz de reduzir custos atravs do uso de uma tecno-
logia que no estava disponvel quando o escopo do projeto foi original-
mente definido).
Implementao de um plano de contingncia, ou workaround, du-
rante a ocorrncia de um evento de risco.

4. Plano de gerncia do escopo. Como resultados do sistema de controle

de escopo podemos ter:
I. Mudanas do escopo. Uma mudana do escopo qualquer modi-
ficao no escopo combinado do projeto, conforme definido pela EAP
aprovada. As mudanas do escopo do projeto, frequentemente, exigem
ajustes no custo, no prazo, na qualidade ou em outros objetivos do pro-
jeto. Mudanas do escopo so retornos (feedback) ao longo do processo
de planejar, os documentos tcnicos e de planejamento so atualizados
conforme necessidade, e as partes envolvidas so informadas conforme
for apropriado.
II. Aes corretivas. A ao corretiva tudo aquilo que feito para com-
patibilizar o desempenho futuro da programao com o plano do projeto.
III. Lies aprendidas. As causas das variaes, as razes por trs da
aes corretivas tomadas, e outros tipos de lies aprendidas do controle
de mudanas do escopo, devem ser documentadas para que estas infor-
maes se integrem a um banco de dados histrico tanto para o projeto
em andamento quanto para outros projetos da organizao.
IV. Baseline ajustado. Dependendo da natureza da mudana, o baseli-
ne correspondente (prazo, custo, etc) pode ser revisado e re-emitido com
o objetivo de refletir a alterao aprovada e criar um novo baseline para
futuras mudanas.

78 captulo 2
 REFLEXO
importante voc ter em mente que um projeto gera um produto/servio, e que depois que
esse produto/servio gerado, o projeto costuma findar (digo costuma, pois ainda pode
haver alguma fase de acompanhamento do produto/servio antes do trmino).
Dessa forma, o ciclo de vida do projeto e o ciclo de vida de gerenciamento de projetos
tambm terminam, continuando, agora, o ciclo de vida do produto, o qual poder gerar vrios
outros projetos.
A confuso com o jogo de palavras acima j no deve mais ser problema para voc
depois de tudo o que conversamos nesta unidade. Mas se ainda for, recomendamos que
voc volte ao incio da unidade e a leia novamente. E ainda recomendamos que voc envie
mensagem ao professor e participe dos plantes para tirar suas dvidas.

LEITURA
Desta vez, no 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.
Gostaramos, 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 ao da Warner Bros. Estrelado por George
Clooney e Brad Pitt, que fazem papel de ladres profissionais que empreendem, na ocasio,
u assalta a um casino em Las Vegas. O grande barato deste filme para ns, 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 animao dos estdios Disney e mostra o empreendi-
mento de uma pequena formiga contra grandes gafanhotos. Para ns, o filme importante,
pois mostra como erros de comunicao podem trazer grandes prejuzos ao projeto.
Bom filme, pessoal!

ATIVIDADES
Desenvolvemos, a seguir, um conjunto de perguntas para que voc possa fixar o contedo
aprendido neste captulo. Responda s perguntas abaixo utilizando como base tudo aquilo
que voc estudou neste captulo, nas conexes apresentadas e utilizando o conhecimento

captulo 2 79
que voc j possui de vivncias profissionais ou de estudos de mdulos passados referentes
ao mundo coorporativo.

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

mostrados pelo PMBOK tambm podem ser classificados em reas de conhecimento. Quais
so elas?

02. Qual a importncia da rea de conhecimento de integrao?

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

04. O que pode incluir uma declarao de requisitos?

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

06. O que um pacote de trabalho?

07. Quais so os aspectos positivos da definio de escopo?

08. O que so premissas de um projeto? D exemplos.

REFERNCIAS BIBLIOGRFICAS
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 Fbio.. Gerenciamento de projetos de tecnologia da informao. Rio de Janeiro:
Elsevier, 2007.

80 captulo 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 sadas dos processos de escopo, portanto geralmente so execu-
tados aps esses processos.
Isso por que o gerenciamento do tempo determinado com base nas atividades
necessrias para a realizao do projeto, que so 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 tambm se configura como uma
atividade complexa, uma vez que estimar/planejar tempo em atividades abstra-
tas, como implantao ou desenvolvimento de software, no algo to trivial,
muito embora a engenharia de software nos oferea algumas tcnicas, como
vamos ver a seguir.

OBJETIVOS
Conceituar gerenciamento de tempo, de custo e de recursos humanos
Identificao das atividades de cada rea
Sequenciamento de atividades
Estimativas de Durao
Ferramentas e tcnicas de refinamento e acompanhamento para elaborao do cronograma

82 captulo 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 organizaes. Dentro dessa ferramenta, um dos conceitos mais importantes
o Gerenciamento do Tempo, cuja funo control-lo eficientemente para
atingir os objetivos planejados pela organizao. O tempo est diretamente li-
gado a trs fatores: escopo, custo e qualidade. Dessa forma, qualquer mudana
em uma das variveis citadas acima pode afetar as outras, i.e. qualquer atraso
em seu tempo de um projeto poder influenciar na mudana de escopo.
Portanto, o gerenciamento do tempo, juntamente com o gerenciamento
de custos, segundo Vargas (2009), so as mais visveis reas do gerenciamento
de projeto. A grande maioria das pessoas que se interessam por projetos tm
como objetivo inicial controlar prazos, confeccionar cronogramas e redes, etc.
O principal objetivo dessa rea garantir que o projeto seja concludo dentro
do prazo determinado.
Como todos sabem, o tempo no espera! Especialmente por aquele gerente
que constri cronogramas baseados em datas impossveis. O cronograma do
projeto sempre uma restrio, at mesmo quando a data de trmino no cr-
tica. Se um projeto atrasa, na maioria das vezes ele ir consumir um capital que
ele no tinha provisionado, comprometendo, tambm, o seu custo, podendo
at mesmo causar consequncias ao produto, servio ou qualquer que seja o
resultado do projeto (VARGAS, 2009).

CURIOSIDADE
Cerca de 68% dos projetos de Tecnologia da Informao (TI) so entregues com atraso,
segundo o Standish Group. Na fase de Planejamento do Projeto so feitas as previses,
que so baseadas em premissas, como visto no captulo anterior. Premissas, dentro do ge-
renciamento de projetos so hipteses admitidas como certas, sem fundamentao, para
fins de planejamento. Isso faz com que na prtica o resultado no seja 100% exato. Assim,
a experincia auxiliada por melhores prticas so fatores que melhoram a proximidade da
estimativa com a realidade.

captulo 3 83
 Para Valeriano (1998), uma das reas de conhecimento de projetos que deve
ter uma administrao mais rgida, o tempo; sua gesto est diretamente li-
gada ao sincronismo das atividades envolvidas no projeto. Portanto, para que
esse possa ser concludo no tempo previsto necessrio se fazer um minucio-
so controle e acompanhamento de todas essas atividades com a elaborao de
um cronograma.
Em suma, o gerenciamento do tempo em projetos inclui os processos ne-
cessrios para realizar o trmino do projeto no prazo previsto, o que requer
disciplina e controle eficientes, permitindo corrigir em tempo hbil os pos-
sveis problemas com prazos, objetivando impedir sua gravidade no decorrer
da execuo.

Standish Group
A misso do Standish group mudar o mundo dos projetos de software, voltado para
a maneira de como esse projetos so gerenciados. A proposta de gesto de desen-
volvimento de software resultar em um desenvolvimento de software mais rpido e
mais seguro. A filosofia do grupo baseada em reflexo de grupos, pesquisa intensiva
e feedback constante.

Relatrio 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 apresentaes 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
trs situaes:
Bem sucedido: O projeto concludo dentro do prazo e oramento planejados, com
todos os recursos e resultados originalmente especificados.
Deficitrio: O projeto concludo 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 concludo ou nunca implementado.

84 captulo 3
 CONEXO
Consulte tambm a comunidade brasileira do Standish Group
Somos uma rede de informao que conecta profissionais que atuam na rea de TI inte-
ressados no gerenciamento de projetos e no aprofundamento das questes prticas e teri-
cas a ele relacionadas. O propsito dessa rede proporcionar informaes e permitir o dia-
logo sobre as pesquisas e servios oferecidos pelo The Standish Group. The Standish Group
tem como misso 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 relatrio 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 usurio 12,8%
Requisitos e especificaes incompletas 12,3%
Mudanas em requisitos e especificaes 11,8%
Falta de apoio executivo 7,5%
Incompetncia tecnolgica 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-
trio CHAOS, 2014. Traduo livre da autora.

CURIOSIDADE
Mas por que h uma taxa to baixa de projeto consegue ser finalizado dentro do prazo previsto?
Atrasos na concluso comprometem o custo, retardam a entrega e consequentemente,
a disponibilidade de iniciar a utilizao dos mesmos e/ou entrarem em operao. Atrasos
podem causar tambm em quebras de clusulas contratuais e consequente falha do projeto.

captulo 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 sadas dos processos de escopo, portanto geralmente so executados aps
esses processos. Devido ao fato de quer que o gerenciamento do tempo deter-
minado com base nas atividades necessrias para a realizao do projeto, que
so baseadas nos pacotes de trabalho definidos na EAP, definida quando da
elaborao da declarao 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 implantao ou desenvolvimento de software, no algo to trivial,
muito embora a engenharia de software nos oferea algumas tcnicas, como os
pontos por funo e os pontos por casos de uso.
Contudo, apesar das tcnicas, uma empresa madura deve ter uma grande
base histrica de mtricas para auxiliar no gerenciamento do tempo do projeto.
O gerenciamento do tempo em projetos composto dos processos descritos na
figura 3.1.

Definio de atividades

Sequnciamento de atividades

Estimativa das duraes das atividades

Desenvolvimento do cronograma

Controle do crongrama

Figura 3.1 Processos de gerenciamento do tempo.

86 captulo 3
Definio de Atividades

O processo de definio de atividades envolve identificar e documentar as ativi-

dades especficas que devem ser realizadas para produzir os diversos nveis de
subprodutos identificados na Estrutura de Analtica do Projeto (EAP). Esse pro-
cesso deve englobar, portanto, a definio de atividades voltadas para o alcance
dos objetivos do projeto.
Alm da EAP, a definio das atividades tambm depende da declarao do
escopo, informaes histrias, restries e as premissas. A justificativa e os ob-
jetivos do projeto contidos na declarao do escopo devem ser considerados,
explicitamente, durante a definio das atividades. As informaes histricas
(que atividades foram realmente requeridas em projetos anteriores semelhan-
tes) devem ser consideradas na definio das atividades do projeto. Por ltimo,
as restries so fatores que limitaro as opes da equipe de gerncia do proje-
to; um exemplo disso o desejo de usar o mximo da durao de uma atividade.
Voc se lembra do que a EAP e a declarao de escopo? Em caso negativo,
consulte a seo 2.3 do Captulo 2.

Tcnicas e Ferramentas para a Definio das Atividades

A primeira ferramenta que trataremos neste captulo a Decomposio. Den-

tro do contexto do processo da Definio de Atividade a decomposio envolve
subdividir os pacotes de trabalho do projeto em componentes menores e mais
manejveis para fornecer melhor controle do gerenciamento. A principal di-
ferena entre a decomposio aqui descrita e a do Detalhamento do Escopo
que nesta as sadas so descritas como atividades (aes) em vez de subprodu-
tos (itens tangveis). A estrutura analtica do projeto e a lista de atividades so
normalmente desenvolvidas sequencialmente, com a EAP comeando as bases
para o desenvolvimento da lista de atividades final. Em algumas reas de apli-
cao, a EAP e a lista de atividades so desenvolvidas paralelamente.
Outra ferramenta a utilizao de modelos. Uma lista de atividades, ou
uma parte de uma lista de atividades de projetos anteriores, frequentemente
til como modelo ou referncia para um novo projeto. As atividades no modelo
tambm podem conter uma lista dos perfis de recursos e suas respectivas horas
de esforo, identificao dos riscos, produtos esperados e outras informaes.

captulo 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 sero realizadas no projeto. Deve ser organizada como uma extenso da
EAP para assegurar que esta est completa e que no inclui qualquer atividade
que no seja requerida como parte do escopo do projeto. Assim como na EAP, a
lista de atividades deve incluir descries de cada atividade para garantir que os
membros da equipe do projeto entendero 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 gerncia do projeto. Os detalhes de suporte devem sem-
pre incluir a documentao de todas as premissas e restries identificadas A
quantidade de detalhes adicionais varia de acordo com a rea de aplicao.
Atualizaes na EAP. Ao utilizar a EAP para identificar quais atividades
so necessrias, a equipe do projeto pode identificar a falta de algum subpro-
duto ou pode ainda determinar que a descrio dos subprodutos precisa ser
clareada ou corrigida. Qualquer uma destas atualizaes deve ser refletida na
EAP e na respectiva documentao, como por exemplo a estimativa dos custos.
Estas atualizaes so 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 definio de atividade, tem-se uma lista contendo to-

das as atividades planejadas que precisam ser executadas para a finalizao
do projeto. Porm, essas atividades no esto cronologicamente organizadas,
ou seja, no h ainda nenhuma informao que diga qual atividade vem antes
ou depois.
Dessa forma, h a necessidade de se realizar o sequenciamento lgico 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 mtodo escolhi-
do, necessrio determinar tambm o tipo de dependncia entre as atividades,
que so dependncia obrigatria, arbitrria e externa.
As dependncias obrigatrias no podem ser mudadas, pois dependem da
natureza do trabalho. Exemplo: no se pode pintar uma parede sem reboc-la

88 captulo 3
primeiramente. J as dependncias arbitrrias so baseadas em melhores pr-
ticas de mercado Exemplo: Devemos pintar a parede primeiramente e depois
instalar os carpetes, pois isso o recomendvel, uma vez que por qualquer des-
cuido poderamos sujar os carpetes.
Por sua vez, a dependncia externa depende de atividades fora do domnio
e controle do projeto. Exemplo: Contratao de quaisquer servios de terceiros
que esteja relacionado a uma atividade do seu projeto. Uma dependncia ex-
terna pode vir a provocar atrasos e problemas de qualidade no projeto se, por
exemplo, o fornecedor no for confivel e qualificado.

Estimar as duraes das atividades

Uma vez definidos o planejamento de todas as atividades que devero ser exe-
cutadas para o trmino do projeto e realizado o respectivo sequenciamento, os
recursos necessrios para a execuo das atividades esto prontos. O prximo
passo planejar (estimar) a durao que cada atividade ter e depois colocar as
atividades dentro do calendrio 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 caractersti-
ca abstrata das tarefas e seu cunho intelectual, em alguns casos quase artsti-
cos (por exemplo o desenvolvimento de um software cientfico como processa-
mento de imagem ou biotecnologia).
Por isso, comum esse processo de estimativa de tempo das atividades seja
realizado por pessoas que esto mais acostumadas com o contexto e nature-
za do projeto (e que utilizam a experincia delas para realizar estimativas mais
confiveis) e tambm realizado em carter progressivo, medida que as infor-
maes necessrias para as estimativas vo ficando cada vez mais claras.
Mas, no s a arte e a experincia ou conhecimento tcito dos colaborado-
res so alternativas para este processo. H tcnicas sistematizadas como pontos
por funo e pontos de caso de uso que podem ser utilizadas juntamente com
bases histricas para a determinao 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 lies aprendidas de projetos

captulo 3 89
anteriores; envolver a equipe do projeto e tambm os clientes, se possvel e con-
siderar riscos e planejar aes.
Para executar a estimativa das duraes das atividades necessrio ter dis-
ponveis a lista de atividades, atributos das atividades, requisitos de ,recursos
das atividades, calendrio do recurso e a declarao do Escopo do Projeto, fato-
res ambientais da empresa.

Tcnicas e Ferramentas para sequenciamento de atividades

Uma das ferramentas utilizadas a opinio de pessoas especializadas nas tare-

fas definidas. Outras tcnicas passveis de utilizao so a estimativa anloga,
que admite que seja utilizada a durao real de atividades em projetos passados
como base para a estimativa de atividades parecidas no projeto atual. Por isso,
a base histrica de projetos e a opinio especializada so entradas importantes
para essa tcnica. J a estimativa paramtrica utiliza os valores unitrios de pro-
dutividade por hora de trabalho (por exemplo, para se colocar o piso em uma
casa demora-se em mdia 10m2/dia) e os multiplica pela quantidade total do
trabalho (ento, se temos 10m2 de piso para colocar em uma determinada ativi-
dade, estima-se que a atividade ter a durao de 10 dias);
A estimativa de trs pontos considera trs cenrios para estimar o prazo. As
questes a serem feitas so:
Baseando-se em um cenrio otimista (tudo dar certo), qual o prazo es-
perado? Prazo otimista (Po)
Baseando-se em um cenrio pessimista (tudo dar errado), qual o prazo
esperado? Prazo pessimista (Pp)
Baseando-se em um cenrio mais provvel, qual o prazo esperado? Prazo
mais provvel (Pmp)
Po + 4Pmp + Pp
Prazo esperado =
6

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

isso, comum a adio de reservas de tempo (ou buffers ou ainda reservas para
contingncia) s estimativas para contingenciar o risco das incertezas do cro-
nograma. Essa tcnica chamada de anlise de reservas.

90 captulo 3
 A quantidade desta reserva pode ser um nmero fixo por tarefa, uma por-
centagem por tarefa ou ainda pode ser adquirido por meio de uma anlise utili-
zando mtodos quantitativos.
O processo de estimativa das duraes da atividades resulta em: estimativa
de durao das atividades e atualizao dos documentos do projeto.

Desenvolvimento do cronograma

O desenvolvimento do cronograma objetiva atribuir datas (prazos) de incio de

trmino para as atividades. Se tais datas no forem realistas, improvvel que
o projeto termine conforme planejado. O processo de desenvolvimento do cro-
nograma deve, frequentemente, ser repetido antes da determinao do cro-
nograma do projeto. Este processo til para definir quando cada atividade do
projeto se inicia e termina.
Para desenvolvimento do cronograma, necessrio ter disponveis: lista de
atividades, diagrama de Rede do Cronograma do Projeto, calendrios de dis-
ponibilidade de recursos, estimativa de durao das atividades; declarao do
Escopo do Projeto e fatores Ambientais da Empresa.

Ferramentas e tcnicas para desenvolvimento do cronograma

Grfico de Gantt
Mtodo do caminho crtico por meio dessa tcnica possvel descobrir
em um grfico de redes qual o caminho de atividades mais longo que ser
feito no projeto e aquele que terminar mais cedo. Com essa anlise possvel
gerenciar o tempo de entrega do projeto aplicando ento tcnicas de parale-
lismo e compresso s atividades do caminho mais longo, ou seja, o caminho
crtico do projeto!
Aplicao de antecipaes e esperas durante o sequenciamento das ta-
refas antecipaes e atrasos podem ocorrer e nesta tcnica eles so ajustados.
Compresso do cronograma tcnicas para a reduo do cronograma sem
reduzir o escopo do projeto: so analisadas as compensaes entre custo e cro-
nograma em busca da reduo do tempo de execuo de uma dada atividade.
Paralelismo descobrir no grafo de rede de atividades as atividades que
esto seriadas e tentar a execuo das mesmas em paralelo para reduzir o tem-
po do caminho crtico.

captulo 3 91
 Grfico de Milestones
Baseline

Nesta disciplina, discutiremos com maior profundidade o Grfico de

Gantt, o mtodo do caminho crtico (CPM ou Critical Path Method), grfico de
Milestones e a Baseline.

Grfico de Gantt

O diagrama ou grfico de Gantt um grfico usado para ilustrar o avano das

diferentes etapas de um projeto. Os intervalos de tempo representando o incio
e fim de cada fase aparecem como barras coloridas sobre o eixo horizontal do
grfico. possvel utilizar essa ferramenta para determinar o incio e o fim das
atividades individuais de um projeto.
Os passos para elaborao so: decompor o projeto em atividades discretas,
determinar a sequncia destas atividades e ter uma estimativa de tempo para
cada atividade (suposta como determinstica) e conhecida. Veja um exemplo de
grfico de Gantt na figura 3.2.

Atividade Durao
5 10 15 20 25
A

Grfico de Gantt planejado

realizado

Figura 3.2 Exemplo de um grfico de Gantt.

A utilizao do grfico de Gantt tem vantagens e desvantagens, representa-

das na figura a seguir.

92 captulo 3
 Vantagens
- Visual/ Fcil construo
- Entendimento continuado
- Fora um planejamento

Desvantagens
- No so adequados para projetos
complexos de grande escala
- No mostram claramente a
interdependncia de atividades
- No fornece indicador de prioridade
quando existem atividades que
concorrem por recursos

Figura 3.3 Vantagens e Desvantagens da utilizao do grfico de Gantt.

Mtodo do caminho crtico (Critical Path Method CPM)

Tcnica usada para planejar e controlar as atividades necessrias para a execu-

o de um projeto. Mostrando cada uma dessas atividades e o tempo associa-
do, possvel determinar o caminho crtico, identificando os elementos que
restringem o tempo total de projeto. Utiliza-se quando tiver que gerenciar pro-
jetos complexos e de longa durao. Mostrando cada uma dessas atividades e
o tempo associado, possvel determinar o caminho crtico, identificando os
elementos que restringem o tempo total de projeto.
Para utilizao do mtodo do caminho crtico necessrio 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
durao das atividades Determinstica (varincia nula). Grafo onde as ativi-
dades do projeto so colocadas de acordo com relaes de precedncia
Primeiramente, vamos tratar da construo do diagrama de rede do projeto.

Mtodo do diagrama de flecha (ADM - Arow Diagramming Method

ou Diagrama Activity on Arc - AOA).

Este um mtodo de construo de diagrama de rede que utiliza setas para repre-
sentar as atividades e as conecta por meio de ns que representam as dependn-

captulo 3 93
cias um diagrama simples de rede lgica utilizando o ADM. Esta tcnica tam-
bm chama de atividade no arco (AOA - Activity-on-arc) . O ADM utiliza apenas
relaes de dependncia do tipo fim/incio e pode requerer o uso de atividades
fantasmas (tambm chamadas de fictcias ou dummy) para definir corretamente
o relacionamento lgico. O ADM pode ser feito manualmente ou no computador.
No Diagrama de Rede, cada atividade possui um incio e um fim, que so
pontos no tempo. Esses pontos no tempo so conhecidos como eventos. As ati-
vidades so representadas por setas e os eventos ponto inicial e final por
crculos (chamados tambm de ns). A seta aponta para o crculo que repre-
senta o evento final, para dar a idia de progresso no tempo. As atividades so
representadas por nmeros ou letras e os crculos so 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 construdo o diagrama de rede, necessrio determinar:

Tempo mais cedo de uma etapa: o momento mais cedo em que ocorre a
concluso de todas as atividades de que a etapa Etapa Final ou o momento
mais cedo em que pode ocorrer o incio de qualquer das atividades de que a eta-
pa Etapa Inicial. Utilizaremos a notao TE time early. Para calcular o tempo
mais cedo de uma etapa j:
Iniciar o clculo 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
durao da atividade associada ao arco;
O TE da etapa j igual maior das somas calculadas.

94 captulo 3
 Tempo mais tarde de uma etapa: o momento mais tarde em que ocorre a
concluso de todas as atividades de que a etapa Etapa Final ou o momento
mais tarde em que pode ocorrer o incio de qualquer das atividades de que a
etapa Etapa Inicial. Utilizaremos a notao TL time later. Para calcular o
tempo mais tarde de uma etapa j:
Iniciar o clculo 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 durao da atividade associada ao arco;
O TL da etapa j igual menor das diferenas calculadas.

Folga de uma etapa: o intervalo de tempo em que ocorre a concluso 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 representao grfica 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 Representao grfica de TE, TL e F.

Um exemplo muito simples de um Diagrama de Rede o planejamento

de um jantar. A deciso 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 incio aps a deciso de oferecer o jan-
tar. Uma vez elaborada a lista de convidados, possvel enviar os convites. Por
outro lado, uma vez comprados os ingredientes, possvel preparar o jantar.
Uma vez preparado o jantar, pode-se deixar a casa em ordem para a recepo.
Segue-se a recepo aos convidados, que deve obrigatoriamente ocorrer aps a
emisso dos convites e aps se deixar a casa em ordem. Finalmente, recepcio-
nados os convidados, pode-se servir o jantar, e dar por encerrado o "projeto".

captulo 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
DESIGNAO
PRECEDENTES IMEDIATAS
A Nenhuma
B A
C A
D B
E C
F D
G E.F
H G

Tabela 3.2 Representao 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 sequncia 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 durao de um caminho soma das duraes de todas as ativida-

des que o compem. Em um Diagrama de Rede, o caminho com a maior durao
chamado de caminho crtico e governa o tempo de trmino do projeto: o tempo
de trmino de um projeto igual durao de seu caminho crtico. Qualquer atra-
so neste caminho, automaticamente determinar um atraso no projeto. As ativi-
dades do caminho crtico so chamadas de atividades crticas. Nenhuma dessas

96 captulo 3
atividades pode se atrasar, sem que o projeto tambm se atrase. Numa linguagem
tpica, dizemos que essas atividades no tm folga ou, equivalentemente, que sua
folga zero. Em outros caminhos que no o caminho crtico, as atividades podem
sofrer algum atraso sem que implicar em atraso do projeto.

EXERCCIO RESOLVIDO
01. Dado o Diagrama de Rede abaixo, determine:
a) os caminhos possveis e a durao de cada um;
b) o caminho crtico e a durao 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 durao 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

Soluo:
a) Caminhos e sua durao

Note que existem apenas quatro caminhos, cujas duraes so dadas pela soma das
duraes das atividades que os constituem:

CAMINHO DURAO
ACH 24 semanas
ADG 22 semanas
BEG 20 semanas
BFI 21 semanas

captulo 3 97
b) Caminho, crtico e durao esperada do projeto
O caminho crtico o de maior durao, portanto:
A C H com 24 semanas, que a durao esperada do projeto.

c) Folga de cada caminho

A folga de cada caminho a diferena entre a durao do caminho crtico e a do pr-
prio caminho;

CAMINHO DURAO
ACH 24 24 = 0
ADG 24 22 = 2 semanas
BEG 24 20 = 4 semanas
BFI 24 21 = 3 semanas

Convenes para a Construo de Diagramas de Rede

O processo de construo do Diagrama de Rede para um projeto envolve, prelimi-

narmente, a especificao de todas as atividades que compem o projeto. Esta
uma etapa chave, que d base construo do Diagrama propriamente dito.
Na construo do Diagrama de Rede, cada atividade ser representada por
uma seta, que se inicia e termina cm um n. Existem diversas regras bsicas
para se indicar as relaes entre as atividades. Para que o seja possvel reali-
zar os clculos de TE, TL e F, tambm necessrio que sejam especificadas as
duraes das atividades. Vejamos agora as convenes fundamentais para a
construo de um Diagrama de Rede:
1a. Cada atividade representada por uma nica seta, cujo comprimento
no precisa guardar relao com a durao da atividade.
2a. A direo da seta indica as progresses no tempo.
3a. Se uma atividade comea num evento (n), ela s pode se iniciar depois
que todas as atividades terminando naquele evento tenham sido completadas.
4a. As atividades so identificadas, principalmente por programas de com-
putador, por seus ns inicial e final, devidamente numerados da esquerda para
a direita. Desta forma, imprprio que duas atividades tenham os mesmos ns
inicial e final.

98 captulo 3
 A representao abaixo da figura 3.7, que est incorreta para efeitos prti-
cos, mostra que a atividade C s pode comear depois que tanto A quanto B
tenham sido concludas. A representao inconveniente, pois A e B tm os
mesmos ns inicial e final.

1 2

Figura 3.7 Exemplo de representao AOA incorreta.

Corrige-se tal situao criando uma atividade fantasma, com durao zero
e sem influncia real no Diagrama de Rede. A atividade fantasma serve apenas
para auxiliar na individualizao 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 no pode se

iniciar antes que B esteja concluda. Logo, indiretamente, fica estabelecida a
relao de dependncia entre C e B.
Dessa forma, a importncia de se identificar o caminho crtico fundamenta-
se nos seguintes parmetros: permitir saber, de imediato, se ser possvel ou
no cumprir o prazo anteriormente estabelecido para a concluso do plano e
identificar as atividades crticas que no podem sofrer atrasos, permitindo um
controle mais eficaz das tarefas prioritrias.
Ainda, o mtodo CPM permite priorizar as atividades cuja reduo ter me-
nor impacto na antecipao da data final de trmino dos trabalhos, no caso de
ser necessria uma reduo desta data final. Possibilita o estabelecimento da
primeira data do trmino da atividade e o estabelecimento da ltima data do
trmino da atividade.

captulo 3 99
Grfico de Milestones

O grfico de milestones uma ferramenta que permite o controle geren-

cial ao longo do projeto atravs da definio de pontos de checagem ou marcos
de desenvolvimento e utilizado em conjunto e baseado no grfico de Gantt.
Considera apenas eventos significativos de um projeto, chamados de eventos
cujas atividades tem durao zero e alocao de recurso zero.
Data
Atual
Evento Jan Fev Mar Abr Mai Jun Jul Ago
Subcontratos Assinados
Especificaes Finalizadas

Projeto Revisto
Subsistema Testado
Primeira Unidade Entregue
Plano de Produo Completado

Planejado Realizado

Figura 3.9 Exemplo de grfico de milestones.

Marcos ou eventos so acontecimentos significativos no desenvolvimento

do projeto e que servem de parmetros para o controle gerencial, tais como:
1. Assinatura de contrato
2. Incio de uma atividade
3. Concluso 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 aprovao do que foi planejado, similar a um congelamento do
cronograma planejado. usada para avaliar a evoluo do projeto monitoran-
do o prazo atravs da comparao do planejado com o realizado. O gerente de
projeto deve entender as causas das alteraes do cronograma e influenci-las
sempre que possvel.
A linha de base do cronograma tambm ajuda o GP a negociar as mudanas
solicitadas demonstrando o impacto que ocorrer no prazo do projeto.

100 captulo 3
Controle do cronograma

O controle do cronograma uma funo contnua e essencial na gesto do pro-

jeto durante toda sua trajetria. Isso possibilitar identificar-se a necessidade
de tomadas de aes corretivas, quando forem verificados desvios negativos ou
tendncias dos mesmos virem a ocorrer, em relao ao que foi planejado.

Sistema de controle de mudanas do cronograma

O sistema de controle de mudanas do cronograma define os procedimentos

pelos quais o cronograma do projeto pode ser mudado. Isto inclui manuais,
sistemas de acompanhamento, e nveis de aprovao para que as mudanas
necessrias sejam autorizadas. O controle de mudanas do cronograma deve
estar integrado com o sistema integrado de controle de mudana. Ferramentas
para realizar o controle do cronograma de um projeto incluem:
Medio do desempenho. As tcnicas de medio de desempenho ajudam
a determinar a magnitude de quaisquer variaes que ocorram. Uma parte im-
portante do controle de mudanas no cronograma decidir se a variao do
cronograma exige uma ao corretiva. Por exemplo: um grande atraso em uma
atividade que no crtica pode ter um efeito pequeno no projeto total, enquan-
to pequenos atrasos em atividades crticas ou quase crticas podem requerer
aes imediatas.
Planejamento adicional. Poucos projetos se desenvolvem exatamente de
acordo com o plano. As mudanas em perspectiva podem requerer novas ou re-
visadas estimativas de durao das atividades, modificaes na seqncia das
atividades ou anlise de cronogramas alternativos.
Softwares de gerncia de projeto. Os softwares de gerncia de projeto esto
descritos A capacidade dos softwares de gerncia de projetos para acompanhar
as datas planejadas versus as datas reais e prever os efeitos de mudanas no
cronograma, reais ou potenciais torna-os uma ferramenta til para o controle
do cronograma.
Anlise de variao. A execuo do processo da anlise de variao durante
a monitorao do cronograma o elemento chave para o controle do tempo.
A comparao das datas alvos com as realizadas de incio e fim, nos fornece
informaes teis para a deteco de desvios e para a implementao de aes
corretivas em caso de atraso. As etapas comuns so:

captulo 3 101
 1. Verificar qualidade das informaes coletadas;
2. Determinar variaes entre real x linha de base;
3. Usar equaes especficas para quantificar as variaes;
4. Determinar impacto das variaes nos custos e no cronograma;
5. Analisar tendncias das variaes e documentar quaisquer desco-
bertas sobre fontes de variao 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 no pode considerar apenas os
cursos incorridos no prprio projeto. Muitas vezes, o projeto est desenvolven-
do um produto, ou servio, 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
concepo 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

Incio da Comercializao
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 captulo 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. Aps esse perodo, inicia-se, imediatamente, a comercializao, ob-
tendo uma receita conforme a curva superior do grfico 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 incio do projeto,
ou z-y meses a partir do incio da comercializao do produto (VARGAS, 2009).
Aps esse perodo, o projeto passa a ter um lucro real, determinado pelo valor do
lucro operacional que superar $x. Porm o produto desenvolvido tambm tem um
ciclo de vida comercial e aps um tempo t, o produto se deteriora comercialmente,
tendo alcanado 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 relao ao gerenciamento de custos diz respeito
aos oramentos. O oramento no pode ser considerado simplesmente como uma
viso do plano. Ele um mecanismo poderoso de controle. O oramento serve como
parmetro de comparao, uma linha de base da qual se extraem informaes sobre
o desempenho financeiro do projeto. O oramento precisa ser validado ao longo do
tempo, durante a execuo do projeto (controle de custos), para que os eventuais pro-
blemas sejam identificados o mais cedo possvel par que a soluo possa ser anteci-
pada, evitando-se assim, danos mais graves ao oramento (VARGAS, 2009).
Muitas vezes, o gerenciamento de custos propicia um processo de recom-
pensa para os envolvidos no projeto, atravs de participao nos seus resulta-
dos. Nesses casos, o controle de custos merece uma ateno especial, sendo
talvez alvo de um processo de oramento 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:
interpretao errada do trabalho a ser realizado;
omisso na definio do escopo do trabalho;
cronograma pobremente definido ou excessivamente otimista;
fracasso na avaliao de riscos;
estrutura analtica do projeto (WBS) mal definida;
parmetros de qualidade mal estabelecidos;
fracasso na estimativa dos custos indiretos e administrativos do projeto.
1 Break Even do projeto:

captulo 3 103
3.3.1 Processos de Gerenciamento de Custos

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

nejamento, estimativa, oramentao e controle de custos de modo que seja
possvel terminar o projeto dentro do oramento aprovado. (PMI, 2012).
Segundo o PMBOK (2008), o gerenciamento de custos responsvel por ge-
renciar os custos dos recursos que so necessrios 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 oramento;
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 aproximao dos custos dos recursos necessrios para terminar
cada atividade do cronograma. (PMBOK, 2004).
Neste processo que cada atividade do cronograma recebe uma estimativa
do custo necessrio para a sua execuo.
Assim como outras estimativas, a preciso da estimativa de custo aumen-
ta conforme as informaes disponveis vo aumentando, sendo que nas fases
iniciais de planejamento do projeto uma possvel 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 oramento

Este processo faz parte do grupo de processos de planejamento

A oramentao envolve a agregao dos custos estimados de atividades
do cronograma individuais ou pacote de trabalhos para estabelecer uma linha
base dos custos totais para a mediao de desempenho do projeto. (PMBOK,
2004 e 2008).

104 captulo 3
 Basicamente, a oramentao a soma dos custos das atividades indivi-
duais, j incluindo as reservas de contingncias para formar a linha base de
custo do projeto.
Ainda, a oramentao pode incluir as reservas de gerenciamento, que es-
to 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 variaes positivas e
negativas e faz parte do controle integrado de mudanas. (PMBOK, 2004 e 2008).
Esse processo tem como responsabilidade gerenciar todas as mudanas
que acontecem no baseline de custo do projeto, bem como gerenciar os fatores
que podem criar mudanas neste baseline.
As tcnicas utilizadas para o controle de custos so bem avanadas 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 precificao: custos so resultantes das necessidades de recursos,
etc., do projeto, enquanto o preo uma deciso de estratgia de negcio
da organizao;
qualquer estimativa de custos deve vir acompanhada por sua memria
de clculo;
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 no
sendo recuperados, porque tm interesse em atingir uma meta de longo prazo
para a organizao.

captulo 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 sero utilizados para gerenciar todos os custos do
projeto. No plano, segundo Vargas (2009), deve estar documentado:
ttulo do projeto;
nome da pessoa que elaborou o documento;
descritivo dos processos de gerenciamento de custos (regras gerais);
descrio das reservas gerenciais e da autonomia em sua utilizao;
sistema de controle de mudanas de prazos (Time Change Control System);
frequncia de avaliao do oramento do projeto e das reservas gerenciais;
alocao financeira das mudanas no oramento;
nome do responsvel pelo plano;
frequncia de atualizao do plano de gerenciamento de custos;
outros assuntos relacionados ao gerenciamento de custos no previstos
no plano;
registro de alteraes no documento;
aprovaes.

CONEXO
Conexo: H um outro podcast do Ricardo Vargas chamado Importncia da Estrutura Ana-
ltica (EAP) no Gerenciamento de Custos do Projeto e disponvel em http://www.ricardo-
vargas.com/pt/podcasts/wbs_costmgmt/, que fala um pouco sobre a importncia da EAP
na oramentao do projeto. uma conexo interessante a partir do momento que Ricardo
Vargas chama a ateno para a interligao 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
funes e responsabilidades atribudas e que contribuiro para o trmino do
projeto. (PMBOK, 2004 e 2008).
Assim, o gerenciamento dos recursos humanos tem como objetivo central fa-
zer o melhor uso dos indivduos envolvidos no projeto. Como se sabe, as pessoas

106 captulo 3
so 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 tcnicas
e sociais. Todos os resultados do projeto podem ser vistos como fruto das relaes
humanas e das habilidades interpessoais dos envolvidos, uma vez que a satisfao
pessoal e a qualidade de vida esto se tornando um dos fatores-chave da motivao
de qualquer profissional (VARGAS, 2009). No passado, a maioria dos projetos se
preocupou unicamente com aspectos tcnicos, que foram altamente desenvolvi-
dos. Porm, os aspectos humanos, que poderiam conduzir o projeto aos mesmos
ganhos do desenvolvimento tcnico, foram relegados a um segundo plano. Agora,
so 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 so as pessoas que
podem mudar os rumos de um projeto, levando-o ao sucesso ou ao fracasso, de-
pendendo de seu grau de envolvimento, motivao e engajamento com a equipe.
Como os custos e o fluxo de caixa variam significativamente atravs do ciclo
de vida do projeto, os recursos humanos so necessrios em vrios nveis de es-
pecialidade e experincia, dependendo da natureza do trabalho a ser realizado,
do nvel de maturidade do time do projeto e das restries 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-
svel pela execuo do projeto; e a equipe de gerenciamento de projeto (que tam-
bm pode ser chamada de equipe principal, executiva ou lder), que responsvel
pelo ciclo de vida de gerenciamento de projeto planejando-o e controlando-o.
Normalmente, essa separao de equipes vista em grandes projetos, nos
quais os papis so muito bem definidos e quase sempre vivenciados por indi-
vduos diferentes. J nos pequenos projetos e em pequenas empresas, os vrios
papis 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 sero
contratados, desenvolvidos, motivados e outros;
realizar a contratao e mobilizao do RH;
executar os treinamentos e desenvolvimentos dos RH; e
acompanhamento de todos os RH do projeto.

captulo 3 107
 Essas atividades so realizadas por meio de 4 processos, que perfazem o ci-
clo de planejamento, de execuo 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 funes, responsabilidades
e relaes hierrquicas 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 informaes sobre contratao e mobilizao
dos membros da equipe do projeto, critrios para o desligamento dessas pes-
soas do projeto, planos de treinamento, motivao e segurana.

3.4.2 Mobilizar a equipe do projeto

Este processo faz parte do grupo de processos de execuo.

o processo de confirmao da disponibilidade e obteno dos recursos hu-
manos necessrios para terminar o projeto, sendo que a equipe de gerenciamen-
to de projeto pode ter, ou no, controle sobre essas selees. (PMBOK, 2012).
Este processo responsvel por contratar, se necessrio, e mobilizar os re-
cursos humanos necessrios para a execuo das atividades que iro compor o
trabalho do projeto (VARGAS, 2009).
bom lembrar que o gerente de projetos pode (ou no) ter controle sobre
o processo de contratao dessas pessoas. Ou seja, nem sempre o gerente de
projetos responsvel pela seleo dos membros da equipe. Isso por que as or-
ganizaes que esto 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 execuo.

108 captulo 3
 Melhorar as competncias e a interao 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 competncias, aumento
da coeso 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 resoluo de problemas e a coordenao de mudan-
as para melhorar o desempenho do projeto. (PMI, 2012).
Alm do descrito no quadro acima, neste processo tambm temos a obser-
vao do comportamento da equipe executora, gerenciamento de conflitos,
resoluo de problemas e avaliao do desempenho dos membros da equipe.
Basicamente, nesse processo todas as medies relativas equipe do pro-
jeto so realizadas, alteraes do plano de gerenciamento so solicitadas e as
lies aprendidas so 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 esprito de corpo contribui para o sucesso;
Conflitos podem ocorrer entre o projeto e a organizao;
Qualquer promessa feita durante o recrutamento deve ser documentada;
Os nveis de equipes so muito mais variveis em um ambiente de projeto
que em um ambiente funcional;
Treinamento e desenvolvimento so mais complexos e crticos durante o
projeto, se comparados com o trabalho tradicional da organizao.

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

02. Quais so os cinco processos do gerenciamento de tempo em projetos?

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

captulo 3 109
04. Porque mais difcil estimar os tempos das atividades planejadas na rea de TI?

05. Quais so as principais ferramentas para desenvolvimento do cronograma?

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

ATIVIDADE DEPENDNCIA

B A,D

C B,F

E A,D

F E,G,I

H E,G,I

J I

K H,J

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

REFLEXO
Podemos notar at este ponto do nosso material, que todos os tipos de gerenciamento, seja
de pessoas, de custos, de escopo como vimos no captulo anterior so 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
gesto, pode ser o caminho para o sucesso!

110 captulo 3
 LEITURA
Gesto de Custos em Projetos da Secretaria de Defesa Social de Minas Gerais, de
Luiza Hermeto Coutinho Campos. Disponvel em:
Resumo do artigo: Este artigo dispe sobre o gerenciamento de projetos no mbito da
Administrao Pblica, tendo em vista a escassez de material cientfico acerca desta meto-
dologia gerencial sob a perspectiva no privada. Assim, o cerne do trabalho o programa
governamental Choque de Gesto, que trouxe a Gesto de Projetos ao Estado de Minas
Gerais, no qual foram estabelecidas rotinas de monitoramento e instrumentos para gesto,
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 gesto de projetos e, ao lidar com as diversas peculiaridades tpicas da gesto
oramentria no setor pblico, 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 endereo: http://www.revistagep.org/ojs/index.php/
gep/article/view/242

LEITURA
Modelo PMBOK/PMI para gesto de projetos nas micro e pequenas empresas: um estudo
de caso, de Vernica 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 gesto 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 gesto de projetos e inclui conhecimentos
comprovados por prticas tradicionais, assim como conhecimentos por prticas inovadoras
com aplicao limitada. Em termos metodolgicos, esta uma pesquisa exploratria, 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 gesto implantado, sem monitoramento das atividades e indicadores de resultados e sem
as informaes necessrias para gerir o negcio. Isso uma dificuldade para a implanta-
o do PMBOK/PMI, mas pode ser uma vantagem por criar controles e disciplina utilizando
ferramentas de gesto, como cronograma e oramentos. Tambm por projetos envolverem

captulo 3 111
atividades no contnuas na empresa, existe o risco de o gestor confundir estas com as
atividades do cotidiano e no conseguir avaliar o que pode ser gerido por projeto.
Leia o artigo na ntegra pelo endereo: http://www.spell.org.br/documentos/
download/3028.

REFERNCIAS BIBLIOGRFICAS
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). Pennsylvnia:
[s.n.], v. 3, 2004.
PMI. Um Guia do Conhecimento em Gerenciamento de Projetos (Guia PMBOK). 4. ed.
Pennsylvnia: [s.n.], 2008.
Pons, R. (2009). Fundamentos em gerenciamento de projetos: mdulo bsico do curso de formao
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). Gerncia em projetos: pesquisa, desenvolvimento e engenharia. So Paulo:
Makron Books.
VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informao. Rio de Janeiro: Elsevier, 2007.

112 captulo 3
 4
Gerenciamento
de Riscos,
Comunicaes,
da Qualidade, do
Gerenciamento de
Aquisies e Partes
Interessadas
O conceito de comunicao, 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 informao so atitudes muito valorizadas Na rea de
Gesto de Projetos vemos essa caracterstica mais claramente, onde o gestor
precisa dominar tal artifcio para que a informao possa ser recebida pela sua
equipe ou cliente de forma clara e objetiva.
precisa considerar que a ideia de comunicao pode ter sofrido varia-
es com o decorrer dos anos, antigamente a escrita era vista como a principal
forma de comunicao. Hoje levamos em conta a comunicao corporal, co-
municao oral, comunicao digital e claro a escrita, todas essas formas de
comunicao 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 captulo vamos ver os gerenciamentos de riscos,
comunicaes, aquisies, qualidade e partes interessadas.
Vamos l!

OBJETIVOS
Conceituar as reas de riscos, aquisies, stakeholders e comunicaes
Apresentar o detalhamento de cada uma dessas reas de conhecimento do PMI;
Conhecer as tcnicas e ferramentas desses tipos de gerenciamento.

114 captulo 4
4.1 Gerenciamento das Comunicaes
O gerenciamento de comunicao do projeto a rea de conhecimento que em-
prega os processos necessrios para garantir a gerao, coleta, distribuio, ar-
mazenamento, recuperao e destinao final das informaes 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, relatrios de acompanhamento, definindo
escopo entre outros.
A arte da comunicao, competncia necessria no gerenciamento de pro-
jetos, algo que vai alm do escopo do ciclo de gerenciamento de projetos e in-
clui atividades como: modelos emissor-receptor, escolha dos meios de comuni-
cao, estilo de redao, tcnicas de apresentao, tcnicas de gerenciamento
de reunies e outros.
Sempre que pensamos em gerenciamento de projetos, logo, pensamos em
administrao de tempo, escopo e qualidade, na verdade, a administrao de
todas estas reas requer do gerente de projeto uma gama de habilidades e tc-
nicas efetivas, pois muitos elementos precisam ser coordenados. Manter um
time unido e slido, e atender as expectativas dos stakeholders um dos gran-
des desafios que um gerente de projeto enfrenta.
Um bom plano de comunicao pode ser chave para que a execuo e o con-
trole do projeto tenham sucesso.
O desenvolvimento de um plano de comunicao envolve vrios fatores
como eles administrao de informao, expectativa dos stakeholders, a preci-
so das informaes entre outros.
Durante todo o ciclo de vida de um projeto, produzida ou recebida, uma
grande quantidade de informaes. A administrao desta informao a res-
ponsabilidade do gerente de projeto. Em um plano de comunicao, necess-
rio identificar de forma clara como uma informao ser gerada e distribuda.
Portanto, responsabilidade desta rea de conhecimento fornecer as liga-
es entre pessoas e informaes adequadas, sendo que entenderemos como
pessoas todos os stakeholders do projeto, como partes interessadas, cliente
e patrocinador.
Um efetivo processo de comunicao necessrio para garantir que todas
as informaes desejadas cheguem s pessoas corretas no tempo certo e de

captulo 4 115
uma maneira economicamente vivel. O gerente de projeto utiliza-se da comu-
nicao 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 comunicao como um processo pelo qual a informao
transferida entre os indivduos atravs de smbolos, sinais e outros. Alm dis-
so, a comunicao um processo de duas vias, onde participam ativamente o
emissor e o receptor da informao, com os envolvidos atuando, na maioria das
vezes, como emissores e receptores simultaneamente.
Ento, para buscar a efetiva comunicao entre os stakeholders do projeto e
o trnsito adequado de informaes, o ciclo de vida de projetos prev 4 proces-
sos de gerncia de comunicao, sendo 1 de iniciao, 1 de planejamento, 1 de
execuo e 2 de monitoramento e controle, a saber:
1. Iniciao
a) Identificar as partes interessadas;
2. Planejamento
a) Planejar as comunicaes;
3. Execuo
a) Distribuir as informaes;
b) Gerenciar as expectativas das partes interessadas.
4. Monitoramento e controle
a) Reportar o desempenho.

4.1.1 O Processo de Comunicao

O processo de comunicao composto de trs 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) Codificao: constitudo pelo mecanismo vocal para decifrar
a mensagem.

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

a) Canal: tambm chamado de veculo, o espao situado entre o
emissor e o receptor.
b) Rudo: a perturbao dentro do processo de comunicao.

116 captulo 4
 3. Receptor: a etapa que recebe a mensagem, a quem destinada.
a) Descodificao: estabelecido pelo mecanismo auditivo para deci-
frar a mensagem, para que o receptor a compreenda.
b) Compreenso: o entendimento da mensagem pelo receptor.
c) Reao: 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 organizaes,

podem ser estabelecidos alguns fluxos no processo de trabalho provocados por
diferentes mecanismos de comunicao entre as pessoas dentro de uma orga-
nizao. So eles:
Fluxo da Autoridade Formal - Onde a informao flui segundo uma hie-
rarquia instituda dentro da organizao ou projeto, realando o fluxo do poder
formal.
Fluxo da Atividade Regulamentada Onde a informao flui segundo um
mecanismo padronizado de informao independente da hierarquia dos en-
volvidos. O foco desse fluxo a padronizao do processo de comunicao.
Fluxo das Comunicaes Informais Onde o processo de comunicao
se d sem a presena de nenhuma estrutura reguladora. As pessoas se agregam
em grupos sociais ou de relacionamento e neles no existe hierarquia ou padro-
nizao. o mais veloz e o mais arriscado mecanismo de comunicao.
Conjunto das Constelaes de Trabalho Onde o processo de comuni-
cao se d atravs de objetivos claros e adequados a cada nvel hierrquico da
estrutura. Normalmente, as constelaes de trabalho so os melhores modelos
para o desenvolvimento do processo de comunicao em projetos.
Fluxo do Processo Decisrio Especfico Onde o processo de comunica-
o necessrio para decises especficas, partindo da gerao do problema
at chegar deciso especfica a ser tomada.

4.1.2 Como Identificar um bom plano de comunicao

Devemos identificar de forma clara como uma informao ser gerada e distri-
buda. Este plano deveria identificar os tipos de relatrios (relatrios formais,
status do projeto, memorandos, etc.), a frequncia que os relatrios sero gera-
dos, e em que momento dever acontecer s reunies.

captulo 4 117
4.1.3 Planejamento das Comunicaes segundo o PMBOK

O processo Planejamento das Comunicaes determina as necessidades de

informaes e comunicaes das partes interessadas; por exemplo, quem pre-
cisa de qual informao, quando precisaro dela, como ela ser fornecida e por
quem. Embora todos os projetos compartilhem a necessidade de comunicar
as informaes sobre o projeto, as necessidades de informaes e os mtodos
de distribuio variam muito. Um fator importante para o sucesso do projeto
identificar as necessidades de informaes das partes interessadas e determi-
nar uma maneira adequada para atender a essas necessidades.[...]O planeja-
mento das comunicaes est, muitas vezes, estreitamente ligado aos fatores
ambientais da empresa e s influncias 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 Comunicao

O processo de gerenciar a comunicao pode ser considerado to importan-

te quanto qualquer outro processo dentro da empresa. Os gerentes gastam a
maior parte do seu tempo em comunicao e muitas vezes nem percebem o
impacto que uma comunicao bem feita implica positivamente no projeto.
O avano da tecnologia da informao permite que as empresas registrem
de forma eficiente as informaes de seus projetos. Mas, o que fazer com tanta
informao? O fato de registrar bem os dados do projeto no garante sua utili-
dade. Perdidos em meio a tantos registros, saber us-los de forma eficaz no
tarefa fcil se no houver um bom planejamento e uma forma de gesto da
comunicao implementada.
As empresas preocupam-se com seus processos. Buscam formas de medir
seus desempenhos, estabelecem rotinas de reunies gerenciais, criam formu-
lrios e relatrios extensos e bem estruturados. Com tudo isto, somando fa-
cilidade de preservar as informaes em formato eletrnico gera um acmulo
de dados cada vez maior. Mas, quando necessrio uma consulta, o resgate da
informao pode ser uma misso quase impossvel.

Planejar as comunicaes
Este processo faz parte do grupo de processos de planejamento.

118 captulo 4
 Determina as necessidades de informaes das partes interessadas.
(PMBOK, 2008).
Este processo tem por responsabilidade determinar as necessidades de in-
formaes no que diz respeito a definio de quem precisa da informao, em
que formato ela deve ser provida e em que tempo ela deve estar disponvel. Ou
seja, em relao s informaes, busca responder s seguintes questes:
Quem precisa?
Quando precisa?
Como precisa?
Quem deve informar?

Distribuir as informaes
Este processo faz parte do grupo de processos de execuo.
Envolve colocar as informaes disposio das partes interessadas e no
momento oportuno. (PMBOK, 2004 e 2008).
Este processo tem por responsabilidade principal colocar em prtica o pla-
no de comunicaes do projeto, disponibilizando as informaes para as pes-
soas corretas, no momento correto e no nvel adequado.

Gerenciar as expectativas dos stakeholders do projeto

Este processo faz parte do grupo de processo de execuo.
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 influncia e tem por
objetivo a execuo de comunicaes e interaes com as partes interessadas,
visando a atender as expectativas dessas partes e solucionar questes proble-
mticas, conforme elas venham a ocorrer. (PMBOK, 2008).
Esse gerenciamento pode se dar de vrias 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 no
aceitao (quando ela existir).
Prever possveis problemas que essas partes interessadas podem trazer e
efetuar a anlise de riscos.
Buscar a soluo de problemas identificados com as partes interessadas.

captulo 4 119
 De fato, o grande objetivo deste processo utilizar a identificao e o enten-
dimento sobre as partes interessadas para antever suas reaes a certas ques-
tes do projeto e, com isso, buscar alternativas preventivas para conseguir o
apoio (ou minimizar obstculos) dessas partes interessadas frente a essas ques-
tes. (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 distribuio das in-
formaes sobre o desempenho s partes interessadas. (PMBOK, 2004 e 2008).
Este processo tem por responsabilidade gerar relatrios de desempenho
sobre vrias reas do projeto, como, por exemplo: escopo, cronograma, custo
e qualidade.
Tambm, este processo informa as pessoas corretas com os documentos
corretos e no nvel de detalhe correto (entenda correto como planejado).

REFLEXO
No gerenciamento das comunicaes, importante que se atente para os aspectos a seguir:
As pessoas do o melhor de si quando compreendem completamente as decises que as
afetam e suas razes. Elas precisam perceber o que tm de fazer e o porqu, o seu desem-
penho em relao ao esperado e a sua situao profissional;
se a base do gerenciamento de projetos a formalizao de processos para alcanar
melhor desempenho, a informao e a comunicao no podem ser relegadas ao improviso
e intuio;
a deciso sobre o que comunicar, para quem e como deve ser incorporada a todas as fases
do planejamento;
os diferentes veculos de comunicao se complementam, combinando mensagens gerais
e especficas para atingir diversos pblicos;
informe sempre, em ocasies regulares e com honestidade. Isso cria credibilidade para o
processo;
nas situaes de crise, seja gil. Informe a posio atual, ainda que no seja a definitiva.
Ningum gosta de saber por ltimo, e a falta de informaes fonte para boatos, criando
instabilidade no projeto;
as pessoas no tm de concordar para cooperar com uma deciso, mas tm de compreen-
der como e por que ela foi tomada.

120 captulo 4
4.2 Gerenciamento de Riscos
Segundo Vargas (2009), na maioria dos projetos, os riscos associados com gran-
des empreendimentos tm merecido uma ateno especial dos gerentes de
projeto, devido no s s grandes somas de dinheiro que esto em suas mos,
como tambm reputao 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 foras e riscos do projeto e responder a eles, geralmente associados
a tempo, qualidade e custos. Portanto, a sobrevivncia de qualquer empreendi-
mento, atualmente, est intimamente vinculada ao conceito de aproveitar uma
oportunidade, dentro de um espectro de incertezas. O que torna a gesto dos
riscos se tornar to importante so fatores diversos, como o aumento da com-
petitividade, o avano tecnolgico e as condies econmicas, que fazem com
que os riscos assumam propores muitas vezes incontrolveis.
O gerenciamento de riscos do projeto inclui os processos que tratam da rea-
lizao de identificao, anlise, 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. Tambm
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 tm 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 anlise qualitativa de riscos
4. Realizar a anlise quantitativa de riscos
5. Planejar as respostas a riscos
6. Monitorar e controlar os riscos.

Vamos a cada um deles!

captulo 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 sero 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 nvel estratgico que o projeto tem para a organiza-
o, pois somente dessa maneira, tempo e recursos adequados sero desviados
de forma coerente para as aes 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 caractersticas dos riscos que podem afetar o
projeto. (PMBOK, 2008). Este processo responsvel por gerar uma listagem
contendo todos os riscos identificados, possveis respostas para os riscos e cau-
sas / razes dos riscos.

4.2.3 Realizar a anlise qualitativa de riscos

Este processo faz parte do grupo de processos de execuo.

Este processo inclui mtodos de priorizao dos riscos identificados (por
meio de anlise de probabilidade e impacto) para ao adicional, como anlise
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 serviro
de entrada para o processo de planejamento de respostas aos riscos.
O processo de anlise quantitativa e o processo de resposta a riscos so pro-
cessos mais morosos e caros, e por isso o processo de realizar a anlise quali-
tativa de riscos funciona como um filtro afim de escolher os processos que so
realmente problemticos para o projeto.

122 captulo 4
4.2.4 Realizar a anlise 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 numrica a esses riscos. (PMBOK, 2004 e 2008).
Este processo deve ser aplicado apenas para os riscos que foram priorizados
pelo processo de anlise qualitativa dos riscos e responsvel 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 opes e determinar aes para aumentar as
oportunidades e reduzir as ameaas aos objetivos do projeto e segue os proces-
sos de anlise qualitativa e quantitativa dos riscos do projeto. (PMBOK, 2008).
Este processo busca solues para os riscos identificados e designa pes-
soas que sero responsveis 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 responsvel por colocar em prtica os planos de resposta aos
riscos e monitorar os resduos dos riscos que j acontecem, acompanhar os ris-
cos que ainda no 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 Aquisies

O gerenciamento das aquisies tem como objetivo dar garantia ao projeto de
que todo elemento externo participante do projeto ir garantir o fornecimento
de seu produto, ou servio, para o projeto.

captulo 4 123
 A relao 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 no o nico elemento a ser analisado na negociao. O tipo de contrato
tambm 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 aquisies do projeto inclui os processos para comprar
ou adquirir os produtos, servios ou resultados necessrios para o projeto, mas
de fora da equipe do projeto, sendo que a organizao executora do projeto
pode ser o comprador ou fornecedor do produto. (PMBOK, 2008).
Como dito acima, o gerenciamento de aquisies o responsvel por geren-
ciar os contratos e alteraes de contrato que a organizao executora tem com
fornecedores ou que a organizao executora tem com clientes para os quais
ela fornece o projeto (ou seus produtos) que est sendo executado (no caso da
organizao executora ser contratada externa para a execuo do projeto).
Para realizar a gerncia desses contratos, a rea de conhecimento de geren-
ciamento de aquisies contm 4 processos, sendo 1 de planejamento, 1 de
execuo, 1 de monitoramento e controle e 1 de encerramento, a saber:
1. Planejar aquisies
2. Conduzir as aquisies
3. Administrao as aquisies
4. Encerrar as aquisies

Vamos a cada um deles:

4.3.1 Planejar as Aquisies

Este processo faz parte do grupo de processos de planejamento

Foca as decises 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/servio. (PMBOK, 2008).
Alm disso, este processo busca nas atividades do projeto quelas que po-
deriam ser melhores atendidas por meio de aquisio externa de produtos e/
ou servios.

124 captulo 4
 Concluindo, este processo utilizado para determinar quais apoios exter-
nos sero contratados e de que forma essa contratao ir ocorrer. Dessa for-
ma, esse processo tambm acaba englobando a seleo de fornecedores.

4.3.2 Conduzir as Aquisies

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 execuo da aquisio em questo. (PMBOK, 2008).
De forma bastante resumida, este processo responsvel por negociar as
aquisies com todos os fornecedores e, por meio de um critrio sistematizado,
buscar a seleo de um fornecedor (para cada aquisio) assinando contrato
com o mesmo

4.3.3 Administrar as Aquisies

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 obrigaes contratuais e que seus prprios 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 Aquisies

Este processo faz parte do grupo de processos de encerramento.

Busca realizar a finalizao de cada aquisio feita no projeto. Por isso, aca-
ba dando suporte ao processo Encerrar o projeto, pois envolve a confirmao
de que todo o trabalho e as entregas foram aceitas. (PMBOK, 2008).
Este processo responsvel pela finalizao de todos os contratos e regis-
tros de informaes em bases histricas sobre os contratos e fornecedores.
Este processo tambm trata sobre a resciso de contratos.

captulo 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 organizaes que podem im-
pactar ou serem impactados pelo projeto, analisar as expectativas das partes
interessadas e seu impacto no projeto, alm de desenvolver estratgias de ge-
renciamento apropriadas para o envolvimento eficaz das partes interessadas
nas decises e execuo do projeto (MARTINS, 2013).
O gerenciamento das partes interessadas tambm se concentra na comu-
nicao contnua com as partes interessadas para entender suas necessidades
e expectativas, abordando as questes conforme elas ocorrem, gerenciando os
interesses conflitantes e incentivando o comprometimento das partes interes-
sadas com as decises e atividades do projeto (MARTINS, 2013). Os processos e
principais produtos de Gerenciamento das partes interessadas so:

PROCESSOS PRINCIPAIS PRODUTOS

Identificar as partes interessadas. Estratgias para gerenciamento das

partes interessadas.

Planejar o gerenciamento das partes Plano de gerenciamento das partes

interessadas. interessadas.

Gerenciar o envolvimento das partes Sistema de informaes gerenciais.

interessadas.

Controlar o envolvimento das partes Estratgia e planos para o envolvimen-

interessadas. to das partes interessadas.

126 captulo 4
4.4.1 Identificar as partes Interessadas

As partes interessadas so pessoas e organizaes, tais como clientes, patroci-

nadores, a organizao executora e o pblico, que esto ativamente envolvidas
no projeto ou cujos interesses podem ser positiva ou negativamente afetados
pela execuo ou pelo trmino do projeto(MARTINS, 2013).
Envolver as partes interessadas no incio do projeto aumenta a probabilida-
de de aceitao das entregas do projeto, haja vista que as partes interessadas
so utilizadas para mapear o escopo do projeto e os requisitos do produto.
A maioria dos projetos tem um grande nmero de partes interessadas.
Como o tempo do gerente de projetos limitado e precisa ser usado com a
maior eficincia possvel, essas partes interessadas devem ser classificadas de
acordo com o interesse, a influncia e o envolvimento no projeto. Isso permite
que o gerente de projetos se concentre nos relacionamentos necessrios para
garantir o sucesso do projeto.
Tambm podem exercer influncia sobre o projeto e suas entregas. As par-
tes interessadas podem estar em diversos nveis da organizao e ter diferen-
tes nveis de autoridade, ou ser externas organizao 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-

tratgias apropriadas de gerenciamento para envolver as partes interessadas de
maneira eficaz no decorrer de todo o ciclo de vida do projeto, com base na anlise
das suas necessidades, interesses, e impacto potencial no xito do projeto.
O gerenciamento das partes interessadas significa mais do que melhorar as
comunicaes e requer mais do que gerenciar uma equipe, envolve a criao e
manuteno 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 avana, a comunidade das partes interessadas e
o nvel exigido de envolvimento podem mudar.
O nvel 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
mudana.

captulo 4 127
 Neutro: ciente do projeto e mesmo assim no d apoio ou resiste.
D apoio: ciente do projeto e dos impactos potenciais e d apoio
mudana.
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 comunicao dirigidas s partes interessadas para influenciar suas
expectativas, abordar as preocupaes e solucionar as questes, tais como:
Gerenciar ativamente as expectativas das partes interessadas para au-
mentar a probabilidade de aceitao do projeto, negociando e influenciando
seus desejos para alcanar 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 preocupaes que ainda no se tornaram questes, geralmen-
te relacionadas com a preveno de futuros problemas. Essas preocupaes
precisam ser reveladas e analisadas e os riscos precisam ser avaliados.
Esclarecer e solucionar as questes que foram identificadas. A soluo
pode resultar em uma solicitao de mudana 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 benefcios e os riscos do
projeto (MARTINS, 2013).
Em geral, o gerente de projetos responsvel pelo gerenciamento das par-
tes interessadas.

4.4.4 Controlar o nvel de comprometimento das partes Interessadas

Controlar o nvel de comprometimento das partes interessadas o processo

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

128 captulo 4
benefcio desse processo a manuteno ou aumento da eficincia e eficcia
das atividades de engajamento das partes interessadas medida que o projeto
se desenvolve e o seu ambiente muda (MARTINS, 2013). As informaes usadas
no processo Controlar o nvel 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 sero cumpridos, como os pa-
pis e responsabilidades, a estrutura hierrquica e o gerenciamento do pessoal
sero abordados e estruturados para o projeto.
Um plano de gerenciamento de mudanas que documenta como as mu-
danas sero monitoradas e controladas.
Necessidades e tcnicas para a comunicao entre as partes.

ATIVIDADES
01. Quais as diferenas na aplicao da anlise qualitativa e quantitativa de riscos?

02. Explique qual a importncia do gerenciamento de riscos?

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

04. Cite alguns sujeitos que so considerados stakeholders do processo de gerenciamento

de projetos e explique por que eles so importantes para o sucesso do projeto?

05. Explique os elementos 5W e 2H para a criao do plano de comunicao do projeto.

REFLEXO
Como j foi dito em outros momentos do livro, gerenciar projetos buscando seu sucesso e
eficcia, no possui receita de bolo, que far com que o projeto ocorra e finalize exatamen-
te como foi previsto e conforme foi escrito. Intercorrncias acontecem, e quanto maior for
o grau de complexidade de um projeto, maior a probabilidade de intercorrncias 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

captulo 4 129
no assegurar sucesso garantido, mas com certeza, dar muito mais segurana em buscar
esse resultado no final do processo. E todas as reas so importantes, cada qual com sua
influncia no projeto como um todo!

LEITURA
IMPLANTAO DE PROJETOS DE SISTEMAS NA REA DE SERVIOS:
AVALIAO DA GESTO DE STAKEHOLDERS. Autores: Elisabete Ceclia Janurio Cha-
ves, Rosemeire Oikawa,
Napoleo Verard Galegale, Marlia Macorin de AzevedoArtigo
Resumo: A rea de conhecimento Gesto de Stakeholders em ambientes de implantao
de projetos de sistemas na rea de servios vem ganhando espao entre os gestores de
projeto. Este artigo visa avaliar os benefcios trazidos por essa rea de conhecimento se-
gundo opinies de especialistas em gesto de projetos. Para essa avaliao utilizou-se uma
pesquisa com o mtodo Delphi, alm de considerar referncias bibliogrficas e melhores
frameworks em Gerenciamento de Projetos. Nessa nova rea de conhecimento, os grupos
de processos recomendam boas prticas em procedimentos para a gesto dos interessados
buscando contribuir para o sucesso na implementao de projetos.
Disponvel no endereo: interessadas, recomendo fortemente que abra.
http://repositorio.enap.gov.br/handle/1/1098.

REFERNCIAS BIBLIOGRFICAS
MARTINS, Carlos Eduardo. 2013. Gerncia de Projetos Teoria e Prtica. Disponvel 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.
Pennsylvnia: [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 captulo 4
VIEIRA, Marconi Fbio.. Gerenciamento de projetos de tecnologia da informao. Rio de Janeiro:
Elsevier, 2007.
Pons, R. (2009). Fundamentos em gerenciamento de projetos: mdulo bsico do curso de
formao em gerenciamento de projetos. [Apostila de aula]. Rio de Janeiro: Projectlab.
VIEIRA, M. F. Gerenciamento de Projetos de Tecnologia da Informao. Rio de Janeiro: Elsevier, 2007.

captulo 4 131
132 captulo 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 polticas de
qualidade de modo que o projeto atenda s necessidades que motivaram sua reali-
zao. Porm, 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 importncia 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 captulo, trabalhado de forma isolada, devido seu grau de importncia
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 vises de qualidade;
Identificar o contexto de aplicabilidade das diferentes contribuies dos autores
da qualidade;
Entender a evoluo da qualidade nas organizaes.
Discutir a relao que se estabelece entre qualidade e as especificaes de um projeto.
Apresentar as etapas necessrias para se construir um plano de gerenciamento da quali-
dade aplicada ao desenvolvimento de um projeto
Compreender os passos necessrios para a elaborao de um plano de gerenciamento da
qualidade de um projeto.

COMENTRIO
Qualidade um termo que est incorporado ao nosso dia a dia, sendo empregado na compra,
venda e uso de produtos e servios, 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: ausncia de defeitos, melhor desempenho, capacidade de atender
a uma necessidade especfica, capacidade de personalizao, diversidade de atributos de
um produto/servio, entre outras. Dada a amplitude do termo, conveniente defini-lo ao

134 captulo 5
interlocutor sempre que o mesmo for utilizado para que no haja confuso na compreenso
de seu significado.
Observa-se que a polmica em torno da ideia de qualidade vem de longa data. Os pri-
meiros registros esto relacionados ao Imprio Grego. Os filsofos gregos discutiram a ideia
de qualidade ligada ao conceito de excelncia ou superioridade moral, intelectual e fsica
(MAXIMIANO, 2006).
Posteriormente, j bem mais tarde, no sculo XVIII, vamos encontrar a sociedade funda-
mentada na ideia noo 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 Revoluo Industrial e o advento da Administrao Cientfica, Taylor, trouxe para
as empresas uma srie de inovaes do ponto de vista tcnico: diviso do trabalho, padro-
nizao das atividades executadas na produo do produto, simplificao dos movimentos
requeridos pelo trabalhador para a execuo de uma determinada tarefa, estabelecimento de
um tempo padro para realizao de cada atividade, definio de uma meta de produo para
cada trabalhador, melhoria dos mtodos e das ferramentas de trabalho (MAXIMIANO, 2006).
Seguindo a linha de pensamento de Taylor, Ford investiu na produtividade da linha de
produo, atravs da especializao total do trabalho (CERTO, 2003), na criao do sistema
de produo em massa (RIBEIRO, 2003) e da simplificao das peas utilizadas na mon-
tagem do automvel, tornando-as padronizadas e intercambiveis (LACOMBE; HEILBORN,
2003). Com esses incrementos, muda-se o foco sobre o conceito de qualidade que passa
a ser relacionado ao processo de produo, adquirindo um carter quantitativo, inerente aos
erros e as falhas dos processos produtivos.
Atualmente, a qualidade pode ser definida como um critrio estratgico de diferenciao
competitiva, no qual a organizao tem como objetivo oferecer ao mercado produtos/servi-
os melhores do que os concorrentes (SLACK, 1997).

captulo 5 135
5.1 Vises da Qualidade
Desde a Revoluo Industrial, vrios autores tentaram definir qualidade.
A concluso que se chegou que o conceito de qualidade subjetivo, ou
seja, no pode ser expresso, numa frase nica, dada a sua complexidade e seu
carter multidimensional. Assim, alguns autores se ocuparam em sintetizar as
diversas maneiras pelas quais a qualidade pode ser vista.
Talvez essa diversidade de definies sobre o assunto, seja consequncia
da prpria evoluo da gesto da qualidade ao longo deste sculo (TOLEDO;
CARPINETTI, 2000). O importante lembrar que elas se complementam entre si!
Garvin (1992) destaca cinco dimenses para definir qualidade:
Transcendental conceitua qualidade como excelncia nata, constituin-
do-se numa propriedade absoluta e universalmente reconhecvel;
Baseada no produto define qualidade como uma varivel precisa, men-
survel e diretamente relacionada aos atributos do produto, podendo ser ava-
liada objetivamente. Nessa abordagem, um maior nvel de qualidade exige
maior custo, portanto produtos de maior qualidade esto associados a produ-
tos com maior preo;
Baseada no usurio associa qualidade a preferncias pessoais. Portanto,
quanto maior a satisfao do cliente maior o nvel de qualidade;
Baseada na produo tem como foco a engenharia, desta forma, qualida-
de significa conformidade com s especificaes;
Baseada no valor conceitua qualidade como o equilbrio entre custo e
preo, ou seja, um produto de qualidade deve apresentar o desempenho espe-
rado a um custo e preo aceitvel.

5.2 Conceitos de Qualidade segundo

Deming

Deming foi um dos principais precursores do conceito e do desmembramento

da qualidade na histria da gesto de negcios. Suas contribuies j ensina-
das e aplicadas at hoje pelo seu carter inovador e moderno.
Willian Edwards Deming nasceu em 1900, em Sioux City, Iowa, Estados
Unidos. Em 1921 licenciou-se em Fsica, na Universidade do Wyoming e, em

136 captulo 5
1928, doutorou-se em Matemtica pela Yale University. Em 1950, foi convidado
pela JUSE (Japan Union of Scientists and Engineers) para dirigir aes de forma-
o em estatstica e controle de qualidade no Japo (SPINER, 2008). O impacto
das suas ideias junto ao empresariado japons foi to grande, que Deming
considerado um dos responsveis pela retomada do desenvolvimento do pas
ps Segunda Guerra mundial (CARAVANTES; PANNO; KLOECKNER, 2005).
A dcada de 1970 foi marcada pela expanso da economia japonesa e sua
penetrao nos mercados ocidentais, especialmente atravs das indstrias ele-
trnica e automobilstica. Esse crescimento despertou o interesse por parte dos
ocidentais em entender as razes do milagre japons. A reao foi de perple-
xidade quando se descobriu que muitos japoneses atribuam a um americano,
desconhecido em seu prprio pas Deming grande parte das razes 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 posio 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 lanou o
livro Out of Crisis (Saia da Crise), a obra que o consagrou como o grande mes-
tre da qualidade, definindo os 14 princpios para o desenvolvimento de um
programa de gesto da qualidade, que esto 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 administrao da qualidade baseada nos
seguintes fatores crticos competitividade de uma empresa (TOLEDO 2000):
Falta de envolvimento dos setores da administrao com os problemas
da produo;
A qualidade era encarada como responsabilidade exclusiva da produo;
O treinamento do pessoal era completamente inadequado para tratar
problemas relacionados com a qualidade;
Utilizao da inspeo como forma prioritria de garantia da qualidade.
Com base nestes aspectos crticos, Deming estabeleceu um conjunto de 14
princpios que serviram de base para o estabelecimento de um programa da
qualidade (MAXIMIANO, 2006):

captulo 5 137
 Princpio 1 melhoria contnua de produtos e servios, com base na ela-
borao de um plano para tornar o negcio mais competitivo;
Princpio 2 adoo de uma filosofia de trabalho moderna, no acei-
tando a convivncia com atrasos, erros, materiais defeituosos e mo de
obra inadequada;
Princpio 3 eliminao da dependncia da inspeo em massa, o foco
deve ser na garantia da qualidade do processo;
Princpio 4 considerao da qualidade ao selecionar fornecedores de
produtos e servios;
Princpio 5 antecipao s consequncias da falta da qualidade, atravs
da identificao de problemas e de suas causas;
Princpio 6 estabelecimento de mtodos atualizados de treinamento
no trabalho;
Princpio 7 introduo de mtodos de superviso e criao de condies
para realizao adequada do trabalho;
Princpio 8 criao de um clima de confiana e respeito mtuo, afastan-
do o medo;
Princpio 9 eliminao das barreiras entre departamentos e conheci-
mento das necessidades dos clientes;
Princpio 10 eliminao das metas numricas, cartazes e rtulos que
apenas pedem maiores nveis de produtividade para os trabalhadores, sem in-
dicar mtodos ou ideias para atingi-los.

O estabelecimento das metas deve ter clara indicao de como elas podem
ser atingidas;
Princpio 11 padres de trabalho inconsistentes no devem ser impos-
tos. Padres numricos devem ser utilizados como instrumentos para que to-
dos tenham conscincia de sua situao e do resultado de seus esforos;
Princpio 12 estabelecimento de um programa de educao e treina-
mento para todos, a fim de afastar o medo e as barreiras que impedem que as
pessoas se sintam responsveis pelo seu trabalho;
Princpio 13 manter a equipe atualizada em relao s mudanas de mo-
delo, estilo, materiais, mtodos e novas mquinas;
Princpio 14 organizar a empresa de tal forma que os princpios opera-
cionais anteriormente apresentados passem a orientar as decises no dia a dia.

138 captulo 5
 Outra contribuio 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 eliminao dos fatores que afetam negativamente as caractersticas de
qualidade desejadas e da identificao das causas comuns e especiais na varia-
o destes processos (MOTTA; VASCONCELOS, 2002).
Uma causa comum pode ser conceituada como uma variao natural de um
processo, que, individualmente, contribu pouco para a variao total do pro-
cesso (MARTINS, 2002).
Por ser inerente ao processo, a remoo das causas comuns requer mudan-
as na concepo e/ou na operao 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, porm a remoo delas depende de uma
ao da gerncia sobre o sistema. Por exemplo, se uma mquina est desgasta-
da e apresenta inmeras folgas, somente uma deciso da alta gerncia 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 remoo delas pode ser feita no prprio local de trabalho
por operrios treinados ou por equipes de manuteno. Por exemplo, a troca
de uma ferramenta desgastada pode ser detectada pelo prprio operrio e ele
mesmo poder trocar a ferramenta gasta (MARTINS, 2002).
Finalizando as contribuies 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 gesto estratgica, utilizada para direcionar
e priorizar os esforos de melhoria do desempenho em cada nvel hierrquico,
de forma que a empresa alcance seus objetivos estratgicos de longo e mdio
prazo (LEE; DALE, 1998).
O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995):
Plan (planejar) identificar os problemas-chave a partir de critrios 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 padro
determinado. Modificar, documentar e utilizar o processo adequadamente.

captulo 5 139
5.3 Eras da Qualidade
Garvin (1992) identificou quatro estgios da gesto da qualidade:
Controle do produto ou inspeo,
Controle do processo ou controle estatstico;
Garantia da qualidade;
Gesto estratgica da qualidade.

Vamos aprender sobre cada um desses estgios?

Controle do produto ou inspeo

O controle do produto formalizou-se com a produo em massa e a necessi-
dade de peas intercambiveis, sendo executado atravs da criao de um siste-
ma de medidas, gabaritos e acessrios, cujo foco principal era a verificao de
erros (MAXIMIANO, 2006).
A conformidade em relao ao padro e a uniformidade dos produtos eram
as preocupaes primordiais, e no a resoluo de problemas. Alm disso, nes-
se perodo, a quantidade produzida de produtos era mais importante do que a
qualidade, reforando a mentalidade de praticar o controle para encontrar os
defeitos ao invs 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 tambm comentar, que a nfase na inspeo, mesmo que fosse mais
barata no era capaz de atuar na causa verdadeira dos problemas!

Controle estatstico ou do processo

O controle do processo deu qualidade um carter cientfico atravs da
utilizao de tcnicas estatsticas para verificar a uniformidade dos produtos
(SILVA, 2002).
A preocupao passa a ser o nvel de variabilidade do processo e a inspeo
passa a ocorrer por amostragem (MOTTA; VASCONCELOS, 2002).
Com o crescimento das empresas e da expanso da produo em massa,
tornou-se impraticvel inspecionar a totalidade dos produtos, surgindo, assim
o controle estatstico da qualidade (MAXIMIANO, 2006)

140 captulo 5
 Em lugar de se inspecionar todos os produtos, seleciona-se uma amostra de
produtos para inspeo. O resultado da anlise dessa amostra estendido ao
lote (GARVIN, 1992).
Apenas como curiosidade, o pioneiro da aplicao da estatstica ao controle
da qualidade foi Walter A. Shewhart, dos Laboratrios Bell, que em 1924 prepa-
rou o primeiro rascunho do que viria a ser conhecido como carta ou grfico de
controle. (MAXIMIANO, 2006).
Os grficos de controle indicam o desempenho do processo, em termos de
sua variao, mediante o controle estatstico de uma varivel ou atributo rela-
cionado a uma caracterstica da qualidade do produto, subconjunto ou pea
(SILVA, 2002).
importante observar que essa ferramenta funciona como um termme-
tro, ou seja, apenas indica o estado do processo. No resolve o problema.
preciso diagnstico e ao sistemtica sobre o processo para que o proble-
ma seja efetivamente resolvido. Por isto, ser imprescindvel o conhecimento
do processo que est sendo controlado (MARTINS, 2002).
O Controle Estatstico de Processo (CEP) mede justamente o nvel de varia-
o desses duas componentes. A ideia eliminar as causas especiais e deixar
em um nvel tolervel as causas comuns, de forma que esta variao no in-
fluencie de forma negativa a qualidade do produto ou servio, aumentando a
sensao de risco do consumidor (MARTINS, 2002).
Quando somente causas comuns agem em um processo, ele apresenta-
r um comportamento previsvel, sendo possvel prever seu comportamento.
Isto implica que os parmetros estimados para o processo so confiveis uma
vez que no existem causas especiais perturbando a variao natural do pro-
cesso. Neste caso, possvel dizer que o processo est sob controle estatstico
(MONTGOMERY, 1991).
Os principais benefcios da utilizao do CEP so (MONTGOMERY, 1991):
Controle da variao dos processos;
Reduo do refugo e retrabalho com consequente diminuio dos custos;
Melhoria da qualidade de conformao;
Autocontrole por parte dos operadores dos processos (quem faz a
qualidade);
Aumento da produtividade e motivao dos operadores dos processos;
Reduo para o mnimo ou eliminao das necessidades de inspeo;

captulo 5 141
 Possibilidade de sistematizao das informaes geradas nos grficos de
controle para futuros estudos de melhoria dos processos.

Vale observar que o CEP no a soluo de todos os problemas de qualidade

e produtividade de uma empresa, mas com certeza parte de uma estratgia
coordenada para a melhoria contnua do desempenho (MARTINS, 2002).
O importante exercer o controle de forma a avaliar os desvios com o pen-
samento probabilstico e no determinstico, ou seja, conhecendo a variao
do processo, agir somente quando houver indcios de mudana brusca ou de
tendncia de mudana (WHEELER, 2001).
Aps verificar se um processo est sob controle estatstico, ou no, pos-
svel analisar a capabilidade do processo, que demonstra, por meio de ndices
numricos, quanto um processo capaz de produzir um produto atendendo a
dada especificao (MARTINS, 2002).
De posse do ndice de capabilidade de um processo possvel avaliar se
ele ir satisfazer ou no as especificaes de uma caracterstica da qualidade
(WHEELER, 2001).
A anlise de capabilidade feita comparando-se a voz do cliente, expressa
pelas especificaes do produto, e a voz do processo, expressa pelas estimati-
vas do parmetro do processo (JURAN, GRYNA, 1991).
Esta parte fundamental do processo de melhoria da qualidade, uma vez que
ela pode direcionar os esforos de melhoria no seguinte sentido (MARTINS, 2002):
Predizer quo bem um processo pode atender s exigncias do cliente;
Auxiliar ou mesmo guiar engenheiros a escolherem um processo
de produo;
Auxiliar no estabelecimento da frequncia de amostragem do processo;
Especificar as necessidades de desempenho de um equipamento;
Auxiliar na seleo de fornecedores;
Auxiliar no projeto de tolerncias;
Guiar o processo de reduo da variao dos processos.

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

exigncias da empresa, ento, os grficos de controle podero ser utilizados
como uma ferramenta poderosa para controlar a qualidade dos processos
(WHEELER, 2001).

142 captulo 5
Garantia da Qualidade

Na era da garantia da qualidade, o foco deixa de ser a fbrica e passa para o ge-
renciamento de todo o processo, da matria-prima ao consumidor final, desta-
cando-se a preveno de problemas (GARVIN, 1992). Com essa nova dimenso, a
qualidade deixa de ser atributo apenas do produto ou servio. Deixa de ser tam-
bm responsabilidade exclusiva do departamento da qualidade. A qualidade
problema de todos e envolve todos os aspectos da operao da empresa. A quali-
dade exige viso sistmica, para integrar as aes das pessoas, as mquinas, in-
formaes e todos os outros recursos envolvidos na administrao da qualidade.
Esta ideia implica a existncia de um sistema da qualidade (TOLEDO, 2000).
A qualidade passa a ser vista de forma sistmica e as empresas passam a exi-
gir que os fornecedores assegurem a qualidade dos insumos (JURAN; GRYNA,
1991). Para colocar essa ideia em prtica, as empresas compradoras passaram a
fazer a auditoria do sistema da qualidade de seus fornecedores, em vez de fazer
a inspeo de seus produtos no momento da entrega (MAXIMIANO, 2006).
Os mtodos de controle e melhoria da qualidade no ficam mais restritos
produo, pelo contrrio, so estendidos a todas s reas organizacionais
(SHIBA et al, 1997).
Para isso so utilizados os seguintes conhecimentos (GARVIN, 1992):
Custos da Qualidade preocupao em identificar os custos evitveis e os
custos inevitveis, eliminando os primeiros e reduzindo os segundos. Foco nos
custos de preveno, em detrimento dos custos de inspeo.
Controle Total da Qualidade (CTQ) o controle da qualidade vai desde o
projeto do produto/servio at entrega ao cliente, envolvendo todas as reas
funcionais, expandindo-se muitas vezes at os fornecedores. A principal preo-
cupao equilibrar custo e qualidade.
Engenharia da Confiabilidade preocupao em garantir o desempe-
nho do produto ao longo do tempo, de forma que este desempenhe sua funo
sem falhas.
Zero Defeito filosofia que tem como foco a motivao e a conscientiza-
o sobre qualidade, dando menos nfase a tcnicas especficas de soluo de
problemas. O lema fazer o trabalho certo da primeira vez.

captulo 5 143
Gesto Estratgica da Qualidade

Finalmente, a qualidade elevada ao nvel estratgico, transformando-se na

base para enfrentar a concorrncia (GARVIN, 1992). Dentro deste contexto, a
qualidade adquire status de sistema de gesto, ligando-se aos objetivos estra-
tgicos e tendo como foco a lucratividade da organizao, atravs da melhoria
contnua (SHIBA et al, 1997).
Para expressar essa nova condio surge o termo Total Quality Management
(TQM), Gesto pela Qualidade Total. Desde, ento, a Gesto pela Qualidade
Total, tornou-se uma febre, sendo adotada por muitas empresas, o que pri-
meira vista bastante positivo. No entanto, infelizmente muitas organizaes
no foram bem sucedidas nessa empreitada, pois muitos consultores passa-
ram a vender a ideia de que a TQM seria a panacia para todos os males das
organizaes, a implantao do sistema seria fcil e os resultados seriam ob-
tidos rapidamente. A atitude inconsequente desses profissionais levou muitos
empresrios a criarem um movimento de resistncia em relao adoo dos
conceitos e mtodos 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-
respondncia entre o seu Escopo, Custo, Prazo e o nvel de confiana nos seus
produtos, ou seja, na sua qualidade. A qualidade, portanto, faz parte do trio
de restries 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 mnimo em gerenciamento da qualida-
de, contudo o nvel de confiana no que ele produziu pode ter sido afetado,
significativamente.
O processo de Planejamento da Qualidade visa ao cumprimento de padres
de qualidade relevantes para o projeto em questo, 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 captulo 5
atividades. Assim, este processo responsvel por identificar e definir como
fazer para obter a satisfao daquilo que o projeto considera como qualidade.
Perceba que todo o contedo discutido neste captulo 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 caractersticas de

uma entidade que a torna capaz de satisfazer necessidades declaradas ou im-
plcitas. Em outras palavras, para se ter qualidade, o produto ou servio dever
atender aos seguintes critrios:
Adequao ao uso (o produto ou servio pode ser usado?);
Adequao ao propsito (o produto ou servio atende aos objeti-
vos propostos?);
Satisfao do cliente (o produto ou servio atende as expectativas
do cliente?);
Conformidade com as especificaes (o produto ou servio est de acordo
com os requisitos estabelecidos?).

5.4.2 Princpios Bsicos

Os princpios definidos para o gerenciamento da qualidade do projeto so ba-

sicamente os seguintes:
Satisfao do cliente entender, gerenciar e influenciar necessidades de
forma com que as expectativas do cliente sejam satisfeitas ou excedidas. Isto
exige a combinao de conformidade com especificao (ou seja, o projeto deve
produzir o que foi dito que produziria) e convenincia para o uso (o produto ou
servio produzido deve satisfazer s necessidades reais).
Preveno ao invs de inspeo o custo destinado a evitar erros sempre
muito menor que o custo para corrigi-los.
Responsabilidade do gerente o sucesso exige a participao de todos os
membros da equipe, mas permanece a responsabilidade do gerente em forne-
cer os recursos necessrios para o xito.

captulo 5 145
5.4.3 Processo de Gerenciamento da Qualidade em Projetos
Segundo PMBOK

O gerenciamento da qualidade segundo PMI, fornece os mtodos 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 funes do gerente, durante a fase de Execuo das atividades
do projeto.
Os objetivos do gerenciamento da qualidade, neste caso, so:
Aumentar o grau de confiabilidade nos produtos gerados pelo projeto;
Reduzir o risco de falhas; e
Aproveitar as oportunidades de melhoria contnua.

O Gerenciamento da Qualidade deve incorporar tcnicas e ferramentas de

controle de forma a garantir com que os produtos gerados apresentem as carac-
tersticas para as quais foram concebidos.
Esta parte do gerenciamento de projetos envolve tambm os processos para
gerenciar mudanas, problemas e incidentes emergentes.
O Gerenciamento da qualidade realizado a partir de trs estgios:
Planejamento da qualidade;
Controle da Qualidade; e
Aes corretivas

5.4.4 Planejamento da Qualidade

O objetivo desta atividade identificar quais padres de qualidade so 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 preveno, alm de anlise detalhada de risco para problemas identificados
pelo controle da qualidade.
A elaborao do plano de gerenciamento da qualidade responsabilidade
do gerente do projeto. Os principais passos na elaborao do plano so:
Definio das caractersticas e atributos dos produtos gerados pelo projeto;

146 captulo 5
 Definio das normas, padres e procedimentos que sero usados para
comparar as caractersticas esperadas dos produtos com as caractersticas efe-
tivamente alcanadas durante a execuo projeto;
Seleo de pontos de controle das caractersticas e elaborao das
checklists bem como dos critrios pelos quais os produtos gerados sero acei-
tos ou rejeitados;
Comunicao aos envolvidos no projeto acerca dos mecanismos que se-
ro adotados para assegurar a qualidade. importante que os interessados se-
jam informados com relao forma como a qualidade ser alcanada.

As habilidades e a experincia das pessoas que iro elaborar o plano da qua-

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

5.5 Plano de Gerenciamento da Qualidade

O plano da qualidade estabelece as polticas, responsabilidades e procedimen-
tos que sero usados para assegurar um adequado nvel de qualidade aos pro-
dutos ou servios que devem ser seguidos por todos os participantes no pro-
jeto. Este documento resume o sistema de decises e instrues com relao
garantia e ao controle da qualidade. A elaborao 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 necessrios para implementar a gerncia da qualidade.
Alm da Garantia de Qualidade e do Controle da Qualidade, o plano de
Gerenciamento da Qualidade aborda tambm os critrios de aceitao dos pro-
dutos gerados pelo projeto.

captulo 5 147
 A equipe do projeto e os principais stakeholders estabelecem, previamente,
os critrios para definir o aceite de cada produto ou servio a ser entregue.
No momento da entrega, os produtos ou servios so avaliados com relao
a estes critrios antes que sejam formalmente aprovados.
comum acordar que haja um documento para cada entrega principal, o
qual necessite de aprovao e de um documento que defina os critrios da acei-
tao para o projeto como um todo.
Os critrios de aceite variam de acordo com o que est sendo produzido.
Ao criar um formulrio de aceite, a equipe deve prever uma coluna para cada
critrio do aceite, uma coluna para expectativas do cliente, e uma outra para os
resultados reais. Se a entrega atingir os critrios 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 (usurio) com relao qualidade do pro-
duto principal e dos produtos intermedirios do projeto, ao preparar ou revisar
o plano da qualidade.

5.6 O que usamos para elaborar o plano

Poltica da qualidade:
Uma declarao que descreve se a abordagem que a equipe do projeto ir
adotar para garantir com que os produtos gerados pelo projeto esto em con-
formidade com as especificaes. A equipe poder adotar a poltica da qualida-
de da organizao que conduz o projeto, ou formular uma poltica prpria, caso
no exista a poltica da empresa.

Especificaes expectativas do cliente:

A qualidade baseada na percepo do cliente sobre os produtos gerados e
como eles atendem s suas expectativas. A adequao dos produtos do projeto
aos objetivos para os quais foram criados fornecem o seu nvel de qualidade. A
equipe do projeto dever identificar e documentar (se necessrio negociar) as
expectativas (caractersticas, atributos) e assegurar com que a equipe e o cliente
tenham entendimento comum sobre eles.

148 captulo 5
 Normas, padres e procedimentos:
As normas e os procedimentos relevantes para o projeto devem ser identi-
ficados e documentados. Isto inclui todas as regulamentaes especficas da
natureza do projeto em trabalho. Mecanismos devem ser colocados em prti-
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 so realizadas continuamente durante a
execuo do projeto, e em pontos definidos, para avaliar se o gerenciamento, e
se os produtos ou servios entregues atendem aos critrios de aceite, estabele-
cidos na fase de planejamento, alm de identificar formas para eliminar causas
de resultados insatisfatrios em decorrncia do projeto.
O controle da qualidade , portanto, o processo contnuo de reviso e testes,
realizado em pontos de controle pr-definidos onde o progresso e as caracters-
ticas dos produtos gerados pelo projeto so examinados em detalhe.
O controle da qualidade adequadamente aplicado faz com que a equipe do
projeto seja mais eficaz, uma vez que previne situaes nas quais o trabalho
resulte em produtos que possam vir a ser rejeitados por no atenderem aos cri-
trios estabelecidos.
Neste caso, a equipe deve monitorar (medir) os resultados do projeto, e deter-
minar se eles esto de acordo com os padres de qualidade estabelecidos, alm
de identificar as formas para eliminar as causas de desempenhos insatisfatrios.
Assim, a equipe identifica desvios e sugere aes corretivas para san-los.
Os mtodos utilizados podem ser:
Teste dos produtos para determinar o nvel de conformidade com
as especificaes;
Avaliao da satisfao dos stakeholders com os produtos do projeto;

captulo 5 149
 O patrocinador do projeto deve receber, regularmente, relatrios que resu-
mam o andamento do controle da qualidade do projeto.
Estes relatrios podem incluir dados estatsticos como, por exemplo, o n-
mero de no conformidades encontradas bem como aes corretivas tomadas.

ATIVIDADES
01. Qual a importncia dos 14 princpios da qualidade, criados por Deming, para uma orga-
nizao que deseja desenvolver um programa de qualidade?

02. Para que serve o ciclo PDCA?

03. Caracterize os quatro estgios da gesto da qualidade: controle do produto ou inspeo,

controle do processo ou controle estatstico; garantia da qualidade; e gesto estratgica da
qualidade. Aponte os pontos positivos e as limitaes de cada um deles.

REFLEXO
Chegamos ao final do nosso livro de Gesto da Qualidade em Projetos. Este ltimo ca-
ptulo teve como tema principal, a abordagem do conceito de Qualidade, sua evoluo e
principais caractersticas. A ideia no foi esgotar o assunto, mesmo porque ele bastante
amplo e abrangente (sendo trabalhado na maioria dos cursos de graduao, em todas as
reas de conhecimento, profisso e segmento), mas sim mostrar sua importncia para o
sucesso gerenciamento de projetos nas organizaes. 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 contedo tenha sido compreendido e que ele de fato faa a diferen-
a em seus estudos e na sua formao. Sucesso!

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

150 captulo 5
 Os 14 princpios da qualidade so a base para a transformao da indstria. No basta
resolver problemas, sejam eles grandes ou pequenos. Os 14 pontos aplicam-se a todos os
tipos de organizaes, grandes ou pequenas, de bens ou de servios. Tambm se aplicam
s divises de uma empresa. A adoo e a prtica desses 14 pontos indicam que uma em-
presa tem a inteno 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 manuteno da qualidade dos bens produzidos, controle
da produo (para que ela no seja muito maior do que as vendas previstas para o futuro
imediato), oramentos, empregos, lucros, vendas, servios, relaes pblicas, estimativas e
assim por diante.
muito fcil deixarmo-nos consumir pelos problemas do presente, tornando-nos cada
vez mais eficientes na resoluo deles, porm, negligenciando os problemas do futuro.
Os problemas do futuro requerem, antes de mais nada, firmeza de propsito e dedicao
no sentido de melhorar a qualidade dos produtos e dos servios. Assim, a empresa fortale-
cer sua posio 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 obrigaes:
Inovar
locar recursos para o planejamento de longo prazo;
Oferecer servios e produtos que contribuam para o bem-estar do consumidor;
Buscar novos insumos;
Melhorar os mtodos de produo;
Investir em treinamento de pessoal.

No podemos mais tolerar os nveis normalmente aceitos de erros, defeitos, insumos

inadequados, profissionais que no sabem o que devem fazer e que tm medo de perguntar,
danos causados por manuseio imprprio de mercadorias, mtodos antiquados de treinamen-
to no ambiente de trabalho, superviso inadequada e ineficaz, administradores descompro-
missados com a empresa.
No depender dos mecanismos de inspeo para garantir qualidade. Contar o tempo
todo com mecanismos de inspeo para garantir qualidade equivale a contar com a incidn-
cia de defeitos e admitir que o processo de produo no est altura das especificaes.
A inspeo vem tarde demais, os defeitos j esto l. Alm disso, ineficaz e dispendiosa.
Quando um produto transpe os portes de uma fbrica, j tarde demais para fazer alguma
coisa acerca de sua qualidade. A qualidade no vem da inspeo, mas do aperfeioamento

captulo 5 151
do processo de produo. Inspeo, retrabalho, degradao e sucateamento de produtos no
constituem medidas de correo do processo de produo. O retrabalho custa dinheiro. im-
portante que a inspeo seja feita no momento exato para que o custo total seja minimizado.
preciso tambm abandonar a prtica de escolher fornecedores com base apenas no
preo. No podemos mais abrir mo da qualidade dos produtos e servios exclusividade aos
sabores da competio por preos mais baixos no nos dias de hoje, quando a demanda
por uniformidade e confiabilidade maior do nunca. Preos no significam nada sem uma
medida exata da qualidade daquilo que comprado. Na ausncia de medidas de qualidade
adequadas, as concorrncias so vencidas pelas ofertas de preo menor e o resultado inevi-
tvel disso qualidade inferior e custos altos.
Os departamentos de compra das organizaes 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. Tambm preciso compreender que as especificaes que acompanham os
produtos venda no contam toda a histria a respeito do desempenho desses produtos.
Materiais e componentes podem funcionar muito bem isoladamente, mas apresentar
problemas quando agregados na linha de produo 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-
teno de economia. H vantagens operacionais nessa parceria. Muito embora dois fornecedores
produzam materiais de excelente qualidade, sempre haver diferenas. Todos os profissionais de
produo 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-
riaes entre os lotes de um nico fornecedor so suficientes para causar problemas na produo.
No difcil supor que as variaes entre os lotes de diferentes fornecedores causem
problemas ainda maiores.
Fonte: Adaptado: DEMING, W. E. Saia da crise. So Paulo: Editora Futura, 2003.

REFERNCIAS BIBLIOGRFICAS
ABNT. NBR ISO 9000: 2000.
ATTADIA, L.; MARTINS, R. Medio de desempenho como base para a evoluo da melhoria
contnua. Revista Produo, 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 captulo 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. Administrao: teorias e processo. So Paulo:
Pearson Prentice Hall, 2005.
CARONA, N. Os prmios de excelncia da qualidade brasileiro e europeu. Anais. V SIMPOI. So
Paulo: FGV-EAESP, 2002.
CARVALHO, M. M et. al. Gesto da qualidade: teoria e casos. Rio de Janeiro: Elsevier, 2005.
DEMING, W. E. Saia da crise. So Paulo: Editora Futura, 2003.
FQN. Critrios de Excelncia. Fundao Nacional da Qualidade (FQN). Disponvel em http://www.
fnq.org.br. Acesso em: 01/05/ 2008.
GARVIN, D. A. Gerenciando a qualidade: a viso estratgica e competitiva. Rio de Janeiro:
Qualitymark, 1992.
GRONROOS, C.: Marketing: gerenciamento e servios. 13. ed. Rio de Janeiro: Campus, 1993.
JURAN, J. M; GRYNA, F. M. Controle da qualidade: handbook. So 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. Administrao: princpios e tendncias. So 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 gesto da qualidade na indstria de calados de Franca-SP. V
SIMPOI (Simpsio de Administrao da Produo, Logstica e Operaes Internacionais).
Anais. ISSN 15186539. So Paulo: FGV- EASP, 2002.
MARTINS, R. Controle Estatstico de Processo. Material didtico da Disciplina Estatstica
Industrial e Controle da Qualidade. Curso de Graduao em Engenharia de Produo: UFSCar, 2002.
MARTINS, R. Modelo para avaliao da evoluo da gesto da qualidade em empresas industriais:
proposta e Aplicao em Pequenas e Mdias Empresas Industriais da Cidade de So Carlos.
Dissertao de mestrado apresentada ao Programa de ps Graduao em Engenharia de Produo da
UFSCar. 1999.
MARTINS, R.; TOLEDO, J. Proposta de modelo para elaborao de programas de gesto para a
qualidade total. Revista de Administrao, So Paulo v.33, n.2, pp.52-59, abril/junho 1998.
MAXIMIANO, A. Teoria geral da administrao: da revoluo urbana revoluo digital. 6. ed.
So Paulo: Atlas, 2006.
MERLI, G. The tqm approach to capturing global markets. Ifs, uk, 1993.

captulo 5 153
MORAES, E. uma anlise crtica sobre o impacto dos fundamentos nos critrios de excelncia do PNQ.
Anais. V SIMPOI. So 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 Administrao. So Paulo: Pioneira Thompson
Learning, 2002.
RIBEIRO, A. Teorias da Administrao. So Paulo: Saraiva, 2003.
ROBLES JR, A. Custos da Qualidade: uma estratgia para a competio global. So 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. Captulos 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 revolues na gesto da qualidade. Artes Mdicas. Porto Alegre: 1997.
SILVA, R. Teorias da Administrao. So Paulo: Pioneira Thompson Learning, 2002.
SLACK, N. et. Al. Administrao da Produo. Editora Atlas, 1997.
TOLEDO, J. C. Enfoque dos principais autores para a gesto da
qualidade. Apostila da Disciplina Planejamento e Gesto da Qualidade
do Departamento de Engenharia de Produo da Universidade Federal de So Carlos. 2000.
TOLEDO, J. C; CARPINETTI, L. C. Gesto da Qualidade. Captulo13. Fbrica do Futuro, NUMA,
Editora Banas. 2000.

GABARITO
Captulo1

01. Sim, possvel e recomendado. Uma vez que um processo sistematizado seja seguido
e ganhe maturidade, resultados de sucessos conseguidos em um determinado projeto po-
dero ser reproduzidos em outros projetos que sigam o mesmo processo de gesto. Lgico
que o ideal termos pessoas sensacionais trabalhando em processos sistematizados, "repe-
tveis" e maduros. Contudo, apenas pessoas sensacionais no garantem que um sucesso de
agora possa ser repetido em outros projetos, mesmo com as mesmas pessoas
02. PMI uma instituio sem fins lucrativos cujas siglas representam Project Management
Institute que tem por objetivo estabelecer o estado da arte de gesto de projetos e tambm
a profissionalizao da gesto do projeto no mundo.

154 captulo 5
03.
Certificao
O PMI oferece seis certificaes que atestam conhecimento e competncia, dentre as quais,
a de Profissional em Gerenciamento de Projetos (PMP), que conta com mais de 370.000
profissionais certificados em todo mundo. Os salrios e oportunidades de carreiras dos pro-
fissionais certificados demonstram que os empregadores reconhecem o valor agregado por
aqueles que possuem essas certificaes.
Padres Globais
Os 12 padres para gerenciamento projetos, programa e de portfolio do PMI so os padres
com mais alto reconhecimento na profisso e que, cada vez mais, vm se tornando o mo-
delo para o gerenciamento de projetos em empresas e governos.
Esses padres so desenvolvidos pelos milhares de voluntrios qualificados e atualizados do
PMI, com experincia em todos os tipos de projetos, e estabelecem uma linguagem comum
para o gerenciamento de projetos em todo o mundo.
Treinamento e Educao
O PMI oferece uma ampla gama de oportunidades de desenvolvimento profissional, desde
nossos SeminarsWorld e cursos de ensino a distncia (e-learning) para congressos mun-
diais e outros eventos do PMI.
Voc tambm pode se dirigir a um dos mais de 1400 Provedores Registrados de Educao
(REPs) para formao e desenvolvimento continuado em gerenciamento de projetos. Aque-
les que estudam em instituies de ensino superior podem contar com os mais de 60 pro-
gramas de graduao e ps-graduao j reconhecidos pelo Centro de Acreditao Global
do PMI para Programas de Educao em Gerenciamento de Projetos.
Pesquisa
O Programa de Pesquisa do PMI, o mais extenso na rea, promove a cincia, a prtica e a
profisso de gerenciamento de projetos. O Programa promove o conhecimento em gerencia-
mento por meio de projetos de pesquisa, simpsios e pesquisas, divulgando essas informa-
es atravs de publicaes, conferncias de pesquisa e sesses de trabalho.
04.
( P ) Aes para o desfile de carnaval de um determinado ano.
( TO ) Construo de carros em srie em uma linha de b) montagem.
( P ) Aes para a criao de um novo modelo de carro de uma determinada montadora.
( P ) Desenvolvimento de um novo d) software de ERP para uma determinada empresa.
( TO ) Aes do setor de RH para a emisso de pagamentos dos funcionrios de uma de-
terminada empresa.

captulo 5 155
( P ) Aes de uma empresa para determinar o processo de emisso de pagamentos dos
funcionrios de uma determinada empresa.
( TO ) Tarefas associadas a um funcionrio de uma lanchonete para a confeco de lanches
padres desta lanchonete.

Captulo2

01.
Gerenciamento/Gesto de integrao do projeto: A Gerncia da integrao do proje-
to o ncleo 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 contnuo que o gerente executa para garantir que o projeto prossiga
do incio ao fim.
Gerenciamento/Gesto 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/Gesto de tempo do projeto: O objetivo da gerncia do tempo de pro-
jeto descrever os processos requeridos para o trmino do projeto, garantindo que o mesmo
cumpra com os prazos definidos em um cronograma de atividades.
Gerenciamento/Gesto de custos do projeto: A gerncia do custo do projeto agrega
os processos que envolvem planejamento, estimativa, oramento e controle de custos que
sero necessrios para a concluso do projeto a partir de uma previso oramentria.
Gerenciamento/Gesto da qualidade do projeto: Originalmente, tal funo era relativa
e voltada para a inspeo; hoje, as atividades relacionadas com a qualidade ampliaram-se
bastante e so consideradas essenciais para o sucesso estratgico do projeto.
Gerenciamento/Gesto de recursos humanos do projeto: Gerenciamento de recur-
sos humanos do projeto tem como base a identificao e documentao de funes, respon-
sabilidades e relaes hierrquicas do projeto em relao aos recursos humanos envolvidos,
alm da criao do plano de gerenciamento de pessoal. Obteno dos recursos humanos
necessrios para terminar o projeto.
Gerenciamento/Gesto das comunicaes do projeto: Inclui os processos necess-
rios para assegurar que as informaes do projeto sejam geradas, coletadas, distribudas,
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 nveis da organiza-
o) ou externas organizao.

156 captulo 5
 Gerenciamento/Gesto de riscos do projeto: Os Riscos de projeto so um conjunto
de eventos que podem ocorrer sob a forma de ameaas ou de oportunidades que, caso se
concretizem, influenciam o objetivo do projeto, negativamente ou positivamente.
Gerenciamento/Gesto de aquisies do projeto: O Gerenciamento de Aquisies
do Projeto responsvel por cuidar das compras e aquisies de produtos, servios ou re-
sultados necessrios para a realizao do trabalho. A organizao pode ser o comprador ou
fornecedor do produto, servio ou resultado.
Gerenciamento das Partes Interessadas do Projeto: O gerenciamento das partes
envolvidas do projeto concentra-se em um dos elementos mais importantes da gesto de
projetos, e gerencia os interessados, suas expectativas, e compromissos.
02. As fases do ciclo de vida de gerenciamento de projetos se interagem intensamente.
Ento, podemos dizer que os processos que compem essas fases tambm esto se intera-
gindo intensamente. A coordenao da interao desses processos de responsabilidade
da gerncia de integrao, uma vez que nessa rea de conhecimento que se decide como
cada rea ser planejada. Ex.: A gerncia de integrao 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 gerncia de in-
tegrao responsvel pela integrao 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 organizao.
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 to importante do que especificar o que est dentro, por causa dos requisitos de
contexto e requisitos no 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, ento
determinar muito bem esses requisitos o primeiro passo para entregar um produto/servio
de qualidade e ter sucesso no projeto.
04. Na fase de definio de escopo, temos a etapa de preparao de uma declarao de
escopo detalhada para o projeto. Ela envolve a identificao de qual o trabalho a ser realiza-
do e os responsveis, o dimensionamento dos pacotes de trabalho, ou work packages (WP)
e a criao de um dicionrio que explique os aspectos tcnicos da EAP.
05. A EAP a estrutura analtica do projeto. Embora em um primeiro momento o nome em
portugus desta ferramenta possa parecer estranho, quando analisamos o nome em ingls
fica mais fcil entender qual a proposta desta ferramenta.

captulo 5 157
WBS o termo em ingls referente a EAP e significa work breakdown structure, que
quer dizer:
Work: esforo fsico ou mental sustentvel para transpor obstculos e atingir um objetivo;
Breakdown: diviso em partes ou categorias. Decompor em partes menores;
Structure: algo organizado de forma padronizada ou formalizada.
Assim fica mais fcil de entender que a EAP e a decomposio (breakdown) hierrquica
(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 decomposio dos trabalhos em partes menores serve para torn-los
mais gerenciveis.
A EAP uma ferramenta grfica, ento a decomposio hierrquica do trabalho do projeto
acontece por meio de retngulos e interligaes desses retngulos para formar a hierarquia
de trabalho.
06. a tcnica de decomposio do trabalho, que sugere a subdiviso das entregas de
trabalhos em componentes menores e mais facilmente gerenciveis 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 confivel. O nvel mais baixo da EAP. Cada pacote de trabalho deve
buscar atender s seguintes caractersticas:
Pode ser estimado de forma realista e confivel;
No permite uma nova subdiviso lgica;
Pode ser concludo rapidamente;
Sua execuo pode ser atribuda a uma pessoa ou grupo de pessoas (internos ou externos)
Possui um trmino significativo, produzindo uma entrega
07. A definio de escopo envolve a preparao de uma declarao de escopo detalhada
para o projeto, que envolve a identificao de qual o trabalho a ser realizado e os respons-
veis, o dimensionamento dos pacotes de trabalho, ou work packages (WP) e a criao de
um dicionrio que explique os aspectos tcnicos da EAP. Entre os aspectos positivos da
definio de escopo esto:
obriga os stakeholders a concordarem com as fronteiras do projeto;
durante a execuo, permite identificar as mudanas que esto fora do escopo do projeto
e requerem renegociao do contrato original;
ajuda a estabelecer critrios que mensurem o sucesso do projeto,
de forma que todos os envolvidos os conheam e estejam de acordo;
auxilia a compreenso da equipe de projeto sobre as abordagens e mtodos utilizados
no projeto.

158 captulo 5
08. Premissas ou suposies so fatores que, para os propsitos do planejamento, so con-
sideradas verdadeiros, reais, ou certos. As premissas afetam todos os aspectos do planeja-
mento do projeto e so parte da elaborao progressiva do projeto. As equipes de projetos
freqentemente identificam, documentam e validam premissas como parte de seu processo
de planejamento. Por exemplo, se a data na qual uma pessoa chave estar disponvel para
o projeto incerta, a equipe pode assumir uma data de incio especfica. Podem ser organi-
zacionais, ambientais e externas. Podem ser consideradas como as clusulas contratuais
que se no 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 no estiver disponvel 50% do tempo, o prazo, provavelmente,
no ser cumprido.

Captulo3

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

a disponibilidade de iniciar a utilizao dos mesmos e/ou entrarem em operao. Atrasos
podem causar tambm em quebras de clusulas 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. Definio de atividades, sequenciamento de atividades, estimativa das duraes das ati-
vidades, desenvolvimento do cronograma, controle do cronograma.
03. Lista de atividades. A lista de atividades deve incluir todas as atividades que sero reali-
zadas no projeto. Deve ser organizada como um extenso da EAP para assegurar que esta est
completa e que no inclui qualquer atividade que no seja requerida como parte do escopo do
projeto. Assim como na EAP, a lista de atividades deve incluir descries de cada atividade para
garantir que os membros da equipe do projeto entendero 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-
rncia do projeto. Os detalhes de suporte devem sempre incluir a documentao de todas
as premissas e restries identificadas A quantidade de detalhes adicionais varia de acordo
com a rea de aplicao.
Atualizaes na EAP. Ao utilizar a EAP para identificar quais atividades so necessrias,
a equipe do projeto pode identificar a falta de algum subproduto ou pode ainda determinar
que a descrio dos subprodutos precisa ser clareada ou corrigida. Qualquer uma destas
atualizaes deve ser refletida na EAP e na respectiva documentao, como por exemplo a
estimativa dos custos. Estas atualizaes so muitas vezes chamadas de refinamentos (re-

captulo 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 caracterstica abstrata das tarefas e
seu cunho intelectual, em alguns casos quase artsticos (por exemplo o desenvolvimento
de um software cientfico como processamento de imagem ou biotecnologia). Por isso,
comum esse processo de estimativa de tempo das atividades seja realizado por pessoas que
esto mais acostumadas com o contexto e natureza do projeto (e que utilizam a experincia
delas para realizar estimativas mais confiveis) e tambm realizado em carter progressivo,
medida que as informaes necessrias para as estimativas vo ficando cada vez mais cla-
ras. Mas, no s a arte e a experincia ou conhecimento tcito dos colaboradores so alter-
nativas para este processo. H tcnicas sistematizadas como pontos por funo e pontos de
caso de uso que podem ser utilizadas juntamente com bases histricas para a determinao
de estimativas de tamanho de software.
05. Grfico de Gantt
Mtodo do caminho crtico por meio dessa tcnica possvel descobrir em um grfico
de redes qual o caminho de atividades mais longo que ser feito no projeto e aquele que
terminar mais cedo. Com essa anlise possvel gerenciar o tempo de entrega do projeto
aplicando ento tcnicas de paralelismo e compresso s atividades do caminho mais longo,
ou seja, o caminho crtico do projeto!
Aplicao de antecipaes e esperas durante o sequenciamento das tarefas antecipaes
e atrasos podem ocorrer e nesta tcnica eles so ajustados.
Compresso do cronograma tcnicas para a reduo do cronograma sem reduzir o escopo
do projeto: so analisadas as compensaes entre custo e cronograma em busca da reduo
do tempo de execuo de uma dada atividade.
Paralelismo descobrir no grafo de rede de atividades as atividades que esto seriadas e
tentar a execuo das mesmas em paralelo para reduzir o tempo do caminho crtico.
Grfico de Milestones
Baseline

160 captulo 5
06.

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

Atividade Depedncia
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
No complete o arco enquanto no tiver clarificado as dependncias

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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

captulo 5 161
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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
(ateno que A e D comeam na mesma etapa...)

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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 captulo 5
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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 (ateno que J s depende de I ...)

Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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

captulo 5 163
 Passos Seguintes
Pergunte a si mesmo: Quais atividades que dependem das que j esto desenhadas?

Atividade Depedncia
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 esto desenhadas?

Atividade Depedncia
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.

No h dependncia de C e K que estas convergem na Etapa Final do Projeto

07. Anlise de variao. A execuo do processo da anlise de variao durante a monitora-

o do cronograma o elemento chave para o controle do tempo. A comparao das datas
alvos com as realizadas de incio e fim, nos fornece informaes teis para a deteco de
desvios e para a implementao de aes corretivas em caso de atraso. As etapas comuns so:
Verificar qualidade das informaes coletadas;
Determinar variaes entre real x linha de base;
Determinar impacto das variaes nos custos e no cronograma;

164 captulo 5
Analisar tendncias das variaes e documentar quaisquer descobertas sobre fontes de va-
riao e rea de impacto.

Captulo4

01. A anlise quantitativa de riscos mensura nmeros e dados tangveis do projeto, j a an-
lise qualitativa, envolve subjetividade dos sujeitos envolvidos, que tero percepo 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 foras e riscos
do projeto e responder a eles, geralmente associados a tempo, qualidade e custos. Portanto,
a sobrevivncia de qualquer empreendimento, atualmente, est intimamente vinculada ao
conceito de aproveitar uma oportunidade, dentro de um espectro de incertezas. O que torna
a gesto dos riscos se tornar to importante so fatores diversos, como o aumento da com-
petitividade, o avano tecnolgico e as condies econmicas, que fazem com que os riscos
assumam propores muitas vezes incontrolveis.
03. Um efetivo processo de comunicao necessrio para garantir que todas as informa-
es desejadas cheguem s pessoas corretas no tempo certo e de uma maneira economi-
camente vivel.
Sempre que pensamos em gerenciamento de projetos, logo, pensamos em administra-
o de tempo, escopo e qualidade, na verdade, a administrao de todas estas reas requer
do gerente de projeto uma gama de habilidades e tcnicas efetivas, pois muitos elementos
precisam ser coordenados. Manter um time unido e slido, e atender as expectativas dos
stakeholders um dos grandes desafios que um gerente de projeto enfrenta.
Um bom plano de comunicao pode ser chave para que a execuo e o controle do pro-
jeto tenham sucesso. Portanto, responsabilidade desta rea de conhecimento fornecer as
ligaes entre pessoas e informaes adequadas, sendo que entenderemos como pessoas
todos os stakeholders do projeto, como partes interessadas, cliente e patrocinador.
04. Stakedolders de um projeto: acionistas da organizao, diretoria, clientes, colaboradores,
fornecedores de produtos e servios, comunidade em que a organizao esteja inserida etc.

Captulo5

01. Tais princpios so ferramentas norteadoras para um eficaz monitoramento de um pro-

jeto, seu eficaz desenvolvimento e efetividade nas respostas. Com base nos princpios da

captulo 5 165
qualidade, segundo Deming possvel 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 gesto estratgica,
utilizada para direcionar e priorizar os esforos de melhoria do desempenho em cada nvel
hierrquico, de forma que a empresa alcance seus objetivos estratgicos de longo e mdio
prazo (LEE; DALE, 1998).
O ciclo PDCA apresenta quatro etapas (SHIBA et al., 1995):
Plan (planejar) identificar os problemas-chave a partir de critrios analticos 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 padro determinado.
Modificar, documentar e utilizar o processo adequadamente.
03.
Controle do produto ou inspeo
O controle do produto formalizou-se com a produo em massa e a necessidade de peas
intercambiveis, sendo executado atravs da criao de um sistema de medidas, gabaritos e
acessrios, cujo foco principal era a verificao de erros (MAXIMIANO, 2006).
A conformidade em relao ao padro e a uniformidade dos produtos eram as preocupa-
es primordiais, e no a resoluo de problemas. Alm disso, nesse perodo, a quantidade
produzida de produtos era mais importante do que a qualidade, reforando a mentalidade de
praticar o controle para encontrar os defeitos ao invs de evit-los (GARVIN, 1992).
Controle estatstico ou do processo
O controle do processo deu qualidade um carter cientfico atravs da utilizao de tcni-
cas estatsticas para verificar a uniformidade dos produtos
(SILVA, 2002).
A preocupao passa a ser o nvel de variabilidade do processo e a inspeo passa a ocorrer
por amostragem (MOTTA; VASCONCELOS, 2002).
Com o crescimento das empresas e da expanso da produo em massa, tornou-se im-
praticvel inspecionar a totalidade dos produtos, surgindo, assim o controle estatstico da
qualidade (MAXIMIANO, 2006).
Garantia da Qualidade
Na era da garantia da qualidade, o foco deixa de ser a fbrica e passa para o gerenciamento
de todo o processo, da matria-prima ao consumidor final, destacando-se a preveno de
problemas (GARVIN, 1992). Com essa nova dimenso, a qualidade deixa de ser atributo ape-

166 captulo 5
nas do produto ou servio. Deixa de ser tambm responsabilidade exclusiva do departamento
da qualidade. A qualidade problema de todos e envolve todos os aspectos da operao da
empresa. A qualidade exige viso sistmica, para integrar as aes das pessoas, as mqui-
nas, informaes e todos os outros recursos envolvidos na administrao da qualidade. Esta
ideia implica a existncia de um sistema da qualidade (TOLEDO, 2000).
Gesto Estratgica da Qualidade
Nesta fase, a qualidade elevada ao nvel estratgico, transformando-se na base para en-
frentar a concorrncia (GARVIN, 1992). Dentro deste contexto, a qualidade adquire status
de sistema de gesto, ligando-se aos objetivos estratgicos e tendo como foco a lucrativida-
de da organizao, atravs da melhoria contnua (SHIBA et al, 1997).

captulo 5 167
168 captulo 5