Este currículo apresenta as qualificações acadêmicas e experiência profissional de Adm. Marcelo Augusto M. Barbosa, incluindo graduação em Administração, mestrado em Desenvolvimento Regional e Meio Ambiente, especializações em Gestão Empresarial Estratégica e Metodologia do Ensino, servidor público desde 1991 e professor desde 2004.

2. Curriculum
Adm.
Marcelo
Augusto
M.
Barbosa
•
Graduado
–
Administração
-­‐
FSL;
•
Mestre
em
Desenvolvimento
Regional
e
Meio
Ambiente
-­‐
UNIR;
•
Especialista
-­‐
MBA
-­‐
Gestão
Empresarial
Estratégica
-­‐
Educon/USP;
•
Especialista
em
Metodologia
do
Ensino
–
FSL;
• Servidor
Público
de
Carreira
–
IPAM
(1991);
•
Professor
(2004)

3. EMENTA
Conceitos
básicos
sobre
gerenciamento
de
projetos,
Perfil
do
Gerente
de
Projetos,
Ferramentas
para
o
Gerenciamento
de
Projetos.
OBJETIVO
GERAL
O
aluno
do
curso
de
Sistemas
para
Internet
deverá
ao
final
do
módulo
saber
aplicar
o
aprendizado
das
ferramentas,
conceitos
e
filosofias
em
aLvidades
profissionais
de
gestão
de
projetos
de
sistema
e
de
soNwares
para
Internet.
OBJETIVO
ESPECÍFICOS
a) Compreender
as
fases
do
gerenciamento
de
projetos
com
base
na
filosofia
do
InsLtuto
de
Gerenciamento
de
Projetos
(PMI);
• Analisar
e
aplicar
a
filosofia
do
PMI
na
gestão
do:
Escopo,
Tempo,
Custo,
Qualidade,
RH
(pessoas),
Aquisições,
Integração,
Risco,
Comunicação
de
projeto
de
sistemas
de
soNwares;

4. CONTEÚDO
PROGRAMÁTICO
DA
DISCIPLINA
1. Premissas
do
Gerenciamento
de
Projetos
• Atributos
de
um
Projeto
• Obje%vo;
condução;
recursos;
tempo;
cliente;
singularidade;
incerteza.
• Fatores
limitantes
para
o
sucesso
e
para
o
próprio
gerenciamento
de
um
projeto.
• Custo;
cronograma
(tempo);
cliente
(sa%sfação);
escopo.
• Ciclo
de
vida
de
um
Projeto
• Iden%ficação
da
necessidade;
Desenvolvimento
da
proposta;
Implementação
da
solução
para
a
necessidade;
conclusão.
• O
processo
de
gestão:
os
sete
passos
para
o
plano
base
• Definição
dos
obje%vos;
divisão
e
subdivisão
do
escopo
em
pacotes
de
trabalhos
–
EAP
(estrutura
analí%ca
de
projetos);
definição
de
a%vidades
específicas
do
projeto;
ilustração
gráfica
do
projeto;
es%ma%va
de
tempos
para
as
a%vidades
de
projetos;
es%ma%va
de
custos;
calculo
do
tempo
e
orçamento

5. 2.
Gerenciamento
de
Projetos
de
Sistemas
de
SoNware
pela
Filosofia
PMI
• Processo
de
Gerenciamento
de
Projeto
• Processo
de
Iniciação;
Processo
de
Planejamento;
Processo
de
Execução;
Processo
de
Encerramento.
• (1)
Integração
do
Gerenciamento
do
Projeto
• Termo
de
abertura;
Declaração
preliminar
de
escopo;
Desenvolver
o
plano
de
gerenciamento
de
projetos;
Orientar
a
gerenciar
a
execução
do
projeto;
Monitorar
e
controlar
o
trabalho
do
projeto;
Controle
integrado
de
mudanças,
encerrar
o
projeto.
• (2)
Gerenciamento
do
escopo
do
projeto
• Planejamento
do
escopo;
definição
do
escopo;
criação
da
EAP;
verificação
do
escopo.
• (3)
Gerenciamento
do
Tempo
do
Projeto
• Definição
da
a%vidade;
sequenciamento
de
a%vidades;
es%ma%vas
de
recursos
das
a%vidades;
es%ma%va
de
duração
das
a%vidades;
desenvolvimento
do
cronograma;
controle
do
cronograma.

6. 2.
Gerenciamento
de
Projetos
de
Sistemas
de
SoNware
pela
Filosofia
PMI
• (4)
Gerenciamento
dos
custos
do
projeto
• Es%ma%vas
de
custos;
orçamento;
controle
de
custos
• (5)
Gerenciamento
da
qualidade
do
projeto
• Planejamento
da
qualidade;
Realização
da
garan%a
da
qualidade
• (6)
Gerenciamento
de
RH
do
projeto
• Planejamento
de
RH;
contratação
ou
mobilização
da
equipe
de
projeto;
desenvolvimento
da
equipe
de
projeto;
gerenciamento
da
equipe
de
projeto.
• (7)
Gerenciamento
do
das
Comunicações
do
projeto
• Planejamento
da
comunicação;
distribuição
das
informações;
relatório
de
desempenho;
gerenciamento
das
partes
interessadas.
• (8)
Gerenciamento
dos
riscos
em
projeto
• Planejamento
de
gerenciamento
de
riscos;
iden%ficação
de
riscos;
análise
qualita%va
de
riscos;
análise
quan%ta%va
dos
riscos;
planejamento
de
repostas
a
riscos.
• (9)
Gerenciamento
de
aquisições
em
projetos
• Planejamento

7. 3.
Seminário
sobre
Gestão
de
Projetos
com
base
em
Ferramentas
Ágeis
Temas
• Agile
Project
Management
(APM)
-­‐
Gerenciamento
Ágil
de
Projetos
• Unified
Process
(UP)
–
Processo
Unificado
• Scrum
–
Processo
de
Desenvolvimento
Intera%vo
e
Incremental
de
Gerenciamento
de
Projetos
• Extreme
Programming
(XP)
–
Programação
extrema
• Feature
Driven
Development
(FDD)
–
Desenvolvimento
Guiado
por
Funcionalidades

8. Regras
do
Jogo
Aulas
aos
sábados
(serão
repassados
conteúdos)
Dias
das
Provas
–
N1
-­‐
Dias
das
Provas
-­‐
N2
–
1.
Alunos
com
“moLvo”
viagem
em
demasia,
gravidez,
doenças,
não
ficam
isentos
de
fazerem
provas,
nem
os
trabalhos.
2.
Faltas:
Tolerância
de
20
faltas
/
21
faltas
aluno
(a)
reprovado
por
falta.
3.
JusLficaLvas
de
Faltas
e
trabalhos
perdidos
com
o
professor
4.
Mais
de
15
dias
somente
com
atestado
(secretaria)
5.
Trabalhos
em
sala,
interação
e
assiduidade
–
(perdeu?
Resumo
e
explicação
do
assunto
ao
professor)
6.
Provas
marcadas
(perdeu?
-­‐
2ª
chamada
procurar
a
coordenação)
7.
Dez
Pontos
de
Assiduidade,
ParLcipação
nas
aulas,
conduta
adequada
do
aluno
(a)
–
entra
e
sai
da
sala,
chegada
atrasada
em
demasia.
8.
Todo
e
qualquer
trabalho
deve
ser
entregue
digitado.
9.
Material
de
Estudo
Livros
na
Biblioteca
e
material
de
apoio
aposLla

9. Avaliação

10. Contato
marcelopvh1@hotmail.com
marcelopvh@gmail.com
8119-­‐1133

11. 1ª
Parte
Pressupostos
Gerais
sobre
Gerenciamento
de
Projeto

12. Um
Projeto
é
assim?

13. 1.
Premissas
sobre
Gerenciamento
de
Projetos
É
um
esforço
para
se
aLngir
um
objeLvo
específico
por
meio
de
um
conjunto
único
de
tarefas
inter-­‐relacionadas
e
da
uLlização
eficaz
de
recursos.
1.1
Atributos
de
um
Projeto
Tem
que
ter
necessariamente
um
objeLvo
bem
definido
–
pode
ser
um
resultado
de
um
produto
desejado.
a)
Um
objeLvo
de
um
projeto
costuma
ser
definido
em
termos
de
escopo,
cronograma
e
custo.
Lançar
no
mercado,
em
dez
meses,
dentro
de
um
orçamento
de
$
500
mil,
um
novo
forno
de
micro
ondas
que
aqueça
e
grelhe
alimentos
e
que
atenda
demais
especificidades
de
desempenho
predefinidas
no
projeto
de
produtos.
b)
É
conduzido
por
meio
de
uma
série
de
tarefas
independentes
.
Tarefas
que
devem
ser
conclusas
em
sequencias
uma
após
a
outra
Uma
casa
só
pode
ser
considerada
uma
casa
se
antes
passar
por
uma
sequencia
lógica
de
tarefas
que
ao
final
darão
a
casa
o
senLdo
de
ser
uma
casa.

14. c)
Um
projeto
uLliza
vários
recursos
para
realizar
as
tarefas
interdependentes
citadas
anteriormente.
Podem
ser
considerados:
Inputs
de
recursos
transformados
que
são:
materiais,
informações
e
consumidores;
ou
ainda
recursos
de
transformação
que
são:
pessoal,
equipamento
e
instalações.
Antes
de
lançar
no
mercado
o
novo
forno
de
micro
ondas
ele
precisou
ser
projetado,
testado,
avaliado...
Para
isso
requereu:
informações
dos
engenheiros,
do
pessoal
no
desenvolvimento
de
protóLpos
para
testes,
requereu
ainda
uma
estrutura
de
testes
,
máquinas,
equipamentos,
recursos
financeiros...outros...
d)
Um
projeto
tem
um
tempo
de
vida
finito.
Uma
caracterísLca
de
todo
e
qualquer
projeto
é
que
ele
tem
hora
para
iniciar
e
hora
para
terminar,
mesmo
que
esse
momento
de
termino
seja
atrasado
em
muitos
dias,
meses
ou
anos.
Um
dia
ele
acaba,
mesmo
que
não
seja
concluso.
Será
abortado.
Um
programador
tem
uma
encomenda
de
um
soNware
empresarial,
ele
inicia
os
trabalhos
e
no
meio
do
caminho
a
empresa
decide
pagar
o
programador
pelo
desenvolvido
e
pagar-­‐
lhe
a
multa
do
contrato
firmado,
pois
não
deseja
mais
o
sistema.
Agora
a
empresa
comprará
outro.
Qual
o
moLvo
do
programador
conLnuar
com
o
projeto
do
soNware???
Nenhum,
dessa
forma
o
projeto
será
abortado.

15. e)
Um
projeto
tem
sempre
um
cliente
(pessoa
xsica
ou
jurídica),
não
existe
projeto
para
ninguém,
somente
desenvolvemos
projetos
se
for
para
alguém,
ou
grupo
de
pessoas.
O
cliente
é
a
figura
que
financia
o
projeto,
portanto
as
especificações
devem
atender
as
necessidades
deste,
senão...
O
Material
do
curso
de
Gerenciamento
de
Projeto
de
Sistemas
é
para
os
alunos
(as).
Quando
a
FORD
desenvolve
um
novo
carro,
pensa
em
comercializa-­‐lo
aos
clientes,
portanto
com
base
nas
necessidades
de
um
carro
por
parte
dos
clientes
a
FORD
cria
o
projeto
de
um
novo
carro
e
o
põe
na
linha
de
produção,
para
depois
ser
comercializado.
f)
É
um
esforço
único
de
uma
única
vez,
para
clientes
com
desejos
diferentes,
e
que
é
feito
em
tempo
disLntos.
• Projeto
de
uma
sonda
espacial;
• Projeto
de
soNwares
customizados
de
Internet
para
empresa;
• Projeto
de
construção
de
uma
ponte,
viaduto...
• Projeto
de
uma
casa
É
um
projeto
único?
SIM
(
)
NÃO
(
)

16. g)
Um
projeto
envolve
um
certo
grau
de
incerteza.
Por
ser
elaborado
sem
garanLa
sobre:
• os
recursos
e
o
orçamento
necessário
e
• o
tempo
a
de
conclusão.
Com
base
nas
incertezas
escopo,
tempo
e
custos
um
projeto
acaba
sendo
incerto.
Um
experiente
projeLsta
com
mais
de
30
anos
no
oxcio
terá
um
certo
grau
de
certeza,
mas
esse
grau
nunca
será
100%.
Mesmo
que
este
esteja
trabalhando
em
um
projeto
similar
servindo
de
parâmetro
de
um
já
realizado,
e
mesmo
que
esse
projeto
possa
ter
dado
muitos
aprendizados.
O
mesmo
não
pode
dizer
que
tem
uma
certeza
total
do
escopo,
do
tempo,
orçamento,
dos
riscos.
Haverá
riscos.
E
os
riscos
devem
ser
gerenciados
com
base
na
experiência
desse
projeLsta.

17. 1.1.1
Fatores
que
limitam
o
Sucesso
do
Projeto
É
a
quanLa
que
o
Especifica
as
datas
em
cliente
concordou
em
que
cada
aLvidade
pagar
por
itens,
deve
começar
e
produtos
ou
serviços
terminar.
Prazo
do
acordados
no
projeto
Projeto
É
todo
o
processo
que
O
objeLvo
de
qualquer
deve
ser
realizado
afim
projeto
é
concluir
o
de
garanLr
ao
cliente
escopo
dentro
do
que
os
itens,
produtos
orçamento,
dentro
da
ou
serviços
cumpram
data
combinada
afim
os
critérios
de
de
saLsfazer
o
cliente
aceitação
acordados

18. 1.2
Ciclo
de
Vida
de
um
Projeto
1ª
Fase
IdenLficação
das
necessidades
–
problema,
oportunidade
e
pode
ou
resultar
de
uma
solicitação
de
proposta
pelo
cliente.
Se
houver
solicitação
a
mesma
se
procede
em
um
instrumento
denominado:
CHAMADA
DE
PROPOSTA
–
CP
–
o
cliente
solicita
que
consultores,
projeLstas
enviem
uma
proposta
sobre
como
resolver
a
necessidade,
e
ou
o
problema.
2ª
Fase
–
desenvolvimento
da
3ª
Fase
–
proposta.
Essa
fase
Implementação
da
resulta
na
entrega
de
solução
da
proposta.
uma
proposta
ao
Fase
de
execução
da
cliente.
Dependendo
proposta.
Envolve
o
do
que
tem
que
ser
planejamento
solucionado
isso
detalhado
do
pode
levar
muito
projeto,
e
em
seguida
tempo.
Ainda
não
é
a
implementação
um
contrato
com
o
desse
plano.
cliente.
4ª
Fase
–
Conclusão
do
projeto.
É
nessa
fase
que
se
efetuam
as
avaliações
dos
resultados
alcançados.

19. 1.3
O
Processo
de
Gestão
de
Projetos
O
processo
de
gestão
de
projetos
significa
planejar
o
trabalho
e
depois
executar
o
plano.
Um
exemplo
é
uma
equipe
de
desenvolvedores
de
sistemas
para
internet
estarem
debruçados
sobre
um
projeto
que
revolucionará
a
metodologia
de
uma
escola
de
idiomas,
que
pretende
ser
100%
virtual.
Isso
é
planejar.
Os
alunos
que
usarão
a
ferramenta
virtual
desenvolvida
julgarão
eficaz
ou
não
do
ponto
de
vista
do
ensino
e
aprendizagem.

20. 1.3
O
Processo
de
Gestão
de
Projetos
1.3.1
Plano
Base
para
o
Processo
de
Gestão
de
Projetos
1º
Passo
–
Definir
claramente
o
objeLvo
do
projeto
–
essa
definição
deve
ser
acordada
entre
o
cliente
e
os
responsáveis
pela
elaboração
e
condução
do
projeto.
2º
Passo
–
Dividir
e
subdividir
o
escopo
do
projeto
em
pacotes
de
trabalhos.
Aqui
trabalhamos
com
um
ferramenta
importan}ssima
para
essa
fase
chamada
de
EAP
(estrutura
analíLca
de
projetos)
ou
WBS,
que
é
uma
espécie
de
árvore
hierárquica
de
elementos
ou
itens
de
trabalho
realizados
pela
equipe
durante
o
período
em
que
o
projeto
esLver
vigendo.
3º
Passo
–
Definir
aLvidades
específicas
que
precisam
ser
conduzidas
para
cada
pacote
de
trabalho
a
fim
de
aLngir
o
objeLvo
do
projeto.
4º
Passo
–
Ilustre
graficamente
as
aLvidades
na
forma
de
um
diagrama
de
rede.
Esse
diagrama
mostra
a
sequencia
necessária
e
as
interdependências
das
aLvidades
para
aLngir
o
objeLvo
do
projeto.

21. 5º
Passo
–
Fazer
uma
esLmaLva
de
tempo
de
quanto
levará
para
completar
cada
aLvidade.
É
necessário
determinar
os
recursos
e
como
esses
serão
uLlizados
em
cada
aLvidade.
6º
Passo
–
Fazer
uma
esLmaLva
de
custos
para
cada
aLvidade.
O
custo
baseia-­‐
se
nos
Lpos
e
nas
quanLdades
de
recursos
necessários
a
cada
aLvidade.
7º
Passo
–
Calcular
o
tempo
e
o
orçamento
para
determinar
se
o
projeto
pode
ser
concluído
dentro
do
prazo
necessário,
com
os
recursos
financeiros
alocados
e
os
demais
recursos
disponíveis.

22. 1.4
Benexcio
da
Gestão
de
Projetos
O
maior
benexcio
é
ter
clientes
saLsfeitos.
Com
isso
quem
desenvolveu
todo
o
projeto
leva
méritos
e
evidentemente
é
indicado
para
outros
novos
projetos.

23. Estudo
de
Caso
E-­‐commerce
para
um
supermercado
pequeno

26. 2ª
Parte
Gestão
de
Projetos
Filosofia

27. 2.
Gerenciamento
de
Projetos
de
Sistemas
de
SoNware
pela
Filosofia
PMI
Fundado
em
1969
por
cinco
pessoas
que
entendiam
o
valor
do
networking,
do
comparLlhamento
das
informações
dos
processos
e
da
discussão
dos
problemas
comuns
de
projetos.
Após
a
primeira
reunião
oficial
em
outubro
de
1969,
no
Georgia
InsLtute
of
Technology
em
Atlanta,
Geórgia,
EUA,
o
grupo
consLtuiu
oficialmente
a
associação
na
Pensilvânia,
EUA.
Desde
então,
o
PMI
cresceu
e
se
tornou
o
maior
defensor
mundial
da
profissão
de
gerenciamento
de
projetos.
O
PMI
conta
com
mais
de
300.000
associados
–
em
mais
de
160
países.
Todos
os
principais
setores
estão
representados,
inclusive
tecnologia
da
informação,
defesa
e
aeroespacial,
serviços
financeiros,
telecomunicações,
engenharia
e
construção,
agências
governamentais,
seguro,
saúde
e
muitos
outros.
A
meta
principal
do
PMI
é
avançar
na
práLca,
na
ciência
e
na
profissão
de
gerenciamento
de
projetos
em
todo
o
mundo,
de
uma
maneira
consciente
e
proaLva,
para
que
as
organizações
em
todos
os
lugares
apoiem,
valorizem
e
uLlizem
o
gerenciamento
de
projetos
–
e
então
atribuam
seus
sucessos
a
ele.

29. Metodologia
das
Aulas

30. 1.
PROCESSO
DE
INICIAÇÃO
DO
PROJETO
PROCESSOS
DE INICIAÇÃO
Desenvolver
o termo de
1.1
Termo
de
abertura
do
projeto
abertura do
projeto
São
documentadas
as
necessidades
de
negócio
e
os
requisitos
Identificar as
principais
do
produto
serviço,
ou
sistema;
apresenta
a
jusLficaLva
do
interessadas
partes
projeto;
o
entendimento
das
necessidades
do
cliente;
descreve
o
produto,
serviço
ou
sistema
que
será
abordado
nos
requisitos.
Em
geral
o
termo
de
abertura
responde
e
posteriormente
documenta:
1. Quais
as
necessidades,
desejos
e
expectaLvas
dos
clientes
patrocinadores
e
outras
partes
interessadas?
2. Quais
as
necessidades
de
negócio,
descrição
de
alto
nível
do
projeto,
além
de
requisitos
do
produto,
serviços
ou
sistema
que
será
abordado
pelo
projeto?
3. Qual
(is)
o
(s)
objeLvo
(os),
que
problema
pretende
ser
resolvido?
4. Qual
a
jusLficaLva
para
o
projeto?

31. PROCESSOS
DE INICIAÇÃO
Desenvolver
o termo de
1.
PROCESSO
DE
INICIAÇÃO
DO
PROJETO
abertura do
projeto
Identificar as
partes
interessadas
5. Quais
serão
os
marcos
(regulatórios)
do
cronograma
do
projeto?
6. Qual
é
o
grau
de
influência
dos
stakeholders
no
projeto
?
7. Quais
premissas
ou
hipóteses
que
podem
aumentar
ou
não
o
risco
do
projeto:
falta
de
recursos
financeiro?,
pessoal
qualificado
para
as
fases
do
projeto?
que
outras?
8. Quais
são
as
restrições
organizacionais
(empresa);
do
ambiente
externo
e
interno?
do
sistema
de
informação?
Dos
processos?

32. Exercício
Com
base
no
CASE:
E-­‐commerce
para
um
supermercado
pequeno
Pense
em
uma
proposta
para
atender
ao
problema
da
empresa,
e,
seguida
desenvolva
um
termo
de
abertura
(texto)
que
tenha
basicamente
a
resposta
as
oito
questões
básicas
para
elaboração
de
um
termo
de
abertura.

33. 2.
PROCESSO
DE
PLANEJAMENTO
2.1
Desenvolvimento
do
plano
de
gerenciamento
de
projeto
O
objeLvo
de
processo
de
planejamento
integrado
é
garanLr
a
coesão
e
a
coerência
entre
vários
processos
do
planejamento
do
projeto.
Ex.:
os
prazos
são
definidos
em
função
dos
recursos
humanos
,
alocados
para
o
projeto,
e
o
nível
de
qualificação
e
as
quanLdades
destes
recursos
influenciarão
o
custo
e
a
qualidade
dos
trabalhos.
O
resultado
deste
processo
é
a
geração
do
plano
de
projeto,
que
será
uLlizado
para
guiar
a
execução
e
o
controle
do
projeto,
documentar
as
premissas
de
planejamento,
a
estratégia
de
desenvolvimento,
formalizar
o
escopo
e
o
cronograma,
além
de
outras
informações
relevantes.
O
planejamento
é
construído
através
dos
seguintes
passos:

34. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Definição
do
Escopo
A
declaração
de
escopo
do
projeto
define,
o
que
vai
ser
realizado
pelo
projeto
e
inclui
as
limitações
do
projeto.
Em
geral
ela
documenta:
a) ObjeLvos
do
projeto;
b) Descrição
do
escopo
do
produto;
c) Requisitos
do
projeto;
d) Limites
do
projeto;
e) Entregas
do
projeto;
f) Critérios
de
aceitação
do
produto;
g) Restrição
do
projeto;
h) Premissas
do
projeto;
i) Organização
da
equipe
e
partes
interessadas;
j) Riscos
iniciais
definidos;
k) Marcos
do
cronograma;
l) Limitação
de
recursos
financeiros;
m) EsLmaLvas
de
custos
n) Requisitos
para
o
gerenciamento
de
configuração
o) Requisitos
de
aprovação.

35. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Criação
de
uma
EAP
(estrutura
analíLca
de
projetos)
ou
WBS
(work
breakdown
structure).
É
uma
espécie
de
check
list
que
idenLfica
todas
as
partes
de
um
projeto
e
as
tarefas
associadas,
ou
seja
subdivide
o
trabalho
do
projeto
em
partes
menores
que
podem
ser
gerenciadas
com
maior
facilidade.
O
que
uma
EAP
apresenta
como
benexcio
ao
gerenciamento
de
projetos?
a) Apresenta
os
produtos
finais
que
serão
entregues
ao
cliente,
assim
como
os
subprodutos
intermediários;
b) Fornece
uma
ilustração
detalhada
do
escopo
do
projeto;
c) Dá
origem
ao
cronograma
e
permite
monitorar
o
progresso;
d) Mostra
o
detalhamento
de
custo
de
equipamento,
mão
de
obra
e
materiais;
e) Auxilia
na
montagem
da
equipe
e
distribuição
do
trabalho;
f) Facilita
a
idenLficação
de
riscos.

36. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Definir
aLvidades
No
nível
mais
baixo
de
uma
EAP
estão
definidos
os
pacotes
de
trabalho
que
serão
executados
no
projeto
,
e
estes,
por
sua
vez,
são
decompostos
em
aLvidades.
Estas
aLvidades
darão
origem
ao
cronograma
do
projeto,
sendo
que
cada
aLvidade
deverá
requerer
uma
entrada
(input)
e
uma
saída
(output),
onde
o
output
de
uma
aLvidade
deve
ser
o
input
da
próxima
aLvidade,
ao
nome
disso
chamamos
de
aLvidades
dependentes
com
relacionamento
lógico
estre
elas.
Ex:
o
desenvolvimento
de
um
soNware
na
aLvidade
teste
(beta)
somente
poderá
ocorrer
se
muitas
outras
aLvidades
anteriores
Lverem
sido
executadas.
A
própria
programação
é
uma
delas.

37. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Sequenciamento
das
aLvidades
Com
a
dependência
de
uma
ou
várias
aLvidades
dependentes
com
relacionamento
lógico
estre
elas
criamos
o
sequenciamento.
A
ferramenta
mais
adequada
para
se
definir
o
relacionamento
lógico
entre
as
aLvidades
ou
o
sequenciamento
é
o
diagrama
de
REDE,
ou
conhecido
como
Diagrama
de
PERT
(program
evaluaLon
and
review
technique)
–
Técnica
de
Avaliação
e
Análise
de
Programas.

38. Exemplo:
Diagrama
de
Rede

39. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
EsLmaLva
dos
recursos
das
aLvidades
Após
a
elaboração
do
diagrama,
o
próximo
passo
é
atribuir,
para
cada
pacote
de
trabalho,
a
quanLdade
necessária
de
recursos
(pessoas
e
materiais),
seus
custos
e
prazos.
EsLmaLva
de
Duração
das
aLvidades
Existem
várias
maneiras
de
fazer
esLmaLvas
de
prazos,
um
exemplo
é
buscar
os
projetos
anteriores
e
verificar
seus
históricos
de
tempo
para
aLvidades
similares.
Mas
quando
não
se
tem
tais
projetos,
a
recomendação
é
ouvir
as
pessoas
que
estarão
na
operação
das
referidas
aLvidades.

40. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Cont.
EsLmaLva
de
Duração
das
aLvidades
As
esLmaLvas
de
tempo
devem
ser
realistas
e
não
oLmistas,
caso
contrário
as
pessoas
poderão
ter
expectaLvas
erradas
da
realidade
do
projeto.
Quando
há
muita
incerteza
na
elaboração
da
esLmaLva,
pode-­‐se
uLlizar
o
PERT
(ferramenta
já
demonstrada
anteriormente)
Essa
técnica
usa
peso
médio
ponderado
para
calcular
a
duração
das
aLvidades,
ou
seja,
a
esLmaLva
considerada
é
igual
a
formula
abaixo:
PRAZO
OTIMISTA
+
PRAZO
PESSIMISTA
+
(PRAZO
PROVÁVEL
x
4)
6

41. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Desenvolvimento
do
Cronograma
O
cronograma
do
projeto
tem
como
base
as
aLvidades
e
o
tempo
que
cada
uma
delas
leva
para
ser
concluída,
e
também
seus
relacionamentos
lógicos
(sequenciamento).
No
cronograma
quando
se
insere
as
aLvidades
o
mesmo
vai
definindo
quais
daquelas
serão
mais
críLcas
no
momento
de
conclusão.
A
essas
aLvidades
que
somam
todo
o
tempo
do
projeto
chamamos
de
aLvidades
críLcas,
que
são
descritas
em
um
cronograma
de
Gan„
simples,
no
próprio
sistema
de
gerenciamento
de
projetos
da
microsoN
o
MS-­‐Project.

42. Como
fazer
um
EAP?
Por
onde
começo?
O
que
tenho
que
fazer?

47. Modelo
Genérico
de
EAP
para
Desenvolvimento
de
SoNware

48. Modelo
de
EAP
com
detalhamento
de
níveis,
dos
executores
(RH)
e
das
fases

49. Modelo
de
EAP
desenvolvida
no
MS-­‐Project
2003
–
Projeto
de
Implantação
de
uma
Clínica
de
Fisioterapia
e
Reabilitação
em
Porto
Velho
–
CIA
do
MOVIMENTO

51. Dicionário
EAP
Desenvolvimento
do
Cronograma
O
dicionário
da
EAP
é
um
documento
gerado
pelo
processo
criação
da
EAP
que
a
suporta.
Fornece
descrições
mais
detalhadas
dos
componentes
da
EAP,
inclusive
dos
pacotes
de
trabalho
e
contas
de
controle.
Em
um
dicionário
da
EAP
são
exigidas
duas
informações
1) A
Descrição
da
aLvidade
2) Os
critérios
de
aceite
da
mesma

52. Exemplo:
Dicionário
EAP

53. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
EsLmaLva
dos
custos
O
planejamento
do
custos
tem
por
objeLvo
a
elaboração
do
orçamento
do
projeto,
definindo-­‐se
os
recursos
que
serão
uLlizados
(pessoas,
equipamentos
e
materiais
de
consumo),
suas
respecLvas
quanLdades
e
as
datas
em
que
serão
necessários.
A
EAP
é
a
principal
fonte
para
o
planejamento
dos
custos,
já
que
ela
idenLfica
os
resultados
do
projeto.
No
início
do
projeto,
geralmente
o
planejamento
é
composto
de
uma
esLmaLva
preliminar
que
apresenta
apenas
ordem
de
grandeza,
que
pode
ter
uma
precisão
entre
–
25%
e
+
75%.
Á
medida
em
que
o
projeto
evolui,
esLmaLvas
mais
precisas
são
elaboradas
com
precisão
entre
-­‐10%
e
+
25%.
A
esLmaLva
definiLva
do
planejamento
dos
custos
geralmente
tem
uma
precisão
entre
-­‐5%
e
+
10%,
uma
vez
que
há
mais
conhecimento
sobre
o
trabalho.

54. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
EsLmaLva
dos
custos
Métodos
de
custos
adotados
em
projetos
mais
conhecidos
são
os
TOP-­‐DOWN
e
BOTTOM-­‐UP.
TOP-­‐DOWN
–
é
uLlizada
nas
fases
iniciais
do
projeto,
quando
as
informações
disponíveis
são
bastante
limitadas.
Neste
método
é
elaborado
uma
única
esLmaLva
para
o
projeto
inteiro,
sendo,
depois,
este
valor
rateado
entre
os
elementos
na
EAP.
A
esLmaLva
pode
ser
realizada
consultando
especialistas,
o
próprio
histórico
de
projetos
similares
O
método
BOTTOM-­‐UP
é
usado
quando
há
necessidade
de
precisão
nos
valores.
Para
obter
o
custo
de
um
item
As
esLmaLvas
de
custos
são
definidas
para
intermediário,
de
um
nível
mais
alto
da
EAP,
os
elementos
dos
níveis
mais
baixos
da
EAP.
basta
somar
os
custos
dos
elementos
que
estão
abaixo
dele.

55. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
EsLmaLva
dos
custos
Quando
há
incerteza
nos
cálculos
dos
custos,
pode
ser
uLlizada
a
técnica
probabilísLca
do
PERT,
também
usada
na
esLmaLva
de
tempo.
Desta
forma,
a
esLmaLva
de
custo
é
igual.
A
vantagem
do
método
BOTTOM-­‐UP
é
a
maior
precisão,
enquanto
que
a
principal
desvantagem
é
o
tempo
e
o
esforço
necessário
no
processo
de
cálculo
dos
custos.
CUSTO
OTIMISTA
+
CUSTO
PESSIMISTA
+
(CUSTO
PROVÁVEL
x
4)
6

56. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Análise
dos
Custos
Em
projetos,
o
poder
de
influência
sobre
os
custos
é
maior
no
início,
quando
eles
ainda
não
são
totalmente
conhecidos.
O
gerenciamento
dos
custos
tem
um
papel
importante
no
planejamento
e
na
definição
dos
pacotes
de
trabalhos
do
projeto,
pois
ele
fornece
dados
para
o
sistema
de
informações
que
as
empresas
uLlizam
para
a
tomada
de
decisão.
Na
elaboração
do
orçamento,
precisamos
ter
conhecimento
dos
custos
que
irão
incorrer
no
projeto
para
que
o
gestor
tenha
consciência
do
o
gestor
efeLvamente
quer
para
o
projeto.

57. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Análise
dos
Custos
Armadilhas
a
serem
evitadas
para
um
bom
gerenciamento
dos
custos
1) Má
interpretação
da
declaração
de
trabalho
do
projeto,
quando
ele
é
resultado
de
um
contrato;
2) Escopo
com
omissões
ou
mal
definido;
3) Cronograma
pobremente
definido
ou
muito
oLmista;
4) EAP
pouco
detalhada;
5) Previsão
de
recursos
com
perfil
inadequado
para
as
tarefas;
6) Falha
na
quanLficação
de
riscos;
7) Falha
no
entendimento
e
contabilização
dos
diversos
Lpos
de
custos;
8) Escolha
errada
das
diferentes
técnicas
de
esLmaLvas
de
custos.

58. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Custos
Diretos
São
idenLficados
e
quanLficados,
a
parLr
dos
recursos
necessários.
São
aqueles
diretamente
atribuídos
ao
trabalho
do
projeto.
Exemplo
de
custos
diretos:
a) Mão
de
obra
(mensurados
através
das
horas
de
trabalho);
b) Materiais
(alocados
conforme
descrição
das
necessidades);
c) Equipamentos
(descrição
conforme
necessidade);
d) Serviços
terceirizados
(alguns
ligados
a
produção
do
projeto);
e) Insumos
a
produção
(quando
necessários
para
o
processamento
das
aLvidades
do
projeto)

59. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Custos
Indiretos
São
despesas
em
gerais
e
gastos
incorridos
pela
empresa
em
benexcio
de
mais
de
um
projeto,
normalmente
são
custos
relaLvos
a
manutenção
do
negócio.
Não
são
facilmente
idenLficados,
pois
se
relacionam
com
as
aLvidades
de
funcionamento
da
empresa
como
um
todo
e
poderão
ser
rateados
com
outros
custos
de
fácil
mensuração.
Esses
custos
são
analisados
em
quatro
grupos
de
análise
a) Custos
administraLvos
=>
relacionados
as
aLvidades
da
administração:
salários
dos
diretores,
do
pessoal
de
assessoramento
e
administraLvo,
materiais
de
escritório
e
outros
(das
aLvidades
meio
da
empresas)
b) Custos
comerciais
=>
incorridos
na
comercialização
dos
produtos
da
organização:
markeLng,
promoção
do
produtos/serviços/sistema
(aLvidades
relacionadas
a
mídia
promocional
e
outras
relacionadas
as
formas
de
venda)
c) Custos
tributários
=>
decorrem
de
disposições
legais:
tributos,
taxas,
impostos,
emolumentos
e
tarifas.
d) Custos
financeiros
=>
são
aqueles
nos
quais
se
referem
ao
custos
do
dinheiro:
juros
de
emprésLmos
necessários
para
financiar
o
projeto

62. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Custos
Fixos
São
aqueles
que
não
variam
com
a
quanLdade
de
aLvidade
do
projeto,
ou
para
uma
dada
faixa
de
volume
de
projetos,
como
por
exemplo:
instalações,
aluguéis
etc.
Quanto
mais
projeto,
mais
pessoas
estarão
trabalhando
e
precisarão
de
mais
espaço,
logo
será
necessário
aumentar
o
número
de
salas,
computadores...

63. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Custos
Variáveis
Se
modificam
de
forma
proporcional
e
direta,
em
função
da
dimensão
do
trabalho
do
projeto
ou
da
quanLdade
dos
produtos
produzidos
como,
por
exemplo:
materiais
e
suprimentos
uLlizados
no
projeto

64. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Custos
Totais
São
os
consLtuídos
pela
somatória
dos
custos
diretos
mais
os
indiretos;
dos
fixos
e
variáveis.

65. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Orçamentação
O
orçamento
agrega
os
custos
esLmados
em
uma
EAP
para
que
assim
possa-­‐se
estabelecer
uma
linha
de
base
dos
custos
totais
do
projeto.
O
desempenho
do
projeto
é
avaliado
com
base
no
dinheiro
que
entra
e
que
sai
durante
o
seu
ciclo
de
vida.
No
orçamento
além
dos
custos
normais
previstos
na
EAP,
pode-­‐se
esLmar
um
percentual
de
aumento
referentes
as
conLngências
do
projeto.

66. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Orçamentação

67. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
da
Qualidade
Esse
processo
ocorre
em
paralelo
com
outros
processos
de
planejamento.
Busca
definir
os
padrões
de
qualidade
que
precisam
ser
seguidos.
O
resultado
do
planejamento
da
qualidade
é
um
plano
que
descreve
como
a
qualidade
do
projeto
será
garanLda,
assim
como
as
aLvidades
que
a
equipe
do
projeto
terá
que
executar
para
garanLr
este
objeLvo.
No
planejamento
da
qualidade
examinam-­‐
se
as
caracterísLcas
do
produto
comparando-­‐os
às
necessidades
explícitas
e
implícitas
dos
stakeholders
(interessados)
no
projetos.

68. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
da
Qualidade
A
qualidade
de
um
produto
se
aplica
tanto
aos
elementos
técnicos
e
funcionais
como
a
documentação.
A
solução
deve
agradar
ao
cliente,
ser
de
fácil
administração,
robusta,
confiável
e
estável.
A
documentação
deve
ser
completa,
clara,
de
fácil
consulta
e
seguir
os
padrões
impostos
pelo
cliente.
No
âmbito
do
próprio
projeto
a
qualidade
está
associada
ao
cumprimento
das
instruções
de
trabalho
que
regem
o
projeto:
comunicação,
cumprimento
das
metas,
prazos
e
orçamento
de
cada
pacote
de
trabalho,
gerenciamento
dos
riscos
e
tudo
o
que
mais
puder
ser
gerenciado
e
verificado
se
vai
atender
as
necessidades
do
clientes.

69. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
da
Qualidade
Princípios
da
Qualidade:
1)
Fazer
o
trabalho
certo
na
primeira
tentaLva,
economizando
recursos
materiais
(dinheiro)
e
tempo;
2)
A
qualidade
é
um
processo
prevenLvo;
3)
Cumprir
as
exigências
e
especificações
do
escopo
do
projeto,
através
da
sua
EAP;
4)
Produzir
produtos
e
serviços
que
atendam
às
necessidades
do
cliente;
5)
Entregar
produtos
cujas
funcionalidades
6)
A
qualidade
é
responsabilidade
de
todos
foram
devidamente
testadas.
Não
deve
os
membros
da
equipe;
haver
falhas
no
produto
entregue!
7)
A
qualidade
é
um
processo
de
aprimoramento
con}nuo.

70. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Ferramentas
da
Qualidade
para
Gestão
de
Projetos:
1) CICLO
PDCA
(FILOSOFIA
DE
GESTÃO)
2) FLUXOGRAMA
DE
PROCESSOS
3) FOLHA
DE
VERIFICAÇÃO
4) CARTA
DE
TENDÊNCIA
5) CHECK
LIST
DE
ADERÊNCIA
6) DIAGRAMA
DE
ISHIKAWA
(CAUSA
E
EFEITO
DOS
PROBLEMAS
EM
GESTÃO
DE
PROJETOS)
7) MATRIZ
DE
GUT
(GRAVIDADE,
URGÊNCIA
E
TENDÊNCIA)
8) HISTOGRAMAS
9) DIAGRAMA
DE
PARETO

71. Desenvolvimento
do
plano
de
gerenciamento
de
projeto

72. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
PLANEJAR
(P)
-­‐
definir
metas,
horizontes,
métodos
e
técnicas.
Pode
ser
um
planejamento
estratégico,
um
plano
de
ação,
um
conjunto
de
padrões
ou
cronograma.
EXECUTAR
(D)
-­‐
executar
as
tarefas
exatamente
como
previsto
na
etapa
de
planejamento
e
coletar
dados
para
verificação
do
processo.
Pode
ser
um
programa
de
treinamento
e
educação
seguido
de
ações
operacionais
concretas,
por
processo.
Nesta
etapa
são
essenciais
a
educação
e
o
treinamento.
VERIFICAR
(C)
–
a
parLr
dos
dados
coletados
na
execução,
comparar
as
metas
definidas
com
os
resultados
obLdos.
CORRIGIR
(A)
-­‐
eliminar
as
causas
idenLficadas
como
geradoras
dos
desvios
(diferenças
entre
meta
e
resultado),
para
que
mesmo
moLvo,
esses
desvios,
não
voltem
a
ocorrer.
A
ação
correLva
pode
ocorrer
no
planejar,
no
executar,
no
verificar
e
no
próprio
corrigir

73. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
As
etapas
a
serem
seguidas
no
planejamento
para
a
qualidade
são:
·∙
1)
IdenLficação
do
produto
ou
do
serviço
• IdenLfique
o
resultado
produzido,
não
a
aLvidade.
• IdenLfique
o
resultado
específico,
não
o
genérico.
• Diferencie
os
resultados
intermediários
dos
resultados
finais.
• IdenLfique
os
resultados
de
acordo
com
o
seu
nível
de
responsabilidade.
2)
IdenLficação
do
cliente
• IdenLfique
o
grupo
que
é
o
próximo
a
parLcipar
no
processo
de
trabalho.
• IdenLfique
a
pessoa,
dentro
do
grupo.
• Verifique
se
há
clientes
indiretos.
• Verifique
a
seqüência
do
processo
até
chegar
ao
cliente
final.
3)
IdenLficação
dos
requisitos
do
cliente
• ConscienLze-­‐se
de
que
cada
cliente
pode
ter
necessidades
diferentes.
• IdenLfique
os
requisitos
racionais
do
cliente.
• IdenLfique
os
requisitos
afeLvos
do
cliente.
4)
Transformação
dos
requisitos
do
cliente
em
especificações
• Verifique
se
as
caracterísLcas
desejadas
podem
ser
medidas.
• Analise
os
requisitos
para
verificar
se
não
existem
contradições.
• Verifique
se
todos
os
requisitos
têm
o
mesmo
peso.
• Analise
se
os
requisitos
do
cliente
são
viáveis.
• Verifique
o
que
pode
ser
negociado.

74. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Organização
Na
organização
para
a
qualidade
as
etapas
a
serem
seguidas
são:
1)
Definição
dos
elementos
do
processo
• IdenLfique
os
conhecimentos
e
as
habilidades
necessárias
ao
desenvolvimento
do
processo.
• Procure
conhecer
a
natureza
dos
materiais
e
das
informações
que
serão
uLlizados.
• Faça
um
levantamento
dos
recursos
e
das
instalações
possíveis.
• Oriente-­‐se
quanto
aos
métodos
e
aos
procedimentos
adequados.
• Estabeleça
padrões
de
desempenho.
2)
Estabelecimento
de
medições
necessárias
IdenLfique:
• O
que
medir.
• Como
medir.
• Quando
medir.

75. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
3)
Determinação
da
Capacidade
do
Processo
• Verifique
se
o
processo
atende
aos
requisitos
do
cliente,
a
um
custo
de
não-­‐
conformidade
zero.
• Assegure-­‐se
de
que
o
processo
escolhido
seja
efeLvamente
capaz
de
produzir
o
resultado
desejado.
• Avalie
se
as
variações
do
processo
permitem
atender
plenamente
aos
requisitos
do
cliente.

76. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Controle
O
controle
da
qualidade
se
verifica
quando
são
executados
os
seguintes
passos:
1)
Avaliação
dos
Resultados
do
Processo
• Compare
o
que
foi
efeLvamente
obLdo
com
as
especificações
acordadas
com
o
cliente.
• Decida,
após
esta
comparação,
as
ações
que
devem
ser
executadas
a
seguir.
2)
Reciclagem
do
Processo
• Procure
idenLficar
as
oportunidades
de
melhoria,
se
nenhum
problema
for
detectado.
• Adote
a
metodologia
de
análise
e
solução
de
problemas,
se
a
avaliação
indicar
a
existência
de
um
resultado
indesejado
do
processo.
• Recicle
o
processo.

77. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Estudando
as
Ferramentas
Por
que
uLlizar
• A
uLlização
de
metodologias
de
trabalho,
e
a
aplicação
de
ferramentas
que
sejam
do
conhecimento
de
todos
na
organização,
dentro
da
mesma
filosofia,
cria
uma
nova
“linguagem
administraLva”,
inclusive
gráfica,
que
permite
uma
maior
rapidez
e
transparência
nas
comunicações
internas
e
a
consequente
agilização
na
tomada
de
decisões.
• As
ferramentas
da
qualidade
não
são
uma
invenção
nova,
algumas
delas
já
existem
desde
a
II
Guerra
Mundial,
e
combinadas
a
outras
mais
recentes
formam
o
atual
conjunto
de
que
se
dispõe
para
o
desenvolvimento
de
ações
de
melhoria.
É
comum
classificá-­‐las
em
ferramentas
esta}sLcas
e
não
esta}sLcas.

78. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Ferramentas
não
Esta}sLcas
Fluxograma
• É
a
representação
esquemáLca,
da
sequência
(setas)
das
etapas
(caixas)
de
um
processo,
e
tem
por
objeLvo
ajudar-­‐nos
a
perceber
sua
lógica
dos
fluxos
e
roLnas.
• O
fluxograma
serve
para
compreender
e
melhorar
o
processo
de
trabalho,
criar
um
procedimento
padrão
de
operação
e
mostrar
como
o
trabalho
deverá
ser
feito.
• É
uLlizado
também,
como
ferramenta
de
comunicação,
de
compreensão,
aprendizado
e
auxílio
à
memória;
possibilita
idenLficar
instruções
incompletas,
"loops"
perigosos
e
serve
como
roteiro
de
controle
e
padronização.
É
muito
úLl
na
idenLficação
e
resolução
de
problemas
e
na
operacionalização,
no
controle
e
na
melhoria
de
um
processo.
• Na
construção
de
um
fluxograma
são
uLlizados
símbolos
variados,
e
os
mais
comuns
são
os
apresentados
a
seguir:

79. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Fluxograma-­‐
Símbolos
mais
usuais
Indica
o
início
e
o
fim
do
fluxo,
devendo
essa
indicação
ser
escrita
dentro
do
símbolo.
Indica
a
execução
de
uma
ação
no
fluxo,
devendo
essa
ação
ser
descrita
sinteLcamente
dentro
do
símbolo
Indica
uma
pergunta,
a
qual
deverá
estar
conLda
no
símbolo
Indica
o
senLdo
do
fluxo
Indica
a
sequência
do
fluxo,
devendo
ser
numerado
para
que
não
se
perca
a
ordem
de
execução.

80. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Exemplo
de
Fluxograma
Processo ???
Operações ???

81. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Folha
de
Verificação
• É
a
ferramenta
uLlizada
para
padronizar
e
verificar
resultados
de
trabalho
ou
para
facilitar
e
organizar
o
processo
de
coleta
e
registro
de
dados.
• As
Folhas
de
Verificação
para
coleta
e
organização
de
dados
são
também
chamadas
de
Folhas
de
Dados.
São
formulários,
nos
quais
os
itens
a
serem
observados
são
previamente
impressos,
permiLndo
a
oLmização
da
análise
dos
dados
obLdos.
Na
preparação
de
uma
Folha
de
Verificação
devem
ser
incluídos,
sempre
que
possível,
os
seguintes
itens:
• ObjeLvo
da
verificação
(por
que
-­‐
"why");
• Os
itens
a
serem
verificados
(o
que
-­‐
"what");
• Os
métodos
de
verificação
(como
-­‐
"how");
• A
data
e
a
hora
das
verificações
(quando
-­‐
"when");
• O
nome
da
pessoa
que
faz
a
verificação
(quem
-­‐
"who");
• Os
locais
e
processos
das
verificações
(onde
-­‐
"where");
• Os
resultados
das
verificações;
• A
sequência
das
verificações.

82. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Além
disso,
é
necessário:
• Definir
o
período
para
a
coleta
de
dados;
• Elaborar
um
formulário
simples
e
fácil
de
ser
preenchido;
• Verificar
se
os
dados
podem
ser
colhidos
consistente
e
oportunamente.
Exemplo
de
uma
Folha
de
Verificação
Carta
de
Tendência
São representações gráficas de dados coletados, em um determinado período, para
identificar tendências ou outros padrões que ocorrem ao longo deste período.

83. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Exemplo
de
Carta
de
Tendência
Minutos
que
se
leva
para
começar
a
trabalhar
na
seção
X
Checklist
de
Aderência
É
um
formulário,
previamente
elaborado,
para
coleta
de
opiniões
sobre
o
quanto
pessoas
ou
organizações
conhecem,
aceitam
ou
praLcam
ações,
princípios
ou
comportamentos
que
estão
sendo
avaliados.

84. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
CHECKLIST
DE
ADERÊNCIA
AOS
PRINCÍPIOS
DA
QUALIDADE
Aderente
5
4
3
2
1
0
Não
Aderente
Extremamente
Extremamente
Bastante
Bastante
Levemente
Levemente
Exemplo
de
Tabela
de
Chek
List
de
Aderência

85. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
5.
Diagrama
de
causa
e
efeito
• É
uma
ferramenta
uLlizada
para
apresentar
a
relação
existente
entre
o
resultado
de
um
processo
(efeito)
e
os
fatores
(causas),
que
possam
afetar
este
resultado;
estudar
processos
e
situações,
e
como
ferramenta
de
planejamento.
• É
também
conhecido
como
diagrama
de
espinha
de
peixe
ou
diagrama
de
Ishikawa.
Desenvolvido
no
Japão,
em
1943,
por
Kooru
Ishikawa,
permite,
ainda,
representar
a
relação
entre
problema
e
todas
as
possibilidades
de
causas
que
podem
implicar
neste
efeito.
• Para
facilitar
a
construção
do
diagrama,
Ishikawa
idealizou
quatro
categorias
de
causas
conhecidas
como
4M.
Outras
categorias
foram
propostas
e
nada
impede
que
cada
pessoa
proponha
sua
próprias
categorias,
não
esquecendo,
todavia,
que
a
simplicidade
é
o
segredo
para
o
bom
funcionamento
desta
ferramenta.

86. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
As
categorias
mais
comuns,
para
agrupamento
das
causas
podem
ser:
• 4M:
Mão-­‐de-­‐obra,
Máquina,
Método
do
Processo
ou
da
Medida
e
Materiais.
• 5M:
Mão-­‐de-­‐obra,
Máquina,
Método,
Materiais
e
Manager
(Gerenciamento).
• 6M:
Mão-­‐de-­‐obra,
Máquina,
Método,
Materiais
Manager
e
Meio
Ambiente.
• 7M:
Mão-­‐de-­‐obra,
Máquina,
Método,
Materiais,
Manager,
Meio
Ambiente
e
Money
(Dinheiro).
Processo
de
elaboração
de
um
Diagrama
de
Causa
e
Efeito
1.
Escreva
o
problema
a
ser
analisado
em
um
retângulo
à
direita
de
uma
folha
de
cartolina,
flip-­‐chart,
quadro
branco,
quadro
para
giz,
etc.
O
Problema
Reuniões
Não
ProduLvas

87. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
2.
Trace
uma
reta,
da
esquerda
para
a
direita,
acrescentando
uma
seta
no
ponto
em
que
a
reta
encontra
o
retângulo.
Reuniões
Não
ProduLvas
3.
Relacione
as
causas
básicas
dentro
de
retângulos
e
ligue
cada
um
deles
ao
eixo
horizontal
do
diagrama.
Mão
de
Obra
Local
Reuniões
Não
ProduLvas
Método
Gerência
Esses
fatores
são
gerais
e
seu
número
varia
Lpicamente
de
4
a
6
categorias

88. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
4.
Relacione,
como
espinhas
médias,
as
causas
secundárias,
terciárias
e
quaternárias.
Para
cada
causa
primária
(dentro
dos
retângulos)
5.
IdenLfique
subcausas
(secundária,
terciária
e
quaternária)
que
as
afetam.
Exemplo
de
Diagrama
de
Ishigawa

89. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Matriz
de
GUT
Gravidade
(impacto
do
problema
sobre
coisas,
pessoas,
resultados,
processos
ou
organizações
e
efeitos
que
surgirão
a
longo
prazo,
caso
o
problema
não
seja
resolvido);
•
Urgência
(relação
com
o
tempo
disponível
ou
necessário
para
resolver
o
problema)
•
Tendência
(potencial
de
crescimento
do
problema,
avaliação
da
tendência
de
crescimento,
redução
ou
desaparecimento
do
problema).

90. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
de
aquisições
Recursos
Humanos
Envolve
a
descrição,
o
recrutamento
e
a
seleção
de
profissionais
para
suprimento
dos
cargos,
funções,
responsabilidade
e
competências
no
projeto.
Para
definir
responsabilidades
aos
profissionais
no
projeto
se
desenvolve
uma
simples
matriz.

91. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
de
aquisições
Recursos
Materiais
Envolve
a
descrição
dos
inputs
de
recursos
de
materiais
necessários
a
todas
as
etapas
do
projetos.
Quando
se
desdobra
as
aLvidades
na
EAP,
e
de
define
as
responsabilidades
aos
gerentes
cada
um
terá
que
planejar
suas
necessidades
de
materiais,
que
como
consequência
será
lançada
no
orçamento
do
projeto.
Se
a
qualidade
não
for
a
máxima
em
um
projeto
os
gerentes
podem
por
descuido
esquecer
itens
importantes
em
um
projeto,
o
que
ocasionará
aumento
dos
custos
e
insaLsfação
do
cliente.
+
+
+
+

92. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
das
Comunicações
No
planejamento
das
comunicações
define-­‐se
que
informações
precisarão
ser
geradas,
para
quem
e
como
serão
distribuídas.
O
ObjeLvo
é
perguntar:
Quem
precisa
da
informação?
De
que
informações
precisam?
Quando
e
como
vão
obter
as
informações?
Em
projetos
pequenos
não
há
necessidade
de
se
formalizar
o
plano
de
comunicação,
pois
nestes
casos
a
quanLdade
de
pessoas
envolvidas
geralmente
é
pequena.
A
seguir
inserimos
um
quadro
como
exemplo
de
como
o
plano
de
comunicação
poderia
ser
registrado.
Todos
os
documentos
em
registros
do
projeto
indicados
no
quadro
devem
ser
manLdos
em
local
acessível
para
todos
os
parLcipantes.

93. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
das
Comunicações

94. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Planejamento
das
Comunicações
O
Plano
de
Comunicação
deve
considerar
as
seguintes
informações:
• Detalhamento
das
informações
a
serem
coletadas
e
os
respecLvos
métodos
de
armazenamento;
• Definição
de
um
estrutura
de
distribuição
das
informações,
indicando
os
desLnatários
e
os
métodos
de
distribuição
• Descrição
das
informações,
incluindo
seu
formato,
conteúdo
e
o
nível
de
detalhamento
• Cronograma
das
comunicações
• Métodos
de
acesso
às
informações,
depois
de
armazenadas,
e
esquemas
de
controle
de
acessos
• Método
para
revisão
do
plano
de
comunicação

95. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
A
palavra
RISCO
é
derivada
do
Italiano
anLgo
RISICARE,
que
quer
dizer
OUSAR,
e
pode
ser
originada
também
do
laLm
RISCU,
RISICU
que
significa
INCERTEZA.
Risco
deve
ser
entendido
como
um:
(1)
UM
CONJUNTO
DE
INCERTEZAS
ENCONTRADAS
QUANDO
UMA
PESSOA
OUSA
FAZER
ALGUM
EMPREENDIMENTO
QUALQUER.
(2)
PMI-­‐
É
UM
EVENTO
OU
CONDIÇÃO
INCERTA
QUE,
SE
OCORRER,
PROVOCARÁ
UM
EFEITO
POSITIVO
OU
NEGATIVO
NOS
OBJETIVOS
DE
UM
PROJETO
.
(3)
PMI-­‐
GESTÃO
DE
RISCOS
É
O
PROCESSO
DE
IDENTIFICAÇÃO,
ANÁLISE,
DESENVOLVIMENTO
DE
RESPOSTAS
E
MONITORAMENTO
DOS
RISCOS
EM
PROJETOS,
COM
OBJETIVO
DE
DIMINUIR
A
PROBABILIDADE
E
O
IMPACTO
DE
EVENTOS
NEGATIVOS
E
DE
AUMENTAR
A
PROBABILIDADE
E
O
IMPACTO
DE
EVENTOS
POSITIVOS
Sempre
que
se
planeja
algo
se
lida
com
inúmeras
variáveis
de
incerteza
que
são
os
possíveis
riscos
inerentes
a
qualquer
Lpo
de
empreendimento.

96. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Os
riscos
estão
ligados
a
apostas
que
uma
empresa
ou
uma
pessoa
pode
pode
fazer
para
crescer
,
desenvolver,
obter
maiores
ganhos,
melhores
remunerações.
Ex:
a
Bolsa
de
valores
é
um
Lpo
invesLmento
onde
muitas
empresas
buscam
capitalizar
de
grandes
invesLdores
recursos
financeiros
para
financiar
seus
invesLmentos.
Os
invesLdores
correm
riscos
elevados,
pois
a
remuneração
futura
é
totalmente
incerta,
não
se
sabe
com
100%
de
certeza
se
aquela
empresa
que
trocou
papéis
por
recursos
financeiros
irá
dar
o
retorno
necessário
e
seguro
aos
seus
invesLdores.
Só
se
saberá
se
um
determinado
invesLmento
terá
sucesso
se
o
empreendedor
TENTAR,
nesse
caso
os
riscos
são
inerentes
as
inconstâncias
existentes
em
torno
de
variáveis
que
cercam
uma
empresa,
um
empreendimento,
etc…

97. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
O
Espectro
da
Gestão
de
Projetos
não
cobre
a
total
certeza,
nem
a
total
incerteza,
cobre,
no
entanto,
um
espectro
de
incerteza
previsível
que
contempla
a
maior
parte
do
que
pode
ocorrer
com
projetos
no
que
se
refere
aos
riscos
que
ele
esta
sujeito.
Espectro da Gestão de Riscos
Sem Informação Informação Parcial Total Informação
INCERTEZA INCERTEZA TOTAL
TOTAL GERAL ESPECÍFICA
INCERTEZA CERTEZA
ESPECTRO DA GESTÃO DE RISCOS DO PROJETOS

98. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Gerenciar
os
riscos
de
um
projeto
envolve
tomar
decisões
em
ambiente
incerto,
complexo,
de
alta
turbulência.
Pergunto:
1)
DO
QUE
VOCÊ
TEM
CERTEZA
QUE
IRÁ
ACONTECER
NO
FUTURO?
2)
O
QUE
PODE
DAR
ERRADO
NO
PROJETO?
Os
riscos
apresentam
obrigatoriamente
três
componentes:
1
–
Evento
em
si,
onde
deve
ser
idenLficada
a
causa
raiz
(a
fonte)
do
risco,
bem
como
seu
efeito
(consequência);
2
–
A
probabilidade
esta
geralmente
associada
a
causa,
ou
seja
uma
quanLdade
relaLva
do
risco
acontecer;
3-­‐
O
impacto
que
um
risco
idenLficado
poderá
causar
ao
projeto,
esta
esta
associado
ao
efeito.

99. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Ex:
sobre
os
três
componentes
dos
riscos
Ao
adquirir
um
veículo
uma
pessoa
decide
colocar
seu
carro
no
seguro.
Ao
assegurar
o
veículo,
a
pessoa
não
esta
atacando
a
causa
do
risco,
pois
a
probabilidade
de
acidentes
e
roubos
conLnuam
as
mesmas
de
antes
de
se
fazer
o
seguro.
A
pessoa
esta
atacando
o
efeito
(impacto),
pois,
caso
ocorra
algum
sinistro
ou
roubo,
quem
paga
é
a
seguradora,
pois
transfere
o
risco
para
a
própria.

100. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Qualquer
projeto
que
se
faça
é
gerenciado
por
pessoas
e
cada
pessoa
reage
de
maneira
diferente
a
cada
situação
nova
que
aparece
em
um
projeto.
Os
seres
humanos
tem
diferentes
graus
de
atração
ou
exposição
a
riscos
–
tem
diferentes
crenças,
experiências
,
padrões
de
comportamento
,etc.
Duas
são
as
situação
disLntas
que
marcam
a
reação
das
pessoas
aos
riscos:
aquelas
avessas
ao
risco
(medo
de
perder),
e
aquelas
pessoas
que
tomam
decisões
de
riscos
(sabem
do
que
podem
perder,
mas
mesmo
assim
ganhar
mais
os
fascina
a
apostar
em
um
Lpo
de
projeto
inteiramente
arriscado)

101. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Uma
das
principais
preocupações
do
gerente
de
projeto
e
de
sua
equipe
em
relação
aos
riscos
deve
acontecer
logo
no
início
do
projeto
e
se
refere
ao
planejamento
do
gerenciamento
de
riscos.
Os
riscos
associados
a
um
projeto
em
geral
dizem
respeito
aos
objeLvos
do
próprio
projeto
que
por
sua
vez
intefere
no:
TEMPO,
no
CUSTO,
no
ESCOPO,
na
QUALIDADE
ou
através
da
combinação
destes.

102. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Iniciando
a
Gestão
de
Riscos
O
planejamento
dos
riscos
somente
deverá
ser
iniciado
após
termos
planejado
o
projeto:
seu
objeLvo,
desenvolvida
a
EAP,
planejado
as
entregas
(fases),
a
qualidade,
o
cronograma,
a
esLmaLva
de
custos

103. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
As
variáveis
de
riscos
que
podem
afetar
um
projeto
são
originadas
de:
•
FATORES
AMBIENTAIS
disponibilidade
econômicas
do
ambiente;
•
FATORES
DE
LIMITAÇÃO
INTERNA
relacionada
a
pessoal
e
outros
inputs
necessários
para
tornar
viável
a
conclusão
do
projeto
principalmente
a
falta
de
recursos
financeiros
que
é
o
centro
de
todo
e
qualquer
suprimento
de
materiais
e
demais
insumos
necessário
a
viabilidade
de
um
projeto.
•
DECLARAÇÃO
DE
UM
ESCOPO
que
possa
balizar
as
ações
asserLvas
do
projeto.
•
PLANO
DE
GERENCIAMENTO
DE
RISCOS
–
possibilidade
de
pensar
antecipadamente
em
conLgências
e
se
previnir
também
de
forma
antecipada
a
elas.

104. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
Os
riscos
podem
ou
não
afetar
o
projeto
negaLvamente.
Entretanto
é
necessário
idenLficar
todos
os
eventos
de
risco
e
suas
respecLvas
consequências.
Possibilidade
de
Riscos
ocorrerem
em
projetos
Orçamento/fundos
de
reserva
Cronogramas
Mudanças
no
Escopo
ou
nos
requisitos
Plano
do
Projeto
Processo
de
Gerenciamento
do
Projeto
Problemas
Técnicos
Problemas
Pessoais
Hardwares
Contratos
Problemas
polí?cos
Riscos
Empresariais

105. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
ConLnuação
Riscos
Legais
Riscos
Ambientais
A
lista
de
possibilidade
associadas
aos
riscos
de
projetos
está
longe
de
ser
exausLva.
Cabe
ao
gestor
em
conjunto
com
a
equipe
do
projeto
analisar
bem
os
possíveis
riscos
oriundos
de
um
projeto
específicos.
Nesse
caso
o
objeLvo
da
idenLficação
de
riscos
é
gerar
uma
lista
de
possíveis
fatos
que
por
ventura
podem
ocasionar
problemas
na
conclusão
do
projeto
(TEMPO),
no
orçamento
(CUSTO)
e
modificações
no
ESCOPO
(qualidade)

106. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
Outra
forma
de
catalogar
os
possíveis
riscos
de
um
Projeto
é
uLlizar
a
metodologia
da
Estrutura
AnáliLca
de
Riscos
(EAR)
EAR
PROJETO
TÉCNICO
EXTERNO
ORGANIZACIONAL
GESTÃO
DE
PROJETO
SUBCONTRATOS
DEPENDÊNCIA
DO
ESTIMATIVAS
REQUISITOS
E
FORNECEDORES
PROJETO
TECNOLOGIA
ASPECTOS
LEGAIS
RECURSOS
PLANEJAMENTO
COMPLEXIDA
E
INTERFACES
MERCADO
CONTROLE
FUNDOS
DESEMPENHO
E
CONSUMIDOR
CONFIABILIDADE
PRIORIZAÇÃO
COMUNICAÇÃO
QUALIDADE
MEIO
AMBIENTE

107. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
Instrumentos
para
coletar
informações
quanto
a
idenLficação
dos
riscos
de
um
projeto.
1-­‐
Brainstorming
e
Brainwri“ng
Técnica
conhecida
por
muitos
para
coletar
informações
para
resolução
de
problemas
nas
empresas
Regras
para
o
brainstorming:
1) Não
ao
não
–
não
se
deve
quesLonar
ou
rebater
qualquer
idéia
que
tenha
sido
apresentada
por
um
membro
da
equipe
de
projeto.
2) Não
existe
outras
regra.
Conforme
as
idéias
vão
sendo
apresentadas,
uma
pessoa
vai
documentando
(fazendo
anotações);
ao
final
da
sessão
temos
uma
lista
de
riscos
idenLficados
para
o
projeto.

108. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
Instrumentos
para
coletar
informações
quanto
a
idenLficação
dos
riscos
de
um
projeto.
2-­‐
Técnica
Delphi
Funciona
como
se
fosse
um
brainstorming
remoto
e
anônimo,
e
apresenta
o
seguinte
processo:
a) Designa-­‐se
um
facilitador
e
escolhem-­‐se
os
parLcipantes,
que
serão
os
mesmo
stakeholders
abordados
na
técnica
de
brainstorming.
Apenas
o
facilitador
terá
conhecimento
dos
parLcipantes.
b) O
facilitador
distribui
as
informações
sobre
o
projeto
e
pede
aos
parLcipantes
que
gerem
uma
lista
de
riscos,
individual
e
anonimamente,
e
que
lhe
seja
enviada.
c) O
facilitador
consolida
as
diversas
listas
em
uma
única
e
redistribui
aos
parLcipantes
para
que
cada
um
revise
ou
complemente
d) Os
parLcipantes
devolvem
a
lista
de
riscos
para
o
facilitador
consolidar
novamente.

109. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
IdenLficação
dos
Riscos
ConLnuação
4-­‐
Diagrama
de
Causa
e
Efeito
(espinha
de
peixe)
–
Ishikawa
Essa
ferramenta
tem
como
objeLvo
mostrar
as
causas
e
os
efeitos
de
um
risco
em
um
determinado
projeto.
As
causas
são
agrupadas
por
categorias
As
etapas
para
elaboração
do
diagrama
de
causa/efeito
1
-­‐
discussão
do
assunto
a
ser
analisado
pelo
grupo,
contemplando
seu
processo,
como
ocorre,
onde
ocorre,
áreas
envolvidas
e
escopo.
2
–
descrição
do
efeito
(problema)
no
lado
direito
do
diagrama
(cabeça)
3
–
levantamento
das
possíveis
causas
e
seu
agrupamento
por
categoria
no
diagrama
4
–
análise
do
diagrama
elaborado
e
coleta
de
dados
para
determinar
a
frequência
de
ocorrência
das
difererentes
causas.

110. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Processo
de
IdenLficação
de
Riscos
(2) DEFINIR
FERRAMENTAS
(1)
(Projetos
BRAINSTORMING
anteriores)
(3)
DESCRIÇÃO
(4)
CATEGORIA
BRAINWRITTING
DOS
RISCOS
(1)
EAR
TÉCNICA
DELPHI
ANÁLISE
DE
SWOT
DIAGRAMA
DE
ISHIKAWA
(5)
LISTA
DE
RISCOS

111. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
O
Processo
da
Análise
de
Riscos
Uma
vez
que
a
equipe
de
projetos
tenha
idenLficado
os
riscos
através
dos
instrumentais
desenvolvidos,
a
próxima
etapa
é
definiar
a
análise
desses
riscos
que
podem
ser
analisados
de
maneira
qualitaLva
e
quanLtaLva
.
Como
observamos
no
início
de
nosso
curso
os
componentes
dos
riscos
são:
EVENTO
DE
RISCO
(CAUSA
E
EFEITO);
PROBABILIDADE
e
IMPACTO.
Todo
risco
tem
uma
probabilidade
associada
que
não
é
zero
(zero
é
certeza
da
não-­‐
ocorrência)
Nem
100%
(certeza
da
ocorrência
de
um
fato)
e
caso
ocorra
ocorrerá
um
IMPACTO.
Existem
duas
maneiras
de
se
dar
peso
ao
risco.
Primeiro
por
meio
da
qualificação
ou
da
quanLficação.

112. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ConLnuação
Sem
o
peso
de
cada
riscos
o
gestor
de
um
projeto
não
tem
como
decidir
adequadamente
sobre
que
Lpo
de
reação
seria
válido
para
esse
risco
ou
pior:
quanto
os
stakeholders
do
projetos
estariam
dispostos
a
pagar
por
esse
risco.
ANÁLISE
QUALITATIVA
Visa
detectar
o
impacto
dos
riscos
idenLficados
sobre
os
objeLvos
do
projeto
e
sua
probabilidade
de
ocorrência.
Também
classifica
os
riscos
por
prioridade,
de
acordo
com
os
efeitos
sobre
os
objeLvos
do
projeto.

113. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ConLnuação
-­‐
ANÁLISE
QUALITATIVA
FERRAMENTAS
E
TÉCNICAS
PARA
ANÁLISE
QUALITATIVA
DOS
RISCOS
Avaliação
de
Probabilidades
e
Impacto
do
Risco
Avalia
a
probabilidade
de
os
eventos
de
risco
idenLficados
ocorrerem
e
calcula
seu
efeito
sobre
os
objeLvos
do
projeto,
incluindo:
TEMPO,
ESCOPO,
QUALIDADE
e
CUSTO.
PROBABILIDADE
Uma
probabilidade
é
uma
chance
de
um
evento
ocorrer.
Ao
jogar
uma
moeda
para
cima
a
probabilidade
dessa
cair
com
a
face
CARA
OU
COROA
é
de
50%
para
cada
lado.
Pode
ser
dixcil
avaliar
a
probabilidade
de
um
risco,
o
que
costuma
ser
feito
por
meio
da
opinião
especializada.
Isso
significa
que
procuramos
adivinhar
a
probabilidade
de
ocorrência
de
determinados
eventos
de
riscos.
Nossos
palpites
são
baseados
em
experiências
anteriores
em
projetos
ou
eventos
de
riscos
similares,
mas
não
há
evento
igual
a
outro.

114. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ConLnuação
IMPACTO
O
Impacto
é
a
quanLdade
de
danos
(ou
ganhos)
que
um
evento
de
risco
representa
para
um
projeto.
A
escala
de
impacto
de
riscos
pode
ser
uma
escala
relaLva
na
qual
se
atribuem
valores
como
ALTO,
MÉDIO
OU
BAIXO.
Ou
valores
numéricos
atribuídos
ao
impacto
dos
riscos
e
expressos
como
números
entre:
0,0
e
1,0.
OBJETIVOS BAIXO/BAIXO BAIXO MÉDIO ALTO ALTO/ALTO
0,05 0,20 0,40 0,60 0,80
CUSTO Nenhum Aumento Aumento de 7 a 12% Aumento Aumento
impacto inferior a 6% de 13 a superior a
significativo 18% 18%
Nenhum Aumento Aumento de 7 a 12% Aumento Aumento
TEMPO impacto inferior a 6% de 13 a superior a
significativo 18% 18%
Nenhum Poucos Impacto significativo, Qualidade Produto
QUALIDADE impacto componentes exigindo aprovação inaceitável inutilizável
significativo afetados do cliente para
continuar

115. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ConLnuação
Uma
das
formas
das
organizações
definirem
os
critérios
de
aceitação
dos
riscos,
com
base
nos
parâmetros
de
probalidades
e
impacto,
é
por
meio
de
uma
grade
de
tolerância
a
riscos.
Análise__
Riscos
Projetados no Alta probabilidade de impacto
quadrante 1 –
seriam
aceitáveis para
a organização
Riscos no
quadrante 2 e 4
precisam de
propostas de Baixa probabilidade de impacto
estratégias de
prevenção.
Riscos no
quadrante 3
seriam
considerados
inaceitáveis

116. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ConLnuação
A
tabela
abaixo
apresenta
uma
visão
comparaLva
entre
os
riscos,
permiLndo
que
seja
visualizado
um
peso
para
cada
risco
e
que
se
comparem
os
riscos
entre
si.
Identificação de Riscos Avaliação qualitativa do Risco
Prioridade do
Impacto
Risco Risco
Descrição do Risco Probabilidade
n.
custo cronograma escopo qualidade geral alta média Baixa
01
02
03
Impacto do risco no custo do PROBABILIDADE
projeto. Impacto do risco no escopo do Impacto do risco na qualidade do DO RISCO SE
Impacto do risco no projeto. projeto.
cronograma do projeto. NENHUMA AÇÃO
1. Aumento insignificante no FOR TOMADA
1. Impacto insignificante no escopo do 1. Impacto insignificante na qualidade
custo (0,1) 1. Atraso insignificante no 1. Muito improvável
projeto (0,1) do projeto (0,1)
cronograma (0,1) de acontecer (0,1)
2. Aumento no custo de
2. Poucas entregas impactadas sem 2. Poucas entregas impactadas sem 2. Mais provável de
menos do que $ 1,00 por dia 2. Atraso de menos de um dia não acontecer do
efeito no aceite do projeto (0,3) efeito no aceite do projeto (0,3)
no cronograma (0,3) quea contecer (0,3)
(0,3)
3. Algumas entregas impactadas 3. Algumas entregas impactadas 3. Probabilidade de
3. Aumento no custo de $ 5,00 3. Atraso de 5 a 10 dias no acontecer ou não é
perceptíveis no aceite do projeto (0,5) perceptíveis no aceite do projeto (0,5)
cronograma igual (0,5)
por dia (0,7)
4. Impacto muito significante para o 4. Impacto muito significante para o 4. Mais provável de
4. Aumentode mais de R$ 4. Atraso maior que 10 dias acontecer do que
cliente (0,7) cliente (0,7)
no cronograma (0,9) não acontecer (0,7)
10,00 por dia (0,9)
5. Inaceitável para o cliente (0,9) 5. Inaceitável para o cliente (0,9) Muito provável que
ocorra (0,9)

117. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ANÁLISE
QUANTITATIVA
Avalia
os
impactos
e
quanLfica
a
exposição
do
projeto
aos
riscos
por
meio
da
atribuição
de
probabilidades
numéricas
a
cada
um
e
aos
seus
impactos
sobre
os
objeLvos
do
projeto.
Os
objeLvos
da
análise
quanLtaLva
dos
riscos
são:
1) QuanLficar
os
possíveis
resultados
e
probabilidades
do
projeto.
2) Determinar
a
probabilidade
de
aLngir
os
objeLvos
do
projeto
3) IdenLficar
riscos
que
requeiram
maior
atenção,
quanLficando
sua
contribuição
para
o
riscos
geral
do
projeto.
4) IdenLficar
metas
de
cronograma,
custos
ou
escopo
realistas
e
viáveis
5) Tomar
as
melhores
decisões
possíveis
de
gerenciamento
do
projeto
quando
os
resultados
forem
incertos.

118. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ANÁLISE
QUANTITATIVA
FERRAMENTAS
Existem
dois
conjuntos
de
instrumentos
no
processo
de
análise
quanLtaLva:
(1)
coleta
de
dados
e
técnicas
de
representação
e
(2)
técnicas
de
modelagem.
Primeiro
conjunto
de
Instrumentos
de
análise
quanLtaLva
de
riscos
Coleta
de
dados
e
técnicas
de
representação
incluem
entrevistas,
distribuições
de
probabilidades
e
opinião
especializada.
1)
Entrevista:
os
interessados
no
projetos
são
os
principais
candidatos
às
entrevistas
–
geralmente
são
perguntados
sobre
suas
experiências
em
projetos
anteriores,
sobre
como
trabalhar
com
novas
tecnologias
ou
processos
que
serão
uLlizados
no
projeto
em
pauta.

119. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
ANÁLISE
QUANTITATIVA
FERRAMENTAS
2)
Distribuição
de
probabilidades:
são
triangulares
usam
esLmaLvas
de
três
pontos
–
perspecLvas
oLmistas,
realistas
e
pessimistas.
É
um
instrumento
que
é
desenvolvido
em
conjunto
com
a
entrevistas,
onde
deve
se
quesLonar
aos
stakeholders
do
projeto
as
informações
serão
uLlizadas
na
composição
quanLtaLva
dos
riscos
no
projeto
em
questão.
3)
Opinião
especializada:
os
especialistas
podem
ser
de
dentro
da
empresa
ou
de
fora
e
devem
ter
experiência
técnica
e
aplicável
ao
projeto
em
questão.
Neste
caso
podem
ser
uLlizado
como
instrumento
auxiliar
a
técnica
DELPHI.

120. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Segundo
conjunto
de
Instrumentos
de
análise
quanLtaLva
de
riscos
Análise
quanLtaLva
de
riscos
e
técnicas
de
modelagem
para
representar
esse
conjunto
de
análise
são
elencados
algumas
técnicas
(veremos)
1)
Análise
de
Sensibilidade
método
de
análise
dos
possíveis
impactos
dos
eventos
de
risco
sobre
o
projeto
e
a
determinação
de
que
evento
de
risco
tem
maior
impacto
potencial
através
da
avaliação
de
elementos
incertos
em
seus
valores
da
linha
de
base.
Uma
das
maneiras
da
apresentação
dos
dados
da
análise
sensiLva
é
o
DIAGRAMA
DE
TORNADO
(PRÓXIMO
SLIDE)

121. Desenvolvimento
do
plano
de
gerenciamento
de
projeto
Análise
quanLtaLva
de
riscos
e
técnicas
de
modelagem
2)
Análise
da
árvore
de
decisão
são
diagramas
que
mostram
a
sequência
de
decisões
inter-­‐relacionadas
e
os
resultados
esperados
de
acordo
com
a
alternaLva
escolhida.
VALOR
ESPERADO
DA
DECISÃO
O
valor
esperado
é
o
impacto
vo
tado
posiL
R$
4.200
previsto
da
decisão,
expresso
Resul ilidade
0,6 em
Reais
no
caso
ao
lado.
b
Proba
O
valor
esperado
resulta
da
A mulLplicação
da
Resu
l probabilidade
do
evento
do
Prob tado
nega
abilid L risco
pelo
impacto
ade
0 vo
R$
2.800
,4
Decisão
Os
retângulos
representam
Início
as
decisões
a
serem
tomadas
e
os
círculos,
os
pontos
em
iLvo
tado
pos ,8
que
os
eventos
dos
riscos
Resul ilidade
0 R$
4.000
podem
ocorrer.
b
Proba
B A
DECISÃO
COM
UM
VALOR
ESPERADO
DE
R$
7.000
É
A
Resu
MELHOR
DECISÃO
A
TOMAR,
Prob ltado
ne
abili g UMA
VEZ
QUE
O
RESULTADO
dade aLvo
R$
1.000
0,2
TEM
VALOR
MAIS
ALTO

122. 2)
PROCESSO
DE
PLANEJAMENTO
Desenvolvimento
do
plano
de
gerenciamento
de
projeto
O
monitoramento
do
controle
de
riscos
em
projetos
é
o
processo
de
idenLficação,
análise
e
planejamento
dos
riscos
recém
surgidos,
acompanhamento
dos
riscos
idenLficados
e
dos
que
estão
na
lista
de
observação,
reanálises
dos
riscos
existentes,
monitoramento
das
condições
de
acionamento
de
planos
de
conLngência,
e
monitoramento
dos
riscos
residuais.
Ferramentos
para
Monitoramento
e
controle
dos
riscos
1. Reavaliação
de
riscos
-­‐
controle
roLneiro
de
riscos
conLngenciais.
2. Auditoria
de
riscos
–
examinam
e
documentam
a
eficácia
das
respostas
aos
riscos
no
tratamento
dos
riscos
idenLficados
e
de
suas
causas-­‐raiz,
e
também
a
eficária
do
processo
de
gerenciamento
de
riscos.
3. Medição
de
desempenho
técnico
–
compara
as
realizações
técnicas
durante
a
execução
do
projeto
com
o
cronograma
do
plano
de
gerenciamento
do
projeto
de
realizações
técnicas.

124. 3)
PROCESSO
DE
EXECUÇÃO

125. 4)
PROCESSO
DE
MONITORAMENTO
E
CONTROLE

126. 4)
PROCESSO
DE
ENCERRAMENTO

127. Seminário
–
Project
–
Modelos
Ágeis
de
Gestão
de
Projetos
Feature*Driven'Development*(FDD)'
Desenvolvimento'Guiado'por' Agile*Project*Management*(APM)'C'
Funcionalidades. Gerenciamento'Ágil'de'Projetos
Unified'Process'(UP)'–'Processo'Unificado
Seminário de Gestão de Projetos
Scrum'–'Processo'de'Desenvolvimento'
Extreme*Programming'(XP)'–' Intera7vo'e'Incremental'de'
Programação'extrema Gerenciamento'de'Projetos