Gerencia de Projetos

GRUPO
Educação a Distância
Caderno de Estudos
GERÊNCIA DE PROJETOS
Profª. Simone Cristina Aléssio
UNIASSELVI
2015
NEAD
CENTRO UNIVERSITÁRIO
LEONARDO DA VINCI
Rodovia BR 470, Km 71, nº 1.040, Bairro Benedito
89130-000 - INDAIAL/SC
www.uniasselvi.com.br
Copyright  UNIASSELVI 2015
Elaboração:
Profª. Simone Cristina Aléssio
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci - UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
658.404
A372g Aléssio, Simone Cristina
Gerência de projetos / Simone Cristina Aléssio.
Indaial : UNIASSELVI, 2015.
254 p. : il.
ISBN 978-85-7830-900-8
1. Administração de projetos.
I. Centro Universitário Leonardo Da Vinci.
APRESENTAÇÃO
Prezado(a) acadêmico(a)!
Bem-vindo(a) à disciplina GERÊNCIA DE PROJETOS. Este Caderno de Estudos foi

elaborado com o intuito de contribuir e aprimorar o seu desenvolvimento acerca da prática de
gestão de projetos.
O conteúdo está dividido em três unidades. Na Unidade 1, você vai encontrar uma
breve revisão teórica acerca de conceitos projetos, gestão de projetos e, projetos de software.
A Unidade 2 concentra os estudos nos processos de gestão de projetos, tendo como

alicerce o guia PMBoK. Esta unidade está dividida em quatro tópicos, concentrando os seguintes
conteúdos: Gestão da Integração, Gestão do escopo, Gestão do tempo e Gestão do Custo
do projeto.
A Unidade 3 finaliza a abordagem dividindo-se em seis tópicos, em que são abordados os

conteúdos de: Gestão da Qualidade, Gestão de Recursos Humanos, Gestão das Comunicações,
Gestão dos Riscos, Gestão das Aquisições e Gestão das Partes Interessadas.
Para facilitar seu estudo e desenvolvimento das rotinas, todos os comandos, possuem
exemplos que você poderá facilmente compreender e executar na base de dados.
Aproveitamos esse momento para destacar que os exercícios NÃO SÃO OPCIONAIS.
O objetivo de cada exercício deste caderno é a fixação de determinado conceito através da
prática. É aí que reside a importância da realização de todos. Sugerimos fortemente que, em
caso de dúvida em algum exercício, você entre em contato com seu tutor externo ou com a
tutoria da Uniasselvi e que não passe para o exercício seguinte enquanto o atual não estiver
completamente compreendido.
Bom estudo!
Profª Simone Cristina Aléssio
GERÊNCIA DE PROJETOS iii

UNI
Oi!! Eu sou o UNI, você já me conhece das outras disciplinas.
Estarei com você ao longo deste caderno. Acompanharei os seus
estudos e, sempre que precisar, farei algumas observações.
Desejo a você excelentes estudos!
UNI
GERÊNCIA DE PROJETOS iv
SUMÁRIO
UNIDADE 1: CONCEITOS GERAIS: PROJETOS, GESTÃO DE PROJETOS,

PROJETOS DE SOFTWARE......................................................................... 1
TÓPICO 1: UMA VISÃO GERAL DE PROJETOS.............................................................. 3

1 INTRODUÇÃO.................................................................................................................. 3
2 PROJETO......................................................................................................................... 4
3 SUBPROJETOS, PROGRAMAS E PORTFÓLIO............................................................ 6
4 ESCRITÓRIO DE PROJETOS – PMO............................................................................. 7
RESUMO DO TÓPICO 1.................................................................................................... 14
AUTOATIVIDADE.............................................................................................................. 16
TÓPICO 2: UMA VISÃO GERAL DE GESTÃO DE PROJETOS...................................... 19

1 INTRODUÇÃO................................................................................................................ 19
2 HISTÓRIA DA GERÊNCIA DE PROJETO..................................................................... 21
3 PRINCIPAIS VARIÁVEIS DA GESTÃO DE PROJETOS............................................... 22
4 PADRÕES DE GERÊNCIA DE PROJETOS................................................................... 24
5 ESTRUTURA ORGANIZACIONAL................................................................................ 25
5.1 ORGANIZAÇÃO FUNCIONAL OU HIERÁRQUICA..................................................... 26
5.2 ORGANIZAÇÃO PROJETADA..................................................................................... 26
5.3 ORGANIZAÇÃO MATRICIAL....................................................................................... 27
6 FERRAMENTAS DE PLANEJAMENTO E CONTROLE................................................ 29
7 GERENCIAMENTO DE PROJETOS NA VISÃO DO PMI.............................................. 29
8 PROCESSOS DA GERÊNCIA DE PROJETOS............................................................. 34
9 METODOLOGIA DE PROJETO..................................................................................... 36
10 PLANO DE PROJETO.................................................................................................. 37
11 PARTES INTERESSADAS NO PROJETO – STAKEHOLDERS................................. 38
12 EQUIPE DO PROJETO DE DESENVOLVIMENTO DE SOFTWARE.......................... 40
RESUMO DO TÓPICO 2.................................................................................................... 42
AUTOATIVIDADE.............................................................................................................. 46
TÓPICO 3: PROJETO DE DESENVOLVIMENTO DE SOFTWARE................................. 47

1 INTRODUÇÃO................................................................................................................ 47
2 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE........... 49
3 A FASE DE PROJETO.................................................................................................... 51
4 CONCEITOS BÁSICOS DE PROJETO DE SOFTWARE.............................................. 51
5 PRINCÍPIOS DE PROJETO............................................................................................ 52
6 QUALIDADE DO PROJETO DE SOFTWARE............................................................... 53
7 TECNOLOGIA IMPERFEITA E REQUISITOS TECNOLÓGICOS.................................. 54
LEITURA COMPLEMENTAR............................................................................................. 55
RESUMO DO TÓPICO 3.................................................................................................... 61
AUTOATIVIDADE.............................................................................................................. 62
AVALIAÇÃO....................................................................................................................... 63
GERÊNCIA DE PROJETOS v
UNIDADE 2: PROCESSOS DE GESTÃO DE PROJETOS.............................................. 65
TÓPICO 1: INTEGRAÇÃO................................................................................................ 67
1 INTRODUÇÃO................................................................................................................ 67
2 DESENVOLVIMENTO DO TERMO DE ABERTURA..................................................... 72
3 DESENVOLVIMENTO DO PLANO DE GERENCIAMENTO DE PROJETOS............... 76
4 ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO........................................... 79
5 MONITORAR E CONTROLAR A EXECUÇÃO DO PROJETO...................................... 82
6 REALIZAR O CONTROLE INTEGRADO DE MUDANÇAS........................................... 84
7 ENCERRAR O PROJETO OU FASE DO PROJETO..................................................... 88
LEITURA COMPLEMENTAR............................................................................................. 91
RESUMO DO TÓPICO 1.................................................................................................... 95
AUTOATIVDADE............................................................................................................... 96
TÓPICO 2: ESCOPO......................................................................................................... 97
1 INTRODUÇÃO................................................................................................................ 97
2 COLETAR REQUISITOS.............................................................................................. 101
3 DEFINIR O ESCOPO.................................................................................................... 104
4 CRIAR A EAP............................................................................................................... 106
5 VERIFICAR O ESCOPO............................................................................................... 109
6 CONTROLAR O ESCOPO............................................................................................111
RESUMO DO TÓPICO 2...................................................................................................114
AUTOATIVIDADE.............................................................................................................115
TÓPICO 3: TEMPO...........................................................................................................117
1 INTRODUÇÃO...............................................................................................................117
2 GERENCIAR PLANEJAMENTO DO TEMPO.............................................................. 120
3 DEFINIR ATIVIDADES.................................................................................................. 121
4 SEQUENCIAR ATIVIDADES........................................................................................ 123
5 ESTIMAR RECURSOS DA ATIVIDADE....................................................................... 125
6 ESTIMAR DURAÇÃO DA ATIVIDADE......................................................................... 127
7 DESENVOLVER O CRONOGRAMA............................................................................ 129
8 CONTROLAR CRONOGRAMA.................................................................................... 132
RESUMO DO TÓPICO 3.................................................................................................. 135
AUTOATIVIDADE............................................................................................................ 136
TÓPICO 4: CUSTO.......................................................................................................... 137

1 INTRODUÇÃO.............................................................................................................. 137
2 ESTIMAR CUSTOS...................................................................................................... 140
3 DETERMINAR O ORÇAMENTO.................................................................................. 143
4 CONTROLAR CUSTOS................................................................................................ 145
RESUMO DO TÓPICO 4.................................................................................................. 147
AUTOATIVIDADE............................................................................................................ 148
GERÊNCIA DE PROJETOS vi
AVALIAÇÃO..................................................................................................................... 149
UNIDADE 3: ÁREAS DE CONHECIMENTO PARA GESTÃO DE PROJETOS............. 151
TÓPICO 1: GERENCIAMENTO DA QUALIDADE DO PROJETO.................................. 153

1 INTRODUÇÃO.............................................................................................................. 153
2 PROCESSOS DE GERENCIAMENTO DA QUALIDADE DO PROJETO.................... 154
2.1 PLANEJAR A QUALIDADE........................................................................................ 155
2.1.1 Definição do processo............................................................................................. 157
2.1.2 Entradas do processo............................................................................................. 157
2.1.3 Ferramentas e técnicas........................................................................................... 157
2.1.4 Saídas do processo................................................................................................. 158
2.2 REALIZAR A GARANTIA DA QUALIDADE................................................................ 158
2.2.1 Definição do processo............................................................................................. 159
2.2.2 Entradas do processo............................................................................................. 159
2.2.4 Saídas do processo................................................................................................. 160
2.3 REALIZAR O CONTROLE DA QUALIDADE............................................................. 160
2.3.1 Ciclo de controle: definição do processo................................................................. 162
2.3.2 Ciclo de controle: entradas do processo................................................................. 162
2.3.3 Ciclo de controle: ferramentas e técnicas............................................................... 162
2.3.4 Ciclo de controle: saídas do processo.................................................................... 163
RESUMO DO TÓPICO 1.................................................................................................. 164
AUTOATIVIDADE............................................................................................................ 165
TÓPICO 2: GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO............... 167

1 INTRODUÇÃO.............................................................................................................. 167
2 PROCESSOS DE GERENCIAMENTO DE RECURSOS HUMANOS
DO PROJETO.................................................................................................................. 168
2.1 DESENVOLVER O PLANO DE RECURSOS HUMANOS......................................... 169
2.1.1 Ciclo de planejamento: definição de processo........................................................ 171
2.1.2 Ciclo de planejamento: Entradas do processo........................................................ 171
2.1.3 Ciclo de planejamento: ferramentas e técnicas...................................................... 172
2.1.4 Ciclo de planejamento: saídas do processo............................................................ 172
2.2 MOBILIZAR A EQUIPE DO PROJETO...................................................................... 172
2.2.1 Ciclo de execução: definição do processo.............................................................. 173
2.2.2 Ciclode execução: entradas do processo............................................................... 174
2.2.3 Ciclo de execução: ferramentas e técnicas............................................................. 174
2.2.4 Ciclo de execução: Saídas do processo................................................................. 174
2.3 DESENVOLVER A EQUIPE DO PROJETO............................................................... 175
2.3.2 Ciclo de execução: entradas do processo.............................................................. 178
2.3.3 Ciclo de iniciação: ferramentas e técnicas ............................................................. 178
2.3.4 Ciclo de iniciação: saídas do processo................................................................... 178
GERÊNCIA DE PROJETOS vii

2.4 GERENCIAR A EQUIPE DO PROJETO.................................................................... 178
2.4.4 Ciclo de execução: saída do processo.................................................................... 181
RESUMO DO TÓPICO 2.................................................................................................. 182
AUTOATIVIDADE............................................................................................................ 184
TÓPICO 3: GERENCIAMENTO DAS COMUNICAÇÕES............................................... 185

1 INTRODUÇÃO.............................................................................................................. 185
2 PROCESSOS DE GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO......... 187
2.1 IDENTIFICAR AS PARTES INTERESSADAS........................................................... 188
2.1.1 Ciclo de iniciação: definição do processo............................................................... 189
2.1.2 Ciclo de iniciação: entradas do processo................................................................ 190
2.1.3 Ciclo de iniciação: ferramentas e técnicas.............................................................. 191
2.1.4 Ciclo de iniciação: saídas do processo................................................................... 191
2.2 PLANEJAR AS COMUNICAÇÕES............................................................................ 191
2.2.1 Ciclo de planejamento: definição do processo........................................................ 192
2.2.2 Ciclo de planejamento: entradas do processo........................................................ 192
2.3 CONTROLAR AS INFORMAÇÕES........................................................................... 193
2.3.4 Ciclo de execução: saídas do processo.................................................................. 195
RESUMO DO TÓPICO 3.................................................................................................. 196
AUTOATIVIDADE............................................................................................................ 198
TÓPICO 4: GERENCIAMENTO DE RISCOS.................................................................. 199

1 INTRODUÇÃO.............................................................................................................. 199
2 PROCESSOS DE GERENCIAMENTO DE RISCOS.................................................... 201
2.1 PLANEJAR O GERENCIAMENTO DOS RISCOS..................................................... 201
2.1.1 Ciclo de planejamento: definição de processo........................................................ 202
2.2 IDENTIFICAR OS RISCOS........................................................................................ 203
2.3 REALIZAR A ANÁLISE QUALITATIVA DOS RISCOS................................................ 206
2.3.1 Ciclo de planejamento: definição do processo e entradas do processo................. 208
GERÊNCIA DE PROJETOS viii

2.4 REALIZAR A ANÁLISE QUANTITATIVA DOS RISCOS............................................. 208
2.4.4 Saídas do processo..................................................................................................211
2.5 PLANEJAR AS RESPOSTAS AOS RISCOS..............................................................211
2.6 MONITORAR E CONTROLAR OS RISCOS.............................................................. 213
RESUMO DO TÓPICO 4.................................................................................................. 216
AUTOATIVIDADE............................................................................................................ 218
TÓPICO 5: GERENCIAMENTO DAS AQUISIÇÕES....................................................... 218

1 INTRODUÇÃO.............................................................................................................. 219
2 PROCESSOS DE GERENCIAMENTO DAS AQUISIÇÕES......................................... 221
2.1 PLANEJAR AS AQUISIÇÕES.................................................................................... 221
2.2 REALIZAR AS AQUISIÇÕES..................................................................................... 224
2.3 Ciclo de execução: controlar as Aquisições............................................................... 227
2.4 ENCERRAR AS AQUISIÇÕES.................................................................................. 229
2.4.1 Ciclo: encerramento................................................................................................ 230
2.4.2 Ciclo: definição do processo................................................................................... 231
2.4.3 Ciclo: entradas do processo.................................................................................... 231
2.4.4 Ciclo: ferramentas e técnicas.................................................................................. 231
2.4.5 Ciclo: saídas do processo....................................................................................... 231
GERÊNCIA DE PROJETOS ix
RESUMO DO TÓPICO 5.................................................................................................. 232
AUTOATIVIDADE............................................................................................................ 233
TÓPICO 6: GERENCIAMENTO DAS PARTES INTERESSADAS

NO PROJETO.................................................................................................................. 235
1 INTRODUÇÃO.............................................................................................................. 235
2 PROCESSOS DE GERENCIAMENTO DAS PARTES INTERESSADAS.................... 236
2.1 IDENTIFICAR AS PARTES INTERESSADAS........................................................... 237
2.2 PLANEJAR O GERENCIAMENTO DAS PARTES INTERESSADAS........................ 239
2.3 Gerenciar o engajamento das partes interessadas.................................................... 241
2.4 Controlar o engajamento das partes interessadas..................................................... 243
2.4.1 Ciclo de encerramento: definição do processo....................................................... 245
2.4.2 Ciclo de encerramento: entradas do processo........................................................ 245
2.4.3 Ciclo de encerramento: ferramentas e técnicas...................................................... 245
2.4.4 Ciclo de encerramento: saídas do processo........................................................... 245
RESUMO DO TÓPICO 6.................................................................................................. 246
AUTOATIVIDADE............................................................................................................ 247
AVALIAÇÃO..................................................................................................................... 249
REFERÊNCIAS................................................................................................................ 250
GERÊNCIA DE PROJETOS x
UNIDADE 1
CONCEITOS GERAIS: PROJETOS, GESTÃO

DE PROJETOS, PROJETOS DE SOFTWARE
Objetivos de aprendizagem
Ao final desta unidade, você será capaz de:
 conhecer as principais características de projetos e gerenciamento

de projetos dentro do seu contexto e importância;
 entender a diferença entre projeto, programa e portfólio;
 conhecer os principais stakeholders dos projetos;
 conhecer a estrutura do guia PMBOK com seus processos e áreas
de conhecimento;
 conhecer os tipos de estrutura organizacionais mais comuns na
realidade atual das organizações;
 conhecer a estrutura básica de uma equipe de desenvolvimento
de software;
 conhecer as dificuldades encontradas no gerenciamento de
projetos de software.
PLANO DE ESTUDOS
Esta unidade de ensino contém três tópicos, sendo que no

G
final de cada um, você encontrará atividades que contribuirão para
E
a apropriação dos conteúdos. R
Ê
N
C
I
TÓPICO 1 – UMA VISÃO GERAL DE PROJETOS A
TÓPICO 2 – UMA VISÃO GERAL DE GESTÃO DE D

PROJETOS E
TÓPICO 3 – PROJETO DE DESENVOLVIMENTO P

DE SOFTWARE R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 1
TÓPICO 1
UMA VISÃO GERAL DE PROJETOS
1 INTRODUÇÃO
Podemos pensar na aplicação da palavra “Projeto”, nas mais variadas situações. Por
exemplo: um trabalho acadêmico pode ser estruturado na forma de projeto, a reforma de uma
casa, um curso de especialização, uma viagem, um filho, ou qualquer atividade que tenha um
objetivo, um início e um fim pré-definidos. Neste sentido, as organizações têm fundamentado
a maioria de suas atividades, na estrutura de projetos.
Atualmente, enfrentamos mudanças em praticamente todos os aspectos da nossa vida

(no âmbito político, cultural, acadêmico e social de forma geral). É muito comum a associação
da palavra mudança, ao resultado de projetos, por isso, gerenciar projetos no atual cenário é
um grande desafio para executivos, que devem pensá-los de forma estruturada e organizada.
Para que isso seja possível, é exigido do gestor de projetos conhecimento nos conceitos de
Gestão de Projetos, bem como técnicas e ferramentas para colocar em prática uma gestão
eficaz.
G
O interesse no aprimoramento acadêmico para a Gestão de Projetos e na evolução e E
R
inovação de seus modelos de gestão cresce exponencialmente a cada ano, sendo que esta Ê
qualificação está sendo cada vez mais valorizada no âmbito organizacional, uma vez que a N
C
educação dos profissionais reflete no sucesso da organização (SENGE, 1990). I
A
Por este motivo, torna-se necessário que os gerentes de projetos primeiro conheçam
D
e depois adotem as melhores práticas para que os objetivos sejam alcançados prevendo a E
máxima otimização dos recursos, obedecendo aos prazos estipulados e, principalmente, os
P
custos estimados. R
O
J
Para Prado (2000) um profissional de projetos qualificado traz os seguintes benefícios E
para a organização: T
O
S
4 TÓPICO 1 UNIDADE 1
• redução no custo e prazo de desenvolvimento de novos produtos;

• aumento no tempo de vida dos novos produtos;
• aumento de vendas e receita;
• aumento do número de clientes e de sua satisfação e,
• aumento da chance de sucesso nos projetos, além de sua própria ascensão profissional.
2 PROJETO
Projeto é algo temporário, com sequência de atividades com início, meio e fim. Seu
Resultado final fornece um produto ou serviço único e progressivo, tangível ou intangível restrito
a restrições de tempo e custo (CARVALHO, 2014).
Temporário, significa que por maior que seja o tempo de seu desenvolvimento, ele
terá um fim. Um projeto não dura para sempre. E, terá fim, assim que seus objetivos sejam
alcançados ou quando se chegar à conclusão de que estes objetivos não serão ou não poderão
mais ser atingidos. Ou também porque a necessidade do projeto não existe mais. Embora um
projeto seja temporário, seu resultado tende a ser duradouro ou permanente, podendo ser
classificados também como resultados tangíveis ou intangíveis (TRENTIN, 2011), conforme
exemplos:
• Produção de um produto, item final ou componente.

• Documentos, criação de conhecimento, relatórios de auditorias, análise de mercados
ou processos.
• Desenvolvimento ou aquisição de um sistema (novo ou modificado).
• Construção de infraestrutura, implementação de novos procedimentos ou processos
G de negócios.
E
R
Um projeto é único, pois mesmo que já tenha sido executado em outras circunstâncias
Ê
N ou organizações, ao ser colocado em prática novamente, o cenário envolvido (necessidades,
C
pessoas, tecnologias) já mudou. A realidade do projeto atual já é outra em decorrência das
I
A mudanças ocorridas.
D
E É considerado como progressivo, pois à medida que temos mais conhecimento
sobre ele, vamos elaborando-o progressivamente, melhorando o seu detalhamento e as
P
R particularidades que o definem como único. Mas, podemos dizer que a característica de
O destaque de um projeto é o risco, pois nunca podemos ter a certeza de que o mesmo será
J
E bem-sucedido.
T
O
S
UNIDADE 1 TÓPICO 1 5
Em contraste com os projetos, encontram-se as operações de uma organização. Estas

são esforços de trabalho contínuo, que seguem padrões organizacionais em sua execução,
tem caráter repetitivo e rotineiro, e são acima de tudo, permanentes (TRETIM, 2010).
Principais diferenças entre projetos e operações:

• Projetos têm um começo e fim definidos. Produzem um resultado ou produto único.
• Operações são repetitivas e produzem os mesmos resultados cada vez que o processo
é executado.
Os projetos para serem lucrativos, executados no prazo e entregues com a devida

qualidade, precisam de gerenciamento, cujo objetivo consiste em planejar e controlar atividades
sincronizadas de diversas pessoas.
Segundo o PMI (Project Management Institute, 2013), podemos entender gerenciamento

de projetos como: “a conversão de uma necessidade, especificada por objetivos e critérios de
sucesso, em um resultado alcançado”.
Cada projeto possui um ciclo de vida, que ajuda a definir o início e término de cada
etapa, o que deve ser realizado e por quem deve ser executado (matriz de responsabilidade do
projeto). Serve para dar alicerce ao tripé de sucesso dos projetos: TEMPO/CUSTO/QUALIDADE.
A entrega deve ser feita no prazo estipulado, dentro do orçamento apontado, com nível de
qualidade atendendo às necessidades do cliente comprador (VARGAS, 2009).
Devido à dinamicidade e competitividade do mercado, diversas empresas têm buscado

alternativas tecnológicas para otimizar seus processos, diminuir custos e maximizar lucros,
melhorar a qualidade de seus serviços e produtos, com o objetivo de atingir ou manter-se em
um patamar importante no mercado em que atuam.
FONTE: Disponível em: <http://www.tecsi.fea.usp.br/envio/contecsi/index.php/contecsi/9contecsi/

paper/download/3508/2007>. Acesso em: 30 abr. 2015. G
E
R
Com a grande demanda do mercado por soluções de software, empresas de Ê
desenvolvimento de software necessitam desenvolver diversos projetos simultaneamente, N
C
onde cada um possui seus objetivos específicos. Esses projetos precisam ser gerenciados
I
estrategicamente de forma a se alcançar os objetivos individuais dos projetos e manter-se A
alinhados com as metas da organização (PHILLIPS, 2003).
D
E
Projetos de desenvolvimento de software estão vulneráveis a eventos que podem afetar
P
negativamente o cronograma, custo, escopo do projeto, e a qualidade do produto final. Em um R
ambiente onde há múltiplos projetos, além de impactar nos objetivos de cada projeto, eventos O
J
adversos podem ameaçar o sucesso das metas organizacionais. E
T
FONTE: Disponível em: <http://www.tecsi.fea.usp.br/envio/contecsi/index.php/contecsi/9contecsi/ O
paper/download/3508/2007>. Acesso em: 30 abr. 2015. S
O gerente de projetos é o responsável pelo controle e bom desempenho dos mesmos.

Deve ser aceito pela equipe. Não precisa ter domínio técnico, uma vez que suas habilidades
devem estar mais voltadas para a área de gestão (DINSMORE; CAVALIERI, 2003). Ainda de
acordo com os autores, o gerente de projetos deve ser um facilitador, não tendo falhas na
liderança, nos seus processos comunicacionais, nas formas de negociação adotadas, e na
condução da resolução de problemas.
3 SUBPROJETOS, PROGRAMAS E PORTFÓLIO
Projetos grandes e de alta complexidade podem ser particionados em projetos menores

ou subprojetos, facilitando assim a atividade de gerenciamento. A diferença entre os conceitos
consiste no princípio de que um subprojeto não existe sem um projeto. Podemos adotar como
exemplo a fabricação de um componente específico de um modelo de carro. O carro seria o
projeto e a fabricação do componente, um subprojeto do projeto principal (TRENTIM, 2001).
Ainda de acordo com o autor, “programas“ são grupos de projetos que são relacionados
e gerenciados de forma coordenada. Podem utilizar as mesmas técnicas de gestão, além de
compartilhar recursos. Projetos gerenciados coletivamente podem apresentar mais benefícios
do que se fossem gerenciados de forma individual, e a escolha sob qual forma de gestão adotar
é uma decisão operacional de cada organização.
Portfólio, ainda na visão do autor, é um conjunto de projetos ou programas com objetivos

afins para atingir uma meta organizacional. A importância é alinhar as execuções organizacionais
com o planejamento estratégico, a fim de evitar desperdício de tempo, dinheiro e demais
recursos em projetos que não estejam alinhados com a estratégia organizacional adotada.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 1 – DIFERENÇA ENTRE PROJETOS, PROGRAMAS E PORTFÓLIO
FONTE: Trentin (2011, p. 20)
4 ESCRITÓRIO DE PROJETOS – PMO
É uma estrutura organizacional centralizada que se responsabiliza pelo gerenciamento

de projetos em uma organização ou departamento (CARVALHO, 2011).
Existem diferentes tipos de PMO, com atribuições e responsabilidades distintas para

cada tipo (TRENTIM, 2011). Dentro das principais atividades, podemos citar:
• Suporte material.
• Padronização de procedimentos e processos.
G
• Criação de modelo de documentação e outros templates. E
• Treinamento e capacitação da equipe do projeto. R
Ê
• Gestão centralizada de softwares de gestão de projetos, entre outras atribuições.
N
C
I
Através do escritório de projetos é possível obter uma visão geral e coordenada dos
A
projetos, equipes e recursos, facilitando o feedback da equipe quanto ao desenvolvimento dos
mesmos. D
E
Uma organização deve atingir um determinado nível de maturidade para possibilitar a P

R
implantação de um PMO. O
J
E
T
O
S
FIGURA 2 – MODELO DE MATURIDADE PARA A IMPLANTAÇÃO DO PMO
FONTE: Adaptado de Kerzner (2002, p. 35)
As funções desempenhadas por um Escritório de Projetos dependem das características

das organizações onde estão instalados, tornando essencial um diagnóstico organizacional
antes de sua implantação para definir o grau de maturidade. O grau de maturidade de um
PMO definirá a sua capacidade de agregar valor para partes envolvidas no projeto (TRENTIM,
2011). Segundo o autor, quanto maior a maturidade em Gestão de Projetos, mais consistentes
serão os resultados dos projetos.
Para avaliação é essencial escolher um modelo de maturidade para efetuar o diagnóstico,

que é realizado com base em questionários e ferramentas de apoio. Basicamente, as pessoas
deverão responder ao questionário, sabendo que o foco não é o conhecimento delas, mas sim,
entender qual o nível de gerenciamento de projetos é praticado diariamente na organização
(KEELLING, 2002).
G
E
R Cada modelo de maturidade tem seu próprio estilo de questionário, bem como
Ê ferramentas de apoio específicas. Após diagnóstico apontado pelo modelo adotado, a gerência
N
C deverá traçar planos de ação visando ao aumento da maturidade através do desenvolvimento
I dos pontos de melhorias identificados pelo modelo em questão.
A
D Seguem três exemplos de modelos de maturidade para seu conhecimento:

E
• PMI OPM3 – Organizational Project Management Matutiry Model.
P • Kerzner PMMM – Kerzner’s Project Management Maturity Model.
R • Prado MMGP – Modelo de Maturidade em Gerenciamento de Projetos (Darci Prado).
O
J
E O modelo OPM3 é dividido em três dimensões:
T
O • Conhecimento (knowledge).
S
• Avaliação (assessment) e.
• Melhoria (improvement).
Trata-se de um modelo bastante completo que parte do contexto organizacional de GP

(knowledge), aplicando ferramentas e técnicas para avaliar o grau de maturidade (assessment)
e então prover um plano de melhoria (improvement). Existem cinco níveis de maturidade:
• Inexistente
• Consistente
• Integrado
• Completo
• Otimizado
OPM3 oferece também um direcionamento para a confecção de planos de melhoria

do OPM da organização.
FONTE: Adaptado de: <http://blog.mundopm.com.br/2012/02/29/maturidade-em-gerenciamento-de-

projetos/>. Acesso em: 30 abr. 2015.
FIGURA 3 – VARIÁVEIS DO MODELO DE MATURIDADE
G
FONTE: Disponível em: <https://brasil.pmi.org/>. Acesso em: 10 abr. 2015. E
R
Ê
N
NOT
A!
C
I
A
D
E
P
No site do PMI, há maiores informações sobre OPM3 e um demo da ferramenta. R
Acesse: <opm3online.pmi.org/demo/default.shtml>. O
J
E
T
O
S
O modelo Kerzner apresenta cinco níveis de maturidade, sendo calculados a partir da

resposta aos questionários:
• Nível 1 – Linguagem Comum.
• Nível 2 – Processos Comuns.
• Nível 3 – Metodologia Única.
• Nível 4 – Análise Comparativa.
• Nível 5 – Melhoria Contínua.
FONTE: Disponível em: <http://blog.mundopm.com.br/2012/02/29/maturidade-em-gerenciamento-de-

FIGURA 4 – NÍVEIS DO MODELO DE MATURIDADE PARA A IMPLANTAÇÃO DO PMO
G
E
R FONTE: Kerzner (2002, p. 47)
Ê
N
C Assim como o modelo Kerzner, o modelo Darci Prado apresenta cinco níveis de
I
A maturidade:
• Nível 1 – Iniciante.
D
E • Nível 2 – Conhecido.
• Nível 3 – Padronizado.
P
R • Nível 4 – Gerenciado.
O • Nível 5 – Otimizado.
J
E
T Cada nível de maturidade é avaliado em seis dimensões:
O
S
• Alinhamento com o Negócio.

• Relacionamentos Humanos.
• Estrutura Organizacional.
• Informatização.
• Metodologia.
• Conhecimento em GP.
FONTE: Disponível em: <http://blog.mundopm.com.br/2012/02/29/maturidade-em-gerenciamento-de-

FIGURA 5 – DIMENSÕES DOS NÍVEIS DO MODELO DE MATURIDADE PARA A IMPLANTAÇÃO

DO PMO
FONTE: Disponível em: <www.maturityresearch.com>. Acesso em: 10 abr. 2015.

G
E

R
NOT
A! Ê
N
C
I
A
D
Os questionários do modelo MMGP podem ser encontrados em <www. E
maturityresearch.com>. Maturidade em Gerenciamento de projetos refere-se à
organização, ou seja, ao grau de aplicação e estabilidade em Gestão de Projetos. P
R
O
J
A maturidade do PMO depende dos serviços prestados por ele, qualidade destes serviços E
T
e como eles são percebidos pelos principais stakeholders (TRENTIM, 2011). O
S
FIGURA 6 – CUBO DE MATURIDADE DE PMO
FONTE: Disponível em: <www.maturityresearch.com>. Acesso em: 10 abr. 2015.
As funções que o PMO pode desempenhar dependem principalmente da maturidade

em gerenciamento de projetos da organização e dos interesses e circunstâncias que cercam
a criação e evolução de tal departamento, indo desde simplesmente “monitorar” múltiplos
projetos, até representar os projetos junto à direção executiva (VARGAS, 2009).
FIGURA 7 – ATRIBUIÇÕES E ATIVIDADES DO PMO
G
E
R
Ê
N
C
I
A
D
E
P
R
O FONTE: Trentin (2011, p. 23)
J
E
T
O
S
De acordo com (TRENTIM, 2011), o escritório de projetos pode ser classificado em

três tipos distintos:
• Autônomo: criado apenas para dar suporte a um projeto ou programa devido à sua
importância estratégica. Ele é extinto no final do programa ou projeto.
• Setorial ou departamental: existe apenas para gerenciar projetos ou programas do
setor ou departamento onde foi criado.
• Corporativo: controla todos os programas e projetos da organização, orientando
processos e estabelecendo padrões de gerenciamento. Tem vida organizacional longa.
Ambos os tipos de PMO concentram-se na gestão ampla dos projetos e programas,

vislumbrando a otimização de recursos. Há um aumento significativo na implantação de PMOs
nas organizações, mas cabe ressaltar que nem todas realmente necessitam desta estrutura. A
decisão pela implantação do mesmo deve ser estudada e planejada, e requer uma avaliação
do nível de maturidade organizacional, inclusive da maturidade em gestão de projetos (ROCHA
et al., 2001).
FIGURA 8 – EXEMPLO DE ESCRITÓRIOS DE PROJETOS NA ORGANIZAÇÃO
G
E
R
FONTE: Trentin (2001, p. 24) Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 1
Neste tópico, você aprendeu que:
• Projetos são frequentemente implementados como um meio de executar um plano estratégico

da organização. As organizações executam trabalho. O trabalho envolve serviços continuados e/
ou projetos, embora possa haver superposição entre os dois. Serviços continuados e projetos
possuem muitas características comuns; por exemplo, ambos são:
 Executados por pessoas.

 Restringidos por recursos limitados.
 Planejados, executados e controlados.
• Serviços continuados e projetos diferem principalmente porque enquanto os primeiros são

contínuos e repetitivos, os projetos são temporários e únicos. Assim, um projeto pode ser definido
em termos de suas características distintas – um projeto é um empreendimento temporário
com o objetivo de criar um produto ou serviço único. Temporário significa que cada projeto tem
um começo e um fim bem definidos.
• Único significa que o produto ou serviço produzido é de alguma forma diferente de todos os
outros produtos ou serviços semelhantes. Para muitas organizações, projetos são um meio de
responder aquelas necessidades que não podem ser endereçadas dentro dos limites normais
de operação da organização.
• Os projetos são desenvolvidos em todos os níveis da organização. Eles podem envolver uma
G única pessoa ou milhares delas. Eles podem ter duração de algumas semanas o durar mais de
E
R cinco anos. Os projetos podem envolver uma unidade isolada da organização ou atravessar
Ê as fronteiras organizacionais, como ocorre com consórcios e parcerias.
N
C
I • Os projetos são críticos para a realização da estratégia de negócios da organização porque
A
eles são um meio para que a estratégia seja implementada. Pode-se citar como exemplos de
D projetos:
E
P  Desenvolver um novo produto ou serviço.

R  Implementar uma mudança na estrutura, nas pessoas ou no estilo gerencial de
O
J uma organização.
E  Planejar um novo veículo de transporte.
T
O  Desenvolver ou adquirir um sistema de informação novo ou modificado.
S
 Construir um prédio ou instalações.

 Construir um sistema de água comunitário em um país em desenvolvimento.
 Levar a cabo uma campanha política.
 Implementar um novo processo ou procedimento de negócio.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 O que é projeto?
2 Defina Gestão de Projetos.
3 Em sua opinião o que difere um gestor de projetos dos demais gestores?
4 Sobre grupos de processos é correto afirmar que:

a) ( ) Se ligam pelos resultados que produzem.
b) ( ) Se sobrepõem uns aos outros.
c) ( ) O encerramento de uma fase é subsídio para outra.
d) ( ) Todas as anteriores.
5 A diferença entre programa e projeto é:

a) ( ) Um programa é feito de múltiplos projetos.
b) ( ) Programas são projetos de longa duração.
c) ( ) Os programas são empreendimentos permanentes.
d) ( ) Todas acima.
6 O propósito do PMBOK é identificar e descrever o conhecimento e práticas que devem

ser aplicadas uniformemente aos projetos:
a) ( ) Pequenos.
b) ( ) Grandes.
G
c) ( ) Que possuem o escopo bem definidos.
E d) ( ) A afirmação acima é falsa.
R
Ê
N 7 Quem determina os requisitos de um novo projeto?
C a) ( ) O cliente.
I
A b) ( ) Os stakeholders.
c) ( ) O gerente do projeto.
D
E d) ( ) O gerente funcional.
P
R 8 _______________ asseguram que os objetivos do projeto estão sendo atingidos, por
O meio de monitoração regular do seu progresso para identificar variações do plano e,
J
E portanto, ações corretivas podem ser tomadas quando necessárias.
T a) ( ) Controles do projeto.
O
S
b) ( ) Processos de controle.
c) ( ) Controles de qualidade.
d) ( ) Garantias da qualidade.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 1
TÓPICO 2
UMA VISÃO GERAL DE GESTÃO DE

PROJETOS
1 INTRODUÇÃO
NOT
A!

Existem muitas empresas especializadas em gerenciamento de projetos. Faça uma

pesquisa na internet e verifique como estas organizações trabalham, que tipos de
serviços oferecem e quem são seus clientes! Boa pesquisa!
Agora que você já sabe o que é um projeto e conhece seu contexto, podemos iniciar o
entendimento acerca do que é o gerenciamento de projetos.
A implantação de gerenciamento de projetos nas organizações ocorre de forma gradual, G

E
trazendo como benefício a melhoria contínua na gestão e execução dos mesmos.
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 9 – EVOLUÇÃO DA IMPLANTAÇÃO DO GERENCIAMENTO DE PROJETOS
Para Kerzner (2002, p. 15) “gestão de projetos pode ser definida como o planejamento,
a programação e o controle de uma série de tarefas integradas de forma a atingir seus objetivos
com êxito, para benefício de todos os participantes do projeto”.
O gerenciamento de projetos é a arte de coordenar atividades com o objetivo de atingir

as expectativas dos stakeholders.
FIGURA 10 – CARACTERÍSTICAS DA GESTÃO DE PROJETOS
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T FONTE: Keelling (2002, p. 40)
O
S
2 HISTÓRIA DA GERÊNCIA DE PROJETO
Como disciplina e área de conhecimento, a gerência de projetos foi formalizada nos anos
60 em diversos campos de aplicação, incluindo a construção, a engenharia mecânica, projetos
militares etc. Nos Estados Unidos, o "pai" da gerência de projeto é Henry Gantt, chamado o
pai de técnicas do planejamento e do controle, que é conhecido pelo uso do gráfico de barras
como uma ferramenta de gerência do projeto. Associou o gráfico de barras às teorias de
Frederick Winslow Taylor, outro pensador da administração científica. Seu trabalho é alicerce
de muitas ferramentas de gerências modernas do projeto, tais como a WBS (Work Breakdown
Structure) ou EAP (Estrutura Analítica do Projeto) (PHILLIPS, 2003). Ambas serão abordadas
nos próximos tópicos.
A modernização da gerência de projetos teve início na década de 50, com o

desenvolvimento dos modelos PERT e COM, utilizados também pelos Estados Unidos.
• Program Evaluation and Review Technique ou o PERT, desenvolvido como uma parte do
programa do míssil do submarino Polaris da marinha dos Estados Unidos (conjuntamente
com a Lockheed Corporation); e
• Critical Path Method (CPM) desenvolvido em conjunto por Du Pont Corporation e
Remington Rand Corporation para projetos da manutenção de planta. Estas técnicas
matemáticas espalharam-se rapidamente em muitas empresas.
Tendo como foco os projetos espaciais na NASA, em 1969, um grupo de profissionais

de Gestão de Projetos, da Philadelphia, Pensilvânia – EUA, discutiu e documentou as melhores
práticas dando início ao Project Management Institute – PMI.

G
NOT
A! E
R
Ê
N
C
I
A
O Instituto de Gerenciamento de Projetos (Project Management Institute PMI) é uma
das maiores associações para profissionais de gerenciamento de projetos. Auxilia D
mais de 700.000 membros, profissionais certificados e voluntários em praticamente E
todos os países do mundo a aumentar o sucesso das suas empresas, evoluir em
suas carreiras e tornar a profissão mais madura. P
R
O
J
Em 1981, os diretores do PMI autorizaram o desenvolvimento do que se transformou E
T
em um guia de projetos, o Project Management Body of Knowledge conhecido como PMBoK,
O
S
contendo os padrões e as linhas mestras das práticas que são usados extensamente durante
toda a profissão.
3 PRINCIPAIS VARIÁVEIS DA GESTÃO DE PROJETOS
Boa parte do tempo do gerente de projetos e sua equipe é gasta no que se chama
“tripé da gestão de projetos” ou “restrição tripla de projetos”. A qualidade pode ser considerada
uma quarta variável, pois é afetada por restrições relacionadas aos demais componentes do
triângulo. Estas variáveis são consideradas o alicerce de qualquer projeto, sendo que qualquer
mudança em uma das variáveis compromete diretamente as outras (PHILLIPS, 2003).
FIGURA 11 – TRIPÉ DA GESTÃO DE PROJETOS
FONTE: A autora
Reduzir o tempo, por exemplo, vai influenciar diretamente o prazo estabelecido para
as atividades que compõem o projeto até o término do mesmo. O custo define o tamanho do
G projeto e o tempo destinado ao mesmo. Uma redução no custo afeta diretamente o tempo de
E
R execução e os prazos de entrega. Um aumento no universo do escopo, que define o que deve
Ê ser feito, vai obrigatoriamente aumentar os prazos de entrega, bem como o custo inicialmente
N
C estimado (VARGAS, 2009).
I
A
Desta forma, as técnicas e padrões de gestão de projetos, permitem que o gerente e a
D equipe organizem as atividades a fim de não comprometer as variáveis do tripé.
E
P Para o guia PMBoK, o gerenciamento de projetos é a aplicação de conhecimento,

R
técnicas, ferramentas, conhecimentos e habilidades às atividades de um projeto a fim de
O
J atender aos seus requisitos, onde gerenciar um projeto inclui:
E
T
O • Identificação de requisitos.
S
• Adaptação às diferentes necessidades e expectativas das partes interessadas.

• Equilíbrio de restrições que incluem Tempo, Escopo, Custos, recursos e riscos de
cada projeto.
O Guia PMBoK tem seu alicerce no plano P-D-C-A (Plan-Do-Check-Act Planejar,

Fazer, Checar, Agir ou Corrigir).
PDCA é um ciclo e deve funcionar continuamente, ou seja, as quatro etapas devem ser
executadas sempre e de modo que haja interação entre elas, para que seja possível obter a
melhoria contínua dos processos envolvidos (CARVALHO, 2011).
FIGURA 12 – CICLO PDCA
G
E
R
Ê
N
C
I
A
Os projetos vão sendo elaborados progressivamente e de modo iterativo entre as etapas
do seu ciclo de vida, sendo que a iteratividade é um resultado natural do processo de melhoria D
E
contínua da elaboração progressiva, na medida em que os projetos vão sendo executados
e posteriormente revistos para assim, adicionar mais detalhamento aos resultados obtidos P
(TRENTIM, 2001). R
O
J
E
T
O
S
4 PADRÕES DE GERÊNCIA DE PROJETOS
A cada novo projeto de implantação, clientes e os próprios escritórios de projetos buscam

sempre aprimorar as suas práticas, métodos e padrões de gerenciamento. Neste contexto,
dúvidas e indefinições são comuns, uma vez que existe uma variedade considerável de opções
de padrões e modelos a serem utilizados (VARGAS, 2009).
Podemos destacar como principais práticas:
• Project Management Body of Knowledge (PMBoK) é um padrão americano. Oferece

uma base sólida de padrões de gerenciamento de projetos. Define a estrutura da gerência de
projetos em função de um conjunto de áreas de conhecimento e dos processos que a compõem.
Certificação como garantia do conhecimento dos padrões e nível de competência. Estabelece
um padrão de comunicação em projetos da empresa. Nivelamento de expectativas pessoais
e interáreas. Padrão é base que possibilita melhorias.
ISO 10006: 1997, Quality management – Guidelines to quality in project

management: é um guia e um padrão internacional desenvolvido pela ISO específico para
gerência de projetos, não com objetivos de certificação, mas de padronização. É aplicável a
projetos de complexidades variadas, pequenos ou grandes, de curta ou longa duração, em
diferentes ambientes e independente do tipo de produto ou processo envolvido. Isto pode
necessitar de alguma adaptação em seu gerenciamento para atender às particularidades do
projeto.
• PRINCE2™ (Projects IN a Controlled Environment): é uma abordagem baseada

nos processos de gerenciamento de projetos. Ele fornece um método facilmente adaptável e
escalável para a gestão de quaisquer tipos de projetos. O PRINCE2® é o padrão atual utilizado
G
E no gerenciamento de projetos no Reino Unido e é praticado em todo o mundo.
R
Ê
N • Referencial Brasileiro de Competências (RBC), um dos conjuntos de conhecimentos
C mais recentes sobre Gerenciamento de Projetos, além dos processos de gestão, aborda
I
A competências Associação Brasileira de Gerenciamento de Projetos (ABGP). Tem-se tornado
um padrão de fato em diversas indústrias, como o caso da Siemens.
D
E
• IPMA Competence Baseline (ICB), edição mais recente do corpo de conhecimento
P
R desenvolvido pelo International Project Management Association, cuja representação no Brasil
O é realizada pela Associação Brasileira de Gerenciamento de Projetos (ABGP). Trata do olho da
J
competência em Gerenciamento de Projetos e traz à área uma visão mais holística e inovadora
E
T do Gerenciamento de Projetos.
O
S
Para obter sucesso na implantação de gerenciamento de projetos é necessário:

• Comprometimento e apoio explícito do alto escalão organizacional;
• Habilitar e treinar gerentes para a gestão de projetos;
• Existência de um Escritório de Projetos (ou PMO: Project Management Office);
• Uma metodologia para dar suporte aos processos;
• Ferramentas de planejamento e controle (softwares específicos para Gestão de
Projetos).
Internamente, o alto escalão organizacional deve evidenciar o interesse no sucesso dos

projetos e suas práticas. Para isso, é necessário diferenciar as demais “gerências” da “gerência
de projetos”, além de adotar um plano de carreira como incentivo para a atividade de gestão
de projetos se tornar mais atrativa (VARGAS, 2009).
5 ESTRUTURA ORGANIZACIONAL
Nas últimas décadas, os gestores têm apontado a necessidade das organizações serem
mais dinâmicas, em resposta à rapidez de mudanças em praticamente todos os segmentos de
negócios. Como contraponto à estrutura funcional ou tradicional, outras formas de estrutura
organizacional foram tomando forma. Como exemplo, podemos citar a estrutura projetada e a
estrutura matricial (KERZNER, 2002).
Grande parte das empresas de desenvolvimento de software adota a estrutura

“funcional”, onde analistas de sistemas, projetistas e programadores estão vinculados a um único
gerente. Neste caso, os projetos são controlados por líderes, geralmente analistas de sistemas
com experiência técnica avançada. Pode-se considerar como uma forma limitada, uma vez
que o analista de sistemas não desenvolveu todas as aptidões necessárias para a gestão de G
projetos, tendo em vista o caráter extremamente técnico de sua formação (PHILLIPS, 2003). E
R
Ê
Nas empresas de desenvolvimento de médio e grande porte, que trabalham com vários N
projetos simultaneamente, sendo estes de alto custo e de customização mais complexa, o C
I
modelo mais adotado é o da organização projetada, onde o gestor do projeto monta a equipe e A
esta permanecerá em suas atividades até o término do projeto. Alguns integrantes permanecem
D
na equipe do início ao fim do projeto. Outros, podem se desligar para incorporar a equipe de E
outro projeto. Não há regra definida para a alocação dos recursos humanos (VARGAS, 2009).
P
R
A literatura do assunto aponta para três tipos de organizações clássicas. Porém, outras O
J
formas ou combinações podem surgir a partir destes: E
T
O
S
5.1 ORGANIZAÇÃO FUNCIONAL OU HIERÁRQUICA
Os membros da equipe geralmente são bem qualificados e têm mais do que um superior.
São agrupados por especialidade (ex.: engenharia, finanças, contabilidade). Reportam-se aos
superiores de acordo com a especialidade de cada um. A autoridade dos superiores sobre o
restante da equipe é parcial.
Este modelo é inapropriado quando se trabalha com projetos onde são necessários
controles sobre atividades que envolvam mais de uma área de conhecimento, e restrições de
custo e tempo de customização.
A orientação é vertical, ou seja, as ordens vêm de cima para baixo, contrariando projetos
multiespecializados que devem ser gerenciados horizontalmente.
FIGURA 13 – ORGANIZAÇÃO FUNCIONAL
G FONTE: Disponível em: <https://brasil.pmi.org>. Acesso em: 10 abr. 2015.

E
R
Ê
N
C
I 5.2 ORGANIZAÇÃO PROJETADA
A
D Este formato apresenta uma forma de trabalho mais dinâmica, onde as equipes são
E
montadas para o alcance de um objetivo específico, tendo como líder o gerente de projetos.
P O modelo é orientado para as tarefas e para a equipe. O gerente de projetos tem autoridade
R
O total sobre todo o projeto, possuindo alto grau de independência e autonomia.
J
E
T
Uma desvantagem é a alocação e realocação das pessoas que compõem as equipes,
O uma vez que os projetos são temporários.
S
FIGURA 14 – ORGANIZAÇÃO PROJETADA
FONTE: Disponível em: <https://brasil.pmi.org>. Acesso em: 10 abr. 2015.
5.3 ORGANIZAÇÃO MATRICIAL
É o modelo adotado por organizações que trabalham orientadas por projeto, sendo
considerada a solução mais avançada em termos de gestão, pois agiliza os processos
organizacionais e trabalha com recursos compartilhados.
FIGURA 15 – ORGANIZAÇÃO MATRICIAL
G
E
R
Ê
N
C
I
A
D
E
P
FONTE: Disponível em: <https://brasil.pmi.org>. Acesso em: 10 abr. 2015. R
O
J
E
T
O
S
A organização matricial ainda pode ser dividida em:
• Matricial Fraca: É uma estrutura muito similar com uma organização funcional e o papel
do gerente de projetos é mais parecido com a de um coordenador ou facilitador. As prioridades
das atividades do projeto são baixas tendo em vista que as equipes são subordinadas aos
seus respectivos departamentos de origem.
• Matriz Balanceada: Nesta estrutura já se reconhece a necessidade de um gerente de

projetos, porém com pouca autonomia sobre o projeto e seu financiamento já que ainda está
sob a gestão de um gerente funcional. Numa estrutura com este modelo destaca-se o aumento
considerável dos conflitos em função de que o superior não é claramente definido.
• Matricial Forte: É uma estrutura que se assemelha com as características de uma

organização projetizada e neste caso podem ter gerentes de projetos em tempo integral com
autoridade considerável e pessoal administrativo trabalhando para o projeto em tempo integral.
Neste modelo, as equipes estão mais comprometidas com o projeto e a prioridade dos projetos
dentro da organização é alta.
FONTE: Disponível em: <http://daseuspulos.com.br/2013/12/14/entenda-os-tipos-de-estruturas-

organizacionais>. Acesso em: 30 abr. 2015.
FIGURA 16 – VANTAGENS E DESVANTAGENS DAS ESTRUTURAS ORGANIZACIONAIS
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
6 FERRAMENTAS DE PLANEJAMENTO E CONTROLE
A tecnologia da informação desempenha um papel fundamental no auxílio à gestão de

projetos, desempenhando, muitas vezes, um papel estratégico. Para que nada fuja ao controle
da equipe e gestores, é necessária a utilização de um bom sistema de gerenciamento de
projetos. Há várias opções no mercado. Podemos citar como exemplo: MS-Project, Primavera,
Artêmis, Plan, Time Line, entre outros (VARGAS, 2009).
Além destes, as empresas podem desenvolver seu próprio sistema de informação para
a gestão de seus projetos, incorporando às funcionalidades um aplicativo para controle de
horas trabalhadas. Geralmente, o aplicativo de horas trabalhadas é integrado ao MS-Project,
por exemplo. Um cadastra as atividades e seus responsáveis e o outro controla os tempos de
desenvolvimento, facilitando a extração de relatórios gerenciais para controle do andamento
do projeto (PHILLIPS, 2003).
A forma de comunicação adotada também interfere diretamente no sucesso dos projetos.

Para isso faz-se necessário o uso de uma rede de comunicação corporativa, com adoção de G
E
e-mail, WEB, intranet, extranet, e adoção de padrões para toda a documentação de projetos R
que circular por estes meios. Ê
N
C
I
A
7 GERENCIAMENTO DE PROJETOS NA VISÃO DO PMI D

E
A primeira publicação do PMBoK foi feita em 1983, pelo Project Management P

R
Institute (PMI). Inicialmente caracterizado como um white paper, surgiu da necessidade de O
documentar e padronizar práticas aceitas e aplicáveis na gestão de projetos. A primeira edição J
E
foi publicada em 1996 e a segunda, em 2000. T
O
S
A terceira edição teve sua publicação efetivada em 2004. A quarta edição em 2008 e
mais recentemente a quinta edição revisada e disponibilizada, em 2013. O guia foi traduzido
para os idiomas: árabe, chinês, francês, alemão, italiano, japonês, coreano, português, russo
e espanhol.
O guia oferece linguagem comum para a discussão, escrita e aplicação do gerenciamento

de projetos, facilitando o entendimento das informações entre os profissionais envolvidos. Sua
estrutura é baseada em processos e subprocessos e descreve de forma detalhada as atividades
a serem desenvolvidas no projeto.
O guia é baseado em processos e subprocessos para descrever de forma organizada
o trabalho a ser realizado durante o projeto. Todos os processos se relacionam e interagem
durante a execução do projeto.
Os processos descritos se relacionam e interagem durante a condução do trabalho. A

descrição de cada um deles é feitada seguinte forma:
• Entradas (documentos, planos, desenhos etc.).

• Ferramentas e técnicas (que se aplicam às entradas).
• Saídas (documentos, produtos etc.).
A 5° Edição do Guia PMBOK aborda normas individuais para a gerência dos projetos
definindo conceitos associados à gestão dos mesmos. A versão atual considera 47 processos
divididos em 5 grupos de processos e 10 áreas de conhecimento que são comuns em quase
todos os segmentos de negócios e seus respectivos projetos.
Conjuntos de conhecimento do Guia PMBOK 4° e 5° Edição
FIGURA 17 – GRUPOS DE CONHECIMENTOS
G
E
R
Ê
N
C
I
A
FONTE: Adaptado de PMBOK (2013)
D
E
As dez áreas de conhecimento do PMBOK (5ª edição) estão distribuídas da seguinte
P forma:
R
O
J • Gerenciamento/Gestão de integração do projeto.
E • Gerenciamento/Gestão do escopo do projeto.
T
O • Gerenciamento/Gestão de tempo do projeto.
S
• Gerenciamento/Gestão de custos do projeto.

• Gerenciamento/Gestão da qualidade do projeto.
• Gerenciamento/Gestão de recursos humanos do projeto.
• Gerenciamento/Gestão das comunicações do projeto.
• Gerenciamento/Gestão de riscos do projeto.
• Gerenciamento/Gestão de aquisições do projeto.
• Gerenciamento/Gestão de envolvidos do projeto (adicionada na 5ª Edição)
A seguir, o conjunto de conhecimentos PMBOK 4° e 5° Edição
FIGURA 18 – CONJUNTO DE CONHECIMENTOS
FONTE: Adaptado de PMBOK (2013)

G
1. Gerenciamento de integração do projeto – descreve os processos requeridos para certificar- E
R
se que os vários elementos do projeto estão propriamente coordenados. Consiste em: Ê
1. Desenvolver o termo de abertura do projeto. N
C
2. Desenvolver o plano de gerenciamento do projeto. I
3. Orientar e gerenciar a execução projeto. A
4. Monitorar e controlar o trabalho do projeto. D

5. Executar o controle integrado de mudanças. E
6. Encerrar o projeto ou fase. P
R
O
2. Gerenciamento do escopo do projeto – define e descreve o que deve ser feito. Efetua o
J
levantamento dos requisitos para definir o universo do projeto. Consiste em: E
T
1. Coletar requisitos.
O
S
2. Definir o escopo.
3. Criar a Estrutura Analítica de Processo (EAP).
4. Verificar o escopo.
5. Controlar do escopo.
3. Gerenciamento de tempo de projeto – descreve os processos requeridos para garantir que

o projeto seja executado e entregue no prazo estabelecido dentro do prazo. Consiste em:
1. Definir atividades.
2. Sequenciar atividades.
3. Estimar de recursos da atividade.
4. Estimar de duração da atividade.
5. Desenvolver do cronograma.
6. Controlar do cronograma.
4. Gerenciamento de custos do projeto – descreve os processos requeridos para que o projeto

seja executado dentro do orçamento estimado. Consiste em:
1. Estimar de custos.
2. Determinar o orçamento.
3. Controlar custos.
5. Gerenciamento da qualidade do projeto – descreve os processos requeridos para garantir

que o projeto vai atender às necessidades e expectativas do patrocinador ou usuário final.
Consiste em:
1. Planejar a qualidade.
2. Realizar a garantia da qualidade.
3. Realizar o controle da qualidade.
6. Gerenciamento de recursos humanos do projeto – descreve os processos requeridos para

otimizar as competências e habilidades em termos de alocação e realocação das pessoas
G
envolvidas no projeto. Consiste em:
E
R 1. Desenvolver o plano de recursos humanos.
Ê
2. Contratar ou mobilizar a equipe do projeto.
N
C 3. Desenvolver a equipe de projeto.
I 4. Gerenciar a equipe de projeto.
A
D 7. Gerenciamento das comunicações do projeto – descreve os processos requeridos para

E
garantir o adequado uso, repasse, armazenamento e disseminação das informações do projeto.
P Consiste em:
R
O 1. Identificar as partes interessadas.
J 2. Planejar as comunicações.
E
T
3. Distribuir as informações.
O 4. Gerenciar as expectativas das partes interessadas.
S
5. Relatar desempenho.
8. Gerenciamento de riscos do projeto – descreve os processos relacionados na identificação,

análise e respostas aos possíveis riscos que envolvem o projeto. Consiste em:
1. Planejar o gerenciamento de riscos.
2. Identificar riscos.
3. Realizar a análise qualitativa de riscos.
4. Realizar a análise quantitativa de riscos.
5. Planejar respostas aos riscos.
6. Monitorar e controlar riscos.
9. Gerenciamento de aquisições do projeto – descreve os processos requeridos para

aquisição de bens e serviços que não são supridos internamente pela organização e que são
indispensáveis para o bom andamento do projeto. Consiste em:
1. Planejar aquisições.
2. Conduzir aquisições.
3. Administrar aquisições.
4. Encerrar aquisições.
10. Gerenciamento das partes interessadas: Descreve os processos necessários para gerenciar
as partes envolvidas no projeto. Consiste em:
1. Identificar as partes interessadas.
2. Planejar o gerenciamento das mesmas.
3. Gerenciar as partes.
4. Controlar o envolvimento das partes.
FIGURA 19 – PROCESSOS E ÁREAS DE CONHECIMENTO DO PMBOK, 5ª EDIÇÃO, 2013
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
FONTE: Disponível em: <https://brasil.pmi.org>. Acesso em: 10 abr. 2015. S
8 PROCESSOS DA GERÊNCIA DE PROJETOS
Cada projeto é único, com isso a incerteza é uma característica predominante em todas
as fases do projeto. Por isso, não é incomum que os gestores optem por dividir os projetos em
várias etapas no intuito de obter maior controle gerencial (PMI, 2008).
O ciclo de vida de um projeto é conhecido como sendo o seu conjunto de fases. Cada
fase é alicerçada por grupos de processos, totalizando cinco: iniciação, planejamento, execução,
controle e finalização (PHILLIPS, 2003).
Um processo é uma série de ações/execuções que geram um resultado específico e

pré-determinado (VARGAS, 2009). De acordo com o autor, processos podem ser classificados
de duas formas distintas:
• Processos da gerência de projetos: englobam desde a fase de descrição, a parte de

organização e demais etapas que envolvam o projeto até a sua conclusão. Pode-se
afirmar que controlam o ciclo de vida do projeto.
• Processos orientados ao produto: voltados para a especificação e criação de produtos.

São específicos de cada produto, mas são definidos pelo ciclo de vida do projeto,
variando de acordo com a área de aplicação.
Cada grupo de processo é formado por um ou mais processos (PMI, 2008), envoltos
nas seguintes atribuições:
• Os processos do grupo de iniciação reconhecem que uma fase ou projeto devem ser
iniciados assumindo o compromisso de iniciá-los.
G
E • Os processos do grupo de planejamento são responsáveis identificar, selecionar e
R adotar as melhores práticas para alcance dos objetivos, cujo projeto se comprometeu
Ê
N a atender.
C • Os processos do grupo de execução são responsáveis por coordenar pessoas e outros
I
A recursos para colocar em prática o plano do projeto.
• Os processos do grupo de controle são responsáveis por assegurar o cumprimento dos
D
E objetivos estabelecidos, bem como suas ações corretivas.
• E finalmente, os processos do grupo de encerramento são responsáveis por formalizar
P
R a aceitação entrega do projeto ou de suas etapas entregues de forma sequenciada.
O
J
E
T
O
S
FIGURA 20 – GRUPOS DE PROCESSO
FONTE: A autora
O ciclo de vida de um projeto serve para definir os marcos de início e fim do mesmo.
Quando uma organização identifica uma oportunidade ou necessidade, esta solicita um estudo
de viabilidade para definir se um projeto será criado para suprir o apontamento. Neste caso, o
ciclo de vida determina se o estudo de viabilidade será o início do projeto ou se será tratado
como um projeto que antecede algo maior (2008).
O ciclo de vida de um projeto permite uma visualização sistêmica do projeto, desde o

seu início até a conclusão, facilitando as técnicas de Gerenciamento de Projetos (PMI, 2013).
Os grupos de processos do ciclo de vida estão ligados uns aos outros pelos resultados
produzidos. Ou seja, a finalização /saída de um grupo, aponta para a entrada/início do outro
grupo. Os grupos são interligados – não existem sozinhos – e são contínuos; não acontecem G
E
uma única vez apenas no projeto, pelo contrário, tornam a se repetir tantas vezes quanto for R
preciso. (PMI, 2008) Ê
N
C
Os processos são classificados em dois tipos: essenciais e auxiliares (ou facilitadores). I
A
• Os processos essenciais têm apresentam dependência entre as atividades e devem por D

E
isso, obedecem a uma ordem de execução. Normalmente, as atividades são definidas
antes do estabelecimento do cronograma ou custo do projeto. P
R
O
• Os processos auxiliares dependem da natureza do projeto e podem mudar com o J
avanço do projeto. Um exemplo disso é a percepção que se tem acerca dos riscos E
T
que envolvem o projeto. Além disso, podem oferecer suporte aos processos básicos já O
S
estabelecidos.
Recomenda-se reaplicar o processo de iniciação antes de iniciar o processo de execução

de cada fase, para verificar se o projeto está cumprindo o seu propósito e não houve desvio no
escopo. Além disso, é importante envolver as partes interessadas a fim de assegurar que as
expectativas estão sendo atendidas, e que os riscos em função disso, tendem a ser minimizados
ou até extintos (ROCHA et al., 2001).
Caso sejam identificadas não conformidades na reaplicação do processo de iniciação,

o gerente do projeto deve prontamente iniciar as medidas corretivas, para que o projeto
não comprometa o “tripé” CUSTO/PRAZO/ESCOPO e volte, desta forma, para as linhas de
conformidade (VARGAS, 2009).
De certa maneira, os processos podem ser ajustáveis ou personalizados para cada

projeto. Podem ser melhorados, modificados, ou até excluídos, desde que estas intervenções
sejam feitas com cuidado para não comprometer o andamento de processos dependentes.
FIGURA 21 – GRUPOS, PROCESSO E ÁREAS DE CONHECIMENTO
G
E
R
Ê FONTE: Disponível em: <https://brasil.pmi.org>. Acesso em: 10 abr. 2015.
N
C
I
A
D 9 METODOLOGIA DE PROJETO
E
P Existem diversos métodos de projeto, mas todos seguem uma estrutura básica:
R
O
J • Observação e análise: definição do problema, pesquisa, definição de objetivos e restrições.
E
• Planejar e projetar: geração de opções de projeto, escolha de opção de projeto,
T
O desenvolvimento, aprimoramento, detalhamento.
S
• Construir e executar: protótipo; produção.
Assim, podemos descrever os seguintes passos:
• Identificação de oportunidade ou necessidade.

• Análise do problema (levantamento de informações ou requisitos).
• Geração de ideias para o projeto (fontes / técnicas).
• Seleção das melhores ideias para o projeto (triagem).
• Desenvolvimento e teste do conceito (em TI não é possível).
• Desenvolvimento da estratégia de marketing (quando necessário).
• Viabilidade (financeira/comercial).
• Desenvolvimento.
• Teste de mercado.
• Comercialização.
10 PLANO DE PROJETO
Um plano de projeto antecede a etapa de planejamento. Tem como objetivo integrar

todos os planos auxiliares do projeto, além de detalhar como ele será executado, monitorado,
controlado e encerrado (PHILLIPS, 2003). Documenta o conjunto de saídas dos processos de
planejamento e inclui:
• Os processos de gestão de projetos selecionados pela equipe de gerenciamento de

projetos.
• O nível de implementação de cada processo selecionado.
• As descrições das ferramentas e técnicas que serão usadas para realizar esses
processos.
• Como os processos selecionados serão usados para gerenciar o projeto específico, G
inclusive as dependências e interações entre esses processos e as entradas e saídas E
R
essenciais.
Ê
• Como o trabalho será executado para realizar os objetivos do projeto. N
C
• Como as mudanças serão monitoradas e controladas.
I
• Como a integridade das linhas de base da medição de desempenho será mantida e A
utilizada.
D
• A necessidade e as técnicas de comunicação entre as partes interessadas. E
• A análise de riscos dos projetos.
P
• O ciclo de vida do projeto selecionado e, para projetos com várias fases, as fases R
associadas do projeto. O
J
• As principais revisões de gerenciamento em relação a conteúdo, extensão e tempo E
para facilitar a abordagem de problemas em aberto e de decisões pendentes. T
O
S
O plano de projeto permite responder às seguintes questões:
• O que deve ser feito futuramente para atingir os objetivos do projeto?

• Como vai ser feito?
• Quem vai fazer?
• Quando estará feito?
Esta documentação é criada na fase de planejamento e será usada no processo de

execução do projeto.
11 PARTES INTERESSADAS NO PROJETO – STAKEHOLDERS
São indivíduos e organizações diretamente envolvidos no projeto, ou aqueles

cujos interesses podem ser afetados, de forma positiva ou negativa, no decorrer
do projeto ou mesmo após sua conclusão; podem, também, exercer influências
no projeto e seus resultados. (TRENTIM, 2011, p. 34)
Cada projeto apresenta diferentes grupos stakeholders que deverão ser mapeados pela
equipe do projeto a fim de determinar as expectativas e necessidades de cada parte. Além
deste mapeamento cabe avaliar seus interesses e forma de atuação no projeto: se a pessoa
é favorável ou contrária ao projeto, por exemplo. Desta forma, faz-se o nivelamento das
partes. Não é um processo fácil, mas caso esta etapa não seja cumprida, podem-se aumentar
significativamente os riscos do projeto (VARGAS, 2009).
Determinar a influência de cada parte interessada no projeto (influência positiva ou

influência negativa) facilita, por exemplo, a etapa de levantamento de requisitos de um projeto.
G Conhecer as características das pessoas antes de interrogá-las é uma maneira escolher e pré-
E determinar corretamente os canais de comunicação adotados, bem como a forma de abordagem
R
das mesmas no intuito de evitar conflitos que acarretem no atraso do projeto (CARVALHO, 2010).
Ê
N
C
Alguns tipos de stakeholders (PMI, 2013):
I
A
• Clientes/usuários: são as pessoas que farão uso do produto ou serviço.
D
E • Patrocinador: Geralmente é quem banca financeiramente o projeto. Pode ser o dono
da empresa, ou alguém do alto escalão da mesma. Ou mesmo um chefe de setor.
P
R Também pode ser uma organização específica, como um Banco, por exemplo.
O • Gerentes de portfólios/comitê de análise de portfólios: os gerentes são responsáveis
J
E por identificar, priorizar, autorizar o gerenciamento e controle do projeto, programa e
T outros trabalhos relacionados.
O
S
• Gerente de programas: são os gerentes que definem e iniciam projeto, auxiliando os

Gerentes de Projetos a gerenciar custo, cronograma e desempenho, trabalhando de
modo a garantir o sucesso do programa.
• Escritório de projetos: o PMO (Project Management Office) é uma estrutura
organizacional à qual são atribuídas várias responsabilidades relacionadas ao
gerenciamento centralizado e coordenado dos projetos sob sua responsabilidade.
• Gerentes de projetos: são os controladores do projeto, de forma geral. Coordenam
a equipe, documentação, stakeholders, Sistemas de Informação, e todo o contexto do
projeto.
• Equipe do projeto: é composta pela equipe do projeto e demais membros envolvidos
em cada etapa do projeto.
• Gerentes funcionais: são os gerentes gerais e de nível médios já instituídos
organizacionalmente.
• Gerenciamento de operações: são os gerentes especialistas, e, lidam diretamente
com a produção e manutenção dos produtos da empresa.
• Fornecedores/parceiros comerciais: todos os parceiros externos que contribuem de
alguma forma para o desenvolvimento do projeto.
FIGURA 22 – MAPA MENTAL DAS PARTES INTERESSADAS OU STAKEHOLDERS
G
E
FONTE: Trentin (2011, p. 35) R
Ê
N
C
NOT
A!
I
A
D
E
P
R
Como você acabou de ver, o termo “STAKEHOLDER” refere-se a todos os grupos
O
que afetam um projeto, ou são afetados por ele. Este termo é utilizado há muito
J
tempo na área de Administração, sempre referenciando os grupos que não ação
E
acionistas de uma empresa (não são seus Stakeholders), mas são influenciados por
T
suas atividades e têm influência sobre elas. Você poderá encontrar uma expressão
O
sinônima para Stakeholders: GRUPOS DE INTERESSE.
S
12 EQUIPE DO PROJETO DE DESENVOLVIMENTO DE SOFTWARE
FIGURA 23 – EQUIPE DE PROJETOS
FONTE: CARVALHO (2010, p. 15)
Gerenciar projetos é uma atividade de extrema importância no processo de

desenvolvimento de software, principalmente porque envolve um considerável número de
pessoas trabalhando juntas em médio e em longo prazo em tarefas altamente complexas
(PRESSMAN, 2005). O autor ainda afirma que estes projetos precisam controlados, pois esta
é a única forma de gerenciar a complexidade envolvida nos mesmos.
A alocação de pessoas em projetos de software ainda é um desafio que exige

competências específicas do gerente de projeto no intuito de mapear as competências técnicas
de cada colaborador para maior otimização da matriz de responsabilidades do cronograma.
Alocar a pessoa certa na atividade certa faz toda a diferença num setor onde cronogramas
apertados ou irracionais são a principal fonte de riscos dos projetos desta natureza (VARGAS,
2009).
Muitas variáveis devem ser consideradas na montagem da equipe de desenvolvimento

de software: prazos e competência técnica da pessoa, quanto a pessoa custa por hora
de trabalho, interdependências entre tarefas, alocação da pessoa em mais de um projeto,
G
E realocação dos especialistas no término de cada projeto, habilidades e experiências individuais,
R disponibilidade e tipo de trabalho, que pode ser empregatício ou por prestação de serviço
Ê
(consultoria) (PRESSMAN, 2005).
N
C
I
Uma estrutura básica de uma equipe de desenvolvimento de software pode ser composta
A
por:
D • Gerente de projeto: coordenador do projeto.
E
• Analista de negócios: especialista nas regras de negócio.
P • Analista de sistemas: faz a modelagem do sistema.
R
O • Projetista de sistemas: documenta as regras de negócio e desenha o aplicativo.
J • Programadores: constroem os programas.
E
T • Analista de qualidade: efetua os testes antes da liberação para o cliente.
O • DBA: responsável pelo banco de dados.
S
Tão importante quanto a equipe, é o gerente de projetos de software. Está sob sua
responsabilidade:
• Definir e controlar os objetivos do projeto;
• Definir e controlar os requisitos do projeto;
• Definir e controlar os riscos do projeto;
• Definir e avaliar os fatores críticos de sucesso do projeto;
• Definir e avaliar os pontos fortes e pontos fracos do projeto;
• Definir e controlar o cronograma;
• Verificar o esforço;
• Avaliar o projeto e a equipe com métricas;
• Alocar e gerenciar recursos (orçamento, materiais, pessoas);
• Definir prioridades;
• Coordenar interações entre os envolvidos no projeto;
• Assegurar que os prazos e custos estão sendo mantidos dentro do planejado;
• Assegurar que os produtos do projeto atendam aos critérios de qualidade e que estejam
de acordo com os padrões estabelecidos;
• Formalizar a aceitação dos artefatos resultantes de cada fase do ciclo de vida do projeto;
• Elaborar relatórios de avaliação e de acompanhamento da situação do projeto;
• Participar de reuniões de acompanhamento e de revisão do projeto.
O sucesso de um projeto está diretamente relacionado às habilidades de seu gerente.

Além de dominar as ferramentas e técnicas de gerência de projetos, ele deve também ter
conhecimento avançado em técnicas de liderança, motivação, gestão de pessoas, de maneira
geral. Ele deve ser um facilitador no projeto e não um obstáculo (PHILLIPS, 2003).
FIGURA 24 – ESTRUTURA DE UMA EQUIPE DE DESENVOLVIMENTO DE SOFTWARE
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: A autora O
S
RESUMO DO TÓPICO 2
Neste tópico você aprendeu que:
• A implantação de gerenciamento de projetos nas organizações ocorre de forma gradual,

trazendo como benefício a melhoria contínua na gestão e execução dos mesmos.
• O gerenciamento de projetos é a arte de coordenar atividades com o objetivo de atingir as
expectativas dos stakeholders.
• Como disciplina e área de conhecimento, a gerência de projetos foi formalizada nos anos 60
em diversos campos de aplicação, incluindo a construção, a engenharia mecânica, projetos
militares, etc. nos Estados Unidos.
• Boa parte do tempo do gerente de projetos e sua equipe são gastos no que se chama “tripé
da gestão de projetos” ou “restrição tripla de projetos”. A qualidade pode ser considerada uma
quarta variável, pois é afetada por restrições relacionadas aos demais componentes do triângulo.
• Para o guia PMBoK, o gerenciamento de projetos é a aplicação de conhecimento, técnicas,
ferramentas, conhecimentos e habilidades às atividades de um projeto a fim de atender aos
seus requisitos, em que gerenciar um projeto inclui:
 Identificação de requisitos.
 Adaptação às diferentes necessidades e expectativas das partes interessadas.
 Equilíbrio de restrições que incluem tempo, escopo, custos, recursos e riscos de
cada projeto.
• O Guia PMBoK tem seu alicerce no plano P-D-C-A (Plan-Do-Check-Act Planejar, Fazer,
Checar, Agir ou Corrigir).
G • Os projetos vão sendo elaborados progressivamente e de modo iterativo entre as etapas do
E
R seu ciclo de vida, sendo que a iteratividade é um resultado natural do processo de melhoria
Ê contínua da elaboração progressiva, na medida em que os projetos vão sendo executados e
N
C posteriormente revistos para assim, adicionar mais detalhamento aos resultados obtidos.
I • Para obter sucesso na implantação de gerenciamento de projetos é necessário:
A
D  Comprometimento e apoio explícito do alto escalão organizacional;

E
 Habilitar e treinar gerentes para a gestão de projetos;
P  Existência de um Escritório de Projetos (ou PMO: Project Management Office);
R  Uma metodologia para dar suporte aos processos;
O
J  Ferramentas de planejamento e controle (softwares específicos para Gestão de
E Projetos).
T
O
S • A literatura de estrutura organizacional aponta para três tipos de organizações clássicas.
Porém, outras formas ou combinações podem surgir a partir destes:
Organização Funcional ou Hierárquica:

Os membros da equipe geralmente são bem qualificados e têm mais do que um superior.
São agrupados por especialidade (ex.: engenharia, finanças, contabilidade). Reportam-se aos
superiores de acordo com a especialidade de cada um.
Organização projetizada
Este formato apresenta uma forma de trabalho mais dinâmica, onde as equipes são
montadas para o alcance de um objetivo específico, tendo como líder o gerente de projetos.
O modelo é orientado para as tarefas e para a equipe. O gerente de projetos tem autoridade
total sobre todo o projeto, possuindo alto grau de independência e autonomia.
Organização matricial
É o modelo adotado por organizações que trabalham orientadas por projeto, sendo
considerada a solução mais avançada em termos de gestão, pois agiliza os processos
organizacionais e trabalha com recursos compartilhados.
 Matricial Fraca: É uma estrutura muito similar com uma organização funcional
e o papel do gerente de projetos é mais parecido com a de um coordenador ou
facilitador. As prioridades das atividades do projeto são baixas tendo em vista que
as equipes são subordinadas aos seus respectivos departamentos de origem.
 Matriz Balanceada: Nesta estrutura já se reconhece a necessidade de um gerente
de projetos, porém com pouca autonomia sobre o projeto e seu financiamento já que
ainda está sob a gestão de um gerente funcional. Numa estrutura com este modelo
destaca-se o aumento considerável dos conflitos em função de que o superior não
é claramente definido.
 Matricial Forte: É uma estrutura que se assemelha com as características de uma
organização projetizada e neste caso podem ter gerentes de projetos em tempo
integral com autoridade considerável e pessoal administrativo trabalhando para o G
E
projeto em tempo integral. Neste modelo, as equipes estão mais comprometidas R
com o projeto e a prioridade dos projetos dentro da organização é alta. Ê
N
C
• As dez áreas de conhecimento do PMBOK (5ª edição) estão distribuídas da seguinte forma: I
A
 Gerenciamento/Gestão de integração do projeto. D

 Gerenciamento/Gestão do escopo do projeto. E
 Gerenciamento/Gestão de tempo do projeto. P

 Gerenciamento/Gestão de custos do projeto. R
O
 Gerenciamento/Gestão da qualidade do projeto. J
 Gerenciamento/Gestão de recursos humanos do projeto. E
T
 Gerenciamento/Gestão das comunicações do projeto. O
S
 Gerenciamento/Gestão de riscos do projeto.

 Gerenciamento/Gestão de aquisições do projeto.
 Gerenciamento/Gestão de envolvidos do projeto (adicionada na 5a Edição).
• Um processo é uma série de ações/execuções que geram um resultado específico e pré-

determinado (VARGAS, 2009). De acordo com o autor, processos podem ser classificados de
duas formas distintas:
 Processos da gerência de projetos: englobam desde a fase de descrição, a parte

de organização e demais etapas que envolvam o projeto até a sua conclusão. Pode-
se afirmar que controlam o ciclo de vida do projeto.
 Processos orientados ao produto: voltados para a especificação e criação de
produtos. São específicos de cada produto, mas são definidos pelo ciclo de vida do
projeto, variando de acordo com a área de aplicação.
• Cada grupo de processo é formado por um ou mais processos (PMI 2008), envoltos nas
seguintes atribuições:
 Os processos do grupo de iniciação reconhecem que uma fase ou projeto devem

ser iniciados assumindo o compromisso de iniciá-los.
 Os processos do grupo de planejamento são responsáveis identificar, selecionar e
adotar as melhores práticas para alcance dos objetivos, cujo projeto se comprometeu
a atender.
 Os processos do grupo de execução são responsáveis por coordenar pessoas e
outros recursos para colocar em prática o plano do projeto.
 Os processos do grupo de controle são responsáveis por assegurar o cumprimento
dos objetivos estabelecidos, bem como suas ações corretivas.
 E finalmente, os processos do grupo de encerramento são responsáveis por formalizar
a aceitação entrega do projeto ou de suas etapas entregues de forma sequenciada.
G
E
R • O ciclo de vida de um projeto serve para definir os marcos de início e fim do mesmo. Quando
Ê
uma organização identifica uma oportunidade ou necessidade, esta solicita um estudo de
N
C viabilidade para definir se um projeto será criado para suprir o apontamento. Neste caso, o
I ciclo de vida determina se o estudo de viabilidade será o início do projeto ou se o mesmo será
A
tratado como um projeto que antecede algo maior (PMI 2008).
D • Cada projeto apresenta diferentes grupos stakeholders que deverão ser mapeados pela
E
equipe do projeto a fim de determinar as expectativas e necessidades de cada parte. Além
P deste mapeamento cabe avaliar seus interesses e forma de atuação no projeto: se a pessoa
R
O é favorável ou contrária ao projeto, por exemplo. Desta forma, faz-se o nivelamento das
J partes. Não é um processo fácil, mas caso esta etapa não seja cumprida, pode-se aumentar
E
T significativamente os riscos do projeto.
O • A alocação de pessoas em projetos de software ainda é um desafio que exige competências
S
específicas do gerente de projeto no intuito de mapear as competências técnicas de cada

colaborador para maior otimização da matriz de responsabilidades do cronograma. Alocar a
pessoa certa na atividade certa faz toda a diferença num setor onde cronogramas apertados
ou irracionais são a principal fonte de riscos dos projetos desta natureza
• O sucesso de um projeto está diretamente relacionado às habilidades de seu gerente. Além de
dominar as ferramentas e técnicas de gerência de projetos, ele deve também ter conhecimento
avançado em técnicas de liderança, motivação, gestão de pessoas, de maneira geral. Ele deve
ser um facilitador no projeto e não um obstáculo (PHILLIPS, 2003).
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 No seu entendimento, o que são os stakeholders?
2 Quais são os três tipos mais comuns de estrutura organizacional?
3 Qual é a estrutura básica de uma equipe de desenvolvimento de software?
4 Os principais grupos de processos ou grupos de processos centrais são:

a) ( ) Iniciação, planejamento, e execução.
b) ( ) Planejamento, controle, e execução.
c) ( ) Iniciação, controle e encerramento.
d) ( ) Planejamento, execução e encerramento.
5 O grupo de processo de controle tem por objetivo:

a) ( ) Garantir o sucesso do projeto.
b) ( ) Assegurar que os objetivos do projeto estão sendo cumpridos.
c) ( ) Controlar o “Modus Operandi” do gerente de projeto.
d) ( ) Garantir a qualidade dos produtos entregues ao cliente.
6 Sobre grupos de processos é correto afirmar que:

a) ( ) Se ligam pelos resultados que produzem.
b) ( ) Se sobrepõem uns aos outros.
c) ( ) O encerramento de uma fase é subsídio para outra.
G d) ( ) Todas as anteriores.
E
R
Ê 7 As orientações contidas no PMBOK representam as boas práticas geralmente aceitas
N
pela comunidade de gerentes de projetos. Assim:
C
I a) ( ) Devem ser aplicadas uniformemente em todos os projetos.
A
b) ( ) Devem servir de base para o gerenciamento de projetos sem, contudo, substituir
D o julgamento do gerente no ambiente em que o projeto está sendo desenvolvido.
E c) ( ) Como processo derivado de método científico, deve ser obedecido sempre que
P possível com vista a alcançar os melhores resultados para o projeto e a organização.
R d) ( ) Constituem os conhecimentos necessários e suficientes para que o gerente possa
O
J alcançar a certificação como profissional de gerenciamento de projetos (PMP).
E
T
O
S
UNIDADE 1
TÓPICO 3
PROJETO DE DESENVOLVIMENTO DE
SOFTWARE
1 INTRODUÇÃO
Não é novidade que todas as operações organizacionais dependem de algum tipo de

software para alcançar maior eficiência. Com isso, nas últimas duas décadas percebe-se uma
busca desesperada no intuito de encontrar um modelo de desenvolvimento de aplicativos que
proporcionem às empresas desenvolvedoras uma customização que resulte em produtividade
e qualidade, e que seja independente da cultura, estrutura organizacional, tecnologia ou tipo
de negócios envolvido no desenvolvimento do sistema (PRADO, 2000).
Por trás desta busca existem objetivos difíceis de serem alcançados:
• Tornar o processo de desenvolvimento lucrativo.

• Desenvolver um software com menos retrabalho.
• Garantir a satisfação e fidelização do cliente.
Quando decide por comprar um software customizado (desenvolvido especialmente G

para as suas necessidades), o cliente, de certa forma quer saber o custo do desenvolvimento E
R
e ter garantias de que a empresa contratada desenvolverá o projeto com foco a atender as Ê
suas expectativas e necessidades, e que será entregue com qualidade, no prazo definido e N
C
custo pré-acertado entre as partes. Para que o desenvolvimento do aplicativo não ocorra na I
base do “achismo”, é necessário definir o universo de trabalho (escopo do sistema), efetuar A
o levantamento de requisitos, orçar o custo com base no escopo, pré-definir a equipe de
D
desenvolvimento, e listar os principais riscos envolvidos neste projeto (PRADO, 2000). E
P
Estas informações geralmente são registradas no que se chama de Plano do Projeto, R
que deverá ser revisado durante o ciclo de vida do projeto, a fim de evitar que se desvie dos O
J
requisitos de desenvolvimento planejados. E
T
O
S
Em função destas necessidades, a área de gestão de projetos de software (GPS)

fortaleceu-se ao longo dos anos em razão da necessidade de garantir a qualidade e o sucesso
dos projetos de software. Integrando conceitos de Administração aos elementos técnicos e
tecnologias específicas da Gestão de Software, esta área pode ser considerada multidisciplinar,
pois agrega conceitos organizacionais e técnicos ao mesmo tempo (PHILLIPS, 2003).
O processo de desenvolvimento de software é caracterizado por uma série de atividades

tanto técnicas quanto organizacionais que se utiliza de ferramentas e metodologias para definir,
especificar, controlar e executas estas atividades dês customização de software. Tudo o que é
definido como atividade técnica envolve desde a metodologia adotada no desenvolvimento até
a infraestrutura do ambiente de TI. As atividades organizacionais por sua vez englobam tudo o
que a organização precisa para desenvolver o projeto, incluindo todas as aquisições feitas para
o projeto, bem como o cuidado com as pessoas responsáveis por executá-lo (VARGAS, 2009).
A integração destes elementos no cenário específico de desenvolvimento de software

não é uma tarefa fácil, exigindo dos gestores um esforço na coordenação de pessoas,
tecnologias e atividades consideradas complexas.
A Gestão de Projetos de Software surgiu da observação do gerenciamento de outras

áreas de negócios, cujos modelos e metodologias foram melhoradas ou adaptadas para dar
suporte ao setor de Tecnologia da Informação. Com isso a GPS difere das outras áreas, pois
possui características que dificultam a gestão, como a rápida mudança tecnológica, perfil
profissional atípico e introvertido, qualificação específica com forte formação técnica dos
profissionais envolvidos, e dificuldades de mensurar e visualizar o software como produto final
(PRADO, 2000).
Como forma de redução de riscos e para suavizar o impacto dos fatores citados acima,
torna-se necessária a adoção de modelos e técnicas específicas para gerenciar projetos de
software sendo que uma série de modelos de gestão de projetos e serviços de software foi
G
elaborada nos últimos anos.
E
R
Ê
Alguns desses modelos são originais e outros são derivados e/ou evoluídos de outros
N
C modelos. Geralmente, as empresas de software adotam a metodologia do guia de boas
I práticas Project Management Knowledge (PMBOK), definidas pelo PMI, conforme já comentado
A
anteriormente.
D
E
É um grande desafio para os profissionais envolvidos no desenvolvimento de software
P gerenciar escopo, requisitos, estimativas, desenho das interfaces, qualidade, desempenho,
R
O usabilidade, riscos e ergonomia, visando atender às necessidades das partes interessadas
J (ROCHA et al., 2001).
E
T
O Para reduzir este desgaste há uma série de ferramentas disponíveis atualmente para
S
gerenciar os projetos de software com foco para as atividades desenvolvidas por (programadores,
analistas, projetistas, gerentes). Estas ferramentas, na sua maioria, são usadas em atividades
específicas – gerenciamento de tarefas, gerência de documentos ou orçamentos que podem
ser feitos por análise de pontos de função, número de linhas de código ou outras métricas.
Estas ferramentas auxiliam em situações específicas, não sendo utilizadas em todas as etapas
do desenvolvimento.
Projetos de software têm como característica principal a sua complexidade, muitas vezes
motivada por falhas na comunicação entre desenvolvedores e clientes (PRADO, 2000). Além
disso, suas etapas são mais específicas, determinadas pelo ciclo de vida – roteiro de trabalho
composto pelas macroatividades do projeto – escolhido para o desenvolvimento do software.
TABELA 1 – RELACIONA AS ETAPAS DO PROJETO COM AS ETAPAS DO CICLO

DE VIDA DO SOFTWARE
FONTE: A autora
2 AS DIFICULDADES DO GERENCIAMENTO DE PROJETOS DE SOFTWARE G

E
R
Ê
A ausência de práticas administrativas no desenvolvimento de software é a N
principal causa de sérios problemas enfrentados pelas organizações, tais C
como: atrasos em cronogramas, custo maior do que o esperado e presença I
de defeitos, ocasionando uma série de inconveniências para os usuários e A
enorme perda de tempo e de recursos. (HUMPHREY,1989, p.75).
D
E
Décadas depois, vários pesquisadores confirmam o apontamento do autor, destacado P

R
acima. Para (WEBER, 1999), a cultura de planejamento utilizada pelas organizações de
O
desenvolvimento de software é superficial. Complementando, (PRADO, 2000) afirma que a J
maioria dos projetos de softwares é desenvolvida sem um planejamento de como a modelagem E
T
inicial pode ser visualizada em forma de produto. Na visão de (VARGAS, 1998), os gerentes O
não têm o hábito de estimar, e quando o fazem, costumam se basear em estimativas anteriores S
mesmo sabendo que não são seguras e que estas práticas colocam o projeto em risco,
Gerenciar um projeto de software requer maior atenção do que outros tipos de projetos,
pois é uma atividade inovativa, criativa e intelectual que envolve muitas variáveis internas e
externas ao processo de desenvolvimento. Projetos de software tendem a ser mais difíceis de
gerenciar porque sofrem muitas alterações de escopo durante o desenvolvimento do projeto, o
que causa impacto direto na redistribuição de tarefas, readaptação de cronogramas, realocação
das pessoas da equipe, nova negociação com o cliente e assim por diante. Por isso se diz
que os projetos de software adaptam-se ao ambiente, pois dependem da disponibilidade de
recursos, tecnologias e pessoas da equipe (VARGAS, 2009).
Outros fatores também contribuem para uma maior dificuldade no gerenciamento de

projetos de software: inexistência processos definidos, limitação de recursos financeiros e
humanos, crescimento ocorrido por demanda e falta de experiência administrativa por parte
dos gerentes e diretores de forma geral.
O gerenciamento não deve ser praticado de maneira amadora, mas deve ser baseado
na aplicação e uso de ferramentas e técnicas, onde se destacam as recomendações do PMI.
Com o frequente uso de metodologias, a cultura de gestão de projetos pode ser mais facilmente
adotada e aceita tornando os projetos mais lucrativos e gerando maior valor ao cliente final
(PHILLIPS, 2003).
Gerenciar projetos com eficiência constitui-se não apenas um grande desafio dos dias
atuais, mas é o fator crítico para o sucesso e para a sobrevivência das empresas. Gerenciar
projetos com eficiência requer um esforço de conscientização das empresas em adotar
metodologias de gerenciamento de projetos e treinar sua equipe e principalmente os seus
gerentes dos projetos. Estas organizações, se possível, devem manter e suportar uma única
metodologia para gerenciamento de projetos (VARGAS, 2009).
G
Para contribuir com este cenário, um gerente de projetos deve ser capacitado para
E
R entender as necessidades daquilo que será desenvolvido. Deve ser treinado em uma
Ê
metodologia de desenvolvimento de projetos para conseguir tirar o melhor proveito dela.
N
C Deve estar no projeto desde o início sendo que um projeto de software é iniciado sempre que
I os requisitos tiverem sido modelados e especificados, correspondendo à primeira das três
A
atividades técnicas (projeto – implementação – testes) (KEELLING, 2002).
D
E
P
R
O
J
E
T
O
S
3 A FASE DE PROJETO
Esta fase tem como objetivo alinhar a tecnologia com os requisitos do usuário
independentemente do paradigma adotado, o projeto deve produzir:
• Projeto da Arquitetura do Software: definir os grandes componentes estruturais do
software e seus relacionamentos.
• Projeto de Dados: projetar a estrutura dos dados necessária para implementar o software.
• Projeto de Interfaces: descrever como o software deverá se comunicar dentro dele
mesmo (interfaces internas), com outros sistemas (interfaces externas) e com essas
que o utilizam (interface com o usuário).
• Projeto Procedimental: refinar e detalhar a descrição procedimental dos componentes
estruturais da arquitetura do software.
O projeto de software é um processo iterativo. Inicialmente, o projeto é representado

em um nível alto de abstração. À medida que iterações ocorrem, os refinamentos conduzem
a representações de menores níveis de abstração.
Uma especificação de projeto deve:

• Contemplar todos os requisitos explícitos contidos no modelo de análise e todos os
requisitos implícitos desejados pelo cliente.
• Ser um guia legível e compreensível para aqueles que irão codificar, testar e manter o
software.
• Prover um quadro completo do software, tratando aspectos funcionais, comportamentais
e de dados, segundo uma perspectiva de implementação.
FONTE: Disponível em: <http://victorvrb.xpg.uol.com.br/1_Projeto%20Software.pdf>. Acesso em: 30

abr. 2015.
G
E
R
Ê
N
4 CONCEITOS BÁSICOS DE PROJETO DE SOFTWARE C
I
A
• Níveis de Abstração: o projeto deve considerar vários níveis de abstração, começando D

E
com em um nível mais alto, próximo da fase de análise. À medida que avançamos no
processo de projeto, o nível de abstração deve ser reduzido. P
R
• Refinamento: processo de elaboração, no qual o projeto vai sendo conduzido de níveis
O
mais altos para níveis mais baixos de abstração. J
• Modularidade: um projeto deve estruturar um sistema como módulos/componentes E
T
coesos e fracamente acoplados. O
S
• Ocultação de informações: módulos / componentes são caracterizados pelas

decisões de projeto que cada um deles esconde dos demais. Módulos devem ser
projetados e especificados de modo que as informações neles contidas (dados e alguns
procedimentos) sejam inacessíveis a outros módulos.
• Independência Funcional: módulos devem cumprir uma função bem estabelecida,
minimizando interações com outros módulos. Esta característica é resultado direto da
soma das demais características e pode ser medida usando dois critérios de qualidade:
coesão e acoplamento.

abr. 2015.
5 PRINCÍPIOS DE PROJETO
Em geral, um modelo de projeto deve:
• começar representando a totalidade da coisa a ser construída;

• refinar para prover orientação para a construção de cada detalhe;
• prover diferentes visões da coisa.
Mais especificamente, o projeto de software deve:
• considerar abordagens alternativas com base nos requisitos do problema, recursos

disponíveis e conceitos de projeto;
• ser rastreável ao modelo de análise;
• não “reinventar a roda”, isto é, reutilizar componentes;
G • minimizar a distância conceitual e semântica entre o software e o mundo real;
E • exibir uniformidade (estilo) e integração (interfaces entre componentes);
R
Ê • ser estruturado para acomodar mudanças (alterabilidade);
N • acomodar circunstâncias não usuais e, se necessário abortar o processamento, fazê-lo
C
I de modo elegante;
A • apresentar nível de abstração superior ao código fonte. Projeto não é codificação;
D • ser passível de avaliação da qualidade;

E • ser revisado para minimizar erros semânticos.
P
R
abr. 2015.
O
J
E
T
O
S
6 QUALIDADE DO PROJETO DE SOFTWARE
Conforme citado anteriormente, a fase de projeto é responsável por incorporar requisitos

tecnológicos aos requisitos essenciais. Assim, o projetista deverá estar atento aos critérios
de qualidade que o sistema terá que atender. O modelo de qualidade definido na norma ISO/
IEC9126-1, utilizado como referência para a avaliação de produtos de software, define seis
características de qualidade, desdobradas em subcaracterísticas (ROCHA et al., 2001):
• Funcionalidade: refere-se à existência de um conjunto de funções que satisfaz às

necessidades explícitas e implícitas e suas propriedades específicas. Tem como
subcaracterísticas: adequação, acurácia, interoperabilidade, segurança de acesso e
conformidade.
• Confiabilidade: diz respeito à capacidade do software manter seu nível de desempenho,
sob condições estabelecidas, por um período de tempo. Tem como subcaracterísticas:
maturidade, tolerância a falhas, recuperabilidade e conformidade.
• Usabilidade: refere-se ao esforço necessário para se utilizar um produto de software,
bem como o julgamento individual de tal uso por um conjunto de usuários. Tem como
subcaracterísticas: inteligibilidade, apreensibilidade, operacionalidade, atratividade e
conformidade.
• Eficiência: diz respeito ao relacionamento entre o nível de desempenho do software
e a quantidade de recursos utilizados sob condições estabelecidas. Tem como
subcaracterísticas: comportamento em relação ao tempo, comportamento em relação
aos recursos e conformidade.
• Manutenibilidade: concerne ao esforço necessário para se fazer modificações no
software. Tem como subcaracterísticas: analisabilidade, modificabilidade, estabilidade,
testabilidade e conformidade.
• Portabilidade: refere-se à capacidade do software ser transferido de um ambiente para G
E
outro. Tem como subcaracterísticas: adaptabilidade, capacidade para ser instalado, R
coexistência, capacidade para substituir e conformidade. Ê
N
C
Xavier et al. (1995) utilizam outra classificação, indicando os seguintes aspectos a I
serem considerados: A
D
• Completeza: diz respeito ao atendimento dos requisitos do cliente. E
• Desempenho: refere-se ao uso otimizado dos recursos computacionais disponíveis P

(hardware, software e peopleware). Fatores que afetam o desempenho incluem: R
O
1. Projeto físico de arquivos: deve minimizar o tempo de acesso a disco. J
2. Reorganização de arquivos. E
T
3. Reorganização de índices. O
S
4. Limpeza de arquivos.
5. Utilização da computação cliente-servidor: front-end local no servidor (interface com
o usuário) e back-end no servidor (processamento e acesso a dados).
• Segurança contra acessos indevidos: é importante projetar:
1. Procedimentos de segurança, tais como controle de acesso (matriz classe de usuário

x operações), criptografia e visões em bancos de dados;
2. Mecanismos de detecção de violações, tal como monitoração e arquivos de log.
• Facilidade de uso: diz respeito ao projeto de interface com o usuário.

• Confiabilidade: refere-se à preservação da disponibilidade do sistema e da integridade
das informações armazenadas. No tocante a este critério de qualidade, deve-se ficar atento a:
• Restrições de integridade: informações a serem armazenadas devem ser filtradas

a partir das regras estabelecidas. Este filtro pode se dar via programa ou Sistema
Gerenciador de Banco de Dados (SGBD).
• Controle de Concorrência: bloqueio.
• Recuperação de Falhas: prever possíveis falhas e definir sua forma de recuperação.
Por exemplo, restaurar um banco de dados a um estado reconhecidamente correto
após a ocorrência de uma falha.
• Tipos de falhas:
- Humana: digitação ou operação do sistema;
- Transação: overflow, erro em tempo de execução, divisão por zero, ...
- de Sistema: problemas no hardware, falta de energia, ...
- de Comunicação: queda de linha, ...
- de Software: erros de desenvolvimento.
FONTE: Adaptado de: <http://victorvrb.xpg.uol.com.br/1_Projeto%20Software.pdf>. Acesso

G em: 4 maio 2015.
E
R
Ê
N
C
I 8 TECNOLOGIA IMPERFEITA E REQUISITOS TECNOLÓGICOS
A
D
E Em função das limitações da tecnologia, devemos tomar decisões que adicionam os
P requisitos tecnológicos à essência do sistema.
R
O
J Limitações da tecnologia
E
T
O
• o custo;
S
• a capacidade de armazenamento;
• a velocidade de processamento;
• a aptidão dos processadores: processador matemático, para comunicação entre
processadores etc.;
• a tecnologia é passível de falha.
Impactos da tecnologia imperfeita
• o uso de processadores diferentes / distribuição / comunicação;

• a redundância: repetição de atividades e dados; inclusão de dados derivados (por
exemplo, totalizadores);
• novas atividades e funções acrescidas em função da imperfeição da tecnologia.
FONTE: Adaptado de: <http://victorvrb.xpg.uol.com.br/1_Projeto%20Software.pdf>. Acesso em: 4

maio 2015.
Levantamento dos requisitos tecnológicos junto aos usuários
• localização geográfica de usuários / transporte de dados;

• problemas operacionais nas atividades dos usuários;
• definição do ambiente de hardware e software de produção:
• frequência de disparo das atividades;
• volume de dados (inicial, estimativa de crescimento, política de esvaziamento);
• tempo de resposta;
• restrições técnicas (novo ambiente?);
• restrições ambientais (temperatura etc.);
• Requisitos de confiabilidade (tempo mínimo entre falhas);
• Restrições de segurança (classes de usuários e acesso);
• Interface com o usuário.
G
FONTE: Disponível em: <http://www.inf.ufes.br/~falbo/download/aulas/projeto/2003-1/Apostila>. E
Acesso em: 4 maio 2015. R
Ê
N
LEITURA COMPLEMENTAR C
I
Certificação ou especialização acadêmica? A
D
Este artigo escrito por Flávia Yuri e retirado da revista eletrônica Computerworld de 15 de E
maio de 2008 e pode ser consultado em: <http://computerworld.uol.com.br/carreira/2008/05/15/ P

certificacao-ou-especializacao-academica/> R
O
J
A certificação pode determinar quanto o profissional de TI será valorizado, mas não se E
T
engane: o diploma universitário é passaporte obrigatório para bons empregos. Historicamente,
O
S
a formação de parte significativa dos profissionais de TI sempre beirou a informalidade. O

ineditismo de algumas tecnologias e a proliferação de plataformas abertas, com desenvolvimento
comunitário, sempre contribuíram para isso.
Por outro lado, na última década pipocaram novas faculdades com cursos para diferentes
segmentos, do tradicional processamento de dados até jogos digitais. O MEC reconhece doze
diferentes áreas de conhecimento em cursos superiores de tecnologia. Entre 2001 e 2003, 544
novas instituições de curso superior foram autorizadas a funcionar, quase um estabelecimento
por dia.
No último senso sobre o assunto, o número de novas faculdades tinha caído de 18,5%,
em 2004, para 7,55% em 2005. Ainda assim, sobram vagas em cursos superiores. No meio do
caminho entre informalidade e diploma acadêmico estão as certificações técnicas, cada vez
mais afinadas com as demandas de mercado e valorizadas pelas empresas. Nesse cenário,
em que deve investir o profissional de TI? Qual é o perfil valorizado pelas empresas?
O que o mercado quer?
Experiência, certificação e diploma. Esse é o mantra entoado por executivos de

empresas de TI, CIOs e diretores de RH. Mas, atenção, se a graduação aparece em terceiro
lugar na lista do que é mais valorizado num processo de seleção, não significa que ela não seja
importante. Pelo contrário. É unanimidade no mercado que hoje o diploma de graduação é tão
básico quanto o domínio de inglês. Experiência e certificações são os critérios de desempate.
“Hoje, pelo menos 90% da nossa equipe tem curso superior, o que já se tornou padrão. O
diferencial éter uma certificação além do diploma”, diz Marcus Stefanini, presidente e fundador
da Stefanini, empresa de serviços de TI e desenvolvimento de programas que emprega cinco
mil funcionários no Brasil e em outros quatorze países.
O mesmo raciocínio faz Maria de Fátima Porcaro, diretora do departamento de

G
informática e desenvolvimento da ALESP – Assembleia Legislativa de São Paulo. Por ser um
E
R órgão público, o ingresso para a TI acontece por meio de concurso e ter diploma de graduação
Ê
é obrigatório.
N
C
I “Se eu precisasse e pudesse escolher, daria preferência a um profissional com
A
certificação”, diz ela. “O principal problema com o qual me deparo aqui na assembleia é que
D as faculdades não conseguem transmitir a bagagem técnica necessária para o mercado de
E
trabalho”, afirma ela.
P
R
O A reclamação sobre o fato de os cursos de graduação não estarem estruturados para
J acompanhar a velocidade que a área de TI exige é recorrente. Mas nem por isso eles são
E
T
menos importantes, principalmente quando se tratam de multinacionais. Jair Pianucci, diretor
O de recursos humanos da HP, ressalta um dos pontos que fazem do diploma formal algo
S
indispensável.
“Mais do que a formação técnica, que pode ser adquirida com certificações e treinamentos
dentro da própria empresa, o curso superior é importante porque dá para o profissional uma
formação extra do ponto de vista de noções de negócios, de economia e mesmo de língua
portuguesa. Infelizmente, vivemos em um país em que é comum as pessoas não receberem
a bagagem mínima necessária até o ensino médio”, afirma Pianucci.
Opções de certificação em gerência de projetos
A importância de ter uma certificação na área de gerenciamento de projetos é uma

discussão frequente entre profissionais do setor. Ela não garante um bom emprego, aumento
salarial ou promoção, mas funciona como uma comprovação de que o profissional tem
habilidades técnicas para atuar como gerente de projetos.
“A certificação auxilia na tomada de decisão de quem está contratando, mas não garante
a competência do profissional”, diz Keiji Sakai, Head of IT do JP Morgan. Quem tem interesse
em obter uma certificação deve ficar atento às opções existentes no mercado. Entidades como
PMI (Project Management Institute), ABGP (Associação Brasileira de Gestão de Projetos) e a
Prince2 oferecem diversos tipos e níveis de certificação. A seguir, você confere informações
sobre custos, prazos e reconhecimento de cada uma delas.
PMI / PMP: O Project Management Institute oferece a PMP (Project Management

Professional), mais reconhecida e tradicional certificação em gerenciamento de projetos em
todo o mundo. Há mais de 5,7 mil profissionais PMP no Brasil, segundo dados de março do
capítulo de São Paulo do PMI.
Para obter essa certificação, é preciso ter 4.500 horas de experiência e 36 meses em
gerenciamento de projetos. Profissionais sem diploma de nível superior devem contar com
7.500horas e 60 meses de experiência na área. O PMI também exige 35 horas de treinamento
G
na área. A base para a prova é o PMBOK, compêndio das melhores práticas de gerenciamento E
de projetos, mas existem treinamentos específicos para o exame, assim como outros livros R
Ê
que podem servir de apoio.
N
C
Uma vez certificado, a cada três anos o PMP precisa comprovar, junto ao PMI, que I
A
continua se desenvolvendo na área. Para isso, no período, ele deve somar 60 PDUs, que
funcionam como créditos que ele acumula ao realizar atividades como palestras, artigos, cursos D
E
ou participação em projetos.
P
R
Em São Paulo, associados do PMI pagam 405 dólares para fazer a prova. Quem não O
é associado desembolsa 555 dólares. Informações sobre cursos, material de apoio e como J
E
marcar aprova, estão disponíveis no site do PMI. T
O
S
CAPM: Para profissionais que não têm ou acumulam pouca experiência em liderar um
projeto, a indicação do PMI é a certificação CAPM (Certified Associate in Project Management).
O exame custa 225 dólares para membros do PMI e 300 para quem não é associado. Há
21CAPMs no país.
Para se submeter a esta prova, é preciso acumular 23 horas de treinamento em

gerenciamento de projetos ou no mínimo 1.500 horas como membro de equipe de projeto. Os
candidatos precisam ter pelo menos segundo grau completo.
Esta certificação tem validade de 5 anos e ao final deste período, o profissional pode
se submeter a uma nova prova ou optar pela certificação PMP, caso possa comprovar a
experiência exigida pelo PMI.
PgMP: A Project Management Professional é voltada para gerentes de programa, ou

seja, para profissionais que gerenciam vários projetos de forma coordenada com um objetivo
comum.
Quem tem curso superior precisa ter, nos últimos 15 anos, quatro anos de experiência
em gerenciamento de projetos e outros quatro em gerenciamento de programas. Se o candidato
não tem graduação, deve ter quatro anos de experiência em gerenciamento de projetos e outros
sete anos em gerenciamento de programas.
O profissional é avaliado em três etapas. Durante o processo de inscrição, será

considerada sua experiência profissional. Se for aprovado, ele passará para a segunda etapa,
com uma prova de múltipla escolha sobre questões ligadas à rotina de gerenciamento de
projetos.
A terceira fase é um exame 360 graus para avaliar habilidades em tarefas ligadas ao
gerenciamento de programas. O candidato também deverá preencher uma autoavaliação e
G
indicar 12 pessoas como referência para avaliação.
E
R
Ê
O processo completo custa 1.500 dólares, para associados PMI, e 1.800 dólares para
N
C quem não é membro do instituto. Segundo o PMI, há apenas dois PgMPs no Brasil.
I PMI-SP: A certificação PMI Scheduling Professional foi lançada recentemente. Ela é
A
voltada para profissionais que respondem pelo cronograma, pelo planejamento de um projeto.
D O exame custa 520 dólares para associados e 670 para não-associados do PMI.
E
P Prince 2: Mais conhecida na Europa, especialmente no Reino Unido, a Prince2 ainda

R
O está dando os primeiros passos na América do Sul. Com proposta totalmente diferente das
J certificações do PMI, a Prince 2 é uma metodologia e tem como objetivo estabelecer um passo
E
T
a passo para gerenciar projetos. Ela tem três níveis de certificação: Foundation, Practicionere
O Instrutor Certificado.
S
Os dois primeiros não exigem qualquer tipo de experiência prévia e são cumpridos dentro
de um mesmo treinamento de 40 horas, realizado em uma semana. A prova do Foundation
acontece na quarta-feira e a do Practitioner, na sexta.
Para passar pelo terceiro nível, o profissional deve comprovar horas de experiência e
é auditado pelo OGC (Office of Government Commerce). O exame, neste caso, só pode ser
aplicado por um instrutor Prince2 – há apenas dois no Brasil, segundo a Elumini, consultoria
oficial dessa metodologia por aqui, que está estruturando um treinamento no país.
O custo estimado do treinamento das duas primeiras etapas é de 7 mil reais por aluno, de
acordo com a Elumini. É possível comprar o manual do Prince2, em inglês, pela Internet e fazer
as provas na Inglaterra. O valor dos dois exames é 555 libras, aproximadamente 1.760 reais.
No site da APMG, órgão responsável por manter a padronização no treinamento e na

certificação da Prince2, há a informação de que é possível fazer testes fora do Reino Unido, no
British Council. No entanto, a unidade do Brasil informou que não tem a estrutura necessária
para aplicar o exame.
IPMA: A certificação da International Project Management Association, representada no

país pela ABGP (Associação Brasileira de Gestão de Projetos), tem quatro níveis: a (diretor de
projetos associado), b (gerente de projetos sênior certificado), c (gerente de projetos certificado),
d (associado em gerenciamento de projetos certificado).
A estimativa é que existam cerca de 70 profissionais certificados no Brasil, em todos

os níveis. A IPMA pretende avaliar não apenas o conhecimento dos profissionais sobre as
melhores práticas, mas também suas competências.
As certificações c e d são as únicas que exigem a realização de exames. No d, não é
preciso ter qualquer experiência prévia e a avaliação se dá exclusivamente por meio da prova.
G
Jáno c, é necessário contar com três anos de experiência e o processo de avaliação envolve E
entrevista, exame e avaliação do currículo do candidato. R
Ê
N
Já o nível b exige cinco anos de experiência em gerenciamento de projetos, dos quais C
três como gerentes de projetos complexos. O candidato também passa por entrevista e avaliação I
A
curricular, além de ter que apresentar um relatório de projeto no formato de dissertação.
D
E
O nível a ainda não é oferecido pela ABGP, pois a associação terá que trazer profissionais
do exterior para certificar pessoas no Brasil. Os requisitos de certificação, no entanto, são P
R
mesmos do nível b. A exceção é que o tempo de experiência na área sobe para 10anos, metade O
como diretor de programas. J
E
T
Os custos das certificações para não-sócios da ABGP giram em torno de 650 reais, no O
S
nível d; 1.400 reais, no nível c; e 3.450 reais no nível b. Sócios têm desconto de, em média,
20%sobre esses valores.
Para obter o título, candidatos que não-graduados devem ter 5 mil horas em
desenvolvimento de cronogramas dentro dos últimos 5 anos e 40 horas de educação formal.
Profissionais com curso superior precisam de 3.500 horas em desenvolvimento de cronogramas
nos últimos 5 anos e 30 horas de educação formal.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 3
Nesta unidade, você aprendeu as principais características dos projetos:
• São temporários: tem início e fim definidos.

• São planejados, controlados e executados.
• São únicos: entregam produtos ou serviços exclusivos.
• São desenvolvidos em etapas e são elaborados progressivamente.
• São realizados por pessoas.
• Dispõem de recursos limitados.
Além disso, você conheceu os conceitos de Gestão de Projetos, o qual é um processo que
coordena esforços e recursos, gerenciando os demais processos de execução na realização
do trabalho definido.
Você estudou sobre os stakeholders, que são todas as partes interessadas no andamento e
finalização de um projeto. Aprendeu que os projetos são desenvolvidos por equipes e atendem
a desejos e necessidades de uma ou mais partes interessadas.
Foi apresentada a você a metodologia proposta pelo PMI através do guia PMBOK que será
apresentado em detalhes nas próximas unidades. Você conheceu os grupos de processos e
as áreas de conhecimento, bem como a estrutura do PMO, escritório de projetos.
Foi destacado que a estrutura organizacional (funcional, matricial ou projetizada) define a forma
como os projetos serão gerenciados internamente.
G
E
Você conheceu a estrutura básica de uma equipe de desenvolvimento de software, bem como R
as dificuldades encontradas no gerenciamento deste tipo de projeto. Ê
N
C
Aprendeu a diferença entre projeto, programa e portfólio. I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Cite algumas atividades do processo de desenvolvimento de software.
2 Quais são os principais obstáculos do gerenciamento de projetos de software?
3 Cite algumas as características do modelo de qualidade definido na norma ISO/

IEC9126-1, utilizado como referência para a avaliação de produtos de software.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
IAÇÃO
AVAL
Prezado(a) acadêmico(a), agora que chegamos ao final da

Unidade 2, você deverá fazer a Avaliação referente a esta unidade.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 2
PROCESSOS DE GESTÃO DE PROJETOS
A partir desta unidade você será capaz de:

 compreender a gestão de integração em projetos;
 entender os processos da gestão de escopo em projetos;
 entender o papel da gestão do tempo em projetos;
 conhecer os principais aspectos da gestão de custos em projetos.
PLANO DE ESTUDOS
Esta unidade está dividida em quatro tópicos, sendo que ao

final de cada um deles, você encontrará atividades que lhe auxiliarão
na apropriação dos conhecimentos.
TÓPICO 1 – INTEGRAÇÃO
TÓPICO 2 – ESCOPO
TÓPICO 3 – TEMPO
TÓPICO 4 – CUSTO G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 2
TÓPICO 1
INTEGRAÇÃO
1 INTRODUÇÃO
A tecnologia da informação (TI) são todos os recursos computacionais utilizados pelas

organizações. É, atualmente, o maior facilitador dos processos organizacionais executados
pelas empresas, sejam elas públicas ou privadas.
Economicamente falando, agrupa-se o setor no termo “economia digital”, ou economia

da internet, em que indivíduos e organizações se conectam através da rede mundial de
computadores, abrindo novos nichos de mercado para os mais variados segmentos de negócios.
O ambiente computacional, de forma geral, sofre mudanças rápidas e imprevisíveis,

exigindo tanto das empresas que usam a TI quanto daquelas que a desenvolvem, rápidas
respostas em relação aos cenários não previstos, exigindo um maior alinhamento entre a área
de TI e as estratégias organizacionais. Porém, na maioria das vezes, as soluções tecnológicas
não são vendidas na forma de pacotes, sendo necessário desenvolver demandas específicas.
Neste caso, são criados projetos para o desenvolvimento customizado, possibilitando com isso G
maior visibilidade para a gestão de projetos dentro das organizações. E
R
Ê
Estes projetos de TI são atípicos e diferem bastante da maioria dos projetos N
C
desenvolvidos pelas empresas, pois são altamente complexos e muito suscetíveis a falhas – I
sua implementação é difícil e consome bastante tempo e recursos financeiros e envolvem um A
alto grau de inovação. A gerência em si é outro complicador para os projetos tecnológicos, uma
D
vez que tendem a subestimar a complexidade e os recursos envolvidos no desenvolvimento E
dos sistemas.
P
R
Os projetos de TI caracterizam-se basicamente por: exigências abstratas, dificuldade de O
J
visualização, percepção excessiva de flexibilidade, complexidade oculta, incerteza, tendência E
à falha do software, objetivo de mudar as características dos processos existentes no negócio, T
O
S
tendência dos projetos de serem mal definidos. Como consequência podemos citar: expectativas
irreais, projetos audaciosos, pedidos frequentes de mudanças, entregas fora do prazo, gastos
acima do orçamento, dificuldade na definição de especificações, problemas na implementação
do sistema específico e detecção tardia de problemas.
Pela natureza complexa, projetos de TI geram um número elevado de riscos, exigindo

gerenciamento cauteloso, inibindo muitas vezes a criatividade dos profissionais envolvidos.
Dessa forma, com a inovação tecnológica de um lado e as exigências gerenciais do

outro, seguidas por cronogramas apertados e gerenciamento ineficiente do projeto da equipe
e das mudanças, os resultados acabam sendo a falta de controle, a insegurança e a obtenção
de sistemas inadequados e entregues fora do prazo.
Mudanças na definição inicial, geralmente, não são fáceis de serem gerenciadas e

controladas. O desenvolvimento de um novo software traz situações desconhecidas em
termos de tecnologia e informações para todos os integrantes do processo, seja em relação
aos usuários ou a equipe de desenvolvimento, afetando de modo direto todo o ambiente que
vai ser operacionalizado.
As mudanças têm impacto direto no orçamento, sendo um dos motivos de falhas nos
projetos, pois leva ao não cumprimento dos prazos, gastos acima do estipulado e falta de
funcionalidade ou usabilidade determinada pelo usuário. Isso ocorre na maioria das vezes por
não se ter um controle efetivo de todo o processo.
Motivados por esses fatores, estudaremos cada uma das áreas de conhecimento de
gestão de projetos na sequência em que elas são descritas no PMBoK (2013). Nesta unidade
concentraremos nossos estudos nas áreas de conhecimento: integração, escopo, tempo e custo.
A figura a seguir proporciona uma visão geral das áreas de conhecimento.

G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 25 – VISÃO GERAL DAS ÁREAS DE CONHECIMENTO EM GERENCIAMENTO DE

PROJETOS E OS PROCESSOS DE GERENCIAMENTO DE PROJETOS
FONTE: PMI (2013)
Na área de conhecimento Integração estão descritos os processos e atividades que

servem de elementos integradores no gerenciamento de projetos. Os principais processos e G
E
atividades são (PMI, 2013): R
Ê
N
• Desenvolvimento do termo de abertura do projeto.
C
• Desenvolvimento do plano de gerenciamento de projeto. I
• Orientar e gerenciar a execução do projeto. A
• Monitorar e controlar o trabalho do projeto. D

• Realizar o controle integrado de mudanças. E
• Encerrar o projeto ou fase do projeto. P

R
O
J
E
T
O
S
FIGURA 26 – ÁREA DE CONHECIMENTO DE INTEGRAÇÃO
FONTE: Adaptado de PMI (2013)
A figura anterior demonstra graficamente os processos de gerenciamento de integração

G
E de projetos. Esta área é responsável por coordenar, supervisionar e integrar os demais
R processos do projeto. Processos importantes de autorização, planejamento, execução são
Ê
N
importantes processos da Integração de Projetos, que convergem para agregar valor ao
C negócio, descrever claramente os processos que serão executados, bem como os benefícios
I
esperados, oferecer flexibilidade nas implementações, além de possibilitar maior agilidade na
A
execução das tarefas, através da execução harmoniosa.
D
E
Os processos de Integração dos Projetos são aplicados em três níveis:
P
R
O • Nível estratégico do projeto: através da definição dos objetivos que permeiam a gestão
J de projetos.
E
T • Nível tático do projeto: através do desenvolvimento e manutenção do plano de
O gerenciamento do projeto visando eficiência e eficácia.
S
• Nível operacional do projeto: através da organização diária das atividades,

gerenciamento dos recursos e gestão das partes interessadas, além de gerir e enviar
informações para o nível tático a fim de manter os planos do projeto atualizados.
Considerando-se os três níveis, a Gestão da Integração possibilita equilibrar as

demandas e restrições de um projeto, além de coordenar todos os processos das demais áreas
de conhecimento durante o ciclo de vida do projeto.
Seis processos dão suporte à Gestão de Integração do Projeto:
• Desenvolver o plano de abertura do projeto.

• Desenvolver o plano de gerenciamento do projeto.
• Orientar e gerenciar o trabalho do projeto.
• Monitorar e gerenciar o trabalho do projeto.
• Realizar controle integrado das mudanças.
• Encerrar a fase ou projeto.
Num primeiro momento a área de integração auxilia na definição do escopo do trabalho

do projeto ou produto, necessários para o Termo de Abertura do Projeto. Em seguida, na
execução dos processos de planejamento, gerencia o Plano do Projeto interagindo com as
demais áreas com o intuito de detalhar mais o projeto. Na execução do Projeto a área de
Integração monitora e orienta a utilização dos recursos bem como a execução das atividades. Na
finalização do Projeto a área de Integração organiza os processos e coordena as formalidades
para a entrega final.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 27 – VISÃO GERAL DO GERENCIAMENTO DE INTEGRAÇÃO DO PROJETO
FONTE: PMI (2013)
G
E Vamos agora, estudar em detalhes, cada processo da integração de projetos.
R
Ê
N
C
I
A 2 DESENVOLVIMENTO DO TERMO DE ABERTURA
D
E O termo de abertura do projeto é o primeiro processo realizado. Ele formaliza a existência
P do projeto que pode surgir com necessidades como:
R
O
J • Demanda de mercado.
E • Necessidade organizacional.
T
O • Inovação tecnológica.
S
• Globalização.
• Imposições governamentais, entre outros aspectos.
O termo de abertura autoriza os demais trâmites do projeto, além de documentar os

seus principais requisitos e obstáculos. É um documento importante, pois estabelece o vínculo
entre o patrocinador e executor do projeto, considerando todos os aspectos legais envolvidos
no contrato comercial firmado entre as partes envolvidas.
Basicamente, o termo de abertura irá abordar de forma bem clara os resultados que
o projeto deverá alcançar, delimitando o universo de trabalho.
FIGURA 28 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
A elaboração do termo de abertura de um projeto liga o projeto ao trabalho em andamento

da organização. Em algumas organizações, o termo de abertura e a iniciação do projeto
não são formalmente realizados antes do término de uma avaliação de necessidades, um
estudo de viabilidade, um plano preliminar ou alguma outra forma equivalente de análise que
tenha sido iniciada separadamente. O desenvolvimento do termo de abertura do projeto trata
principalmente da documentação das necessidades de negócios, da justificativa do projeto, do
entendimento atual das necessidades do cliente e do novo produto, serviço ou resultado que
G
deve satisfazer esses requisitos. E
R
FONTE: Disponível em: <http://www.inpe.br/twiki/pub/Main/GerenciamentoProjetosEspaciais/ Ê
Parte-03_CSE-325_2012.pdf>. Acesso em: 11 maio 2015. N
C
I
Conforme demostrado na figura anterior, o termo de abertura possui as seguintes A
entradas (PMI, 2013): D

E
• declaração do trabalho do projeto: inclui a necessidade do projeto bem como o escopo P
do trabalho a ser desenvolvido; R
O
• business case: inclui informações de negócio para justificar o projeto; relaciona as
J
estratégias, missão, visão e valores organizacionais; define os critérios de seleção para E
T
o projeto;
O
S
• acordos ou contratos: define acordos ou contratos necessários quando necessário

aplicar;
• fatores ambientais da empresa: aborda a infraestrutura organizacional, condições de
mercado, padrões comerciais, industriais, governamentais, entre outros;
• ativos de processos organizacionais: aborda modelos, templates, processos
padronizados, informações de projetos anteriores bem como as lições aprendidas.
Uma das principais técnicas para validar o termo de abertura é a opinião de especialistas.
Estes podem ser internos ou externos, como:
• outras unidades da organização;

• consultores;
• intervenientes, inclusive clientes ou patrocinadores;
• associações profissionais e técnicas;
• grupos industriais;
• especialistas no assunto;
• escritório de projetos.
FIGURA 29 – DIAGRAMA DE DESENVOLVIMENTO DO TERMO DE ABERTURA
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O FONTE: PMI (2013)
S
Como resultado dos processos descritos anteriormente, surge o termo de abertura

formalizando o início do projeto. A figura anterior apresenta um diagrama com o fluxo de
atividades que tipicamente são realizadas para a elaboração do termo de abertura de um projeto.
De acordo com o PMI (2013), o termo de abertura pode conter:
• o propósito ou justificativa do projeto;

• os objetivos mensuráveis e critérios de sucesso relacionados;
• requisitos de alto nível;
• resumo do cronograma de marcos;
• resumo do orçamento;
• requisitos de aprovação;
• influência das partes interessadas;
• critérios de sucesso;
• riscos iniciais identificados;
• definição do gerente do projeto;
• nome e autoridade do patrocinador e outras partes interessadas que assinam o termo.
Não se esqueça das informações a seguir:
• Identificação: na identificação deve ser informado o nome do projeto, o nome do

gerente de projetos que responderá pelo mesmo e a data de formalização da abertura
do projeto.
• Pessoas: as pessoas envolvidas (stakeholders) devem ser relacionadas no termo de
abertura. Além do nome podem ser incluídas outras informações que sejam relevantes
ao projeto.
• Objetivos: deve descrever os critérios mensuráveis para medição do grau de sucesso
do projeto. Esta descrição pode incluir objetivos técnicos ou objetivos de negócios.
• Descrição: deve explicitar as características do projeto. Estas características não
G
necessitam de grande detalhamento, mas devem refletir o que é esperado em termos E
de resultados mensuráveis. R
Ê
• Justificativas: deve descrever os benefícios esperados com o projeto. Estas justificativas
N
podem incluir ainda alguma necessidade ou exigência que deve ser atendida pela C
organização. I
A
Dependendo da natureza do projeto pode ser importante acrescentar outras D

E
informações ao termo de abertura. Porém, com as seções relacionadas no exemplo é
possível ter uma visão geral do que se pretende desenvolver e dos atores diretamente P
R
envolvidos. O
J
E
T
O
S
3 DESENVOLVIMENTO DO PLANO DE GERENCIAMENTO DE PROJETOS
O plano de projeto contempla as estratégias e especificações para pôr em prática o

plano de gerenciamento do projeto e as execuções previstas durante todo o ciclo de vida. Deve
conter respostas para a questão: como serão definidos, planejados, controlados e executados
o escopo, tempo, custo, qualidade, recursos humanos, comunicações, riscos e aquisições do
projeto? Este detalhamento serve de referência para os demais planos.
São atribuições do plano de gerenciamento do projeto:
• Documentar as ações necessárias para definir, preparar, e integrar os demais planos

do projeto.
• Definir como o próprio plano de gerenciamento será executado.
• Ser progressivamente elaborado através de atualizações supervisionadas pelo processo
de Controle Integrado de Mudança.
FIGURA 30 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS PARA O DESENVOLVIMENTO

DO PLANO DE GERENCIAMENTO DE PROJETOS
FONTE: PMI (2013)
G
E Conforme PMI (2013) e demonstrado na figura anterior, o plano de gerenciamento de
R
Ê
projeto pode possuir as seguintes entradas:
N
C
• termo de abertura do projeto;
I
A • saídas dos processos de planejamento;
• fatores ambientais da organização;
D
E • ativos de processos organizacionais.
P
R Da mesma forma como na elaboração do termo de abertura, na elaboração do plano de
O gerenciamento de projeto, é utilizada como ferramenta e técnica a avaliação de especialistas.
J
E A avaliação de especialistas é utilizada principalmente para (PMI, 2013):
T
O
S
• adequar o processo para atender às necessidades do projeto;

• desenvolver detalhes técnicos e de gerenciamento para serem incluídos no plano de
gerenciamento do projeto;
• determinar recursos e níveis de habilidades necessárias para executar o trabalho do
projeto;
• determinar o nível de gerenciamento de configuração a ser usado no projeto; e
• determinar quais documentos do projeto estarão sujeitos ao processo formal de controle
de mudanças.
Uma visão mais abrangente das integrações existentes entre o processo de

desenvolvimento do Plano de Gerenciamento de Projeto e outros processos pode ser
observada na figura a seguir.
FIGURA 31 – FLUXOGRAMA PARA DESENVOLVIMENTO DO PLANO DE GERENCIAMENTO DE

PROJETOS
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: PMI (2013) O
S
O resultado do processo de desenvolvimento do Plano de Gerenciamento de Projeto

que especifica a gestão global do projeto, e pode conter as seguintes informações:
• Objetivo: descrição do objetivo do plano de projeto, bem como a definição dos principais
elementos do projeto que devem ser gerenciados.
• Limites do projeto: descrição dos limites de abrangência do projeto, de forma que o
maior foco possível seja dado ao que realmente está no escopo do projeto.
• Marcos do projeto: identificação dos principais pontos de controle do progresso do
projeto, bem como suas respectivas datas.
• Critérios de aceite: descrição dos critérios a serem medidos para definição do aceite
dos entregáveis do projeto.
• Premissas: descrição das premissas sobre as quais o desenvolvimento do projeto está
apoiado. As premissas são questões assumidas como verdadeiras e a partir das quais
são tomadas decisões de projeto.
• Restrições: descrição das restrições impostas ao projeto e com as quais será necessário
lidar.
• Funções e responsabilidades: relação das pessoas envolvidas no projeto com suas
respectivas funções e responsabilidades.
• Iniciação do projeto: descrição de como deve ser conduzida a fase de iniciação do
projeto.
• Planejamento do projeto: descrição de como devem ser conduzidas as atividades de
planejamento do projeto.
• Execução do projeto: descrição de como devem ser conduzidas as atividades de
execução do projeto.
• Monitoramento do projeto: descrição de como devem ser conduzidas as atividades
de monitoramento e controle do projeto.
• Encerramento do projeto: descrição de como deve ser conduzida a fase de
encerramento do projeto.
• Planejamento do escopo: descrição dos processos a serem realizados para que seja
G
dado o tratamento adequado ao escopo do projeto.
E
R • Planejamento do tempo: descrição das atividades que deverão ser realizadas para o
Ê
adequado gerenciamento do cronograma do projeto.
N
C • Planejamento de custos: descrição das regras a serem utilizadas no momento da
I realização das estimativas de custos do projeto.
A
• Planejamento das aquisições: descrição da abordagem a ser utilizada para o
D planejamento das aquisições para o projeto.
E
• Planejamento de riscos: descrição das atividades a serem realizadas para o adequado
P gerenciamento dos riscos do projeto.
R
O • Planejamento da qualidade: descrição das regras a serem utilizadas no processo de
J planejamento da qualidade do projeto.
E
T
• Planejamento de recursos humanos: descrição da abordagem a ser utilizada para o
O planejamento de recursos humanos do projeto.
S
• Planejamento de comunicação: descrição das regras a serem seguidas em relação às

informações a serem comunicadas, o formato de documentos/relatórios, a periodicidade,
os responsáveis pela comunicação, os principais eventos que demandam comunicação,
os destinatários das informações e o método para atualização das comunicações.
• Planejamento das partes interessadas: descreve as ferramentas e técnicas para a
identificação dos stakeholders, bem como para o engajamento das mesmas e gestão
de suas expectativas.
O Plano de Gerenciamento de Projetos deve possuir um nível de detalhamento para

cada projeto, podendo ser mais resumido ou mais detalhado, dependendo da complexidade
do cenário envolvido. Este deve ser aprovado formalmente pelos principais stakeholders,
especificamente pelo patrocinador ou cliente. É com base neste documento que o gerente de
projetos irá coordenar as atividades e a equipe.
Caso sofra alterações, estas deverão ser controladas pelo processo de Controle Integrado
de Mudanças, que deverá solicitar novamente a aprovação dos principais Stakeholders.
4 ORIENTAR E GERENCIAR A EXECUÇÃO DO PROJETO
É o processo responsável por coordenar a realização das atividades detalhadas no

Plano de Gerenciamento do Projeto. Entre as principais atividades estão:
• Orientar a execução das atividades, definir a alocação dos recursos, gerenciar interfaces
técnicas e organizacionais, coletar informações de desempenho, gerenciar aquisições,
emitir solicitações de mudanças e gerenciar a comunicação do projeto.
• Implementar mudanças que já foram aprovadas: executando correções, prevendo e G

reparando erros ou defeitos. E
R
Ê
Este processo orienta e supervisiona todos os demais processos de execução do N
C
projeto. Deve prover orientação específica para cada uma das áreas de conhecimento a fim
I
de gerenciar as particularidades dos processos abaixo relacionados: A
D
• Realizar a garantia da qualidade. E
• Mobilizar a equipe do projeto.
P
• Desenvolver a equipe do projeto. R
• Gerenciar a equipe do projeto. O
J
• Distribuir informações. E
• Gerenciar as expectativas dos stakeholders. T
O
S
• Gerenciar aquisições.
O gerenciamento da execução é a atividade central do projeto. Nesta atividade deve

ser considerada a necessidade da utilização de uma série de informações de planejamento e
definições do projeto. Um dos documentos que guiará boa parte das ações desta atividade é
o plano do projeto.
Conforme pode ser observado na figura a seguir, as entradas do processo de orientar

e gerenciar a execução do projeto são:
• plano de gerenciamento do projeto: descreve, define e documenta como o projeto

será iniciado, gerenciado e encerrado;
• solicitações de mudanças aprovadas: solicitações aprovadas serão agendadas para
a execução, depois de serem documentadas e aprovadas;
• fatores ambientais da empresa: cultura organizacional, tolerância a riscos e software
de gerenciamento de projetos;
• ativos de processos organizacionais: procedimentos e meios de comunicação, banco
de dados para medição, coleta e disseminação de informações referentes aos processos.
FIGURA 32 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS PARA GERENCIAMENTO DA

EXECUÇÃO
FONTE: PMI (2013)

G
E
R De acordo com o PMI (2013), algumas das atividades que devem ser realizadas durante
Ê a execução do projeto são:
N
C
I • executar as atividades necessárias para obter os requisitos do projeto;
A
• criar as entregas do projeto;
D • apoiar, treinar e gerenciar a equipe dedicada ao projeto;
E • obter, gerenciar e utilizar os recursos humanos e materiais do projeto;
P • implementar os métodos e padrões planejados;
R • estabelecer e gerenciar os canais de comunicação do projeto;
O
J • gerar os dados do projeto;
E • tratar requisições de mudanças e replanejar o projeto;
T
O • gerenciar riscos e implementar atividades de resposta a riscos;
S
• gerenciar fornecedores;
• coletar e documentar lições aprendidas;
• implementar atividades de melhoria de processo aprovadas.
FIGURA 33 – FLUXOGRAMA DO GERENCIAMENTO DA EXECUÇÃO DO PROJETO
FONTE: PMI (2013)
O processo de orientar e gerenciar a execução do projeto produzirá as seguintes

saídas (PMI, 2008):
G
• entregas: resultado da execução das tarefas do projeto. Podem ser tangíveis ou E
R
intangíveis. Ex.: relatórios, plano de projeto, treinamento, sistema, protótipo etc.; Ê
• informações sobre o desempenho do trabalho: informações sobre o projeto e N
C
desempenho das atividades executadas;
I
• solicitações de mudanças: devem ter seu efeito colateral avaliado antecipadamente A
pelo processo Controle Integrado de Mudanças;
D
• atualizações do plano de gerenciamento do projeto: alterações na especificação E
inicial;
P
• atualizações dos documentos do projeto: atualizações nos documentos de requisitos, R
cronogramas, orçamentos, registro de riscos, matriz de responsabilidade etc. O
J
E
Em suma, é neste processo que é alicerçada a ação do projeto. Seu objetivo é seguir T
O
S
à risca a execução das atividades previstas no plano do projeto. Após a autorização, inicia-se
o trabalho de execução.
É um dos processos mais dinâmicos, acarretando muitas atividades de controle para

o gerente do projeto, sendo uma ferramenta que garante o entendimento comum sobre ele.
5 MONITORAR E CONTROLAR A EXECUÇÃO DO PROJETO
O monitoramento e controle de projetos trabalham de forma integrada com o processo

que gerencia a execução. Estes processos compartilham algumas entradas e saídas.
O monitoramento e controle de projetos preocupam-se primordialmente com a realização

das atividades planejadas para o projeto, no intuito de garantir que o escopo definido seja
cumprido.
O processo de monitoramento e controle da execução do projeto possui as seguintes

entradas (PMI, 2013):
• plano de gerenciamento do projeto: detalhamento do projeto;

• previsões: previsões de cronograma e custos são necessárias para garantir que o
projeto atinja seus objetivos. Estas previsões podem ser extraídas de qualquer software
de gestão de projetos;
• mudanças validadas: mudanças que foram aprovadas e implementadas;
• relatórios de desempenho: extraídos da análise dos dados da execução das atividades
do projeto;
• fatores ambientais da empresa: padrões, cultura organizacional, tolerância a riscos;
G • ativos de processos organizacionais: requisitos para a comunicação do projeto;

E
R
A ferramenta e técnica desse processo é a opinião especializada. Já as saídas são
Ê
N (PMI, 2013):
C
I
A • solicitações de mudança;
• atualizações do plano de gerenciamento do projeto;
D
E • atualizações dos documentos do projeto.
P
R
O
J
E
T
O
S
FIGURA 34 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS PARA MONITORAMENTO E

CONTROLE DE PROJETOS
FONTE: PMI (2013)
O processo de Monitoramento e Controle envolve a coordenação das pessoas e dos

recursos, além da integração e realização das atividades do projeto de acordo com o Plano
Geral do Projeto. Neste momento, a equipe do projeto e os recursos devem estar disponíveis
para a execução das atividades planejadas na fase anterior.
Nesta fase é gasta a maior parte do orçamento previsto. Havendo variações de execução,
o que é normal, poderá ser necessário replanejamento em determinados momentos. Essas
variações podem afetar a duração das atividades, a disponibilidade dos recursos e acarretar
riscos não esperados. A fase de Monitoramento e Controle serve para observar o andamento
do projeto, de forma que problemas porventura existentes sejam identificados no momento
adequado e adotadas ações corretivas, quando necessário, para controlar a execução do
projeto. Tem como principal benefício acompanhar o desempenho do projeto, passando este a
ser observado e medido regularmente para identificar variações em relação ao Plano do Projeto.
FONTE: Adaptado de: <http://www.tjrn.jus.br/files/pej/METODOLOGIA_EXECUO_E_CONTROLE.

pdf>. Acesso em: 11 maio 2015.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 35 – FLUXOGRAMA DE MONITORAMENTO E CONTROLE DE PROJETOS
FONTE: PMI (2013)

G
E
Em geral, quanto maior, mais complexo e mais espalhado geograficamente for um
R
Ê projeto, mais difícil e caro vai ser seu monitoramento e controle. Há projetos, entretanto, que
N
por sua complexidade e curta duração, podem forçar que seu controle seja muito estruturado
C
I e sofisticado. Cabe ao gerente de projeto e à equipe analisar caso a caso para balancear o
A custo do monitoramento e controle versus o seu benefício.
D
E
P
R 6 REALIZAR O CONTROLE INTEGRADO DE MUDANÇAS
O
J
E
T Este processo revisa todas as solicitações de mudança do projeto, para definir se
O aprova ou rejeita a solicitação. Inclui o gerenciamento de mudanças nas entregas, os ativos
S
dos processos organizacionais, demais documentos do projeto e plano de gerenciamento do
projeto.
Gerenciar a configuração faz parte do processo de Controle Integrado de Mudanças

e visa:
• Identificar a configuração.
• Registrar a situação da configuração.
• Verificar e auditar a configuração.
Neste sentido, o Controle Integrado de Mudanças deve:
• Documentar o impacto da solicitação da mudança, bem como as suas causas.

• Revisar, analisar, aprovar ou rejeitar solicitações de mudança.
• Aferir para que apenas mudanças aprovadas sejam executadas.
FIGURA 36 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS PARA O CONTROLE

INTEGRADO DE MUDANÇAS
FONTE: PMI (2013)
Gerir as mudanças é um dos grandes desafios da gestão de projetos, principalmente de

projetos na área de tecnologia da informação. As entradas do processo de controle integrado
de mudanças são (PMI, 2013):
G
E
• plano de gerenciamento do projeto; R
Ê
• informações sobre o desempenho do trabalho; N
• solicitações de mudança; C
I
• fatores ambientais da empresa; A
• ativos de processos organizacionais.
D
E
Muitos fatores contribuem para que o projeto sofra alterações. Quando estão em fase
P
de execução, os projetos não deveriam sofrer alterações de escopo. Porém, isso na maioria R
das vezes, é inevitável, geralmente são esperadas e até previstas alterações durante o ciclo O
J
de vida do projeto, porém, os impactos podem variar, dependendo da fase em que o mesmo
E
se encontra. As mudanças não devem surpreender ninguém e nem servir de base para supor T
falta de competência na gestão do projeto. O
S
Como ferramentas e técnicas para o controle integrado de mudanças pode-se utilizar

(PMI, 2013):
• opinião especializada;
• reuniões de controle de mudanças.
As mudanças de escopo são tipicamente indesejadas, pois exigem o replanejamento

do projeto. Se as mudanças forem frequentes o projeto estará constantemente sendo
replanejado. O replanejamento é uma atividade trabalhosa e delicada. Uma forma eficaz de
reduzir a quantidade de mudanças de escopo é solicitar a formalização da solicitação através
de documento específico.
Da mesma forma como os demais documentos de projeto não possuem um padrão

largamente aceito e utilizado, o documento de solicitação de alterações de escopo também
não possui. Logo, deve-se definir e adotar o documento que mais se adapte à realidade da
organização ou natureza dos projetos desenvolvidos.
As saídas do processo de controle integrado de mudanças (PMI, 2013):
• atualizações do andamento de solicitação de mudança com registro das solicitações

aprovadas e registro das mudanças;
• atualizações dos documentos do projeto.
Independente da origem da solicitação de alteração de escopo, esta deve ser formalizada

através de um documento de solicitação de mudança de escopo. Um exemplo deste documento
pode possuir as seguintes seções:
• Solicitação: deve ser informado o nome do solicitante, a data de solicitação, a área a

G
qual o solicitante pertence, bem como a prioridade da mudança. Depois de informados
E
R estes dados, a mudança sugerida deve ser descrita da forma mais clara e objetiva
Ê
possível. Devem ser informadas ainda justificativas para que a mudança de escopo
N
C seja aprovada.
I
A
• Impactos: devem ser descritos os diversos impactos que a mudança poderá causar.
D Devem ser descritos os impactos que serão causados no escopo, cronograma e custos,
E
bem como o detalhamento dos custos envolvidos para facilitar a análise dos decisores.
P Tão importante quanto informar os impactos causados pela mudança é informar os
R
O impactos ao projeto, caso a mudança não seja realizada.
J
E
T
• Aprovadores: deve ser informada uma lista de pessoas com poder para decidir sobre
O realização da mudança do escopo, tipicamente o comitê gestor, se for ocaso. Para que
S
o escopo seja alterado é necessário que todos estejam de acordo e manifestem seu
aceite.
A figura a seguir demonstra graficamente os processos que interagem com o processo

de controle integrado de mudanças. O fluxograma deixa bastante claro o impacto que uma
mudança no escopo pode representar ao projeto.
FIGURA 37 – FLUXOGRAMA DO CONTROLE INTEGRADO DE MUDANÇAS
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: PMI (2013) O
S
O processo para executar mudanças deve obedecer ao seguinte checklist:
• Preencher modelo de documento para registrar a mudança (causas e impactos).

• Verificar a origem da mudança.
• Avaliar a real necessidade de mudança.
• Pesquisar e elencar possíveis soluções com o intuito de reduzir custos e minimizar
impactos.
• Obter a aprovação da mudança junto com comitê ou pessoa responsável.
• Atualizar a documentação do projeto, incluindo as mudanças aprovadas.
• Disseminar as informações da mudança para todas as partes interessadas.
• Programar a mudança acompanhando a execução, sempre verificando e avaliando a
eficácia da solução adotada.
7 ENCERRAR O PROJETO OU FASE DO PROJETO
O processo de encerramento da fase ou projeto formaliza a entrega de atividades

de todos os grupos de processos. Nesta etapa são revisados os documentos do projeto,
principalmente os documentos de encerramento das fases anteriores, como forma de garantir
que os objetivos foram alcançados. Este processo é executado em cada fase, e, depois, no
final do projeto.
Faz parte do encerramento da fase ou projeto:
• Avaliar o escopo comparando-o com o plano de gerenciamento e atividades realizadas.

• Ações e atividades que ainda se fazem necessárias para encerrar a etapa ou o projeto
como um todo.
• Ações e atividades necessárias para que se possa avançar para a próxima etapa prevista
G
E no plano do projeto.
R
• Ações para coletar informações da fase ou projeto; avaliar o sucesso ou fracasso,
Ê
N elencando as lições aprendidas.
C • Motivos de encerramento do projeto antes do tempo previsto.
I
A
Um importante aspecto deste processo é o levantamento de informações para verificar
D
E o que foi aprendido no projeto, e também para facilitar o aceite do cliente na entrega final.
P
R São atividades frequentes realizadas nesse processo:
O
J
E
• Confirmar que o resultado final atende ao escopo definido.
T • Confirmar o aceite do patrocinador ou cliente do projeto.
O
S
• Finalizar os contratos ou acordos.

• Documentar o que foi aprendido.
• Guardar os documentos do projeto.
• Entregar o projeto, verificando os termos de garantia.
• Apresentar o projeto às partes interessadas.
• Liberar os recursos do projeto (materiais e humanos) para novas demandas.
O processo de encerramento do projeto ou fase do projeto possui as seguintes entradas
(PMI, 2013):
• plano de gerenciamento do projeto;

• entregas aceitas através da verificação do escopo;
Quanto a ferramentas e técnicas do processo de encerramento do projeto ou fase do

projeto a que é relacionada pelo PMI (2013) é a opinião especializada, também conhecida
como avaliação de especialistas.
FIGURA 38 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS DE ENCERRAMENTO DE

PROJETO OU FASE
FONTE: PMI (2013)
As saídas do processo de encerramento do projeto ou fase do projeto são (PMI, 2013):

G
E
• transição de produto, serviço ou resultado final; R
Ê
• atualizações de ativos de processos organizacionais. N
C
I
De certa forma, o projeto sempre será finalizado com o alcance dos objetivos, ou não.
A
Um motivo para o não alcance dos objetivos e encerramento antes do previsto, seria a falta
de recursos ou o projeto não ser mais necessário para a organização. D
E
Formalizar o encerramento das atividades deve ser uma prática para evitar problemas P
R
futuros. O
J
E
A figura a seguir apresenta o fluxograma do encerramento do projeto ou fase do projeto. T
O
S
FIGURA 39 – FLUXOGRAMA DO ENCERRAMENTO DO PROJETO OU FASE
FONTE: PMI (2013)
Após a finalização do projeto, é importante que o gerente reúna a equipe para juntos
elaborarem o documento de lições aprendidas. Todas as experiências e técnicas utilizadas
que resultaram em benefícios para o projeto entregue podem ser reaplicadas ou novamente
utilizadas em projetos futuros.
Um exemplo das informações que este documento deve conter:
• Data: data em que a lição aprendida foi registrada.

• Lição aprendida: descrição da lição aprendida com a situação relatada e que deverá
ser considerada no futuro em situações similares.
G • Descrição da situação: descrição da situação ocorrida, a partir da qual pode ser
E
R aprendida uma lição de forma a potencializar as ações futuras em situações similares.
Ê
N
Sugere-se que o registro da lição deva ser feito imediatamente após alguém da
C
I equipe ter percebido e comprovado o benefício da prática. Isso evita que algo importante
A
caia no esquecimento e não seja mencionado na reunião final da abordagem das lições
D aprendidas. Estas devem fazer parte da base de conhecimento de gestão de projetos da
E organização, favorecendo equipes de projetos futuros.
P
R
O
J
E
T
O
S
LEITURA COMPLEMENTAR
BARREIRAS QUE DIFICULTAM O GERENCIAMENTO DE PROJETOS
A dificuldade no gerenciamento de projeto é a realidade mais evidente no contexto

de pequenas e médias empresas de TI, refletindo em todo o negócio, seja no planejamento
estratégico como na execução de tarefas de fabricação do produto. Nesse artigo são explanados
alguns critérios que dificultam a gestão de projetos.
Falta de uma definição própria de ‘Projeto’
Segundo PMI “Projeto é um esforço temporário empreendido para criar um produto

ou serviço único. Desta forma, um projeto tem início e ﬁm deﬁnidos o que resulta em um
produto ou serviço de alguma forma diferente de todos os outros anteriormente produzidos”. A
organização é livre para ter sua própria característica definida em seus projetos, sem esquecer
que é fundamental ter prazos definidos, tarefas organizadas, mesmo havendo diferenciais
quanto prazo, custo e complexidade.
Quando se fala em definição de projeto é necessário evidenciar a diferença de produto

e projeto, onde produto é o que é desenvolvido pela organização, por exemplo, um software.
As atividades são executadas e associadas a recursos para se produzir resultados com

excelência, sendo imprescindível a definição de projeto através de um escopo, aprovado pelos
stakeholders (interessados no projeto), para então gerenciá-los.
A Estrutura Analítica de Projetos (EAP) é uma ferramenta que auxilia na decomposição

do projeto, ou seja, possibilita a criação de tarefas que devem ser executadas durante o projeto,
conforme a figura.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
Gestão de projetos
Depois de definidos os projetos devem ser gerenciados. Para PMI, gestão de projeto
é o processo através do qual se aplicam conhecimentos, capacidades, instrumentos e
técnicas às atividades do projeto, de forma a satisfazer as necessidades e expectativas dos
diversos stakeholders, ou seja, a execução de atividades que visam alcançar um objetivo
comum.
Gerenciar projetos consiste em aplicar alternativas compatíveis com a realidade

organizacional que reflitam em resultados positivos. É respeitar e adotar a mudança de cultura,
a flexibilidade nas decisões, a troca de experiência e conhecimento de envolvidos, é aceitar
desafios e todos comprometerem-se a vencê-lo.
Falta de institucionalização da gestão de projeto
Não apenas a equipe do projeto deve estar envolvida e comprometida com projetos,
mas toda a organização, tendo em vista que os projetos são influenciados por diferentes
processos de apoio, como:
• Portfólio – Responsável por alinhar projetos aos objetivos organizacionais, e analisar

a viabilidade;
• Recursos humanos – Responsável por disponibilizar recursos humanos e gerenciar
procedimentos relacionados com pessoas no projeto;
• Financeiro – Patrocina recursos e também influencia na viabilidade de projetos;
• Qualidade – Acompanha e garante a qualidade na execução das tarefas e também no
produto final;
• Atendimento – Canal direto com o usuário, fonte de requisitos e melhoria no processo.
A falta do envolvimento de todos os setores da organização no projeto acaba

G
dificultando ou impossibilitando o gerenciamento, por não existir um retorno de informações e
E
R um alinhamento de objetivos.
Ê
N
C Não investir tempo na engenharia de requisitos
I
A
A falta de preocupação na engenharia de requisitos resulta em clientes insatisfeitos,
D colaboradores frustrados e manutenções intermináveis. A construção de um software costuma
E
ser precedida apenas da percepção de necessidade de automatização, não havendo uma
P preocupação maior de conhecer o negócio e satisfazer necessidades do cliente.
R
O
J Indiferente do tamanho da equipe, podendo ser de um ou mais envolvidos, o negócio
E
T
deve ser mapeado e as necessidades identificadas, é preciso saber como é a organização e
O suas influências. Todas as informações de negócio e de rotinas devem estar disponíveis a todos
S
os envolvidos, evitando a ocorrência de dúvidas na execução, podendo utilizar de linguagem

e ferramentas correspondentes.
Os requisitos solicitados pelos fornecedores devem ser qualificados e validados e

nos casos onde existirem inviabilidade essas devem ser tratadas evitando conflitos entre os
envolvidos e garantido sucesso do projeto.
Automatizar a bagunça
Se a rotina a ser automatizada não possuir um padrão, não há como automatizar,

se o cliente trabalha de maneira errada, o software não funcionará, uma vez que o mesmo
estará sendo alimentado erroneamente. Na coleta de requisitos é comum o analista perceber
a necessidade de introduzir padrões na própria rotina manual do cliente, sendo necessário o
consenso de todos os envolvidos e o comprometimento na execução.
Vale destacar que além do produto ter a necessidade de ser coeso com as rotinas
manuais, o mesmo deverá ser compatível com as leis vigentes do negócio.
Falta de um gerenciador de projeto
Muitas empresas defendem que o gerenciador de projetos deve ter mais tempo de
empresa do que os demais ou um maior domínio técnico, acreditando que o papel de gerenciador
de projeto está na hierarquia acima dos demais executores do projeto, o que resulta na alocação
de pessoas com perfis inadequados.
O gerente de projeto é um papel totalmente diferente do desenvolvedor, analista ou

testador, se tornando necessário separar dentro do projeto estes papéis, indiferente se será a
mesma pessoa que os executará. A dificuldade de encontrar um gerente de projeto, na maioria
das vezes, está em não conhecer o perfil adequado, compatível com esse papel, que necessita
de pessoas que:
G
E
• Aceitem desafios – É necessário o comprometimento em se chegar ao objetivo esperado; R
Ê
• Opinem – O gerente de projeto é questionador e deve ter a capacidade de alinhar todos
N
os seus recursos conforme objetivos; C
• Sejam comunicativas – A comunicação é indispensável no gerenciamento de projetos. I
A
Ouvir diferentes opiniões e ser capaz de usá-las para auxiliar na tomada de decisão;
• Influenciem – Os stakeholders são fundamentais para o alcance de objetivos, cabe D
E
ao gerente exercer influência sobre esses, para que todos trabalhem para um objetivo
comum; P
R
• Solucionem problemas – Embora riscos sejam planejados, quando ocorrem devem ser O
tratados pelo gerente, de maneira rápida e produtiva; J
E
• Gerenciem atividades – Todas as atividades do projeto devem ser planejadas e T
gerenciadas pelo gerente, assim como sua execução, prazo e custo; O
S
• Sejam responsáveis – O que é planejado deve ser executado, conforme o esperado,

sendo de responsabilidade do gerente, junto com sua equipe, de entregar o esperado
e nas condições previstas, necessitando de organização e comprometimento.
Para ser um gerente de projeto é necessário ter perfil correspondente, sendo fundamental
a organização identificar os perfis de seus colaboradores e proporcionar oportunidades de
crescimento para cada um deles. Vale ressaltar que o gerente de projeto além de ter o perfil
desejado, pode também ser provido de conhecimento técnico e gerencial, o que facilita e
contribui para o gerenciamento de projetos.
Escolha de tecnologia e ferramentas sem analisar o contexto da organização
As tecnologias e ferramentas devem ser escolhidas analisando a compatibilidade

com a realidade da organização, buscando agilizar processos e alcançar resultados. Invista
tempo e recursos em buscar alternativas baseadas na necessidade da equipe, a qual utilizará
os recursos, caso não exista nenhuma ferramenta que se encaixe no perfil da empresa, crie
planilhas, automatize processos, lembrando que isso não é custo e sim investimento.
Não tratar o software como um produto
Assim como qualquer produto, o software deve suprir necessidades de seu cliente e
não do desenvolvedor. A prioridade de desenvolvimento de um requisito deve ser medida pela
necessidade do cliente e não pela complexidade de desenvolvimento. Todo cliente quer saber
quando será entregue seu software e quanto vai lhe custar, antes de fechar o negócio, a gestão
de projeto deve oferecer isso ao negócio.
Conclusão
Gerenciar projetos não é uma tarefa fácil e rápida a ser implementada,

G
principalmente quando empresas já adotam processos desorganizados. Mudar a cultura é
E
R o principal desafio. A gestão de projetos deve ser adotada gradativamente, à medida que
Ê
os projetos vão sendo gerenciados, serão definidos padrões baseados em estimativas da
N
C equipe e da organização, permitindo uma gestão transparente, que possibilite gerenciar
I tempo, recurso e custo.
A
D FONTE: Disponível em: <Barreiras que dificultam o gerenciamento de projetos http://www.devmedia.

E com.br/barreiras-que-dificultam-o-gerenciamento-de-projetos/25870#ixzz3XJYE5sln>. Acesso em: 20
abr. 2015.
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 1
Neste tópico estudamos os processos da área de integração.
Pontos importantes:
• desenvolvimento do termo de abertura do projeto;
• desenvolvimento do plano de gerenciamento de projeto;
• orientar e gerenciar a execução do projeto;
• monitorar e controlar o trabalho do projeto;
• realizar o controle integrado de mudanças;
• encerrar o projeto ou fase do projeto.
Para isso o gerente de projetos deve:

• trabalhar sempre junto às partes interessadas para lapidar o escopo do projeto antes de dar
início às atividades;
• equilibrar o plano de gerenciamento de projeto, as restrições, riscos e obstáculos do projeto
com as necessidades das partes interessadas;
• estar sempre reavaliando o termo de abertura do projeto para ter certeza de que o projeto
continua sendo necessário;
• garantir que somente mudanças aprovadas serão executadas;
avaliar o encerramento do projeto junto das partes interessadas.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Em qual documento é registrado o planejamento global do projeto?
2 O Business case é uma entrada para qual processo de projeto?
3 Liste duas finalidades para a utilização da avaliação de especialistas no desenvolvimento

do plano de gerenciamento de projeto.
4 Liste duas atividades que devem ser realizadas no processo de orientar e gerenciar
a execução do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 2
TÓPICO 2
ESCOPO
1 INTRODUÇÃO
A área de conhecimento tem como objetivo principal definir todo o esforço necessário
para o projeto, delimitando o seu universo para que não sejam feitas entregas desnecessárias
ao patrocinador ou cliente. O PMI (2013) é contra a prática do Gold plating que é justamente
a entrega de aditivos que não estão no escopo do projeto. Para não comprometer a definição
do escopo e o andamento do projeto pautado por toda a sua documentação, é de restrita
importância que a equipe se concentre em executar somente o que está estabelecido na
documentação do projeto. Nada, além disso.
Mas entregar algo a mais não deixaria o Cliente mais satisfeito? Não necessariamente.
Executar algo que não está previsto é um dos fatores de risco do projeto, pois pode comprometer
cronograma, custos e qualidade das atividades.
De forma objetiva, o Escopo define, determina e controla o que faz e também o que
não será feito em determinado projeto. O escopo deve ser planejado com antecedência. As G
mudanças que ele poderá sofrer também. E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 40 – ÁREA DE CONHECIMENTO DE ESCOPO
Para manter fielmente os requisitos do Escopo, os seguintes processos devem ser

G realizados (PMI, 2013):
E
R
Ê • Planejar o gerenciamento do escopo
N
C • Coletar requisitos
I • Definir o escopo
A
• Criar a EAP (Estrutura Analítica do projeto)
D • Validar o escopo
E
• Controlar o escopo
P
R
A figura apresenta de forma clara os processos em conjunto com suas entradas,
O
J ferramentas e técnicas e saídas esperadas.
E
T
O São atividades primordiais do gerenciamento de escopo:
S
• Planejar e documentar como o escopo será definido e gerenciado durante o ciclo de

vida do projeto.
• Coletar e selecionar os requisitos do projeto.
• Equilibrar as demandas das partes interessadas em relação ao especificado no escopo.
• Criar a estrutura analítica do projeto para decompor as atividades em pacotes facilitando
os processos de gerenciamento e execução.
• Aferir o escopo em relação ao plano do projeto.
• Obter a aceitação da entrega pelas partes interessadas, conforme definição no escopo.
• Medir e controlar o desempenho na realização do escopo.
FIGURA 41 – PROCESSOS DE GERENCIAMENTO DO ESCOPO DO PROJETO
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: PMI (2013) O
S
De acordo com o PMI (2013), o gerenciamento do escopo do projeto compreende todos

os processos necessários para garantir que serão realizadas todas as atividades necessárias
e apenas as atividades necessárias para a conclusão do projeto com sucesso.
As entradas do processo de gerenciamento segundo o PMI (2013) são:
• Termo de abertura do projeto.

• Plano de gerenciamento do projeto.
• Fatores ambientais da empresa.
• Ativos de processos organizacionais.
Como técnicas e ferramentas o PMI (2013) sugere opiniões especializadas e reuniões

para detalhamento do projeto.
Como saída apresentam-se (PMI, 2013):
• Plano de gerenciamento de escopo.

Plano de gerenciamento de requisitos.
FIGURA 42 - ÁREA DE CONHECIMENTO DE ESCOPO

G
E
R Terminar no prazo acertado, com o custo combinado e da forma como os clientes
Ê
desejam é o que se espera de qualquer projeto. Porém, a experiência mostra que na maioria
N
C das vezes, esse não é um desafio fácil de ser cumprido. Inúmeras ações podem fazer com
I que as expectativas não se cumpram. As falhas vão deste o estabelecimento das expectativas
A
até a execução do projeto.
D
E
Se analisarmos os motivos do fracasso de um projeto, notaremos que normalmente
P este fato se deve a falha no gerenciamento do Escopo ou tempo insuficiente na definição do
R
O projeto. Assim, mesmo quando o Gerente de Projetos desenvolve um bom trabalho na definição
J de escopo, gerenciar o projeto dentro do escopo estabelecido torna-se seu maior desafio.
E
T Muitas vezes nos deparamos com projetos cujo escopo não é claro, que deixa margem à
O interpretação, assim o cliente poderá persistir que a mudança está dentro do escopo, dificultando
S
o cumprimento do escopo definido.
Um bom gerenciamento do escopo passa pela definição clara do que deve ser feito
durante o projeto e como isso será realizado. Essa definição deve ser feita com base nos
resultados esperados para o projeto e nas restrições que se terá para sua realização.
Ainda mais importante é a definição do que não será feito durante o projeto. Isso serve
de proteção às “vontades” que sempre acontecem durante a realização do projeto. Em geral,
pensar antes no que vai ser feito serve de garantia para que o resultado traçado inicialmente
seja alcançado.
FONTE: Disponível em: <http://www.avm.edu.br/docpdf/monografias_publicadas/k212493.pdf>.

Acesso em: 11 maio 2015.
2 COLETAR REQUISITOS
É o processo mais crítico do Gerenciamento de Escopo, pois ele será responsável por
especificar detalhadamente cada atividade. Define e documenta características e funcionalidades
de cada atividade que será executada para atender às expectativas das partes interessadas.
Faz o refinamento dos requisitos.
Podemos entender como requisitos, as peculiaridades e especificações que as partes

interessadas definiram a respeito do projeto. O processo de coletar requisitos nada mais é
do que gerenciar as expectativas e necessidades daqueles que estão comprando o projeto.
Os requisitos, após coletados serão o alicerce para a construção da Estrutura Analítica

do Projeto (EAP), e servirão de base para todo o planejamento do projeto a partir desta fase.
G
Devem ser definidos, acordados e validados pelas partes interessadas. E
R
Ê
Coletar de forma equívoca os requisitos compromete todo o projeto, colocando a sua N
execução em risco, e até mesmo inviabilizá-lo. Por exemplo: um requisito não identificado no C
I
início vai gerar solicitações de mudanças, acarretando alterações em cronogramas e custos, A
além de possivelmente comprometer a qualidade da entrega.
D
E
Para efetuar de forma correta o levantamento de requisitos, é necessário analisar
P
e coletar informações do Termo de Abertura do Projeto. Em seguida, verificar quem são os
R
interessados no projeto e quais participarão e contribuirão para elencar o detalhamento dos O
itens propostos. Nem todos os integrantes das partes interessadas serão entrevistados para o J
E
apontamento dos requisitos. Normalmente só usuários chave (key-user), chefe do setor, gerente T
ou colaboradores especialistas no assunto serão convocados. Isso evita conflitos e concentra O
S
o levantamento somente para questões relevantes, não considerando vícios ou necessidades

de pessoas com pouco conhecimento do assunto, ou com interesse irrelevante para o projeto.
FIGURA 43 – COLETAR OS REQUISITOS: ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
Conforme é demonstrado na figura, o processo de coletar requisitos possui as seguintes

entradas (PMI, 2013):
• Plano de gerenciamento de escopo.

• Plano de gerenciamento de requisitos.
• Plano de gerenciamento das partes interessadas.
• Registro das partes interessadas.
Por se tratar da fase inicial do projeto, o Termo de Abertura é o principal ativo de entrada
de informações. A partir do registro das partes interessadas é que será possível identificar quais
G
são os principais stakeholders para iniciar o trabalho de entrevistas e efetivamente obter os
E
R requisitos com o grau de detalhe necessário à realização do projeto. As ferramentas e técnicas
Ê do processo de coletar requisitos são (PMI, 2013):
N
C
I • entrevistas;
A
• grupos de discussão;
D • oficinas facilitadas;
E
• técnicas de criatividade em grupo;
P • técnicas de tomada de decisão em grupo;
R
O • questionários e pesquisas;
J • observações;
E
• protótipos.
T
O
S
Os requisitos priorizam as necessidades das partes interessadas. Direcionam a definição,

sequenciamento e execução das atividades. Somente após definido o escopo, serão feitas as
estimativas de Tempo, Custo e o planejamento da Qualidade do projeto.
As saídas do processo de coletar requisitos são (PMI, 2013):
• documentação dos requisitos;

• matriz de rastreabilidade de requisitos.
FIGURA 44 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO COLETAR OS REQUISITOS
G
E
R
Ê
N
C
FONTE: PMI (2013)
I
A
Considerando que a quantidade de requisitos de um projeto pode ser muito grande,
D
sugere-se adotar uma ferramenta específica para o gerenciamento do escopo. Ex.: DotProject, E
OpenReq e OSRMT.
P
R
O
J
E
T
O
S
3 DEFINIR O ESCOPO
A definição do escopo tem como base o levantamento dos requisitos e as premissas e

restrições documentadas no início do projeto. Este processo é fortemente pautado pela tomada
de decisões no intuito de definir o que fará parte ou não do projeto.
As entradas para o processo definir o escopo são (PMI, 2013):
• plano de gerenciamento do escopo;

• termo de abertura do projeto;
FIGURA 45 – ENTRADAS, SAÍDA, FERRAMENTAS E TÉCNICAS DE DEFINIÇÃO DO ESCOPO
FONTE: PMI (2013)
As seguintes ferramentas e técnicas são utilizadas na definição do escopo (PMI, 2013):
G
E
R • análise do produto;
Ê • geração de alternativas;
N
C • oficinas facilitadas;
I
A
As saídas do processo de definição do escopo geram (PMI, 2013):
D
E
• declaração do escopo do projeto;
P • atualizações dos documentos do projeto.
R
O
J Para o registro das informações relativas à definição do escopo do projeto pode ser
E
utilizado um documento específico, também conhecido como declaração do escopo do projeto.
T
O Este documento pode possuir as seguintes informações:
S
• Escopo: descrição dos objetivos do documento de declaração do escopo do projeto.

• Objetivos: descrição dos objetivos do projeto.
• Requisitos: descrição dos requisitos do projeto.
• Limites: relação clara de todos os limites do projeto para que sejam investidos esforços
apenas na declaração de trabalho que realmente atenda aos objetivos do projeto.
• Entregas: descrição dos itens de entrega do projeto.
• Critérios de aceite: descrição clara dos critérios que deverão ser atendidos para que
sejam aceitas as entregas do projeto.
• Premissas: descrição do conjunto de premissas sobre as quais o projeto está apoiado.
• Restrições: descrição do conjunto de restrições às quais o projeto está sujeito.
• Riscos iniciais: relação dos principais riscos identificados durante o processo de
definição do escopo.
FIGURA 46 – FLUXOGRAMA DE DEFINIÇÃO DO ESCOPO
G
E
R
Ê
N
C
I
A
FONTE: PMI (2013)
D
E
A declaração de escopo varia de acordo com a complexidade do projeto, mantendo
interações com diversos outros processos do projeto. Pode ser detalhada em outras fases, P
R
acarretando mudanças na proposta inicial.
O
J
E
T
O
S
4 CRIAR A EAP
É uma estrutura analítica hierárquica que serve para orientar as entregas do projeto,
facilita as estimativas e gerenciamento do trabalho. Também referenciada como WBS (Work
Breakdown Structure) – termo original na língua inglesa.
A criação da EAP é o processo que facilita a decomposição das principais entregas do

projeto e do trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
O processo de criação da EAP possui as seguintes entradas (PMI, 2008):

FIGURA 47 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS DE CRIAÇÃO DA EAP
FONTE: PMI (2013)
G A EAP organiza e define o escopo total do projeto. Ela subdivide o trabalho em partes
E menores e mais facilmente gerenciáveis, em que cada nível descendente representa uma
R
Ê
definição cada vez mais detalhada do trabalho a ser realizado.
N
C
É possível agendar a realização, estimar custos, monitorar e controlar o trabalho
I
A planejado contido nos componentes de nível mais baixo da EAP, denominados pacotes
de trabalho. O processo de criação da EAP possui as seguintes ferramentas e técnicas a
D
E decomposição (PMI, 2008):
P
R A criação da EAP tem por objetivo dividir o escopo do projeto em partes menores e que
O possam ser gerenciadas com maior facilidade. Kerzner (2011) recomenda que o trabalho do
J
E projeto seja estruturado em pequenos elementos que sejam:
T
O
S
• gerenciáveis de modo que possam ser designadas autoridade e responsabilidade

específicas;
• independentes ou com o mínimo de interface e dependência de outros elementos em
curso;
• integráveis para que o pacote completo possa ser visualizado;
• mensuráveis em termos de progresso.
A técnica utilizada é a decomposição, que consiste em:

• Subdividir as entregas:
• Identificação e análise das entregas.
• Estrutura e organização da EAP.
• Decomposição em níveis mais baixos.
• Definir os códigos de identificação das atividades.
• Verificar se o grau de decomposição é necessário ou suficiente.
As saídas do processo de criação da EAP são (PMI, 2008):

• EAP;
• dicionário da EAP;
• linha de base do escopo;
A criação da EAP é um importante processo da área de conhecimento de escopo, pois

fornece uma estrutura comum da qual Kerzner (2011) descreve:
• o escopo total do projeto pode ser descrito como um somatório de elementos subdivididos;
• o planejamento pode ser realizado;
• os custos e orçamentos possam ser estabelecidos;
• tempo, custos e desempenho possam ser monitorados;
• os objetivos possam ser ligados logicamente a recursos da empresa;
G
• possam ser estabelecidos procedimentos para os cronogramas e os relatórios de E
progresso; R
Ê
• seja possível iniciar a construção de rede e o planejamento de controle;
N
• as designações de responsabilidades para cada elemento possam ser estabelecidas. C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 48 – FLUXOGRAMA DE CRIAÇÃO DA EAP
FONTE: PMI (2013)
A figura anterior demonstra o fluxograma de criação da EAP. Conforme descrito por

Kerzner (2011), a estrutura analítica de projeto pode ser usada para fornecer a base para:
G
• a matriz de responsabilidades;
E
R • a programação da rede do cronograma;
Ê
• o custeio;
N
C • a análise dos riscos;
I • a estrutura organizacional;
A
• a coordenação dos objetivos;
D • o controle, inclusive administração de contratos.
E
P A figura a seguir apresenta um exemplo de EAP para facilitar o entendimento da

R
O estrutura da mesma. A elaboração da EAP é uma atividade que pode envolver diversas
J pessoas do projeto, cada uma contribuindo com o refinamento de um ou mais grupos de
E
T
atividades.
O
S
FIGURA 49 – EXEMPLO DE EAP
FONTE: PMI (2013)
A EAP não é criada apenas para o gerente do projeto, mas para toda a equipe de
execução do projeto, bem como para as demais partes interessadas tais como clientes e
fornecedores. A EAP deve ser completa, organizada e pequena o suficiente para tornar
possível a medição do progresso, mas não detalhada o suficiente para se tornar, ela mesma,
um obstáculo à realização do projeto.
FONTE: Disponível em: < http://www.trabalhosfeitos.com/ensaios/Estrutura-Anal%C3%ADtica-De-

Projeto/53022803.html>. Acesso em: 11 maio 2015.
G
E
R
5 VERIFICAR O ESCOPO Ê
N
C
O processo de verificar o escopo tem a finalidade de aumentar a garantia de que as I
A
entregas do projeto atendem aos critérios inicialmente definidos. Este é um importante trabalho
de acompanhamento que não pode ser desconsiderado ou deixado em segundo plano dentre D
E
as atividades de gestão de um projeto. O processo de verificar o escopo possui as seguintes
entradas (PMI, 2013): P
R
O
• plano de gerenciamento do projeto; J
• documentação dos requisitos; E
T
• matriz de rastreabilidade de requisitos; O
S
• entregas validadas.
Conforme o PMI (2013), a verificação do escopo é o processo de formalização da

aceitação das entregas do projeto. A verificação do escopo implica a revisão dos entregáveis
com o cliente/usuário ou patrocinador do projeto para garantir que as entregas do projeto foram
realizadas satisfatoriamente.
FIGURA 50 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS DE VERIFICAÇÃO DO ESCOPO
FONTE: PMI (2013)
O objetivo fundamental do processo de verificação do escopo é obter do cliente/usuário

ou patrocinador do projeto o aceite formal dos entregáveis. Para garantia de que o resultado
do projeto será aceito é utilizada a ferramenta e técnica de inspeção (PMI, 2013).
É importante não confundirmos validação com verificação. A validação está tipicamente

associada ao controle da qualidade. A validação dos entregáveis do projeto deve ocorrer antes
do processo de verificação. É na validação que se pretende garantir que o produto do projeto
esteja correto. O processo de verificação do escopo possui as seguintes saídas (PMI, 2008):
• entregas aceitas;
G • solicitações de mudança;
E
• atualizações dos documentos do projeto;
R
Ê • relatórios de desempenho.
N
C
I A validação de entregáveis é garantia da qualidade de determinado artefato do projeto.
A O processo de validação de entregáveis deve ser realizado com muito critério, pois o entregável
D em questão deve atender aos critérios de aceite descritos no plano do projeto. A figura a seguir
E demonstra o fluxograma do processo de verificação do escopo com suas interações.
P
R
O
J
E
T
O
S
FIGURA 51 – FLUXOGRAMA DE VERIFICAÇÃO DO ESCOPO
FONTE: PMI (2013)
Uma vez garantido que o produto do projeto está correto, pode-se partir para a
verificação. Na verificação, a ideia central é certificar-se de que o produto do projeto esteja
atendendo às necessidades para as quais foi ou está sendo construído. Neste caso, o aceite
necessariamente deve ser dado por quem tem competência para indicar o atendimento ou
não da entrega.
6 CONTROLAR O ESCOPO G
E
R
Ê
É o processo de verificar e monitorar a execução das atividades detalhadas no escopo N
do projeto. Gerenciar mudanças solicitadas durante o ciclo de vida do projeto. O processo de C
I
controlar o escopo possui as seguintes entradas (PMI, 2013):
A
D
E
• informações sobre o desempenho do trabalho;
• documentação dos requisitos; P
R
• matriz de rastreabilidade de requisitos; O
• ativos de processos organizacionais. J
E
T
O
S
FIGURA 52 – ENTRADAS, SAÍDAS, FERRAMENTAS E TÉCNICAS DE CONTROLE DO ESCOPO
FONTE: PMI (2013)
Este processo visa garantir que todas as mudanças solicitadas – de correção ou

prevenção – sejam executadas e controladas pelo processo Controle Integrado de Mudanças.
A principal ferramenta e técnica utilizada para este processo é a análise da variação (PMI,
2013), que consiste em efetuar medições de desempenho do projeto usadas para averiguar as
variações do mesmo em relação ao escopo inicial. Isso é importante para determinar o grau
de divergência relativa ao escopo inicial e serve como forte indicador sobre a necessidade de
tomada de decisão em relação às ações corretivas, preventivas ou de melhorias.
Como saídas deste processo temos:
• medição do desempenho do trabalho;

• atualizações de ativos de processos organizacionais;
• solicitações de mudança;
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 53 – FLUXOGRAMA DE CONTROLE DO ESCOPO
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de controle do escopo. O escopo é

a principal ferramenta de controle utilizada pelo gestor para conduzir adequadamente o projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 2
Caro acadêmico! Nesse tópico, você estudou:
• Os processos de gerenciamento de escopo que é uma área de conhecimento de extrema

importância, pois serve de suporte para as demais áreas de conhecimento do projeto. É
responsável por definir tudo o que será realizado no projeto.
• Os processos de planejamento do escopo foram a base do projeto, garantindo um entendimento

comum das partes interessadas.
• A equipe do projeto deve participar do levantamento de requisitos, bem como da definição

do escopo e da montagem da Estrutura Analítica do Projeto (EAP).
• A EAP deve ser descrita em detalhes e cada componente deve estar corretamente ligado ao
componente superior.
• Quem gerencia e controla o Escopo é o gerente do projeto, exigindo dele proatividade no

levantamento e apontamento das causas das mudanças solicitadas.
A coleta de requisitos pode ser realizada com apoio de:
• Entrevistas.
• Dinâmicas de grupo.
• Oficinas.
G • Técnicas de criatividade em grupo.
E
R • Técnicas de tomada de decisão em grupo.
Ê • Questionários e pesquisas.
N
C • Observações.
I • Protótipos.
A
D A EAP permite que o escopo do projeto seja estruturado em pequenos elementos que possam
E
ser:
P
R • Gerenciáveis de modo que possam ser designadas autoridade e responsabilidade específicas.
O
J • Independentes ou com o mínimo de interface e dependência de outros elementos em curso.
E • Integráveis para que o pacote completo possa ser visualizado.
T
O • Mensuráveis em termos de progresso.
S

IDADE
ATIV
AUTO
1 Quais são os processos da área de conhecimentos de escopo?
2 Quais são as entradas do processo de coleta de requisitos?
3 A documentação de requisitos é entrada para qual processo?
4 Qual é a ferramenta e técnica utilizada no processo de verificação do escopo?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 2
TÓPICO 3
TEMPO
1 INTRODUÇÃO
O gerenciamento de tempo do projeto inclui os processos necessários para concluir o

projeto no prazo. Cada processo ocorre pelo menos uma vez em todos os projetos e ocorre
em uma ou mais fases do projeto, se o projeto estiver dividido em fases. Em alguns projetos,
especialmente nos de menor escopo, o sequenciamento de atividades, a estimativa de recursos
da atividade, a estimativa de duração da atividade e o desenvolvimento do cronograma estão
tão estreitamente ligados, que são considerados um único processo, que pode ser realizado
por uma pessoa durante um período de tempo relativamente curto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 54 – ÁREA DE CONHECIMENTO DE TEMPO
G
E Boa parte dos projetos de TI inicia com uma restrição de prazo de entrega. Logo, se a
R
Ê
data de término do projeto tem um limite imposto por necessidades de negócio, é função do
N gestor de projetos lidar com tal restrição com a devida atenção, fazendo uso de ferramentas
C
e técnicas adequadas.
I
A
Os processos do gerenciamento de tempo compreendem (PMI, 2008):
D
E
• planejar gerenciamento do tempo;
P
R • definir atividades;
O • sequenciar atividades;
J
E • estimar recursos da atividade;
T • estimar durações da atividade;
O
S
• desenvolver o cronograma;
• controlar cronograma.
Embora muitos softwares auxiliem no desenvolvimento do cronograma do projeto, é

importante que o gerente de projeto saiba criá-lo manualmente sem recursos tecnológicos, para
que ele domine as técnicas e posteriormente tire o máximo proveito das tecnologias disponíveis.
FIGURA 55 – PROCESSOS DE GERENCIAMENTO DO TEMPO
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: PMI (2013) O
S
2 GERENCIAR PLANEJAMENTO DO TEMPO
Este processo identifica as ferramentas, técnicas e os procedimentos que serão utilizados

na definição e planejamento do cronograma do projeto. O planejamento do tempo influencia
diretamente os outros processos, pois determina como serão executados.
As entradas deste processo são:

FIGURA 56 - ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE DEFINIÇÃO DE ATIVIDADES
FONTE: PMI (2013)
As técnicas utilizadas são:

• Validação por especialistas.
• Técnicas analíticas.
G • Reuniões.
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 57 – GERENCIAMENTO DO TEMPO DO PROJETO
FONTE: PMI (2013)
As saídas do processo:
• Plano de gerenciamento de tempo que deverá incluir:

• Metodologia para a criação do cronograma.
• Software e demais ferramentas utilizadas.
• Técnicas de sequenciamento e estimativas das atividades.
G
• Técnicas utilizadas para medir a performance e a variação em relação ao escopo. E
• Procedimentos de controle. R
Ê
N
C
I
A
3 DEFINIR ATIVIDADES
D
E
É o processo de identificação das ações específicas a serem realizadas para produzir as P
entregas do projeto. Neste processo, os pacotes de trabalho são decompostos nas atividades ou R
O
nas ações necessárias para construir e entregar cada um dos pacotes de trabalho identificados J
na EAP/WBS. E
T
O
S
A figura a seguir apresenta as entradas, ferramentas e técnicas e saídas do processo de

definição de atividades. As entradas do processo de definição de atividades são (PMI, 2013):
• Plano de gerenciamento de tempo.

• Linha de base do escopo: declaração do escopo, EAP.
• Fatores ambientais da empresa: softwares de gestão de projetos e cronograma.
• Ativos de processos organizacionais: modelos, checklist e templates.
FIGURA 58 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE DEFINIÇÃO DE ATIVIDADES
FONTE: PMI (2013)
Definir atividades é o primeiro processo da área de conhecimento. Gerir o tempo do

projeto, visto que fornece a informação necessária para os processos sequenciar e estimar
tanto a duração como os recursos. As ferramentas e técnicas do processo de definição das
atividades são (PMI, 2008):
• Decomposição: é a subdivisão das tarefas em pacotes;

• planejamento em ondas sucessivas: é a elaboração progressiva do que deve ser feito
priorizando atividades de futuro próximo;
G
• opinião especializada: opinião de especialistas.
E
R
Ê
Espera-se como saída deste processo: (PMI, 2008):
N
C • lista das atividades;
I • atributos das atividades: identificadores de cada atividade;
A
• lista dos marcos.
D
E
P
R
O
J
E
T
O
S
FIGURA 59 – PROCESSO DE DEFINIÇÃO DE ATIVIDADES
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de definição de atividades com

as relações estabelecidas com os demais processos de gestão de projeto.
4 SEQUENCIAR ATIVIDADES
G
E
Define a hierarquia de execução das atividades. Qual atividade antecede e qual é
R
sucessora de uma atividade em execução. Definir e sequenciar são processos distintos e Ê
não devem ser feitos ao mesmo tempo. No sequenciamento prioriza-se definir as relações de N
C
procedência e dependência entre as atividades. Isso evita que uma atividade seja interrompida I
pelo fato de requisitos necessários à sua execução não terem sido executados/implementados A
ainda. D
E
Existem quatro tipos de relacionamentos entre as atividades: P

R
O
• Término – Início: a segunda atividade só pode ser começada após a finalização da J
primeira. E
T
• Início – Início: a segunda atividade só pode ser iniciada após o início da primeira.
O
S
• Início – Término: a segunda atividade só pode terminar quando a primeira for iniciada.
• Término – Término: a segunda atividade só pode ser encerrada, quando a primeira for
finalizada.
O processo de sequenciamento das atividades possui as seguintes entradas (PMI, 2013):
• plano de gerenciamento do tempo;

• lista das atividades;
• atributos das atividades;
• lista dos marcos;
FIGURA 60 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE SEQUENCIAR AS ATIVIDADES
FONTE: PMI (2013)
O processo de sequenciamento das atividades possui as seguintes ferramentas e

técnicas (PMI, 2013):
G • determinação das dependências;
E
R • método do diagrama de precedência (MDP);
Ê • determinação de dependência;
N
C
• aplicação de antecipações e esperas;
I • modelos de diagrama de setas.
A
D No final da atividade de sequenciamento das atividades dos projetos, as saídas

E esperadas são (PMI, 2013):
P • diagramas de rede do cronograma do projeto;
R • atualizações dos documentos do projeto.
O
J
E
T
O
S
FIGURA 61 – PROCESSO DE SEQUENCIAR AS ATIVIDADES
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de sequenciamento de atividades

com as relações estabelecidas com os demais processos de gestão de projeto e artefatos
relacionados.
5 ESTIMAR RECURSOS DA ATIVIDADE G

E
R
Ê
Processo que analisa e define os tipos e quantidades de recursos materiais, humanos, ou N
qualquer outro tipo de suprimentos ou aquisições necessárias para a execução das atividades. C
I
Para realização das estimativas de recursos das atividades, as seguintes entradas utilizadas: A
(PMI, 2013):
D
• plano de gerenciamento de tempo; E
• lista das atividades;
P
• atributos das atividades;
R
• calendários de recursos; O
J
• registro dos riscos;
E
• estimativas de custos das atividades; T
• fatores ambientais e ativos de processos organizacionais. O
S
FIGURA 62 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE ESTIMAR RECURSOS DA

ATIVIDADE
FONTE: PMI (2013)
As estimativas devem ser baseadas na EAP e na lista de atividades. É importante

envolver as pessoas responsáveis pela execução das tarefas no intuito de obter estimativas
mais confiáveis. As técnicas utilizadas são (PMI, 2013):
• análise de alternativas;
• dados publicados para auxílio a estimativas;
• estimativa bottom-up;
• software de gerenciamento de projetos.
Uma vez realizada a atividade de determinação dos recursos para as atividades,

geralmente são geradas as seguintes saídas (PMI, 2013):
• requisitos do recurso da atividade;

• estrutura analítica dos recursos;
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 63 – PROCESSO DE ESTIMAR RECURSOS DA ATIVIDADE
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de estimativa de recursos para

as atividades com as relações estabelecidas com os demais processos de gestão de projeto
e artefatos relacionados.
6 ESTIMAR DURAÇÃO DA ATIVIDADE

G
E
Este processo analisa e determina o tempo total necessário para o desenvolvimento
R
de cada atividade. As seguintes entradas são fornecidas (PMI, 2013): Ê
N
C
• plano de gerenciamento de tempo; I
• lista das atividades; A
• atributos das atividades; D

• requisitos dos recursos da atividade; E
• calendários dos recursos; P

• declaração do escopo do projeto; R
O
• registro de riscos; J
• estrutura analítica dos recursos; E
T
• fatores ambientais da empresa;
O
• ativos de processos organizacionais. S
FIGURA 64 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE ESTIMAR DURAÇÃO DA

ATIVIDADE
FONTE: PMI (2013)
O gerente e sua equipe devem ser capazes de fazer estimativas corretas, documentando-
as e analisando-as sempre que for preciso. Além disso, devem analisar os riscos e incertezas.
Para facilitar o trabalho do gestor de projetos as seguintes ferramentas e técnicas são utilizadas
(PMI, 2013):
• estimativa análoga;
• estimativa paramétrica;
• estimativas de três pontos;
• análise das reservas.
Concluído o processo de estimativas as seguintes saídas são obtidas (PMI, 2008):

• estimativas da duração da atividade;
G
E • atualizações dos documentos do projeto.
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 65 – PROCESSO DE ESTIMAR DURAÇÃO DA ATIVIDADE
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de estimar a duração para as

atividades com as relações estabelecidas com os demais processos de gestão de projeto e
artefatos relacionados.
7 DESENVOLVER O CRONOGRAMA
G
E
R
Processo que faz a análise do diagrama e sequenciamento das atividades do projeto
Ê
com seus tempos e também os recursos humanos associados a elas. N
C
I
Este processo é dinâmico, necessitando de entradas dos demais processos de A
planejamento para ser construído. A equipe deve ser imparcial na elaboração do mesmo para
D
poder fazer um apontamento real e sem tendências. As seguintes entradas são fornecidas E
(PMI, 2013):
P
R
• plano de gerenciamento de tempo; O
J
• lista das atividades; E
• atributos das atividades; T
O
S
• diagramas de rede do cronograma do projeto;

• requisitos dos recursos da atividade;
• calendários dos recursos;
• estimativas da duração da atividade;
• registro de riscos;
• designações da equipe do projeto;
• estrutura analítica dos recursos;
• fatores ambientais da empresa;
FIGURA 66 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE DESENVOLVER O

CRONOGRAMA
FONTE: PMI (2013)
G
E A EAP contém a visão espacial do projeto sendo um importante documento para a
R construção do cronograma. Para o desenvolvimento do cronograma as seguintes ferramentas
Ê
N e técnicas são utilizadas (PMI, 2013):
C • análise da rede do cronograma;
I
A • método do caminho crítico;
• método da cadeia crítica;
D
E
• otimização dos recursos;
• técnicas de criação de modelos;
P
• análise do cenário “E- se”;
R
O • aplicação de antecipações e esperas (lead/lag);
J • compressão do cronograma;
E
T • ferramenta para desenvolvimento do cronograma.
O
S
As seguintes saídas são esperadas (PMI, 2013):

• cronograma do projeto;
• linha de base do cronograma;
• dados do cronograma;
• calendários do projeto;
• atualização do plano de gerenciamento do projeto;
FIGURA 67 – DIAGRAMA DO PROCESSO DESENVOLVER O CRONOGRAMA
G
E
R
Ê
N
C
I
FONTE: PMI (2013) A
D
Com o cronograma de cada etapa especificado é possível montar o cronograma geral E
do projeto, que poderá conter as seguintes informações: P
R
O
• Nome da atividade: identificação da atividade a ser desenvolvida.
J
• Duração: tempo necessário para execução da atividade (na unidade de tempo definida E
no projeto). T
O
• Início: data de início da atividade. Caso sejam informadas corretamente as durações S
das atividades predecessoras, a data de início da atividade corrente será calculada pelo
software de gerenciamento de projetos utilizado.
• Término: data de término da atividade. Caso seja informa corretamente a duração, a
data de término será calculada pelo software de gerenciamento de projetos utilizado.
• Predecessoras: a identificação de predecessoras serve para indicar as atividades
que devem iniciar ou terminar antes que a atividade atual possa iniciar ou terminar. A
informação correta das atividades predecessoras é fundamental para que se obtenha
o caminho crítico real do projeto.
A figura anterior apresenta o fluxograma do processo de desenvolver o cronograma

com as relações estabelecidas com os demais processos de gestão de projeto e artefatos
relacionados.
8 CONTROLAR CRONOGRAMA
Na atividade de controle do cronograma é registrado o progresso do projeto e controladas

as mudanças ocorridas no cronograma.
Basicamente o controle de cronograma gerencia os tempos e as mudanças ocorridas

no projeto. Para isso, deve:
• Possibilitar a qualquer momento a visualização atual do projeto e seu progresso;

• Gerenciar o cronograma, realocando recursos entre as tarefas;
• Calcular estimativas de atividades pendentes bem como a data para conclusão das
atividades do projeto;
• Controlar as solicitações de mudanças do projeto.
G
E Este processo possui as seguintes entradas (PMI, 2008):
R
Ê
N • cronograma do projeto;
C
I
A • ativos de processos organizacionais.
D
E
P
R
O
J
E
T
O
S
FIGURA 68 – ENTRADA, FERRAMENTAS E TÉCNICAS E SAÍDAS DE CONTROLE DO

CRONOGRAMA
FONTE: PMI (2013)
Este processo é de extrema importância para a identificação e análise dos desvios do

projeto, ou seja, daquilo que diverge do que foi proposto no cronograma em termos de tempo
e recursos. Para esta atividade, as seguintes ferramentas são utilizadas (PMI, 2013):

• análise de desempenho dos trabalhos;
• calendários do projeto;
• informações do cronograma;
As técnicas utilizadas por este processo são:

• análise de desempenho;
• análise de variação;
• software de gestão de projetos; G
E
• otimização dos recursos; R
• desenvolvimento de modelos; Ê
N
• antecipações e esperas; C
• compreensão do cronograma; I
A
• ferramenta de elaboração do cronograma.
D
E
Com a realização da atividade de controle do cronograma espera-se que as seguintes
saídas sejam obtidas (PMI, 2013): P
• medição do desempenho do trabalho; R
O
• atualizações de ativos de processos organizacionais; J
• solicitações de mudança; E
T
• atualizações do plano de gerenciamento do projeto; O
• atualizações dos documentos do projeto. S
FIGURA 69 – DIAGRAMA DO PROCESSO CONTROLAR O CRONOGRAMA
FONTE: PMI (2013)
A figura anterior apresenta o fluxograma do processo de controle do cronograma com as

relações estabelecidas com os demais processos de gestão de projeto e artefatos relacionados.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 3
Caro acadêmico! Nesse tópico você estudou que:
• O gerenciamento de tempo envolve os processos de criação e controle do cronograma para

garantir que o projeto seja finalizado na data estimada.
• A responsabilidade pela montagem do cronograma é da equipe e seu gerente de projetos.
• As atividades são definidas a partir da EAP, que é a decomposição dos objetivos do projeto.
• A estimativa de recursos leva em consideração o tipo de recurso e as quantidades necessárias

para a execução das atividades.
• A duração das atividades é definida com base na experiência de especialistas ou de bases

de dados de projetos anteriores.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Quais são os processos de gerenciamento do tempo em projetos, de acordo com o

PMBoK?
2 A principal causa de fracasso de projetos é de natureza técnica ou comportamental?
3 Quais são as entradas do processo de sequenciamento de atividades?
4 A análise de desempenho é uma ferramenta de qual processo de gerenciamento do

tempo em projetos?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 2
TÓPICO 4
CUSTO
1 INTRODUÇÃO
O gerenciamento de custos tem como objetivo estimar, gerenciar e controlar os custos e

orçamentos do projeto de todos os recursos necessários para a sua execução. O gerenciamento
de custos além de se preocupar com os custos específicos do projeto, pode também considerar
custos de manutenção ou outros custos externos que influenciam a viabilidade ou finalização
do mesmo.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 70 – ÁREA DE CONHECIMENTO DE CUSTOS
Os custos tendem a ser mais baixos no início do projeto, aumentando conforme a sua
evolução e influência das partes interessadas. A figura a seguir demonstra os processos de
G gerenciamento do custo em projetos.
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 71 – PROCESSOS DE GERENCIAMENTO DE CUSTO
G
FONTE: PMI (2013)
E
R
Ê
Para o registro das informações relativas ao planejamento do gerenciamento de custos N
deve ser utilizado o plano de projeto. O gerenciamento de custos do projeto inclui os processos C
I
envolvidos em planejamento, estimativa, orçamentação e controle de custos, de modo que seja
A
possível terminar o projeto dentro do orçamento definido. Os processos de gerenciamento de
custos do projeto incluem (PMI, 2008): D
E
• Planejar o gerenciamento dos custos.
• Estimar os custos. P
R
• Determinar o orçamento. O
• Controlar os custos. J
E
T
As entradas do processo: O
S

FIGURA 72 - ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DO GERENCIAMENTO DE

CUSTOS
FONTE: PMI (2013)
As técnicas utilizadas:
• Opinião especializada.
• Técnicas analíticas.
• Reuniões.
As saídas do processo:
• Plano de gerenciamento de custo.
2 ESTIMAR CUSTOS
G Realiza uma estimativa de valores acerca das atividades do projeto. Para elaborar a
E
R estimativa devem-se considerar os riscos envolvidos, bem como análise do compartilhamento de
Ê recursos para maior produtividade do projeto. Estas estimativas devem ser revistas e detalhadas
N
durante o progresso do projeto para que possam ser enquadrados detalhes adicionais ou
C
I excluídos, aumentando a confiabilidade do orçamento proposto.
A
D O gerente do projeto deve estar atento e evitar as questões abaixo (KERZNER, 2001):
E
P • Interpretação equivocada da declaração do trabalho.

R • Escopo definido inadequadamente ou omissões.
O
J • Cronograma mal definido ou excessivamente otimista.
E • Estrutura analítica do projeto inexata.
T
O • Aplicação inadequada dos níveis de qualificação para as tarefas.
S
• Falha em contabilizar os riscos.

• Falha em compreender ou contabilizar o aumento de custos ou a inflação.
• Falha no uso da técnica correta de estimativas.
• Falha na utilização da taxa de preços futuros para os custos de overhead, administrativos
e custos indiretos.
As entradas para o processo de estimativa de custos são (PMI, 2013):
• Plano de gerenciamento do custo.

• Plano de gerenciamento de recursos humanos.
• Linha de base do escopo.
• Cronograma do projeto.
• Registro dos riscos.
FIGURA 73 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE ESTIMAR OS CUSTOS
FONTE: PMI (2008)

G
E
As técnicas utilizadas no processo de estimativa de custos são (PMI, 2013): R
• opinião especializada; Ê
N
• estimativa análoga; C
• estimativa paramétrica; I
A
• estimativa “bottom-up”;
• estimativas de três pontos; D
E
• análise das reservas;
• custo da qualidade (CDQ); P
R
• software para estimativas em gerenciamento de projetos;
O
• análise de proposta de fornecedor; J
E
• técnicas de tomada de decisão em grupo.
T
O
S
Podem-se esperar as seguintes saídas do processo de estimativa de custos (PMI, 2013):

• estimativas de custos da atividade;
• bases de estimativas;
• atualizações nos documentos do projeto.
FIGURA 74 – DIAGRAMA DOS PROCESSOS DE ESTIMAR OS CUSTOS
FONTE: PMI (2013)
A figura anterior apresenta o diagrama do processo de estimativa de custos com as

relações estabelecidas com os demais processos de gestão de projeto e artefatos relacionados.
G
E
R Os custos podem ser classificados em (diretos ou indiretos) e (fixos ou variáveis). Os
Ê
N custos diretos remetem exclusivamente ao trabalho de execução do projeto. Os custos indiretos
C são divididos pela organização. Exemplo:
I
A
Custos diretos: salários, horas extras, materiais e equipamentos adquiridos para o
D
desenvolvimento das atividades;
E
P Custos indiretos: aluguel de máquinas, salas comerciais etc., e que são compartilhados
R
O com o restante da organização.
J
E
T Os custos fixos não variam. Ex.: equipamentos. Os custos variáveis são proporcionais
O à utilização. Ex.: valor hora de trabalho de cada componente da equipe.
S
3 DETERMINAR O ORÇAMENTO
Este processo documenta as reservas financeiras destinadas e autorizadas para

executar o projeto e servirá de base para medir o desempenho dos custos envolvidos em cada
etapa de customização.
FIGURA 75 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE DETERMINAR O

ORÇAMENTO
FONTE: PMI (2013)
Entradas previstas para o processo de Determinar o Orçamento: (PMI, 2013):

• plano de gerenciamento de custos;
• linha de base do escopo;
• estimativa de custos das atividades;
• bases de estimativas;
• calendários de recursos;
G
• registro de riscos; E
• contratos ou acordos; R
Ê
• ativos de processos organizacionais. N
C
I
Técnicas e ferramentas e técnicas são utilizadas (PMI, 2013): A
• agregação de custos;
D
• análise das reservas; E
P
• relações históricas;
R
• reconciliação do limite de recursos financeiros. O
J
E
As saídas resultantes desse processo são (PMI, 2013): T
O
S
• linha de base do desempenho de custos;

• requisitos dos recursos financeiros do projeto;
FIGURA 76 – DIAGRAMA DO PROCESSO DE DETERMINAR O ORÇAMENTO
FONTE: PMI (2013)
G
E A figura anterior apresenta o diagrama do processo de determinação do orçamento
R do projeto com as relações estabelecidas com os demais processos de gestão de projeto e
Ê
N artefatos relacionados.
C
I
A Após concluído, o orçamento deve ser analisado e validado, para posteriormente ser
aprovado pelas partes interessadas.
D
E
O processo de determinar orçamento é também conhecido como orçamentação e calcula
P
o custo total do projeto para determinar a necessidade ou não da utilização de reservas que
R
O podem ser caracterizadas como:
J • reservas de contingência: usadas em resposta aos riscos;
E
T • reservas gerenciais: orçamento extra direcionado aos riscos não previstos; montante
O que o gerente tem acesso para equilibrar e controlar o projeto.
S
4 CONTROLAR CUSTOS
Este processo mede e compara a evolução financeira do projeto com as determinações

e reservas orçamentárias pré-definidas.
Este processo deve ser eficiente em:

• influenciar fatores de mudança na linha de base de custos autorizada;
• garantir que as solicitações de mudança sejam executadas da forma correta;
• gerenciar as mudanças após a execução;
• garantir que os gastos não extrapolem o montante previsto;
• analisar o desempenho dos custos para entender as variações e causas das divergências;
• monitorar a evolução do trabalho comparando com os recursos financeiros consumidos;
• não permitir mudanças não aprovadas, a fim de não consumir sem necessidade efetiva
os recursos financeiros disponíveis;
• informar as partes interessadas acerca das mudanças aprovadas e seu impacto nas
finanças do projeto;
• permitir ações para que os custos fiquem dentro do limite estipulado;
As entradas para o processo de controle de custos são (PMI, 2008):

• requisitos dos recursos financeiros do projeto;
FIGURA 77 – ENTRADAS, FERRAMENTAS E TÉCNICAS E SAÍDAS DE CONTROLAR CUSTOS
G
E
R
Ê
N
C
I
A
D
E
P
FONTE: PMI (2013) R
O
J
E
T
O
S
As ferramentas e técnicas utilizadas no controle dos custos do projeto são (PMI, 2013):
• gerenciamento do valor agregado;
• previsão;
• índice de desempenho para término (IDPT);
• análise de desempenho;
• análise de reservas;
• software de gerenciamento de projetos.
As saídas desse processo são (PMI, 2008):

• medições de desempenho do trabalho;
• previsões de custos;
• solicitações de mudanças;
• atualizações no plano de gerenciamento do projeto;
• atualizações nos documentos do projeto;
• atualizações nos ativos de processos organizacionais.
FIGURA 78 – DIAGRAMA DO PROCESSO CONTROLAR CUSTOS
G
E
R
Ê
N
C
I
A
D
E
P FONTE: PMI (2013)

R
O
J A figura anterior apresenta o diagrama do processo de controle de custos do projeto
E
T com as relações estabelecidas com os demais processos de gestão de projeto e artefatos
O relacionados.
S
RESUMO DO TÓPICO 4
Caro acadêmico! Nesse tópico, você estudou que:
• Gerenciamento de custos envolve os processos necessários para estimar o montante

financeiro do projeto, desenvolver o orçamento e controlar outras despesas durante o ciclo de
vida do mesmo.
• O objetivo final deste processo é criar uma linha de base de custos real e executável para
o projeto.
• O gerente de projetos deve antecipar-se ao prever situações que acarretem em custos

adicionais ao projeto.
• Um projeto de sucesso é aquele que se desenvolve dentro do que foi planejado, principalmente
em relação aos custos, evitando que o projeto seja finalizado com resultados financeiros
negativos, gerando prejuízos às partes interessadas
• Um cronograma realista e bem especificado é uma importante entrada para a elaboração e

determinação dos custos.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Em qual documento de projeto devem ser registras informações relativas ao

planejamento do gerenciamento de custos do projeto?
2 Quais são os processos de gerenciamento de custos de projetos?
3 Relacione duas recomendações para o adequado controle dos custos do projeto.
4 Quais são as ferramentas e técnicas utilizadas para o controle dos custos?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
IAÇÃO
AVAL

G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
ÁREAS DE CONHECIMENTO PARA GESTÃO

DE PROJETOS
A partir desta unidade você será capaz de:
• conhecer a estrutura do PMBOK, cujo conteúdo contempla: as

entradas, ferramentas, técnicas e as saídas que orientam cada
processo;
• conhecer as áreas de conhecimento de gerenciamento de projetos
nos aspectos de qualidade; recursos humanos; comunicações;
riscos; aquisições; partes interessadas;
• conhecer os processos de cada área de conhecimento e sua
utilidade na gestão dos projetos.
PLANO DE ESTUDOS
Esta unidade está dividida em seis tópicos. No final de cada um

deles, você encontrará atividades que reforçarão o seu aprendizado.
TÓPICO 1 – GERENCIAMENTO DA QUALIDADE DO

PROJETO
TÓPICO 2 – GERENCIAMENTO DE RECURSOS

HUMANOS DO PROJETO G
E
TÓPICO 3 – GERENCIAMENTO DAS COMUNICAÇÕES R
DO PROJETO Ê
N
TÓPICO 4 – GERENCIAMENTO DE RISCO DO PROJETO C
I
TÓPICO 5 – GERENCIAMENTO DAS AQUISIÇÕES DO A
PROJETO
D
TÓPICO 6 – GERENCIAMENTO DAS PARTES E
INTERESSADAS
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 1
GERENCIAMENTO DA QUALIDADE DO
PROJETO
1 INTRODUÇÃO
A qualidade de software não é algo simples de definir. Mas é possível descrevê-la

como um conjunto de requisitos ou necessidades que variam de acordo com as diferentes
aplicações e os usuários ou clientes que as solicitam. Fatores de qualidade de softwares têm
duas classificações: internos e externos (MEYER, 1988). E o grau com que um conjunto de
características atende aos requisitos, sendo que grau é uma categoria atribuída aos produtos
ou serviços que possuem a mesma utilidade funcional, mas diferentes características técnicas
(TRENTIM, 2011).
Ainda de acordo com o autor, os fatores externos são aqueles cuja ausência em um
sistema computacional, pode ser facilmente percebida pelo usuário (velocidade, facilidade de
uso). Já os fatores internos são percebidos e apontados apenas pela equipe que desenvolve o
sistema (modularidade, falta de legibilidade no código, carência ergonômica etc.). E, apesar de
apenas os fatores externos terem importância e visibilidade para o usuário, os fatores internos
contemplam um meio para atingir a qualidade externa desejada no software (MEYER, 1988). G
E
R
Existe também outra forma de classificar os fatores ou atributos: atributos funcionais Ê
e não funcionais amplamente estudados pela engenharia de software. Os funcionais estão N
C
relacionados com o que deve ser feito. Os não funcionais, com o quão bem deve ser feito. I
O gerenciamento da qualidade de software complementa o gerenciamento de projetos, A
no reconhecimento e preocupação com:
D
 Satisfação do cliente: gerenciar a satisfação do cliente equilibrando as E
necessidades com as expectativas.
P
 Prevenção em vez de inspeção: a qualidade deve ser planejada, controlada e R
incorporada, em vez de inspecionada. O
J
 Melhoria contínua: a qualidade deve sempre ser acompanhada e suportada por E
metodologias de melhoria contínua. T
O
S
O gerenciamento da qualidade do projeto inclui os processos e as atividades

da organização executora que determinam as políticas de qualidade, os objeti-
vos e as responsabilidades, de modo que o projeto satisfaça às necessidades
para as quais foi empreendido. O gerenciamento da qualidade do projeto usa
as políticas e procedimentos para a implementação, no contexto do projeto,
do sistema de gerenciamento da qualidade da organização e, de maneira
apropriada, dá suporte às atividades de melhoria do processo contínuo como
empreendido no interesse da organização executora. O gerenciamento da qua-
lidade do projeto trabalha para garantir que os requisitos do projeto, incluindo
os requisitos do produto, sejam cumpridos e validados (PMI, 2013, p. 227).
2 PROCESSOS DE GERENCIAMENTO DA QUALIDADE DO PROJETO
Conforme a estrutura do PMI (2013, p. 227), a área de conhecimento de gerenciamento

da qualidade do projeto está dividida em alguns processos, a saber:
 Planejar o gerenciamento da qualidade – o processo de identificação dos requisitos

e/ou padrões da qualidade do projeto e suas entregas, além da documentação de como
o projeto demonstrará a conformidade com os requisitos e/ou padrões de qualidade.
 Realizar a garantia da qualidade – o processo de auditoria dos requisitos de qualidade
e dos resultados das medições do controle de qualidade para garantir o uso dos padrões
de qualidade e das definições operacionais apropriadas.
 Realizar o controle da qualidade – o processo de monitoramento e registro dos
resultados da execução das atividades de qualidade para avaliar o desempenho e
recomendar as mudanças necessárias.
A Figura 1 nos mostra uma visão sobre o modelo de gerenciamento de projetos do PMI
com ênfase na área de gerenciamento da qualidade do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 79 – VISÃO GERAL DO GERENCIAMENTO DA QUALIDADE
FONTE: PMI (2013)
Na sequência, detalharemos cada um dos processos desta área de conhecimento. G

E
R
Ê
N
C
2.1 PLANEJAR A QUALIDADE I
A
A figura a seguir apresenta os elementos de entrada, ferramentas e técnicas e as saídas D

E
do processo Planejar a Qualidade, conforme PMI (2013):
P
R
O
J
E
T
O
S
FIGURA 80 – PROCESSO PLANEJAR A QUALIDADE, ENTRADAS, FERRAMENTAS E TÉCNICAS

E SAÍDAS
FONTE: PMI (2013)
A figura a seguir apresenta o diagrama de fluxo de dados do processo Planejar a

Qualidade no qual se inclui a participação de entregáveis de outros processos como se mostra
a seguir:
FIGURA 81 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR A QUALIDADE
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O FONTE: PMI (2013)
S
2.1.1 Definição do processo
É o processo responsável pela identificação dos requisitos e padrões de qualidade do

projeto e do produto. Especifica e documenta como o projeto demonstrará a conformidade.
Este é o processo que define como os outros serão executados.
2.1.2 Entradas do processo
As entradas do processo são:
 linha de base do escopo;

 registro das partes interessadas;
 linha de base do desempenho de custo;
 registro dos riscos;
 atores ambientais da empresa;
 ativos de processos organizacionais.
2.1.3 Ferramentas e técnicas
São utilizadas as seguintes ferramentas e técnicas:
 análise custo-benefício;
G
 custo da qualidade; E
 gráficos de controle; R
Ê
 benchmarking;
N
 projeto de experimentos; C
 amostragem estatística; I
A
 elaboração de fluxogramas;
 metodologia proprietária de gerenciamento da qualidade; D
E
 ferramentas adicionais de planejamento da qualidade.
P
R
O
J
E
T
O
S
2.1.4 Saídas do processo
 plano de gerenciamento da qualidade;

 métricas da qualidade;
 listas de verificação da qualidade;
 plano de melhorias no processo;
 atualizações dos documentos do projeto.
2.2 REALIZAR A GARANTIA DA QUALIDADE
O processo de Planejar a Qualidade identifica os padrões e procedimentos a serem

seguidos pelo projeto. Mas, não basta definir e documentar os requisitos. É preciso garantir
que sejam executados corretamente. Para isso, existe o processo Realizar a Garantia da
Qualidade, responsável por executar todas as atividades que envolvam a qualidade do projeto.
É um processo que usa informações durante o processo Realizar Controle da Qualidade.
O gerente de projeto, a equipe de desenvolvimento e as demais partes interessadas
são responsáveis pela garantia da qualidade do projeto, devendo sempre buscar a melhoria
contínua de todos os processos envolvidos.
A figura a seguir apresenta os elementos de entrada, ferramentas e técnicas e as saídas

do processo Realizar a Garantia da Qualidade, conforme PMI (2013):
FIGURA 82 – PROCESSO REALIZAR A GARANTIA DA QUALIDADE, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
G
E
R
Ê
N
C
I
A
D
E
FONTE: PMI (2013)
P
R
O
J
E
T
O
S
A próxima figura apresenta o diagrama de fluxo de dados do processo Realizar a

Garantia da Qualidade que inclui a participação de entregáveis de outros processos como se
mostra a seguir:
FIGURA 83 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO REALIZAR A GARANTIA DA

QUALIDADE
FONTE: PMI (2013)
2.2.1 Definição do processo
G
É o processo de auditoria dos requisitos de qualidade e dos resultados das medições E
R
de controle da qualidade para garantir que sejam usados os padrões de qualidade e definições Ê
operacionais apropriados. N
C
I
A
D
2.2.2 Entradas do processo E
P
 Plano de gerenciamento da qualidade R
O
 Plano de melhorias do processo J
 Métricas da qualidade E
T
 Medições de controle da qualidade O
 Documentos do projeto S
2.2.3 Ferramentas e técnicas
 Ferramentas e técnicas de planejar a qualidade e realizar o controle da qualidade.

 Auditorias de qualidade.
 Análise de processos.
 Atualizações dos ativos de processos organizacionais.

 Solicitações de mudanças.
 Atualizações do plano de gerenciamento do projeto.
 Atualizações dos documentos do projeto.
O processo Realizar a garantia da qualidade implementa um conjunto de ações

e processos planejados e sistemáticos dentro do plano de gerenciamento da
qualidade do projeto. A garantia da qualidade visa assegurar que uma saída
futura ou uma saída não terminada, também conhecida como trabalho em
andamento, seja concluída de forma a cumprir os requisitos e expectativas
especificados. A garantia de qualidade contribui para o estado de certeza
sobre a qualidade ao impedir os defeitos nos processos de planejamento
ou ao eliminar tais defeitos na inspeção realizada durante a etapa trabalho-
-em-andamento de implementação. Realizar a garantia da qualidade é um
processo de execução que usa dados criados durante os processos Planejar
o gerenciamento da qualidade e Controlar a qualidade. (PMI, 2013, p. 243).
2.3 REALIZAR O CONTROLE DA QUALIDADE

G
E
R
Ê Este é o processo responsável pelo monitoramento e registro dos resultados e medições
N da qualidade, que é executado durante todo o projeto. É um processo de acompanhamento,
C
I supervisão e medição. É um processo que tem as atribuições de medir as variáveis do projeto
A conforme o plano de gerenciamento no intuito de verificar se os requisitos estão sendo atingidos.
D
E A figura, a seguir, apresenta os elementos de entrada, ferramentas e técnicas e as
P saídas do processo Realizar o Controle da Qualidade, conforme PMI (2013):

R
O
J
E
T
O
S
FIGURA 84 – PROCESSO REALIZAR O CONTROLE DA QUALIDADE, ENTRADAS,

FERRAMENTAS, TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo Realizar o

Controle da Qualidade que inclui a participação de entregáveis de outros processos como se
mostra a seguir:
FIGURA 85 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO REALIZAR O CONTROLE DA

QUALIDADE
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
FONTE: PMI (2013) S
2.3.1 Ciclo de controle: definição do processo
É o processo responsável pelo monitoramento e registro dos resultados e medição da

qualidade. Este processo é executado durante todo o projeto. Aqui, existe a preocupação de
verificar se os processos e procedimentos corretos estão sendo cumpridos durante o processo,
e também, se estes, são a melhor alternativa ou opção naquele momento.
É importante que a equipe do projeto tenha conhecimento acerca das estatísticas da
qualidade, de modo a avaliar as suas saídas através de:
 Prevenção: mantém os erros fora do processo;

 Inspeção: mantém os erros fora do alcance do cliente;
 Amostragem de atributos: verifica se o resultado está e, conformidade ou não;
 Amostragem de variáveis: verifica se o resultado é classificado em uma escala contínua
que mede o grau de conformidade;
 Tolerâncias: intervalo de resultados aceitáveis;
 Limites de controle: são os limites que podem indicar que o processo está fora do
controle.
2.3.2 Ciclo de controle: entradas do processo
 Plano de gerenciamento do projeto.

 Métricas da qualidade.
 Listas de verificação da qualidade.
 Medições de desempenho do trabalho.
G  Solicitações de mudanças aprovadas.
E
R
 Entregas.
Ê  Documentos do projeto.
N
 Ativos de processos organizacionais.
C
I
A
D
E 2.3.3 Ciclo de controle: ferramentas e técnicas
P
R
O  Diagrama de causa e efeito.
J  Gráficos de controle.
E
T  Fluxograma.
O  Histograma.
S
 Gráfico de execução.
 Diagrama de dispersão.
 Diagrama de pareto.
 Amostragem estatística.
 Inspeção.
 Revisão de solicitações de mudança aprovadas.
2.3.4 Ciclo de controle: saídas do processo
 Medições do controle da qualidade.

 Mudanças validadas.
 Entregas verificadas.
 Informações sobre o desempenho do trabalho.
O processo Controlar a qualidade usa um conjunto de técnicas e tarefas ope-

racionais para verificar se a saída entregue cumprirá os requisitos. A garantia
da qualidade deve ser usada durante as fases de planejamento e execução
do projeto para transmitir a confiança de que os requisitos da parte interes-
sada serão cumpridos, e o controle da qualidade deve ser usado durante as
fases de execução e encerramento para demonstrar formalmente, com dados
confiáveis, que os critérios de aceitação do patrocinador ou do cliente foram
cumpridos. (PMI, 2013, p. 250).
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 1
Neste tópico vimos que:
• Qualidade é um assunto muito discutido e difundido nas organizações, conceito utilizado

inicialmente na indústria para controle da produção, mas que, posteriormente, se ramificou
também para a área da tecnologia da informação com seus produtos e serviços.
• O próprio gerenciamento de projetos é uma ação em direção da busca da qualidade, pois

visa estabelecer processos para atingir os objetivos e acordos estabelecidos com os clientes.
• O controle da qualidade é fundamental para que o sucesso nos resultados dos projetos seja
atingido. Este gerenciamento se faz necessário devido à grande complexidade e exigência
em torno dos projetos.
• O objetivo mais importante desta área é garantir que o projeto seja concluído dentro da
qualidade desejada, garantindo a satisfação das necessidades de todos os envolvidos.
• O gerente de projeto é o principal responsável pelo gerenciamento da qualidade no projeto.
• Alguns fatores que influenciam a necessidade de melhoria de processos do projeto:
• exigência de alto desempenho;

• ciclo de vida de desenvolvimento de produtos reduzido;
• níveis tecnológicos elevados;
G • processos e equipamentos levados constantemente a condições limítrofes.
E
R
Ê • Conforme a estrutura do PMI (2013), a área de conhecimento de gerenciamento da qualidade
N
C do projeto é composta dos seguintes processos:
I
A
• planejar a qualidade;
D • realizar a garantia da qualidade;
E
• realizar o controle da qualidade.
P
R • Cada processo descrito possui as entradas, as ferramentas, as técnicas e as saídas.
O
J • O plano de gerenciamento da qualidade é também um documento auxiliar do plano de
E gerenciamento de projetos que descreve os procedimentos que serão utilizados para gerenciar
T
O todos os aspectos da qualidade do projeto.
S

IDADE
ATIV
AUTO
1 Qual é o objetivo da área de conhecimento de gerenciamento da qualidade do projeto?
2 Cite cinco ferramentas e/ou técnicas do processo Planejar a Qualidade.
3 Quais são os fatores estudados que impulsionam as necessidades de melhorias nos

processos da qualidade?
4 Cite os processos que compõem a área de conhecimento de gerenciamento da

qualidade do projeto.
5 Qual é o principal produto dos processos da área de gerenciamento da qualidade?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 2
GERENCIAMENTO DE RECURSOS
HUMANOS DO PROJETO
1 INTRODUÇÃO
O gerenciamento de um projeto de software é um processo decisório que envolve o

uso de recursos, tanto materiais como humanos, para coordenar, controlar e realizar atividades
temporárias para atingir um objetivo específico. Coordenar pessoas com tecnologia não é tarefa
fácil e exige um esforço coordenado por parte dos envolvidos.
Projetos de software dependem diretamente das pessoas para serem bem-sucedidos,

cujo capital alocado é o intelectual, sendo compartilhado, muitas vezes, por vários projetos
e trabalhos distintos. Geralmente é por falta de controle nos profissionais que os projetos de
software saem do escopo planejado, o que gera atrasos e eleva os custos.
Uma gestão eficiente de recursos humanos pode reduzir gastos, utilizando menos
pessoas na execução de atividades planejadas da forma adequada.
O gerenciamento dos recursos humanos do projeto inclui os processos que organizam,

gerenciam e guiam a equipe do projeto. A equipe do projeto consiste das pessoas com G
papéis e responsabilidades designadas para completar o projeto. Os membros da equipe E
do projeto podem ter vários conjuntos de habilidades, atuar em regime de tempo integral R
ou parcial, e podem ser acrescentados ou removidos da equipe à medida que o projeto Ê
progride. Os membros da equipe do projeto também podem ser referidos como pessoal N
do projeto. Embora os papéis e responsabilidades específicos para os membros da
C
equipe do projeto sejam designados, o envolvimento de todos os membros da equipe
no planejamento do projeto e na tomada de decisões pode ser benéfico. A participa-
I
ção dos membros da equipe durante o planejamento agrega seus conhecimentos ao A
processo e fortalece o compromisso com o projeto. (PMI, 2013, p. 255).
D
E
P
R
O
J
E
T
O
S
2 PROCESSOS DE GERENCIAMENTO DE RECURSOS

HUMANOS DO PROJETO
Conforme a estrutura do PMI (2013, p. 255), a área de conhecimento de gerenciamento

de recursos humanos do projeto está dividida em alguns processos:
 Desenvolver o plano dos recursos humanos – O processo de identificação

documentação de papéis, responsabilidades, habilidades necessárias, relações
hierárquicas, além da criação de um plano de gerenciamento do pessoal.
 Mobilizar a equipe do projeto – O processo de confirmação da disponibilidade
dos recursos humanos e obtenção da equipe necessária para terminar as
atividades do projeto.
 Desenvolver a equipe do projeto – O processo de melhoria de competências, da
interação da equipe e do ambiente geral da equipe para aprimorar o desempenho
do projeto.
 Gerenciar a equipe do projeto – O processo de acompanhar o desempenho
dos membros da equipe, fornecer feedback, resolver problemas e gerenciar
mudanças para otimizar o desempenho do projeto.
O gerente de projetos é a pessoa que gerencia a equipe, e não pode transferir esta
responsabilidade. Ele deve acompanhar e avaliar o desempenho individual e coletivo da equipe.
No início do projeto a equipe é reduzida composta apenas pelos integrantes envolvidos

na parte de gerenciamento. Após esta fase é necessário alocar um número maior de profissionais
para iniciar a execução. A quantidade de pessoas alocadas bem como a qualidade profissional.
A seguinte figura apresenta o resumo dos processos da área de conhecimento do

gerenciamento de recursos humanos do projeto (PMI, 2013).
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 86 – RESUMO DO GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO
G
E
R
Ê
N
FONTE: PMI (2013)
C
I
A
Na sequência, detalharemos cada um dos processos desta área de conhecimento.
D
E
P
R
2.1 DESENVOLVER O PLANO DE RECURSOS HUMANOS
O
J
E
A figura, a seguir, apresenta os elementos de entrada, ferramentas e técnicas e as saídas T
do processo de desenvolver o plano de recursos humanos, conforme PMI (2013): O
S
FIGURA 87 – PROCESSO DE DESENVOLVER O PLANO DE RECURSOS HUMANOS, ENTRADAS,

FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo de desenvolver

o plano de recursos humanos que inclui a participação de entregáveis de outros processos
como se mostra a seguir:
FIGURA 88 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO DE DESENVOLVER O PLANO

DE RECURSOS HUMANOS
G
E
R
Ê
N
C
I
A
D
E
P
R
FONTE: PMI (2013)
O
J
E
T
O
S
2.1.1 Ciclo de planejamento: definição de processo
Este processo compreende a identificação e documentação de funções, responsabilidades

e relações hierárquicas do projeto, além da criação do plano de gerenciamento de pessoal.
Apesar de o índice de sucesso em projetos de software ter evoluído bastante, ainda
podemos pensar em muitas melhorias para que os projetos sejam entregues com prazo,
orçamento e qualidade adequadas às necessidades e expectativas dos compradores.
Uma possível solução para alcance do sucesso e fazer com que a gerência do projeto
foque mais na alocação de recursos humanos em atividades que componham estes projetos.
Pessoas são um dos fatores de menos destaque nos processos de desenvolvimento de
software atuais. Porém, a importância do assunto é crítica: softwares dependem diretamente
das pessoas para serem construídos, sendo que influenciam diretamente a produtividade no
desenvolvimento, considerada acima de tudo como uma atividade intelectual e social.
Alocar recursos em atividades técnicas requer posicionamento do gestor. O gerente,

primeiro, precisa decidir que pessoa vai alocar em cada atividade. Para isso, ele precisa
conhecer os conhecimentos, habilidades e experiências de cada pessoa de sua equipe, além
da formação acadêmica de cada um. Deverá entender cada atividade e seus requisitos, a fim
de alocar adequadamente a pessoa com o trabalho que deverá ser desenvolvido. Não é um
trabalho rápido e muito menos fácil, se considerarmos a quantidade de combinações possíveis
para tratar a alocação das pessoas.
Para a alocação das pessoas geralmente são considerados os fatores:
 Das pessoas: competências e formação que as pessoas possuem; intervalos em

que estão disponíveis; valor da hora de trabalho etc.
 Do projeto: os dados do projeto – atividades a serem desempenhadas, as G
competências e formação necessárias para a realização de cada tarefa, o período em que a E
R
atividade precisa ser feita etc.
Ê
N
C
I
A
2.1.2 Ciclo de planejamento: Entradas do processo
D
E
 Plano de gerenciamento do projeto. P

 Requisitos de recursos das atividades. R
O
 Fatores ambientais da empresa. J
 Ativos de processos organizacionais. E
T
O
S
2.1.3 Ciclo de planejamento: ferramentas e técnicas
 Organogramas e descrições de cargos.

 Rede de relacionamentos – MR – Matriz de Responsabilidade.
 Teoria organizacional.
 Opinião especializada.
 Reuniões.
2.1.4 Ciclo de planejamento: saídas do processo
 Plano de Recursos Humanos.
2.2 MOBILIZAR A EQUIPE DO PROJETO
FIGURA 89 – PROCESSO DESENVOLVER A EQUIPE DO PROJETO, ENTRADAS,

G
E
R
Ê FONTE: PMI (2013)
N
C
I A figura a seguir apresenta o diagrama de fluxo de dados do processo Mobilizar a Equipe
A do Projeto que inclui a participação de entregáveis de outros processos como se mostra a seguir:
D
E
P
R
O
J
E
T
O
S
FIGURA 90 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO MOBILIZAR A EQUIPE DO

PROJETO
FONTE: PMI (2013)
2.2.1 Ciclo de execução: definição do processo

G
E
R
Este é o processo que integra a equipe ao projeto, que pode ir desde a coordenação do Ê
início dos trabalhos até a contratação de mais profissionais, caso a equipe não esteja completa N
C
ou apresente carências em determinados conhecimentos. I
É importante que os seguintes fatores sejam considerados durante o processo de A
mobilização da equipe do projeto: D
E
 O gerente de projetos ou a equipe de gerenciamento de projetos deve P

R
negociar com eficácia e influenciar outras pessoas que estejam em uma
O
posição de fornecer os recursos humanos necessários para o projeto. J
E
 Deixar de mobilizar os recursos humanos necessários para o projeto pode T
O
S
afetar os cronogramas e orçamentos, a satisfação do cliente, a qualidade

e os riscos. Pode reduzir a probabilidade de êxito e, em última instância,
resultar em cancelamento do projeto.
 Se os recursos humanos não estiverem disponíveis devido a restrições,

fatores econômicos ou designações anteriores para outros projetos, o
gerente de projetos ou a equipe do projeto pode precisar designar recursos
alternativos, talvez com menos competências, desde que não ocorra
infração de requisitos jurídicos, regulatórios, obrigatórios ou outros critérios
específicos.
2.2.2 Ciclode execução: entradas do processo

 Fatores ambientais da empresa.
2.2.3 Ciclo de execução: ferramentas e técnicas
 Pré-designação.
 Negociação.
 Contratação.
 Equipes virtuais.
G
E
R
Ê 2.2.4 Ciclo de execução: Saídas do processo
N
C
I a) Designações do pessoal do projeto.
A
b) Calendários dos recursos.
D c) Atualizações do plano de gerenciamento do projeto.
E
P
R
O
J
E
T
O
S
2.3 DESENVOLVER A EQUIPE DO PROJETO
A figura a seguir apresenta os elementos de entrada, ferramentas, técnicas e as saídas

do processo Desenvolver a Equipe do Projeto, conforme PMI (2013):
FIGURA 91 – PROCESSO DESENVOLVER A EQUIPE DO PROJETO, ENTRADAS,

FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo Desenvolver

a Equipe do Projeto que inclui a participação de entregáveis de outros processos como se
mostra a seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 92 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO DESENVOLVER A EQUIPE DO

PROJETO
FONTE: PMI (2013)
G
E
R Este processo tem como objetivo melhorar as competências individuais e desenvolver
Ê
N
a equipe do projeto tem como objetivo melhorar as competências individuais e aperfeiçoar a
C integração entre a equipe de desenvolvimento. Este processo deve ocorrer sempre, porém
I
traz melhores resultados quando aplicado já no início do projeto. Desenvolver o colaborador
A
nos requisitos técnicos, comportamentais e até gerenciais forma uma base sólida para o
D crescimento de toda a equipe.
E
Aspectos importantes do desenvolvimento de equipes em projetos:
P  Os gerentes de projetos devem adquirir habilidades para identificar, construir,
R
O manter, motivar, liderar e inspirar as equipes de projetos a alcançar um alto
J desempenho da equipe e cumprir os objetivos do projeto. O trabalho em equipe
E
T é um fator essencial para o êxito do projeto, e desenvolver equipes de projetos
O eficazes é uma das responsabilidades primárias do gerente de projetos. Os
S
gerentes de projetos devem criar um ambiente que facilite o trabalho em equipe.
 Os gerentes de projetos devem motivar a equipe continuamente fornecendo

desafios e oportunidades, oferecendo feedback e apoio conforme necessário
e reconhecendo e recompensando o bom desempenho. Uma equipe de alto
desempenho pode ser alcançada usando comunicações abertas e eficazes,
desenvolvendo a confiança entre os membros da equipe, administrando conflitos
de forma construtiva e estimulando soluções de problemas e tomadas de
decisão de forma colaborativa. O gerente de projetos deve solicitar o apoio da
administração e/ou influenciar as partes interessadas apropriadas para mobilizar
os recursos necessários para desenvolver equipes de projeto eficazes.
 Os gerentes de projetos atuais operam em um ambiente global e trabalham em

projetos caracterizados por diversidade cultural. Com frequência, os membros da
equipe têm experiência em setores diversos, vários idiomas e, às vezes, operam
na ”linguagem da equipe”, adotando uma linguagem ou uma norma que não é a
sua nativa. A equipe de gerenciamento de projetos deve aproveitar as diferenças
culturais, concentrar-se em desenvolver e apoiar a equipe do projeto ao longo
do ciclo de vida do mesmo, e promover o trabalho de forma interdependente,
em um clima de confiança mútua. Desenvolver a equipe do projeto melhora
as habilidades das pessoas, as competências técnicas, o ambiente global da
equipe e o desempenho do projeto. Requer comunicação clara, oportuna, eficaz
e eficiente entre os membros da equipe ao longo da vida do projeto. Os objetivos
de desenvolver uma equipe de projeto incluem, entre outros.
 Aprimorar os conhecimentos e as habilidades dos membros da equipe para

aumentar sua capacidade de concluir as entregas do projeto, reduzir os custos,
reduzir os cronogramas e melhorar a qualidade.
 Aprimorar os sentimentos de confiança e consenso entre os membros da equipe G

para melhorar a motivação, reduzir os conflitos e aumentar o trabalho em equipe. E
R
Ê
 Criar uma cultura de equipe dinâmica e coesa para aumentar a produtividade N
individual e da equipe, o espírito de equipe e a cooperação, e habilitar o C
I
treinamento e mentoria entre os próprios membros da equipe para compartilhar A
conhecimentos e experiências.
D
E
P
R
O
J
E
T
O
S
2.3.2 Ciclo de execução: entradas do processo
 Designações do pessoal do projeto.

 Calendários dos recursos.
2.3.3 Ciclo de iniciação: ferramentas e técnicas
 Habilidades interpessoais.
 Treinamento.
 Atividades de construção da equipe.
 Regras básicas.
 Agrupamento.
 Reconhecimento e recompensas.
2.3.4 Ciclo de iniciação: saídas do processo
 Avaliações de desempenho da equipe.

 Atualizações dos fatores ambientais da empresa.
G
E 2.4 GERENCIAR A EQUIPE DO PROJETO
R
Ê
N A figura a seguir apresenta os elementos de entrada, ferramentas, técnicas e as saídas
C
I
do processo Gerenciar a Equipe do Projeto, conforme PMI (2013):
A
D
E
P
R
O
J
E
T
O
S
FIGURA 93 – PROCESSO GERENCIAR A EQUIPE DO PROJETO, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
A figura seguinte apresenta o diagrama de fluxo de dados do processo Gerenciar a

Equipe do Projeto que inclui a participação de entregáveis de outros processos como se mostra
a seguir:
FIGURA 94 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO GERENCIAR A EQUIPE DO

PROJETO
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
FONTE: PMI (2013) O
S
Gerenciar a equipe do projeto é o processo de acompanhar o desempenho de membros

da equipe, fornecer feedback, resolver questões e gerenciar mudanças para otimizar o
desempenho do projeto. A equipe de gerenciamento do projeto observa o comportamento
da equipe, gerencia os conflitos, resolve questões e avalia o desempenho dos membros da
equipe. Como resultado do gerenciamento da equipe do projeto, as solicitações de mudanças
são encaminhadas, o plano de recursos humanos é atualizado, as questões são resolvidas,
são fornecidos comentários para as avaliações de desempenho e as lições aprendidas são
acrescentadas ao banco de dados da organização.
Gerenciar a equipe do projeto requer diversas habilidades de gerenciamento para
estimular o trabalho em equipe e integrar os esforços dos membros da equipe para criar equipes
de alto desempenho. O gerenciamento da equipe envolve uma combinação de habilidades,
com ênfase especial em comunicação, gerenciamento de conflitos, negociação e liderança.
Os gerentes de projetos devem fornecer tarefas desafiadoras para os membros da equipe e
reconhecimento pelo alto desempenho.
FONTE: Disponível em: <http://projetoseti.com.br/execucao-do-projeto-mobilizar-desenvolver-e-

gerenciar-a-equipe-do-projeto-recursos-humanos/>. Acesso em: 10 maio 2015.
 Designações do pessoal do projeto.

 Avaliação do desempenho da equipe.
G
E
 Relatório de desempenho.
R  Ativos de processos organizacionais.
Ê
N
C
I
A
D
E
 Observação e conversas.
P
R  Avaliações de desempenho do projeto.
O  Gerenciamento de conflitos.
J
E  Registro das questões.
T  Habilidades interpessoais.
O
S
2.4.4 Ciclo de execução: saídas do processo
 Atualizações dos fatores ambientais da empresa.

 Atualizações dos ativos dos processos.
 Solicitações de mudança.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 2
• Os projetos são altamente dependentes dos recursos associados à sua execução,

principalmente em relação aos recursos humanos.
• Assim como os outros tipos de recursos dos projetos, os recursos humanos devem ser
planejados e devidamente alocados para que o sucesso de um projeto seja possível.
• Em relação aos recursos humanos, podemos dizer que é uma das partes mais sensíveis
dos projetos, pois lida com aspectos do relacionamento interpessoal e, para isso, é necessário
possuir conhecimentos e habilidades para estes tratamentos.
• O gerenciamento de recursos humanos do projeto inclui os processos que organizam e

gerenciam a equipe do projeto. A equipe do projeto consiste nas pessoas com papéis e
responsabilidades designadas para a conclusão do projeto.
• Tem como objetivo central fazer o melhor uso dos indivíduos envolvidos no projeto. As
pessoas são o elo central dos projetos e seu recurso mais importante. Definem as metas, os
planos, organizam o trabalho, produzem os resultados, direcionam, coordenam e controlam
as atividades do projeto.
• A área de conhecimento de gerenciamento de recursos humanos do projeto está dividida

em quatro processos:
G
E
R • desenvolver o plano de recursos humanos;
Ê • mobilizar a equipe do projeto;
N
C • desenvolver a equipe do projeto;
I • gerenciar a equipe do projeto.
A
D • No gerenciamento de recursos humanos, é importante atentar para:

E
P • o trabalho em time é vital para o sucesso do projeto;

R • o espírito de corpo contribui para o sucesso;
O
J • conflitos podem ocorrer entre o projeto e a organização;
E • qualquer promessa feita durante o recrutamento deve ser documentada;
T
O • os níveis de equipes são muito mais variáveis em um ambiente de projeto que em
S
um ambiente funcional;
• treinamento e desenvolvimento são mais complexos e críticos durante o projeto, se
comparados com o trabalho tradicional da organização.
• O plano de gerenciamento de recursos humanos é o documento formal que descreve os

procedimentos que serão utilizados para gerenciar todos os recursos humanos do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Qual é o objetivo central da área de conhecimento de gerenciamento de recursos

humanos?
2 Quais são as principais atribuições dos recursos humanos nos projetos?
3 Cite os processos para o gerenciamento da área de conhecimento dos recursos

humanos do projeto.
4 Cite os objetivos do processo de Desenvolver a Equipe do Projeto.
5 Qual é o principal produto dos processos da área de conhecimento do gerenciamento

dos recursos humanos do projeto?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 3
GERENCIAMENTO DAS COMUNICAÇÕES
1 INTRODUÇÃO
Quando da implantação do gerenciamento de projeto, muitas organizações focam seus

esforços em habilitar-se com grande expertise em gerenciamento do escopo, gerenciamento
do tempo, ou outras competências. O fato é que todas estas tarefas serão desenvolvidas por
pessoas, e apesar desta ser uma constatação intuitiva, esta priorização normalmente não
acontece.
Para implementar bem o gerenciamento de projeto, com maior chance de su-
cesso, deve-se lembrar que projetos são gerenciados por pessoas e não por
ferramentas e ainda que as pessoas controlam as ferramentas. Atualmente,
as empresas que têm tido sucesso na implementação de gerenciamento de
projeto, têm focado esforços em temas direcionados às pessoas, por exemplo,
cultura, comunicação, trabalho em equipe, entre outros. Somente após tratar
os assuntos relacionados aos indivíduos é que as ferramentas e metodologias
são abordadas. (ALVES, 2008, p. 35).
Ainda de acordo com o autor:

Desta forma, percebe-se a influência da comunicação na implementação do
gerenciamento de projetos, visto que para alcançar pessoas, construir uma
G
relação de confiança e mantê-la, é imprescindível o desenvolvimento de habi-
E
lidades e técnicas de relacionamento interpessoal, que indiretamente torna-se
R
objeto deste estudo. O gerente de projetos deve ter a capacidade de coor-
Ê
denar a equipe a todo tempo, mesmo não sendo possível estar em todos os
N
lugares ao mesmo tempo, até mesmo porque seria humanamente impossível,
C
mas ele tem que manter presença e contato com o time ao longo do projeto
I
atento a tudo o que ocorre, sendo capaz de ser informado e informar as de-
A
cisões que afetam os envolvidos no projeto. O gerente de projeto é a junção,
o ponto de ligação que mantém todos os elementos do projeto integrados.
D
Sem essa integração, todo o andamento do projeto fica comprometido. Um
E
grande número de boas ideias pode ser perdido em função da dificuldade de
administrar relacionamentos. O gerente de projetos tem a responsabilidade
P
de assegurar que as informações sejam explícitas, claras e 15 completas, de
R
modo que os seus interlocutores não tenham dificuldades para entender as
O
mensagens transmitidas. Após a divulgação das informações, passa a ser
J
responsabilidade do receptor certificar-se de que realmente as entendeu. O
E
processo de gerenciamento da troca de informações ou gerenciamento da
T
comunicação em projetos constitui-se basicamente de um gerador de planos,
O
S
relatórios e reuniões. Ele descreve o processo requerido para assegurar, no

tempo certo, a obtenção e interação das informações com os envolvidos.
(ALVES, 2008, p. 53).
De acordo com o PMBOK (2013), dentro deste universo, o gerenciamento da

comunicação tem algumas funções como as citadas a seguir:
 Determinação das necessidades de informações e comunicação das partes

interessadas no projeto.
 Colocação das informações necessárias à disposição das partes interessadas
no projeto no momento adequado.
 Coleta e distribuição das informações sobre o desempenho.
 Incluindo relatório de andamento, medição do progresso e previsão.
 Gerenciamento das comunicações para satisfazer os requisitos das partes
interessadas no projeto e resolver problemas com elas.
Em suma, este processo se bem coordenado torna-se uma ferramenta adicional para
consagrar a boa performance de atuação de um gerente de projetos e consequentemente da
sua equipe de projetos. Ora, se esta equipe já possui habilidades e capacitação requeridas
em outros ambientes do gerenciamento, adquirindo um padrão estratégico no gerenciamento
das informações, a melhora na performance torna-se mais facilmente atingível, como mostra
o PMBOK, (2004).
Conforme o PMI (2013), o gerenciamento das comunicações do projeto inclui os

processos necessários para assegurar que as informações do projeto sejam geradas, coletadas,
distribuídas, armazenadas, recuperadas e organizadas de maneira oportuna e apropriada.
A figura a seguir nos mostra uma visão sobre o modelo de Gerenciamento de Projetos
G
do PMI com ênfase na área de Gerenciamento das Comunicações do Projeto.
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 95 – ÁREAS DE CONHECIMENTO DO PMI
FONTE: PMI (2013)
2 PROCESSOS DE GERENCIAMENTO DAS COMUNICAÇÕES DO PROJETO

G
E
R
Conforme a estrutura do PMI (2013), a área de conhecimento de Gerenciamento de Ê
Comunicações do Projeto está dividida em alguns processos, a saber: N
C
I
 identificar as partes interessadas; A
 planejar as comunicações; D
 distribuir as informações; E
 gerenciar as expectativas das partes interessadas;
P
 reportar o desempenho. R
O
FONTE: PMI (2013) J
E
T
Na sequência, detalharemos cada um dos processos desta área de conhecimento. O
S
2.1 IDENTIFICAR AS PARTES INTERESSADAS

do processo de identificar as partes interessadas, conforme PMI (2013):
FIGURA 96 – PROCESSO IDENTIFICAR AS PARTES INTERESSADAS, ENTRADAS,

FONTE: PMI (2013)
A figura a seguir apresenta o diagrama de fluxo de dados do processo de identificar

as partes interessadas que inclui a participação de entregáveis de outros processos como se
mostra a seguir:
FIGURA 97 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO DE IDENTIFICAR AS PARTES

INTERESSADAS
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S FONTE: PMI (2013)
2.1.1 Ciclo de iniciação: definição do processo
Os processos de gerenciamento das comunicações asseguram que as informações,

incluindo planos, relatórios, reuniões e outros, serão documentadas, distribuídas e arquivadas
de modo adequado, permitindo transparência e alinhamento das expectativas. As informações
relevantes devem ser distribuídas conforme seu público-alvo, considerando-se também a
periodicidade desejada. Além disso, a organização, a indexação e o arquivamento dessas
informações servirão para a base de dados de conhecimento da empresa.
Gerenciar comunicação em projetos é um processo tão importante quanto qualquer outro
processo nas empresas. Os gerentes gastam a maior parte do seu tempo com comunicação ou
com problemas decorrentes deste nos projetos. Reconhecer a comunicação como um processo,
conhecendo seus elementos, formas de comunicação e partes envolvidas, é o primeiro passo
para implantação de um sistema de gestão eficiente. Um projeto pode gerar conhecimento na
empresa se as informações e dados gerados forem tratadas de forma eficiente profissional e
o conhecimento gerado pode vir a ser um diferencial no mercado, quando se torna um ativo
que pode ser utilizado pela empresa na gestão de outros projetos.
POR QUE GERENCIAR COMUNICAÇÃO NOS PROJETOS?

O avanço da tecnologia da informação permite que as empresas registrem de forma
eficiente as informações de seus projetos. Mas, o que fazer com tanta informação? O fato
de registrar bem os dados do projeto não garante sua utilidade. Perdidos em meio a tantos
registros, saber usá-los de forma eficaz não é tarefa fácil se não houver um bom planejamento
e uma forma de gestão da comunicação implementada.
As empresas preocupam-se com seus processos. Buscam formas de medir seus
desempenhos, estabelecem rotinas de reuniões gerenciais, criam formulários e relatórios
extensos e “bem estruturados”. Com tudo isto, somando à facilidade de preservar as informações
em formato eletrônico, gera um acúmulo de dados cada vez maior. Mas, quando necessário
G
uma consulta, o resgate da informação pode ser uma missão quase impossível. Falta tratar a E
R
questão com um pouco mais cuidado e profissionalismo.
Ê
Na mensagem, existem atributos que às vezes não são de conhecimento comum das N
partes. Ao estabelecer uma comunicação é preciso estabelecer um nível de entendimento. O C
I
receptor deve ter conhecimento necessário para entender e interpretar o formato da mensagem, A
a linguagem e o contexto. Faz-se necessário planejar como ocorrerá a comunicação no projeto.
O processo Planejamento das Comunicações determina as necessidades de D
informações e comunicações das partes interessadas; por exemplo, quem E
precisa de qual informação, quando precisarão dela, como ela será fornecida
e por quem. Embora todos os projetos compartilhem a necessidade de comu- P
nicar as informações sobre o projeto, as necessidades de informações e os R
métodos de distribuição variam muito. Um fator importante para o sucesso do O
projeto é identificar as necessidades de informações das partes interessadas J
e determinar uma maneira adequada para atender a essas necessidades. [...] E
O planejamento das comunicações está, muitas vezes, estreitamente ligado T
aos fatores ambientais da empresa e às influências organizacionais, pois a O
S
estrutura organizacional do projeto terá um efeito importante nos requisitos de

comunicações do projeto. (PMBOK, PROJECT MANAGEMENT INSTITUTE,
2004, p. 225).
A comunicação ocorre de diversas formas, podendo ser verbal ou não verbal, formal ou
informal. A maneira como ela ocorre e é tratada nos projetos pode determinar o diferencial de
uma empresa. “Caminhões” de relatórios estão arquivados nas empresas. De nada adianta a
experiência de uma organização, uma grande base de dados, um excelente histórico, se não
é eficaz sua utilização. Quando existe um gerenciamento de comunicação eficaz é possível a
recuperação das informações e sua utilização.
As informações geradas no projeto podem gerar conhecimento. Em seu livro “As Novas
Realidades”, Peter Drucker considera que conhecimento é a informação que muda algo ou
alguém, seja provocando uma ação, seja tornando um indivíduo ou uma instituição capaz de
uma ação diferente ou mais eficiente. Os registros das informações em um projeto geram um
histórico, uma base de dados, que quando bem tratados geram valia na empresa.
O conhecimento em uma empresa pode ser explícito ou tácito. O explícito é aquele
conhecido por todos em forma de registros como procedimentos, instruções de trabalho,
projetos, relatórios etc. O conhecimento tácito, do latim “tacitus” (não expresso por palavras),
definido como conhecimento informal, segundo Polanyi (1891-1976) é também tido como
conhecimento pessoal enraizado na experiência individual e envolvendo crenças pessoais,
perspectivas e valores (NONAKA E TAKEUCHI,1997). As pessoas quando saem do projeto
sem registrar bem o aprendizado adquirido no projeto, levam com elas informações preciosas
que poderiam se transformar em conhecimento para empresa em outros projetos.
O conhecimento é um ativo da companhia. A economia de recursos que se pode
alcançar é incalculável – é espantoso o número de empresas que não usa a informação que
está dentro dela.
O PMBOK considera como uma boa prática da gestão de projetos utilizar os ativos de
processos organizacionais. Apesar de um projeto ser único e temporário, as informações geradas
e o histórico de um projeto podem e devem ser considerados como base de dados para outro
G
projeto semelhante. Para se ter uma boa gestão da comunicação em um projeto, segundo o
E PMPOK (2004), além do planejamento é preciso cuidar da distribuição das informações, do
R
relatório de desempenho e gerenciar as partes interessadas.
Ê
N
C FONTE: Disponível em: <http://www.techoje.com.br/site/techoje/categoria/detalhe_artigo/647>.
I Acesso em: 10 maio 2015.
A
D
E
P
2.1.2 Ciclo de iniciação: entradas do processo
R
O
J  Termo de abertura do projeto.
E
 Documentos de aquisição.
T
O  Fatores ambientais da empresa.
S  Ativos de processos organizacionais.
2.1.3 Ciclo de iniciação: ferramentas e técnicas
 Análise de partes interessadas.

2.1.4 Ciclo de iniciação: saídas do processo
 Registro das partes interessadas.

 Estratégia para gerenciamento das partes interessadas.
2.2 PLANEJAR AS COMUNICAÇÕES
A figura, a seguir, apresenta os elementos de entrada, ferramentas, técnicas e as saídas

do processo Planejar as Comunicações, conforme PMI (2013):
FIGURA 98 – PROCESSO PLANEJAR AS COMUNICAÇÕES, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
G
E
R
Ê
FONTE: PMI (2013) N
C
I
A próxima figura apresenta o diagrama de fluxo de dados do processo Planejar as A
Comunicações que inclui a participação de entregáveis de outros processos como se mostra D
a seguir: E
P
R
O
J
E
T
O
S
FIGURA 99 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR AS

COMUNICAÇÕES
FONTE: PMI (2013)
2.2.1 Ciclo de planejamento: definição do processo

G
E
R
É o processo de determinar as necessidades de informação das partes interessadas
Ê no projeto e definir uma abordagem de comunicação
N
C
I
A
D 2.2.2 Ciclo de planejamento: entradas do processo

E
P  Registro das partes interessadas.

R
O  Estratégia para gerenciamento das partes interessadas.
J  Fatores ambientais da empresa.
E
T  Ativos de processos organizacionais.
O
S
 Análise de requisitos da comunicação.

 Tecnologia das comunicações.
 Modelos de comunicação.
 Métodos de comunicação.
 Plano de gerenciamento das comunicações.

2.3 CONTROLAR AS INFORMAÇÕES

do processo Distribuir as Informações, conforme PMI (2013):
FIGURA 100 – PROCESSO DISTRIBUIR AS INFORMAÇÕES, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
G
E
R
Ê
N
C
I
A
FONTE: PMI (2013)
D
E
A figura seguinte apresenta o diagrama de fluxo de dados do processo Distribuir as
Informações, que inclui a participação de entregáveis de outros processos conforme se mostra P
R
a seguir: O
J
E
T
O
S
FIGURA 101 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO DISTRIBUIR AS

INFORMAÇÕES
FONTE: PMI (2013)

G
E
R Com a criação no PMBOK 5 de uma área de conhecimento específica para a gestão
Ê
das expectativas dos interessados (13. Gestão de Expectativas dos Interessados), a gestão
N
C das comunicações ganhou um maior foco no controlo e disseminação do fluxo das informações
I do projeto.
A
Controlar as Comunicações do Projeto é um processo transversal ao ciclo de vida do
D projeto, que tem como objetivo a monitorização e o controlo do fluxo de partilha de informação
E
sobre o andamento do projeto por todas as partes interessadas (stakeholders). O tipo de
P informação, o meio usado e a periodicidade com que a informação é partilhada pelos diversos
R
O interessados ou grupos de interessados está definida no Plano de Gestão de Comunicações.
J O controle do fluxo de comunicação é um processo que permite ao gestor de projeto e
E
T
a sua equipe, perceber se o plano de comunicação está a ser corretamente executado e se os
O objetivos de comunicação definidos, e identificar de forma proativa, a necessidade de ações
S
preventivas ou corretivas e eventuais oportunidades de introdução de melhorias.
No âmbito do PMBOK, a gestão da comunicação do projeto segue a hierarquia

DIKW (Data-Information-Knowledge-Wisdow) também conhecida por pirâmide do conhecimento.
O sucesso da implementação desse modelo, que permite transformar dados no conhecimento
necessário à decisão, depende essencialmente da confiança da equipa nos dados obtidos e
no processo de análise que conduz à informação, e no apoio dos patrocinadores do projeto os
quais têm, em última análise, a responsabilidade de apoiar, e defender perante a organização,
as decisões que são tomadas no âmbito do projeto.
O que isto quer dizer em termos práticos é que os relatórios devem ser capazes de
sintetizar tudo aquilo que é relevante para compreender o progresso do projeto, o que implica que
a forma como os relatórios são desenhados, os indicadores e os gráficos que são apresentados,
e os assuntos que são selecionados para serem apresentados com maior relevo, devem ser
aqueles que melhor contribuem para a compreensão sobre o andamento do projeto. A seleção
de informações que auxilia na formação de opinião, preferencialmente em uma única página
(estilo tableau de bord), contribui de forma positiva para o sucesso do projeto.
Um processo de controle de comunicação eficaz assenta na eficiência do processo de
monitoração que lhe está a montante. O trabalho de monitoramento periódico e sistemático é
essencial para a recolha da informação que é necessária para a comparação entre os planos
de projetos que foram efetuados e a execução concreta das atividades do projeto.
FONTE: Disponível em: <http://pm2all.blogspot.com.br/2014/09/pmbok-v5-103-controlar-as-

comunicacoes.html>. Acesso em: 10 maio 2015.

 Relatórios de desempenho.
G
E
R
Ê
2.3.3 Ciclo de execução: ferramentas e técnicas N
C
I
A
 Ferramentas de distribuição das informações. D
E
P
R
O
2.3.4 Ciclo de execução: saídas do processo J
E
T
 Atualizações dos ativos de processos organizacionais. O
S
RESUMO DO TÓPICO 3
• A comunicação é um elemento essencial, imperativo e de caráter de sobrevivência para toda

a sociedade desde os tempos mais remotos.
• Outro elemento importantíssimo é a informação, que há muito é considerada elemento

essencial para as organizações.
• Tão importante quanto realizar a comunicação é veicular as mensagens com qualidade.
• Uma mensagem de qualidade é aquela que atende às expectativas e as necessidades de

informação de emissor e receptor.
• As comunicações têm o seu tempo certo para acontecer. Comunicações podem referenciar
algo do presente, passado e futuro.
• Este gerenciamento inclui os processos necessários para assegurar que as informações do

projeto sejam geradas, coletadas, distribuídas, armazenadas, recuperadas e organizadas de
maneira oportuna e apropriada.
• A área de conhecimento de gerenciamento de comunicações do projeto está dividida em

cinco processos, a saber:
• identificar as partes interessadas;
G • planejar as comunicações;
E
R • distribuir as informações;
Ê • gerenciar as expectativas das partes interessadas;
N
C • reportar o desempenho.
I
A
• No gerenciamento de comunicações deve-se atentar para os seguintes aspectos:
D • as pessoas dão o melhor de si quando compreendem completamente as decisões que
E
as afetam e suas razões. Se a base do gerenciamento de projetos é a formalização
P de processos para alcançar melhor desempenho, a informação e a comunicação
R não podem ser relegadas ao improviso e à intuição;
O
J • deve-se planejar sobre o que comunicar, para quem e como;
E • são usados diferentes veículos de comunicação;
T
O • gerar credibilidade através de procedimentos regulares e honestos;
S
• nas situações de crise, seja ágil. Informe a posição atual, ainda que não seja a
definitiva;
• as pessoas devem compreender como e por que uma decisão foi tomada.
• É gerado o Plano de Gerenciamento de Comunicações, documento formal que descreve os

procedimentos que serão utilizados para gerenciar todo o processo de comunicação no projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Segundo nossos estudos, qual é o elemento essencial da comunicação, cuja

importância é capital para as organizações?
2 Quais são os principais aspectos que indicam que uma mensagem é de qualidade?
3 Quais são os processos que compõem a área de conhecimento de gerenciamento

de comunicações do projeto?
4 O que deve assegurar a área do gerenciamento das comunicações do projeto e seus

processos?
5 Qual é o principal produto dos processos da área de gerenciamento de comunicações?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 4
GERENCIAMENTO DE RISCOS
1 INTRODUÇÃO
O gerenciamento de riscos está se tornando cada vez mais relevante em projetos de

desenvolvimento de software, devido ao alto grau de incerteza envolvido neste tipo de projeto.
O gerenciamento de riscos conduz a organização a sistematicamente planejar, antecipar e
mitigar os riscos para proativamente eliminar ou minimizar seus impactos nos projetos.
O desenvolvimento de software é geralmente repleto de incertezas, como problemas

que ocasionam os atrasos de cronogramas, aumento de custos ou entrega dos produtos de
forma insatisfatória. Embora alguns problemas não possam ser totalmente resolvidos, alguns
podem ser controlados através de ações preventivas. A área de gerência de projetos que lida
com estas incertezas ou problemas mesmo antes que eles ocorram é a gerência de riscos. Nos
processos de qualidade de software, a gerência de risco é ponto fundamental para a garantia
da qualidade do produto gerado. Este artigo tem a finalidade de proporcionar uma análise
detalhada das atividades de gerência de risco presentes nos modelos de qualidade de software.
G
O risco em um projeto de software é uma medida da probabilidade e da perda E
R
relacionadas à ocorrência de um evento negativo que afete o próprio projeto, seu processo Ê
ou o seu produto. Em outras palavras, qualquer coisa que possa acontecer e ameaçar o bom N
C
andamento do projeto é um risco. O risco do projeto relaciona-se com aspectos operacionais, I
organizacionais e contratuais. Este tipo de risco é uma responsabilidade do Gerente do A
Projeto, nele estando incluídas limitações de recursos, interfaces externas, relacionamentos
D
com fornecedores e restrições contratuais. Exemplos comuns são fornecedores incapazes de E
responder à altura e falta de apoio da organização para o projeto. A falta de controle sobre
P
as dependências externas do projeto torna extremamente difícil o gerenciamento dos riscos. R
Normalmente, o maior risco dos projetos de software é financeiro – tem a ver com a obtenção O
J
dos recursos orçamentários. O risco do processo inclui tanto procedimentos técnicos quanto E
gerenciais. Nos procedimentos gerenciais, este tipo de risco será encontrado no planejamento, T
O
na obtenção de recursos humanos, no acompanhamento e controle do projeto, na garantia da S
qualidade e na gerência de configuração. Nos procedimentos técnicos, o risco será encontrado

em atividades tais como a análise de requisitos, o design, a codificação e o teste. O risco do
produto está associado às características do mesmo. Este tipo de risco é uma responsabilidade
técnica (não gerencial). Será encontrado na estabilidade dos requisitos, na performance do
design, na complexidade do código e nas especificações de teste. O maior risco relativo ao
produto nos projetos de software refere-se aos requisitos.
FONTE: Gerenciando Riscos nos Projetos de Software por Mauricio Aguiar - Artigo
A figura seguinte nos mostra uma visão sobre o modelo de Gerenciamento de Projetos
do PMI com ênfase na área de Gerenciamento de Riscos.
FIGURA 102: VISÃO GERAL DO GERENCIAMENTO DO TEMPO DE PROJETO
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FONTE: PMI (2013)
2 PROCESSOS DE GERENCIAMENTO DE RISCOS
Conforme a estrutura do PMI (2013), a área de conhecimento de Gerenciamento de

Riscos está dividida em alguns processos, a saber:
 Planejar o gerenciamento dos riscos.

 Identificar os riscos.
 Realizar a análise qualitativa dos riscos.
 Realizar a análise quantitativa dos riscos.
 Planejar as respostas aos riscos.
 Monitorar e controlar os riscos.
2.1 PLANEJAR O GERENCIAMENTO DOS RISCOS

do processo Planejar o Gerenciamento dos Riscos, conforme PMI (2013):
FIGURA 103 – PROCESSO PLANEJAR O GERENCIAMENTO DOS RISCOS, ENTRADAS,

G
E
R
Ê
FONTE: PMI (2013) N
C
I
A figura a seguir apresenta o diagrama de fluxo de dados do processo Planejar o A
Gerenciamento dos Riscos, que inclui a participação de entregáveis de outros processos como
D
é mostrado a seguir: E
P
R
O
J
E
T
O
S
FIGURA 104 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR O

GERENCIAMENTO DOS RISCOS
FONTE: PMI (2013)
2.1.1 Ciclo de planejamento: definição de processo
É o processo de definição de como conduzir as atividades de gerenciamento dos riscos

do projeto.
G
E
R
Ê
N 2.1.2 Ciclo de planejamento: entradas do processo
C
I
A  Declaração do escopo do projeto – fornece uma percepção clara de possibilidades
D associadas com o projeto e suas entregas.
E  Plano de gerenciamento dos custos – define o uso dos orçamentos, contingências e
P
as reservas de gerenciamento de riscos.
R  Plano do gerenciamento do cronograma – define como as contingências do
O
cronograma serão reportadas e utilizadas.
J
E  Plano do gerenciamento das comunicações – define as interações que vão ocorrer no
T projeto e determina quem estará disponível para compartilhar informações dos riscos do projeto.
O
S
 Fatores ambientais da empresa – fatores que podem influenciar o planejamento do

gerenciamento dos riscos. São as tolerâncias e atitudes sobre riscos.
 Ativos de processos organizacionais – ativos que podem influenciar o planejamento
do gerenciamento dos riscos.
 Reuniões e análises de planejamento – reuniões para desenvolver o plano de

gerenciamento de riscos.
 Plano de gerenciamento dos riscos – descrição de como o gerenciamento dos riscos

será estruturado e executado.
2.2 IDENTIFICAR OS RISCOS
A próxima figura apresenta os elementos de entrada, ferramentas, técnicas e as saídas

do processo Identificar os Riscos, conforme PMI (2013):
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 105 – PROCESSO IDENTIFICAR OS RISCOS, ENTRADAS, FERRAMENTAS, TÉCNICAS

E SAÍDAS
FONTE: PMI (2013)
A figura a seguir apresenta o diagrama de fluxo de dados do processo Identificar os

Riscos, que inclui a participação de entregáveis de outros processos como se mostra a seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 106 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO IDENTIFICAR OS RISCOS
G
E
R
Ê
FONTE: PMI (2013) N
C
I
A
D
2.2.1 Ciclo de planejamento: definição do processo E
P
Realizar a análise qualitativa de riscos tem como objetivo avaliar a exposição ao risco R
O
para priorizar os riscos que serão objeto de análise ou ação adicional. Os riscos com maior J
probabilidade e impacto são priorizados para posterior criação de um plano de respostas. Os E
T
riscos com menor probabilidade e impacto são mantidos nos registros dos riscos dentro de O
uma lista de observação para monitoramento futuro. S
2.2.2 Ciclo de planejamento: entradas do processo
 Plano de gerenciamento de riscos.

 Estimativa de custos das atividades.
 Estimativa de duração das atividades.
 Linha de base do escopo.
 Plano de gerenciamento dos custos.
 Plano de gerenciamento do cronograma.
 Plano de gerenciamento da qualidade.
 Documentos do projeto.
 Revisões de documentação.
 Técnicas de coleta de informações.
 Análise de listas de verificação.
 Análise de premissas.
 Técnicas de diagramas.
 Análise de forças, fraquezas, oportunidades e ameaças (SWOT).
G
E
R
Ê 2.2.4 Ciclo de planejamento: saídas do processo
N
C
I
 Registro dos riscos.
A
D
E
P 2.3 REALIZAR A ANÁLISE QUALITATIVA DOS RISCOS

R
O
J
E A figura a seguir apresenta os elementos de entrada, ferramentas, técnicas e as saídas
T do processo Realizar a Análise Qualitativa dos Riscos, conforme PMI (2013):
O
S
FIGURA 107 – PROCESSO REALIZAR A ANÁLISE QUALITATIVA DOS RISCOS, ENTRADAS,

FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo Realizar a Análise

Qualitativa dos Riscos, que inclui a participação de entregáveis de outros processos como é
mostrado a seguir:
FIGURA 108 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO REALIZAR A ANÁLISE

QUALITATIVA DOS RISCOS
G
E
R
Ê
N
C
I
A
D
E
FONTE: PMI (2013)
P
R
O
J
E
T
O
S
2.3.1 Ciclo de planejamento: definição do processo e entradas do processo

 Plano de gerenciamento dos riscos.
 Declaração do escopo do projeto.
 Avaliação de probabilidade e impacto dos riscos.

 Matriz de probabilidade e impacto.
 Avaliação de qualidade dos dados sobre riscos.
 Categorização dos riscos.
 Avaliação de urgência dos riscos.
 Atualização do registro dos riscos.
G
E 2.4 REALIZAR A ANÁLISE QUANTITATIVA DOS RISCOS
R
Ê
N A figura, a seguir, apresenta os elementos de entrada, ferramentas, técnicas e as saídas
C
I
do processo Realizar a Análise Quantitativa dos Riscos, conforme PMI (2013):
A
D
E
P
R
O
J
E
T
O
S
FIGURA 109 – PROCESSO REALIZAR A ANÁLISE QUANTITATIVA DOS RISCOS, ENTRADAS,

FONTE: PMI (2013)
A figura seguinte apresenta o diagrama de fluxo de dados do processo Realizar a

Análise Quantitativa dos Riscos, que inclui a participação de entregáveis de outros processos
como se mostra a seguir:
FIGURA 110 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO REALIZAR A ANÁLISE

QUANTITATIVA DOS RISCOS
G
E
R
Ê
N
C
I
A
D
E
P
R
FONTE: PMI (2013) O
J
E
T
O
S
A análise Quantitativa dos Riscos do Projeto é o processo de analisar numericamente o

efeito dos riscos, nos objetivos gerais do projeto. A análise quantitativa do risco analisa os efeitos
desses riscos e eventos e atribui uma valoração numérica a cada um desses riscos com o intuito de:
 Quantificar os resultados possíveis do projeto e as suas respectivas probabilidades.

 Avaliar a probabilidade de atingir objetivos específicos do projeto.
 Identificar os riscos que requerem mais atenção, quantificando a sua contribuição
relativa para o risco global do projeto.
 Tornar mais realistas e atingíveis as estimativas de custo, calendário ou âmbito.
 Determinar as melhores decisões de gestão quando determinadas condições ou
resultados são incertas.
A análise quantitativa dos riscos do projeto tem por base os processos anteriores incluídos na
área de conhecimento de gestão de risco, mas também o cronograma do projeto e o respectivo
plano de gestão de custos, bem como o contexto da empresa em que o projeto se insere.
FONTE: Disponível em: <http://pm2all.blogspot.com.br/2012/10/114-realizar-analise-quantitativa-dos.

html>. Acesso em: 10 maio 2015.

 Plano de gerenciamento dos riscos.
G
E  Plano de gerenciamento dos custos.
R  Plano de gerenciamento do cronograma.
Ê
 Ativo de processos organizacionais.
N
C
I
A
D 2.4.3 Ferramentas e técnicas

E
P
R  Técnicas de coleta e apresentação de dados.
O  Técnicas de modelagem e análise quantitativa de riscos.
J
E  Opinião especializada.
T
O
S
 Atualizações do registro dos riscos.
2.5 PLANEJAR AS RESPOSTAS AOS RISCOS

do processo Planejar as Respostas aos Riscos, conforme PMI (2013):
FIGURA 111 – PROCESSO PLANEJAR AS RESPOSTAS AOS RISCOS, ENTRADAS,

FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo Planejar as

Respostas aos Riscos, que inclui a participação de entregáveis de outros processos como se
mostra a seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 34 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR AS RESPOSTAS

AOS RISCOS
FONTE: PMI (2013)
É o processo de desenvolvimento de opções e ações para aumentar as oportunidades

e reduzir as ameaças aos objetivos do projeto.

G
E
R
Ê  Registro dos riscos.
N  Plano de gerenciamento dos riscos.
C
I
A
D
E 2.5.3 Ciclo de planejamento: ferramentas e técnicas
P
R  Estratégias para riscos negativos ou ameaças.
O
J  Estratégias para riscos positivos ou oportunidades.
E  Estratégias de respostas de contingência.
T
O  Opinião especializada.
S
 Atualização do registro dos riscos.

 Decisões relacionadas a riscos.
2.6 MONITORAR E CONTROLAR OS RISCOS

do processo Monitorar e Controlar os Riscos, conforme PMI (2013):
FIGURA 113 – PROCESSO MONITORAR E CONTROLAR OS RISCOS, ENTRADAS,

FONTE: PMI (2013)
A figura seguinte apresenta o diagrama de fluxo de dados do processo Monitorar e G

E
Controlar os Riscos, que inclui a participação de entregáveis de outros processos como é R
mostrado a seguir: Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 114 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO MONITORAR E CONTROLAR

OS RISCOS
FONTE: PMI (2013)
É o processo de implementação dos planos de respostas a riscos, acompanhamento

G dos riscos identificados, monitoramento dos riscos residuais, identificação de novos riscos e
E
R avaliação da eficácia do processo de riscos durante todo o projeto.
Ê
N
C
I
A
D
E
P
R
O  Informações sobre o desempenho do trabalho.
J
E
T
O
S
2.6.3 Ciclo de controle: ferramentas e técnicas
 Reavaliação de riscos.
 Auditorias de riscos.
 Análise da variação e tendências.
 Medição de desempenho técnico.
 Análise de reservas.
 Reuniões de andamento.
 Atualizações do registro dos riscos.

Na área de conhecimento de gerenciamento de riscos é gerado o Plano de

Gerenciamento de Riscos, que é o documento que descreve os procedimentos que serão
utilizados para gerenciar riscos através do projeto. É considerado um dos planos secundários
do plano geral do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 4
• Riscos são inerentes a projetos, portanto devemos manter a visão crítica sobre riscos que
envolvem os projetos.
• Ao contrário dos riscos associados à nossa vida pessoal, os riscos em projetos, na maioria
das vezes, não nos permitem que se busquem os caminhos menos “perigosos” e de riscos
reduzidos.
• As naturezas dos projetos de TI, essencialmente, estão associadas com riscos consideráveis,
isso em função, basicamente, da dependência que as organizações têm em relação à própria TI.
• Existem riscos nas questões da execução e suas complexidades tecnológicas, os possíveis

impactos, assim como todo o pessoal envolvido, a começar pela TI, responsável por sua
execução, fornecedoras, clientes e/ou usuários, gestores, executivos.
• Algumas fontes geradoras de riscos e que podemos distinguir como:

• de ordem tecnológica;
• de ordem administrativa;
• de ordem dos elementos externos.
• Possibilita a chance de melhor compreender a natureza do projeto envolvendo os membros

do time de modo a identificar as potenciais forças e riscos do projeto e responder a eles,
G geralmente associados a tempo, qualidade e custos.
E
R
Ê • O objetivo do gerenciamento dos riscos do projeto é garantir que acontecimentos indesejáveis
N
C ao projeto não venham a interferir em sua consecução.
I
A
• Outros objetivos – aumentar a probabilidade e o impacto dos eventos positivos e reduzir a
D probabilidade e o impacto dos eventos negativos do projeto.
E
• O risco do projeto é sempre futuro. O risco é um evento ou condição incerta que, se ocorrer,
P tem um efeito em pelo menos um objetivo do projeto.
R • Diz-se que os riscos têm sua origem nas incertezas e subjetividades existentes nos projetos.
O
J • A área de conhecimento de Gerenciamento de Riscos está dividida em seis processos:
E • planejar o gerenciamento dos riscos;
T
O • identificar os riscos;
S
• realizar a análise qualitativa dos riscos;

• realizar a análise quantitativa dos riscos;
• planejar as respostas aos riscos;
• monitorar e controlar os riscos.
• É importante que se atente para os seguintes aspectos:

• compreenda o projeto, produto ou processo a ser empreendido;
• identifique os elementos do projeto sujeito a riscos;
• desenvolva uma lista de ameaças e fraquezas para cada elemento;
• priorize as ameaças e as fraquezas;
• identifique impactos;
• identifique os controles a serem adotados para evitar, ou minimizar, os impactos;
• crie controles alternativos para quando os controles principais não forem efetivos ou
não puderem ser acionados;
• gere sempre documentação para servir de base a futuros projetos.
• É gerado o Plano de Gerenciamento de Riscos, que é o documento que descreve os

procedimentos que serão utilizados para gerenciar riscos através do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Quais são os processos que compõem a área de gerenciamento de riscos do projeto?
2 Conforme nossos estudos, são apontadas algumas fontes geradoras de riscos, cite
e explique cada uma delas.
3 Cite o objetivo do gerenciamento dos riscos do projeto.
4 Qual é o principal produto dos processos da área de Gerenciamento de Riscos?
5 Diante da afirmação de que os riscos têm sua origem nas incertezas e subjetividades
dos projetos, cite quais são as ações necessárias para seu gerenciamento.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 5
GERENCIAMENTO DAS AQUISIÇÕES
1 INTRODUÇÃO
Os projetos, em sua maioria, são compostos de diversos elementos, e sua aplicação deve
ter um fundamento importante para a organização e sua execução plenamente viável. Sendo
assim, o contexto do escopo dos projetos pode envolver diversas necessidades de recursos, de
origem técnica ou administrativa, em termos de bens e serviços para a consecução do projeto.
Notadamente, tais recursos e expertises muitas vezes inexistem no cenário e nos membros
da equipe do projeto, assim como o domínio de determinados conhecimentos e técnicas pelas
equipes de TI ou por equipes relacionadas. Estas necessidades podem ser muito específicas.
Estes e outros motivos justificam a busca das incorporações por recursos que viabilizem a
execução destes projetos. Para tanto, as melhores práticas em gerenciamento de projetos,
através da área de conhecimento do Gerenciamento das Aquisições, incluem ações que visam
ao controle sobre estas atividades que vão desde o planejamento, a escolha da melhor opção,
a contratação (formalização através dos contratos) até a liberação de recursos contratados,
quando da finalização da execução da etapa, com os procedimentos do encerramento deste
contrato com o fornecedor. G
E
R
Conforme o PMI (2013), o gerenciamento das aquisições do projeto inclui os Ê
processos necessários para comprar ou adquirir produtos, serviços ou resultados externos à N
C
equipe do projeto. A organização pode ser tanto o comprador como o vendedor dos produtos, I
serviços ou resultados do projeto. A
D
O gerenciamento das aquisições do projeto abrange os processos de E
gerenciamento dos contratos e controle de mudanças que são necessários para desenvolver
P
e administrar contratos ou pedidos de compra emitidos por membros autorizados da equipe R
do projeto. O
J
E
O gerenciamento de aquisições prevê o controle dos contratos formais celebrados T
O
S
entre clientes e fornecedores e que devem refletir os acordos firmados entre as partes com
a especificação dos direitos e obrigações, assim como as formas de execução, as entregas,
prazos e custos decorrentes.
do PMI com ênfase na área de Gerenciamento das Aquisições.
G
E
R
Ê
N
C
I
A
D
E FONTE: PMI (2013)
P
R
O
J
E
T
O
S
2 PROCESSOS DE GERENCIAMENTO DAS AQUISIÇÕES
Conforme a estrutura do PMI (2013), a área de conhecimento de gerenciamento de

aquisições está dividida em alguns processos, a saber:
 Planejar as aquisições.
 Conduzir as aquisições.
 Administrar as aquisições.
 Encerrar as aquisições.
A próxima figura apresenta o resumo dos processos da área de conhecimento do

Gerenciamento das Aquisições do Projeto (PMI, 2008).
2.1 PLANEJAR AS AQUISIÇÕES

do processo Planejar as Aquisições, conforme PMI (2013):
FIGURA 116 – PROCESSO PLANEJAR AS AQUISIÇÕES, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
G
E
R
Ê
N
C
I
A
D
E
FONTE: PMI (2013)
P
R
O
A figura a seguir apresenta o diagrama de fluxo de dados do processo Planejar as
J
Aquisições, que inclui a participação de entregáveis de outros processos como é mostrado a E
seguir: T
O
S
FIGURA 117 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR AS AQUISIÇÕES
G
E FONTE: PMI (2013)
R
Ê
N
C
I
A
D
E É o processo de documentação das decisões de compras do projeto, especificando a
abordagem e identificando fornecedores em potencial.
P
R
O
J
E
T
O
S
 Linha de base do escopo.

 Documentação dos requisitos.
 Acordos de cooperação.
 Decisões contratuais relacionadas a riscos.
 Requisitos de recursos das atividades.
 Cronograma do projeto.
 Estimativas de custos das atividades.
 Linha de base do desempenho de custos.
 Análise do fazer ou comprar.

 Tipos de contratos.
G
 Plano de gerenciamento das aquisições. E
 Declaração dos trabalhos das aquisições. R
Ê
 Decisões de fazer ou comprar. N
 Documentos de aquisição. C
I
 Critério de seleção de fontes.
A
D
E
P
R
O
J
E
T
O
S
2.2 REALIZAR AS AQUISIÇÕES

do processo Realizar as Aquisições, conforme PMI (2013):
FIGURA 118 – PROCESSO REALIZAR AS AQUISIÇÕES, ENTRADAS, FERRAMENTAS, TÉCNICAS

E SAÍDAS
FONTE: PMI (2013)
A figura a seguir apresenta o diagrama de fluxo de dados do processo Realizar as

Aquisições, que inclui a participação de entregáveis de outros processos como é mostrado a
seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 119 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO REALIZAR AS AQUISIÇÕES
G
E
R
FONTE: PMI (2013) Ê
N
C
I
A
2.2.1 Ciclo de execução: definição do processo D

E
P
É o processo de obtenção de respostas de fornecedores, seleção de um fornecedor e R
adjudicação de um contrato. O
J
E
T
O
S

 Critérios para seleção de fontes.
 Lista de fornecedores qualificados.
 Proposta dos fornecedores.
 Documentos do projeto.
 Decisões de fazer ou comprar.
 Acordos de cooperação.
 Reuniões com licitantes.

 Técnicas de avaliação de propostas.
 Estimativas independentes.
 Publicidade.
 Pesquisa na internet.
 Negociações das aquisições.
G 2.2.4 Ciclo de execução: saídas do processo

E
R
Ê
N
 Fornecedores selecionados.
C  Adjudicação do contrato de aquisição.
I
 Calendários dos recursos.
A
D  Atualizações do plano de gerenciamento do projeto.
E
P
R
O
J
E
T
O
S
2.3 Ciclo de execução: controlar as Aquisições

do processo Administrar as Aquisições, conforme PMI (2013):
FIGURA 120 – PROCESSO ADMINISTRAR AS AQUISIÇÕES, ENTRADAS, FERRAMENTAS,

TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
A próxima figura apresenta o diagrama de fluxo de dados do processo Administrar as

Aquisições, que inclui a participação de entregáveis de outros processos como se mostra a
seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 121 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO ADMINISTRAR AS

AQUISIÇÕES
FONTE: PMI (2013)
G
E
R
Ê
N 2.3.1 Ciclo de controle: definição do processo
C
I
A É o processo de gerenciar as relações de aquisição, monitorar o desempenho do contrato
e fazer mudanças e correções conforme necessário.
D
E
P
R
O
J
E
T
O
S
 Contrato.
 Solicitações de mudanças aprovadas.
 Informações sobre o desempenho do trabalho.
 Sistema de controle de mudança no contrato.

 Análise de desempenho das aquisições.
 Inspeções e auditorias.
 Sistemas de pagamento.
 Administração de reivindicações.
 Sistema de gerenciamento de registros.
 Documentação da aquisição.
G
 Atualizações dos ativos de processos organizacionais. E
 Solicitações de mudanças. R
Ê
 Atualizações do plano de gerenciamento do projeto. N
C
I
A
D
2.4 ENCERRAR AS AQUISIÇÕES
E
P
A figura, a seguir, apresenta os elementos de entrada, ferramentas, técnicas e as saídas R
do processo Encerrar as Aquisições, conforme PMI (2013): O
J
E
T
O
S
FIGURA 122 – PROCESSO ENCERRAR AQUISIÇÕES, ENTRADAS, FERRAMENTAS, TÉCNICAS

E SAÍDAS
FONTE: PMI (2013)
A figura seguinte apresenta o diagrama de fluxo de dados do processo Encerrar as

seguir:
FIGURA 123 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO ENCERRAR AS AQUISIÇÕES
G
E
R
Ê
N
C
I FONTE: PMI (2013)
A
D
E
P 2.4.1 Ciclo: encerramento

R
O
J
E
T
O
S
2.4.2 Ciclo: definição do processo
É o processo de finalização de cada aquisição do projeto. Como envolve verificar se

todo o trabalho e as entregas são aceitáveis, serve de apoio ao processo de encerramento do
projeto ou da fase.
2.4.3 Ciclo: entradas do processo

2.4.4 Ciclo: ferramentas e técnicas
 Auditorias de aquisições.
 Acordos negociados.
 Sistema de gerenciamento de registros.
2.4.5 Ciclo: saídas do processo
 Aquisições encerradas. G
 Atualizações dos ativos de processos organizacionais. E
R
Ê
Conforme Vargas (2009, p. 98), no gerenciamento de aquisições deve-se atentar para N
C
os seguintes aspectos: I
A
 utilize um checklist para a preparação de propostas e contratos;
D
 avalie os riscos antes de escolher um determinado tipo de contrato; E
 sempre reveja, com o departamento jurídico, o contrato a ser assinado;
P
 garanta, através de contrato ou seguro, os riscos não cobertos. R
O
J
Na área de conhecimento de Gerenciamento de Aquisições é gerado o Plano de E
Gerenciamento de Aquisições, que é o documento formal que descreve os procedimentos que T
O
serão utilizados para gerenciar todos os contratos do projeto. S
RESUMO DO TÓPICO 5
• Os projetos no contexto do escopo podem envolver diversas necessidades de recursos, de

origem técnica ou administrativa, em termos de bens e serviços para a consecução do projeto.
• Devido às necessidades muito específicas, muitas vezes, é necessário adquirir bens ou

serviços que viabilizem a execução destes projetos.
• A área de conhecimento do gerenciamento das aquisições inclui ações que visam ao controle
sobre estas atividades que planejam e contratam recursos para a consecução do projeto.
• O gerenciamento das aquisições do projeto inclui os processos necessários para comprar

ou adquirir produtos, serviços ou resultados externos à equipe do projeto.
• O gerenciamento das aquisições do projeto abrange os processos de gerenciamento dos

contratos e controle de mudanças que são necessários para desenvolver e administrar contratos
ou pedidos de compra emitidos por membros autorizados da equipe do projeto.
• A área de conhecimento de gerenciamento de aquisições está dividida em quatro processos,

a saber:
• planejar as aquisições;
G • conduzir as aquisições;
E
R • administrar as aquisições;
Ê • encerrar as aquisições.
N
C
I • Deve-se atentar para os seguintes aspectos:
A
D • utilize um checklist para a preparação de propostas e contratos;

E
• avalie os riscos antes de escolher um determinado tipo de contrato;
P • sempre reveja, com o departamento jurídico, o contrato a ser assinado;
R • garanta, através de contrato ou seguro, os riscos não cobertos.
O
J
E • É gerado o Plano de Gerenciamento de Aquisições, documento formal que descreve os
T
O procedimentos que serão utilizados para gerenciar todos os contratos do projeto.
S

IDADE
ATIV
AUTO
1 Notadamente, os projetos necessitam invariavelmente de recursos que devem

ser incorporados para viabilizar as suas execuções. Para gerenciar esta área de
conhecimento, são aplicadas as melhores práticas. Elas prescrevem quais ações
básicas?
2 Cite os processos que compõem a área de conhecimento de gerenciamento de

aquisições do projeto.
3 Os processos do gerenciamento das aquisições do projeto devem incluir ações de __

_____________________________________________________________________.
4 Segundo nossos estudos, para o gerenciamento das aquisições, devemos atentar

para quais aspectos em relação às aquisições?
5 Qual é o principal produto dos processos da área de gerenciamento de aquisições

do projeto?
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
UNIDADE 3
TÓPICO 6
GERENCIAMENTO DAS PARTES

INTERESSADAS NO PROJETO
1 INTRODUÇÃO
O gerenciamento das partes interessadas do projeto inclui os processos exi-

gidos para identificar todas as pessoas, grupos ou organizações que podem
impactar ou serem impactados pelo projeto, analisar as expectativas das
partes interessadas e seu impacto no projeto, e desenvolver estratégias de
gerenciamento apropriadas para o engajamento eficaz das partes interessadas
nas decisões e execução do projeto. O gerenciamento das partes interessadas
também se concentra na comunicação contínua com as partes interessadas
para entender suas necessidades e expectativas, abordando as questões
conforme elas ocorrem, gerenciando os interesses Conflitantes e incentivando
o comprometimento das partes interessadas com as decisões e atividades do
projeto. A satisfação das partes interessadas deve ser gerenciada como um
objetivo essencial do projeto. (PMI, 2013, p. 391).
do PMI com ênfase na área de Gerenciamento das Partes Interessadas.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FONTE: PMI (2013)

G
E
R
Ê
N 2 PROCESSOS DE GERENCIAMENTO DAS PARTES INTERESSADAS
C
I
A
Conforme a estrutura do PMI (2013), a área de conhecimento de Gerenciamento das
D Partes Interessadas está dividida em alguns processos, a saber:
E
P  identificar as partes;
R
 planejar o gerenciamento;
O
J  gerenciar o engajamento;
E
 controlar o engajamento;
T
O
S
A próxima figura apresenta o resumo dos processos da área de conhecimento do

Gerenciamento das Partes Interessadas no Projeto (PMI, 2013).
2.1 IDENTIFICAR AS PARTES INTERESSADAS

do processo Identificar as Partes Interessadas, conforme PMI (2013):
FIGURA 125 – PROCESSO IDENTIFICAR AS PARTES INTERESSADAS, ENTRADAS,

FONTE: PMI (2013)
A figura a seguir apresenta o diagrama de fluxo de dados do processo Identificar as

Partes Interessadas, que inclui a participação de entregáveis de outros processos como é
mostrado a seguir:
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
FIGURA 126 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO IDENTIFICAR AS PARTES

INTERESSADAS
FONTE: PMI (2013)
O processo de identificar pessoas, grupos ou organizações que podem impactar ou

G serem impactados por uma decisão, atividade ou resultado do projeto e analisar e documentar
E informações relevantes relativas aos seus interesses, nível de engajamento, interdependências,
R
Ê influência, e seu impacto potencial no êxito do projeto. (PMI, 2013, p. 391).
N
C
I
A
D 2.1.2 Ciclo de planejamento: entradas do processo

E
P  Termo de abertura do projeto

R
O
 Documentos de aquisição
J  Fatores ambientais da empresa
E
 Ativos de processos organizacionais
T
O
S
 Análise das Partes Interessadas: coletar informações sistemáticas quantitativas

e qualitativas para determinar e priorizar interesses durante o projeto. Identificar
interesses, expectativas e influências dos Stakeholders.
 Reuniões.
 Registro das partes interessadas: informações de identificação; informações de

avaliação: requisitos, expectativas e influências; informações de classificação:
interna/externa; apoiadora/neutra/resistente.
2.2 PLANEJAR O GERENCIAMENTO DAS PARTES INTERESSADAS

do processo Realizar as Aquisições, conforme PMI (2013):
FIGURA 127 – PROCESSO PLANEJAR O GERENCIAMENTO DAS PARTES, ENTRADAS,

G
E
R
Ê
N
C
I
A
D
E
FONTE: PMI (2013) P

R
O
A figura a seguir apresenta o diagrama de fluxo de dados do processo Realizar as J
Aquisições, que inclui a participação de entregáveis de outros processos como é mostrado a E
T
seguir: O
S
FIGURA 128 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO PLANEJAR O

GERENCIAMENTO DAS PARTES INTERESSADAS
FONTE: PMI (2013)
G
E “O processo de desenvolver estratégias apropriadas de gerenciamento para engajar
R as partes interessadas de maneira eficaz no decorrer de todo o ciclo de vida do projeto, com
Ê
N base na análise das suas necessidades, interesses, e impacto potencial no sucesso do projeto”.
C (PMI, 2013, p. 391).
I
A
D
E
P
R
O
J
E  Registro das partes interessadas.
T
O
S  Ativos de processos organizacionais.
a) Opinião especializada.
b) Técnicas analíticas.
c) Reuniões.
2.2.4 Ciclo de execução: saídas do processo
 Plano de Gerenciamento das Partes Interessadas

 Atualizações dos documentos do projeto
2.3 Gerenciar o engajamento das partes interessadas

do processo Administrar as Aquisições, conforme PMI (2013):
FIGURA 129 – PROCESSO GERENCIAR O ENGAJAMENTO DAS PARTES, ENTRADAS,

G
E
R
Ê
N
C
I
FONTE: PMI (2013) A
D
E
A próxima figura apresenta o diagrama de fluxo de dados do processo Administrar as
Aquisições, que inclui a participação de entregáveis de outros processos como se mostra a P
seguir: R
O
J
E
T
O
S
FIGURA 130 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO ADMINISTRAR AS

AQUISIÇÕES
FONTE: PMI (2013)
G
E O processo de se comunicar e trabalhar com as partes interessadas para atender às
R suas necessidades/expectativas, abordar as questões à medida que elas ocorrem, e incentivar
Ê
N o engajamento apropriado das partes interessadas nas atividades do projeto, no decorrer de
C todo o ciclo de vida do projeto (PMI, 2013, p. 391).
I
A
D
E
P
R
O
J
E
T
O
S
 Plano de gerenciamento das partes interessadas.

 Estratégia de gerenciamento das partes interessadas.
 Plano de gerenciamento das comunicações.
 Registro das questões.
 Registro de mudanças.
 Habilidades interpessoais.
 Habilidades de gerenciamento.
 Registro de questões.
 Atualização do plano de gerenciamento do projeto.
 Atualização do documento do projeto.
G
 Atualização dos ativos dos processos organizacionais. E
R
Ê
N
C
I
2.4 Controlar o engajamento das partes interessadas A
D
A figura, a seguir, apresenta os elementos de entrada, ferramentas, técnicas e as saídas E
do processo Encerrar as Aquisições, conforme PMI (2013):
P
R
O
J
E
T
O
S
FIGURA 131 – PROCESSO CONTROLAR O ENGAJAMENTO DAS PARTES INTERESSADAS,

ENTRADAS, FERRAMENTAS, TÉCNICAS E SAÍDAS
FONTE: PMI (2013)
A figura seguinte apresenta o diagrama de fluxo de dados do processo Encerrar as

seguir:
FIGURA 132 – DIAGRAMA DE FLUXO DE DADOS DO PROCESSO CONTROLAR O

ENGAJAMENTO DAS PARTES INTERESSADAS
G
E
R
Ê
N
C
I
A
D
E
P
R
O FONTE: PMI (2013)
J
E
T
O
S
2.4.1 Ciclo de encerramento: definição do processo
O processo de monitorar os relacionamentos das partes interessadas do projeto em

geral, e ajustar as estratégias e planos para o engajamento das partes interessadas. (PMI, 2013).
2.4.2 Ciclo de encerramento: entradas do processo
 Plano de gerenciamento do projeto

 Dados sobre o desempenho do trabalho
 Documentos do projeto
 Ativos de processos organizacionais
2.4.3 Ciclo de encerramento: ferramentas e técnicas
 Sistema de gerenciamento de informações

 Opinião especializada
 Reuniões
2.4.4 Ciclo de encerramento: saídas do processo
G
 Informações sobre o desempenho do trabalho E
R
 Solicitações de mudança Ê
 Atualizações do Plano de Gerenciamento do Projeto N
C
 Atualizações dos documentos do projeto I
 Atualizações de ativos dos processos organizacionais A
D
E
P
R
O
J
E
T
O
S
RESUMO DO TÓPICO 6
 As habilidades de comunicação e gestão de pessoas são extremamente importantes, não

somente para os gerentes, mas para todos os profissionais.
Aspectos importantes:
• Identificar as partes interessadas processo de identificação de todas as

pessoas que serão afetadas pelo projeto, documentando suas expectativas,
impacto, necessidade e influência. O registro das partes interessadas deve
conter todas as informações importantes sobre os stakeholders, devendo ser
atualizado continuamente.
• Planejar o gerenciamento das partes interessadas processo responsável por
conduzir a análise das partes interessadas, classificando-as e categorizando-as
de acordo com sua influência e impacto.
• Gerenciar engajamento das partes interessadas Processo responsável pelo
engajamento do projeto e seus stakeholders. Aqui são implementadas as
estratégias de engajamento das partes, seguindo o plano de gerenciamento
das comunicações e das partes interessadas.
• Controlar engajamento das partes interessadas neste processo são
monitorados o engajamento das partes, incluindo o registro de questões e novos
participantes do projeto.
 É importante que o gerente de projetos invista em conhecimentos de comunicação e

G negociação, a fim de equilibrar e amenizar os conflitos e expectativas dos interessados.
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S

IDADE
ATIV
AUTO
1 Em relação às partes interessadas (stakeholders) do projeto todas as afirmações

a seguir, exceto:
a) ( ) As partes interessadas podem ter influência positiva ou negativa em um

projeto.
b) ( ) Os interesses das partes interessadas negativas seriam atendidos de melhor
forma se impedissem o progresso do projeto.
c) ( ) Negligenciar as partes interessadas negativas não aumenta a probabilidade
de falha no projeto.
d) ( ) Os interesses das partes interessadas positivas seriam atendidos de melhor
forma se ajudarem o projeto a ter sucesso.
2 A matriz que segue procura relacionar interessados-chave (stakeholders) com seus

respectivos papéis em atividades específicas do projeto. Preencha a matriz, utilizando
para tal a seguinte legenda:
a) Responsável pela realização/conclusão das atividades.
b) Pode colaborar com as atividades.
c) Deve-se manter/ser mantido informado.
d) Aprovação necessária.
G
E
R
Ê
N
C
I
3 Durante uma reunião de revisão de status de um projeto sobre um sistema de A
informações, a equipe do projeto observou que poderia ser facilmente construído D

um gráfico, o qual permitiria ao cliente a identificação mais rápida de informações E
importantes. Essas informações estavam previstas para serem exibidas em planilhas, P

cujo formato não proporcionava uma boa interpretação delas. Diante deste fato, qual R
O
decisão o gerente do projeto poderia tomar? J
E
T
O
S
a) ( ) Deveria autorizar à equipe do projeto a implementação deste gráfico, para fazer

uma “surpresa” ao cliente, demonstrando suas boas intenções em agregar valor.
b) ( ) Deveria pedir à equipe do projeto para esquecer esta sugestão.
c) ( ) Deveria analisar o impacto da modificação e submetê-la à aprovação do cliente.
d) ( ) Deveria negociar a sua implantação com o cliente, porém acrescentando um
tempo e custo bem maiores do que os necessários, para compensar eventuais desvios
de custo e prazo no futuro.
4 Você vai montar uma equipe para um projeto, mas observa que dois dos melhores
profissionais a serem alocados não possuem um bom relacionamento entre si. Qual
das atividades a seguir, a princípio, melhor representa uma opção para a resolução do
problema?
a) ( ) Promover uma conversa entre eles, para identificar a causa-raiz do problema.

b) ( ) Escolher qual dos dois seria o mais indicado ao projeto, e deixar o outro de fora,
para evitar futuros problemas.
c) ( ) Alocar os dois profissionais e deixar que eles se entendam sozinhos.
d) ( ) Deixar claro aos dois que não vai admitir problemas de relacionamento no ambiente
do projeto.
G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
IAÇÃO
AVAL

G
E
R
Ê
N
C
I
A
D
E
P
R
O
J
E
T
O
S
250
REFERÊNCIAS
ALVES, Marcus V. B. Guia internet de conectividade. São Paulo: Ed. SENAC, 2000.
ARANHA, Eduardo S. A internet das coisas: a arma da fidelidade do futuro. Disponível

em: <http://www.incompanypr.com.br/a-internet-das-coisas-a-arma-da-fidelidade-do-futuro/>.
Acesso em: 12 mar. 2015.
AUDY, Jorge L. N.; ANDRADE, Gilberto K.; CIDRAL, Alexandre. Fundamento de sistemas
de informação. Porto Alegre: Ed. Bookman, 2005.
AVILLA, Olivia. Sistemas de informação e as decisões gerenciais na era da internet.

Disponível em: <http://slideplayer.com.br/slide/1261305/>. Acesso em: 10 mar. 2015.
BIO, Sérgio R. Colaboração: CORNACHIONE JR., Edgard B. Sistemas de informação. Um

Enfoque Gerencial. São Paulo: Ed. Atlas, 2008.
BITENCOURT, Claudia. Gestão contemporânea de pessoas. Porto Alegre: Ed. Bookman,

2010.
BORTOLDI, Joel. Data Mining – (Mineração de dados). Disponível em: <http://www.

joeldebortoli.com/2012/08/data-mining-mineracao-de-dados.html>. Acesso em: 12 mar. 2015.
BRAGA, Luis P. V. Introdução à mineração de dados. Rio de Janeiro: Ed. E-Papers, 2005.
BRANCO, Diogo. Sistemas de informação – Conceitos Tipos de Sistemas de Informação ERP

– Sistema de Gestão Empresarial – CRM – Gestão de relacionamento com clientes. Disponível
em: <http://slideplayer.com.br/slide/385214/>. Acesso em: 10 mar. 2015.
BUENO, Maurício. Informática fácil para concursos. Rio de Janeiro: Ed. Brasport, 2005.
1. CARNETI, Karen. Comércio eletrônico fatura R$ 43 bi e registra crescimento de 26%

nas vendas em 2014. Disponível em: <http://info.abril.com.br/noticias/internet/2015/01/
G comercio-eletronico-fatura-r-43-bi-e-registra-crescimento-de-26-nas-vendas-em-2014
E shtml>. Acesso em: 12 mar. 2015.
R
Ê
CARVALHO, F. C. A. Gestão de projetos. Pearson. São Paulo: 1ª Ed. 2010.
N
C
I CHAGAS, Diego J.; CHAN, Chou S.; CORSI, Alessandra C. Análise do Banco de Atendimento
A da Defesa Civil do Estado de São Paulo. Disponível em: <http://turmalina.igc.usp.br/scielo.
php?script=sci_arttext&pid=S0101-97592010000100003&lng=es&nrm=iso>. Acesso em: 12
D mar. 2015.
E
CHAVES, Leonardo G. O EAI como abordagem de integração de sistemas corporativos
P para a obtenção de vantagem competitiva. Disponível em: <http://www.linhadecodigo.com.
R br/artigo/429/o-eai-como-abordagem-de-integracao-de-sistemas-corporativos-para-a-obtencao-
O
de-vantagem-competitiva.aspx>. Acesso em: 12 mar. 2015.
J
E
T COELHO, Willianny. Dados, informação, conhecimento e competência. 2009. Disponível em:
O <http://www.webartigos.com/artigos/dados-informacao-conhecimento-e-competencia/26653/>.
S
251
Acesso em: 10 mar. 2015.
CRUZ, Tadeu. Sistemas de informações gerenciais. São Paulo: Ed. Atlas, 2010.
CRUZ, Tadeu. Sistemas, organização e métodos: Estudos integrados das novas Tecnologias
de informação. São Paulo: Editora Atlas, 2002.
CURIOSIDADES: através da inteligência artificial os robôs podem dominar a terra. Disponível

em: <http://curiosidades.bl.ee/curiosidades-atraves-da-inteligencia-artificial-os-robos-podem-
dominar-a-terra/>. Acesso em: 12 mar. 2015.
DALFOVO, Oscar; TAMBORLIN, Norberto. Business intelligence. Blumenau: Ed. Autor, 2010.
DAMASCO, Prof. Inteligência artificial nos negócios. Disponível em: <http://www.

profdamasco.site.br.com/InteligenciaArtificialTexto.pdf>. Acesso em: 12 mar. 2015.
DAMOSCO, Miguel. Conceitos de sistemas de informação. Disponível em: <http://www.

profdamasco.site.br.com/SlidesFundamentosSI.pdf>. Acesso em: 10 mar. 2015.
DANTAS, Samara et al. eBusiness: Conceitos, Implementação e Tendências. Disponível em:

<http://professor.ucg.br/siteDocente/admin/arquivosUpload/13515/material/e%20business%20
e%20commerce.pdf>. Acesso em: 10 mar. 2015.
DINIS, José A. H. A guerra de informação: perspectivas de segurança e competitividade.

Disponível em: <http://www.revistamilitar.pt/artigo.php?art_id=401>. Acesso em: 10 mar. 2015.
DINSMORE, C. e CAVALIERI, A. Como se tornar um profissional em gerenciamento de

projetos: livro-base de preparação para certificação pmp – project management professional.
Rio de Janeiro. Quality Mark, 2003.
DOUGLAS, Merrill. E-Fulfillment strategies that deliver the goods. Disponível em: <http://
www.inboundlogistics.com/cms/article/e-fulfillment-strategies-that-deliver-the-goods/>. Acesso
em: 12 mar. 2015.
DRUCKER, P. Post-capitalist Society. Butterworth Heinemann. 1SBN 0-7506-2025-0,1993.
ELIAS, Diego. O que significa OLTP e OLAP na prática. Disponível em: <http://corporate.
canaltech.com.br/o-que-e/business-intelligence/O-que-significa-OLTP-e-OLAP-na-
pratica/#ixzz3WBeDB9iR>. Acesso em: 12 mar. 2015. G
E
ESCOVEDO, Lorenzo. Sistemas digitais e arquitetura de computadores. Disponível em: R
<http://slideplayer.com.br/slide/1245219/>. Acesso em: 10 mar. 2015. Ê
N
C
FECOMERCIO SP. Comércio Eletrônico. Disponível em: <http://www.fecomercio.com.br/ I
NoticiaArtigo/Artigo/12423>. Acesso em: 12 mar. 2015. A
FURLAN, J. D. Como elaborar e implementar o planejamento estratégico de sistemas de D

informação. São Paulo: Makron Books, 1991. E
GOLSTEIN, Cláudia S.; SOUZA, César A. Tecnologia da Informação aplicada à Gestão P

Empresarial: um modelo para a empresa digital. Disponível em: <http://www.ead.fea.usp.br/ R
Semead/6semead/MQI/005MQI%20-%20Tec%20Inform%20Aplicada%20Gestao%20Empres. O
J
doc>. Acesso em: 10 mar. 2015.
E
T
GOMES, Carlos F. S.; RIBEIRO, Priscilla C.C. Gestão da cadeia de suprimentos, integrada O
S
252
à tecnologia da informação. São Paulo: Ed. Pioneira Thomson Learning, 2004.

2.
3. GOMES, Eduardo H. Browsers/Navegadores. Disponível em: <http://ehgomes.
com.br/disciplinas/dwe/introducao.php>. Acesso em: 12 mar. 2015.
GONZALEZ, José A. Q.; ZAMPIROLLI, Francisco A. Sistemas inteligentes e mineração de

dados. São Paulo: Ed. Triunfal, 2014.
Guia PMBoK 2013 – 5ª Ed. / PMI – Project Management Institute.
HUMPHREY, W.; KITSON, D., KASSE, T., “The state of software engineering practice:
A preliminary report”. In: Proceedings of the 11th International Conference on Software
Engineering, 1989.
JUNIOR, Cícero C. Sistemas integrados de gestão ERP. Curitiba: Ed. Ibpex, 2008.
KEELLING, R. Gestão de projetos: uma abordagem global. Porto Alegre, Bookman, 2002.
KERZNER, Harnold. Gestão de Projetos: As melhores práticas. 2. ed., Artmed, 2006.
LAUDON Kennethc C.; LAUDON Jane P. Sistemas de informações gerenciais. São Paulo:
Ed. Pearson Prentice Hall, 2007.
LAURINDO, Fernando J. B. et al. O papel da tecnologia da informação (TI) na estratégia

das organizações. Disponível em: <http://www.scielo.br/pdf/gp/v8n2/v8n2a04.pdf>. Acesso
em: 10 mar. 2015.
LIMA, Anderson B. Informática moderna, comércio eletrônico certificação digital. Clube

de Autores, 2009.
LUCCIA, Paulo R. EAD – Diferenças entre cursos síncronos e assíncronos. Disponível em:
<http://www.designinstrucional.com.br/ead-sincrono-e-assincrono/>. Acesso em: 12 Marc. 2015.
MATA, Marlis. Sistemas empresariais de negócio. Disponível em: <http://siyti.blogspot.com.

br/>. Acesso em: 12 mar. 2015.
MAY, Carlos. Gestão e produção. Disponível em: <http://www.scielo.br/scielo.php?script=sci_

arttext&pid=S0104-530X2006000200013>. Acesso em: 12 mar. 2015.
G
E MEYER Jr., Victor. Considerações sobre o planejamento estratégico na universidade apud
R Universidade: Organização, Planejamento e Gestão. OEA/UFSC. (Org.). Almeri P. Finger,
Ê Florianópolis (SC), 1988.
N
C
MUIA. Presentation. Disponível em: <http://www.dia.fi.upm.es/masteria/?q=en/MUIA>. Acesso
I
A em: 12 mar. 2015.
D NOEL, Michael. Collaborating with extranet partners on share point 2010. Disponível em:
E <http://pt.slideshare.net/michaeltnoel/collaborating-with-extranet-partners-on-sharepoint-2010-
sharepoint-connections-amsterdam-2011>. Acesso em: 12 mar. 2015.
P
R OLIVEIRA, Eddy. Sistema de gerenciamento da cadeia de suprimento – SCM. Disponível
O em: <https://ufamfsi2014.wordpress.com/2014/08/21/sistema-de-gerenciamento-da-cadeia-de-
J
suprimentos-%C2%AD-scm%C2%AD/>. Acesso em: 12 mar. 2015.
E
T
O OLIVEIRA, Marcell. Introdução ao data warehouse. Disponível em: <http://www.diegomacedo.
S
253
com.br/introducao-ao-data-warehouse/?print=print>. Acesso em: 12 mar. 2015.

4.
5. OLIVEIRA, Paulo A. A informática e o século 21. Disponível em: <http://www.batebyte.
pr.gov.br/modules/conteudo/conteudo.php?conteudo=1284>. Acesso em: 10 mar. 2015.
PHILLIPS, Joseph. Gerência de projetos de tecnologia da informação. Rio de Janeiro:

Campus, 2003.
PINHO, Henry. Supply chain management. Disponível em: <http://slideplayer.com.br/

slide/1738757/>. Acesso em: 12 mar. 2015.
PMI – PROJECT MANAGEMENT INSTITUTE. A guide to the project management body of

knowledge. Syba: PMI Publishing Division, 2000. Disponível em <http://www.pmi.org>. Acesso
em: 11 fev. 2015.
PRADO, D. Gerenciamento de projetos nas organizações, Vol. I, Belo Horizonte, FDG, 2000.
PRESSMAN, Roger S. Engenharia de software. São Paulo: McGrall-Hill, 2005.
PROJECT MANAGEMENT INSTITUTE – PMI. A guide to the project management body of

knowledge. 4. ed. Newton Square: Project Management Institute, 2008.
PROJECT MANAGEMENT INSTITUTE – PMI. Project Management Body of Knowledge –

PMBoK, Pennsylvania: USA, 2004.
PROJECT MANAGEMENT INSTITUTE – PMI. Project Management Body of Knowledge –

PMBoK. 5. Ed. Pennsylvania: USA, 2013.
R. DIGITAL. Inteligência digital. Disponível em: <http://www.rdigital.com.br/e-commerce/

comercio-eletronico-foi-destaque-em-2014/>. Acesso em: 12 mar. 2015.
RAINER, R. Kelly; CEGIELSKI, Casey G. Introdução a sistemas de informação. Rio de

Janeiro: Ed. Elsevier, 2012.
REZENDE, Denis A. Engenharia do software e sistemas de informação. Rio de Janeiro:

Ed. Brasport, 2005.
ROCHA, Ana. MALDONADO, José. WEBER, Kival, et al. Qualidade de software: teoria e
prática. São Paulo: Prentice Hall, 2001. G
E
ROSSETTI, Adroaldo. O papel da tecnologia da informação na gestão do conhecimento. R
Disponível em: <http://revista.ibict.br/index.php/ciinf/article/view/795/644>. Acesso em: 10 mar. Ê
N
2015.
C
I
SALVADOR, Jocelito A. Tecnologia da informação na sociedade do conhecimento. A
Disponível em: <http://conducereconsultoria.blogspot.com.br/2011/01/tecnologia-da-informacao-
na-sociedade.html>. Acesso em: 10 mar. 2015. D
E
SANTOS, Plácida L.V. A. C.; SANT'ANA, Ricardo C. G. Transferência da Informação: análise
para valoração de unidades de conhecimento. Disponível em: <http://www.dgz.org.br/abr02/ P
Art_02.htm>. Acesso em: 10 mar. 2015. R
O
J
SENGE, P. M. A Quinta disciplina, Editora Best Seller, São Paulo, 1990.
E
T
SETZER, Valdemar W. Meios Eletrônicos e Educação: uma visão alternativa. São Paulo: O
S
254
Ed. Escrituras, 2001.
Sistemas de Informação. Disponível em: <http://osdees2012.blogspot.com.br/p/sistemas-de-

automacao-de-escritorio-sae.html>. Acesso em: 10 mar. 2015.
STAIR Ralph M.; REYNOLDS George W. Princípios de sistemas de informação. São Paulo:
Ed. Cengage Learning, 2011.
TIBÉRIO, Professor. Sistemas de informação gerencial. Disponível em: <http://rhquixada.

blogspot.com.br/2012/10/s-i-g.html>. Acesso em: 10 mar. 2015.
TRENTIN, M. H. Gerenciamento de projetos. Guia para as certificações CAPM e PMP. Atlas,

2ª Ed. 2001.
TURBAN, Efraim et al. Business intelligence: um enfoque gerencial para a inteligência do

negócio. Porto Alegre: Ed. Artmaed, 2008a.
TURBAN, Efraim et al. Tecnologia da Informação para Gestão. Porto Alegre: Ed. Artmed,
2008b.
VARGAS, Ricardo Viana. Gerenciamento de projetos: estabelecendo diferenciais competitivos.

7. ed. Rio de Janeiro: Brasport, 2009.
VARGAS, S. Gerenciamento de projetos – Ms Project. Brasport, 1998.
VELLOSO, Fernando. Informática básica, conceitos. Rio de Janeiro: Ed. Elsevier, 2014.
VILHA, Anapatrícia M.; AGUSTINI, Carlos A. E-marketing, para bens de consumo durável.
Rio de
Janeiro: Ed. FGV, 2002.
WEBER, M. 1999. Sobre a teoria das ciências sociais. São Paulo: Moraes, 1999.
WOLF. The difference between software and hardware. Disponível em: <http://www.tech900.
com/2014/11/the-difference-between-software-and.html>. Acesso em: 10 mar. 2015.
XAVIER, C. PORTILHO, C. Projetando com qualidade a tecnologia de sistemas de

informação. Livros Técnicos e Científicos Editora, 1995.
G
E ZWICKER, Ronaldo; SOUZA, César A. Sistemas ERP: conceituação, ciclo de vida e estudos
R de casos comparados. Disponível em: <http://www.softsystemit-ead.com.br/phocadownload/
Ê ERP/Sistemas%20ERP.
N
C
I
A
D
E
P
R
O
J
E
T
O
S

Gerencia de Projetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerencia de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

GRUPO

Profª. Simone Cristina Aléssio

Copyright  UNIASSELVI 2015

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

Bem-vindo(a) à disciplina GERÊNCIA DE PROJETOS. Este Caderno de Estudos foi

A Unidade 2 concentra os estudos nos processos de gestão de projetos, tendo como

A Unidade 3 finaliza a abordagem dividindo-se em seis tópicos, em que são abordados os

Profª Simone Cristina Aléssio

GERÊNCIA DE PROJETOS iii

UNIDADE 1: CONCEITOS GERAIS: PROJETOS, GESTÃO DE PROJETOS,

TÓPICO 1: UMA VISÃO GERAL DE PROJETOS.............................................................. 3

TÓPICO 2: UMA VISÃO GERAL DE GESTÃO DE PROJETOS...................................... 19

TÓPICO 3: PROJETO DE DESENVOLVIMENTO DE SOFTWARE................................. 47

TÓPICO 4: CUSTO.......................................................................................................... 137

UNIDADE 3: ÁREAS DE CONHECIMENTO PARA GESTÃO DE PROJETOS............. 151

TÓPICO 1: GERENCIAMENTO DA QUALIDADE DO PROJETO.................................. 153

TÓPICO 2: GERENCIAMENTO DE RECURSOS HUMANOS DO PROJETO............... 167

GERÊNCIA DE PROJETOS vii

TÓPICO 3: GERENCIAMENTO DAS COMUNICAÇÕES............................................... 185

TÓPICO 4: GERENCIAMENTO DE RISCOS.................................................................. 199

GERÊNCIA DE PROJETOS viii

TÓPICO 5: GERENCIAMENTO DAS AQUISIÇÕES....................................................... 218

TÓPICO 6: GERENCIAMENTO DAS PARTES INTERESSADAS

CONCEITOS GERAIS: PROJETOS, GESTÃO

Ao final desta unidade, você será capaz de:

 conhecer as principais características de projetos e gerenciamento

Esta unidade de ensino contém três tópicos, sendo que no

TÓPICO 2 – UMA VISÃO GERAL DE GESTÃO DE D

TÓPICO 3 – PROJETO DE DESENVOLVIMENTO P

UMA VISÃO GERAL DE PROJETOS

Atualmente, enfrentamos mudanças em praticamente todos os aspectos da nossa vida

• redução no custo e prazo de desenvolvimento de novos produtos;

• Produção de um produto, item final ou componente.

Em contraste com os projetos, encontram-se as operações de uma organização. Estas

Principais diferenças entre projetos e operações:

Os projetos para serem lucrativos, executados no prazo e entregues com a devida

Segundo o PMI (Project Management Institute, 2013), podemos entender gerenciamento

Devido à dinamicidade e competitividade do mercado, diversas empresas têm buscado

FONTE: Disponível em: <http://www.tecsi.fea.usp.br/envio/contecsi/index.php/contecsi/9contecsi/

O gerente de projetos é o responsável pelo controle e bom desempenho dos mesmos.

3 SUBPROJETOS, PROGRAMAS E PORTFÓLIO

Projetos grandes e de alta complexidade podem ser particionados em projetos menores

Portfólio, ainda na visão do autor, é um conjunto de projetos ou programas com objetivos

FIGURA 1 – DIFERENÇA ENTRE PROJETOS, PROGRAMAS E PORTFÓLIO

FONTE: Trentin (2011, p. 20)

4 ESCRITÓRIO DE PROJETOS – PMO

É uma estrutura organizacional centralizada que se responsabiliza pelo gerenciamento

Existem diferentes tipos de PMO, com atribuições e responsabilidades distintas para

Uma organização deve atingir um determinado nível de maturidade para possibilitar a P

FIGURA 2 – MODELO DE MATURIDADE PARA A IMPLANTAÇÃO DO PMO

FONTE: Adaptado de Kerzner (2002, p. 35)

As funções desempenhadas por um Escritório de Projetos dependem das características

Para avaliação é essencial escolher um modelo de maturidade para efetuar o diagnóstico,

D Seguem três exemplos de modelos de maturidade para seu conhecimento:

Trata-se de um modelo bastante completo que parte do contexto organizacional de GP

OPM3 oferece também um direcionamento para a confecção de planos de melhoria

FONTE: Adaptado de: <http://blog.mundopm.com.br/2012/02/29/maturidade-em-gerenciamento-de-

FIGURA 3 – VARIÁVEIS DO MODELO DE MATURIDADE

O modelo Kerzner apresenta cinco níveis de maturidade, sendo calculados a partir da

FONTE: Disponível em: <http://blog.mundopm.com.br/2012/02/29/maturidade-em-gerenciamento-de-

FIGURA 4 – NÍVEIS DO MODELO DE MATURIDADE PARA A IMPLANTAÇÃO DO PMO

• Alinhamento com o Negócio.