O documento discute a importância de consolidar os conceitos de gestão de projetos através da prática. Também aborda a necessidade de reflexão sobre a situação do ProjetoTCC, incluindo possíveis mudanças de escopo, grupo e foco, além de organizar e resolver problemas. Por fim, revisa alguns conceitos como justificativa, premissas e restrições de projetos.

1. AlessandroAlmeida | www.alessandroalmeida.com
15/05/2013
1° Semestre de 2013

2. Consolidando o aprendizado de Gestão de Projetos

3.  Através da prática, consolidar o aprendizado
dos conceitos de Gestão de Projetos
apresentados nas últimas semanas

4.  Provocar a reflexão sobre a situação do
ProjetoTCC...
 Mudanças de escopo
 Mudanças no grupo
 Foco
 Organização
 Resolver ou aceitar os problemas

5.  Provocar a reflexão sobre a situação do
ProjetoTCC...
 Mudanças de escopo
 Mudanças no grupo
 Foco
 Organização
 Resolver ou aceitar os problemas
Espero que vocês tenham
aproveitado os dois
objetivos

6.  Após concluirmos a atividade, alguns
conceitos precisam ser revisados...

8.  A justificativa deve responder a seguinte
pergunta: Qual problema precisamos
resolver?
 Aqui o foco é no problema, e não na solução
 A solução será descrita nas seções...
▪ 5. Descrição Macro da Solução
▪ 6. Escopo / Principais entregas

9.  Por que é importante pensar na justificativa?
 Precisamos entender o problema, antes de propor
(ou detalhar) a solução!
 Cuidado ao perder o foco da justificativa do
projeto!
“People don’t want to buy a quarter-inch drill.They
want a quarter-inch hole!” Theodore Levitt

10.  Premissa
 São fatores que, para fins de planejamento, são
considerados verdadeiros, reais ou certos sem
prova ou demonstração
 Talvez o seu projeto dependa de alguma premissa
para dar certo
 Restrição
 Limitação ou imposição de limite
 Seu projeto precisa ser realizado dentro do limite
definido

11.  Premissa:Talvez o seu projeto dependa de
alguma premissa para dar certo...
▪ A Roberta, especialista em BI, vai participar do projeto.
▪ O cliente vai disponibilizar um analista de negócios em
tempo integral na fase de levantamento de requisitos.
 Restrição: Seu projeto precisa ser realizado
dentro do limite definido...
▪ O projeto precisa ser concluído antes de 31/12
▪ O custo não pode ultrapassar R$ 500.000

12.  Todos podem fazer tudo?
 Cuidado com a difusão de responsabilidade
 Artigo recomendado:
www.administradores.com.br/artigos/administracao-e-
negocios/difusao-de-responsabilidade/29147/
 Lembrem-se do ditado...
 “Cachorro que tem dois donos morre de fome.”
 Definam os papéis e as responsabilidades de
cada membro da equipe

13. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

14. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

15.  Pessoa, grupo ou organização que tem
interesse ou pode afetar, ser afetado, ou
perceber-se afetado por qualquer aspecto de
um projeto
 ABNT NBR ISO 21500:2012

16.  Pessoa, grupo ou organização que tem
interesse ou pode afetar, ser afetado, ou
perceber-se afetado por qualquer aspecto
de um projeto
 ABNT NBR ISO 21500:2012

17.  Podemos considerar como stakeholders:
 A equipe do projeto
 O sponsor
 O cliente
 O fornecedor
 Minha família

18.  Será que esqueci de algum stakeholder?
 É importante detalhar o mapeamento e verificar
se faltou alguém
 Qual é o papel e a influência do stakeholder
dentro do projeto?
 Papel: Qual é a função deste stakeholder dentro
do projeto?
 Influência: Alta? Média? Baixa? O stakeholder
pode ter um cargo irrelevante, mas ser bem
relacionado dentro da empresa

19.  Será que esqueci de algum stakeholder?
 É importante detalhar o mapeamento e verificar
se faltou alguém
 Qual é o papel e a influência do stakeholder
dentro do projeto?
 Papel: Qual é a função deste stakeholder dentro
do projeto?
 Influência: Alta? Média? Baixa? O stakeholder
pode ter um cargo irrelevante, mas ser bem
relacionado dentro da empresa
Lembre-se: O stakeholder pode
ter o poder de matar o seu
projeto!

20.  Considerando a importância do tema, o
Gerente de Projeto precisa ter um Mapa de
Stakeholders
 Mapa de Stakeholders:
 Lista de todos os stakeholders do projeto,
destacando o papel e a influência de cada um
 Dependendo do papel e influência do stakeholder,
será necessário montar um plano de ação para
gerenciá-lo

21.  Exemplo...
 Importante: O Mapa de Stakeholders é uma
ferramenta exclusiva da equipe de gestão do
projeto (ou talvez somente do gerente de
projeto)
Stakeholder Papel Influência Plano de Ação
Zé das Couves
(Analista
Financeiro)
Aprovar
relatórios
financeiros do BI
Alta
(afilhado do
CFO)
Envolvê-lo na
definição e
aprovação dos
relatórios

22.  Exemplo...
 Importante: O Mapa de Stakeholders é uma
ferramenta exclusiva da equipe de gestão do
projeto (ou talvez somente do gerente de
projeto)
Stakeholder Papel Influência Plano de Ação
Zé das Couves
(Analista
Financeiro)
Aprovar
relatórios
financeiros do BI
Alta
(afilhado do
CFO)
Envolvê-lo na
definição e
aprovação dos
relatórios
Por que não é recomendável
compartilhar o Mapa de Stakeholders
com o cliente?

23.  O que o Mapa de Stakeholders não é?
 Ele não é um Plano de Recursos Humanos
▪ Então não tente definir ações para sua equipe através
dele
 Ele não é um Plano de Comunicação
▪ Então não queira detalhar nele as formas como se
comunicará com os seus stakeholders
 O Mapa de Stakeholders pode ser uma lista
informal, que é atualizada durante todo o
projeto

24. SISTEMAS DE INFORMAÇÃO
Processo para Gestão de Projetos
MAPA DE STAKEHOLDERS
STAKEHOLDER PAPEL INFLUÊNCIA PLANO DE AÇÃO

25. Execução
Monitoramento
Encerram
ento
Iniciação Planejamento

26. Execução
Monitoramento
Encerram
ento
Iniciação Planejamento

27. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

28. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

29.  O trabalho que deve ser realizado para
entregar um produto, serviço ou resultado
com as características e funções
especificadas
 Fonte: PMBoK, 4ª Edição
 Não basta definir o que faz parte do escopo,
mas, principalmente, o que está fora do
escopo

30.  A Declaração de Escopo pode ser um
documento bem detalhado...

31.  A Declaração de Escopo pode ser um
documento bem detalhado...

32.  A Declaração de Escopo pode ser um
documento bem detalhado...

33.  A Declaração de Escopo pode ser um
documento bem detalhado...
 ... mas o principal é definir tudo que está dentro
do escopo e tudo que está fora do escopo
 Sim!!!!
 A Declaração de Escopo pode usar, como ponto
de partida, o conteúdo doTermo de Abertura do
Projeto

34.  Escopo do produto: As características e
funções que descrevem um produto, serviço
ou resultado
 Fonte: PMBoK, 4ª edição
 Escopo do projeto: O trabalho que precisa ser
realizado para entregar um produto, serviço
ou resultado com as características e funções
especificadas
 Fonte: PMBoK, 4ª edição

35.  Escopo do projeto:
Documentação
Gestão da
Mudança
Treinamento da
Equipe
Sistema
Projeto

36.  Escopo do projeto:
 Escopo do produto:
Documentação
Gestão da
Mudança
Treinamento da
Equipe
Sistema
Sistema
Cadastro Relatórios
Controle
de Acesso
Banco de
Dados
Parametri
zações
Projeto

37.  O escopo do produto é muito importante,
mas não deve ser considerado isoladamente,
pois ele faz parte do escopo do projeto

39. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

40.  Considerando as informações da Declaração
de Escopo, é hora de revisar a EAP e o
Cronograma construídos na etapa de
iniciação.
 Há entregas que eu não considerei na versão
inicial da EAP?
 Quais atividades eu preciso incluir no
cronograma?

41.  EAP...
 Estrutura Analítica do Projeto
 Também conhecida comoWBS: Work Breakdown
Structure
 Decomposição das entregas que compõem o
projeto

42.  Uma EAP bem estruturada ajuda a organizar
e definir o escopo do projeto!
 Também facilita a estruturação do
cronograma
É muito mais fácil gerenciar as “partes
menores”! (especialmente em grandes projetos)

43.  Lembre-se!
 A EAP e o Cronograma são muito úteis, pois
permitem que você, Gerente de Projeto, tenha
visibilidade sobre o que deve ser feito, quando
será feito e quem fará

44.  Exemplo de EAP:
Pedreiro
Eletrônico
Document
ação
Manual
Descrição
de Caso de
Uso
Requisito
Funcional
Requisito
Não
Funcional
Regras de
Negócio
Plano de
Testes
Cenário de
Testes
Script de
Testes
Diagrama
de Classes
Sistema
Cadastro
de
Pedreiros
Cadastro
de
Materiais
Relatórios
Controle
de Acesso

45.  Exemplo de Cronograma:
PEDREIRO ELETRÔNICO
SETEMBRO OUTUBRO NOVEMBRO
1 2 3 4 1 2 3 4 5 1 2 3 4
DOCUMENTAÇÃO RESPONSÁVEL
Plano de Testes
Criar plano de testes José
Validar com Gerente José
Realizar testes Manoel
Diagrama de Caso de Uso
Levantar requisitos Joana
Criar diagrama de Caso de Uso Maria
Validar com o cliente Maria
SISTEMA
Cadastro de Pedreiros
Codificar módulo Luiza
Realizar testes unitários Luiza
Encaminhar módulo para a célula de testes Pedro

46. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

47.  Agora que você já mapeou todas as partes
interessadas, é hora de planejar a
comunicação!

48.  Por que a comunicação é importante?
 O Gerente do Projeto passa a maior parte do
tempo comunicando-se com...
▪ Equipe
▪ Sponsor
▪ Fornecedores
▪ Demais stakeholders
 ...então é fundamental definir como e quando
nos comunicaremos com os stakeholders do
projeto

49.  Qual é o meu público-alvo?
 Observar a lista de stakeholders!
 O que é necessário comunicar?
 Situação do projeto (prazo, custo, etc.)?
 Novas entregas?
 Cada público com o seu nível de informação!
 Qual é a frequência?
 Diário? Semanal? Quinzenal?

50.  Exemplos de ferramentas de comunicação...
 Relatório de Status (apresentação ou detalhado)
 Site do Projeto
 Diário de Bordo
 Apresentação Executiva
 Situação Financeira do Projeto

51. SISTEMAS DE INFORMAÇÃO
Processo para Gestão de Projetos
PLANO DE COMUNICAÇÃO
NOME PÚBLICO-ALVO FORMA DE ENVIO FREQUÊNCIA
RESPONSÁVEL PELA CRIAÇÃO /
DISPONIBILIZAÇÃO

52. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

53.  Engloba (também, mas não somente) os
seguintes tópicos...
 Quem fará parte da equipe?
 Como a equipe do projeto será estruturada?
(organograma)

54.  Engloba (também, mas não somente) os
seguintes tópicos...
 Quais são as habilidades e conhecimentos
necessários para realizar o projeto?
 Treinamentos serão necessários?
 É necessário contratar alguém?

55.  Engloba (também, mas não somente) os
seguintes tópicos...
 Quais são as habilidades e conhecimentos
necessários para realizar o projeto?
 Treinamentos serão necessários?
 É necessário contratar alguém?
Não deixe para pensar nos Recursos
Humanos somente quando o projeto
entrar na execução!

59. 1. Detalhar o
mapeamento
dos
stakeholders
do projeto
2. Detalhar o
Escopo do
projeto
3. Detalhar a
EAP e o
Cronograma
4. Criar o
Plano de
Comunicação
5. Criar o
Plano de
Recursos
Humanos
6. Criar o
Plano de
Riscos
7.Validar e
divulgar os
planos do
projeto

60.  Primeiro, vamos entender a definição de
risco...

61.  Definição do PMBoK, 4ª edição:
 Um evento ou condição incerta que, se ocorrer,
provocará um efeito positivo ou negativo nos
objetivos de um projeto

62.  O risco envolve...
 Incerteza
 Impacto
 Probabilidade
 Oportunidades

63.  Risco...
 de atraso
 de não atender o escopo
 de não cumprir o orçamento
 de não ser homologado
 de algum membro da equipe sair da empresa
 de antecipar a entrega
 de superar as expectativas do cliente

64.  Premissa
 São fatores que, para fins de planejamento, são
considerados verdadeiros, reais ou certos sem
prova ou demonstração
 Talvez o seu projeto dependa de alguma premissa
para dar certo
 Restrição
 Limitação ou imposição de limite
 Seu projeto precisa ser realizado dentro do limite
definido

65.  Premissa:Talvez o seu projeto dependa de
alguma premissa para dar certo...
▪ A Roberta, especialista em BI, vai participar do projeto.
▪ O cliente vai disponibilizar um analista de negócios em
tempo integral na fase de levantamento de requisitos.
 Restrição: Seu projeto precisa ser realizado
dentro do limite definido...
▪ O projeto precisa ser concluído antes de 31/12
▪ O custo não pode ultrapassar R$ 500.000

66.  Premissas e restrições são um bom ponto de
partida para identificação dos riscos a serem
monitorados...
 A Roberta, especialista em BI, vai participar do
projeto.
▪ Quais eventos podem tirar a Roberta do projeto?
▪ O que faremos se ela sair?
 O projeto precisa ser concluído antes de 31/12
▪ Quais eventos podem fazer com que o projeto atrase?
▪ O que faremos se o projeto atrasar?

67. # Descrição Fonte
001 Entrega fora do prazo Falta de planejamento
002 Escopo não atendido
Mapeamento de requisitos
inexistente
003 Não aceitação do sistema pelos clientes Tecnologia nova

68.  Vários riscos serão identificados
 A análise permite priorizar o foco no
tratamento dos riscos!
 Probabilidade: Qual é a chance do risco ocorrer?
 Impacto: Qual é o “tamanho” dos danos, caso o
risco ocorra?
 Probabilidade x Impacto = Prioridade, Criticidade
ou Peso do risco

69. # Descrição Prob. Imp. Criticidade
001 Entrega fora do prazo 4 5 20
002 Escopo não atendido 3 4 12
003
Não aceitação do sistema
pelos clientes
2 3 6

70.  Quando for um risco negativo...
 Eliminar: Remover totalmente a ameaça (pode
envolver mudanças radicais)
 Transferir: Repassar o risco para um terceiro, mas
não o elimina (por exemplo: Seguro)
 Mitigar: Reduzir o impacto ou a probabilidade
 Aceitar: Conheço o risco, sua probabilidade e seu
impacto, mas concluí que é melhor “deixar a vida
me levar” e atuar somente se o risco ocorrer

71.  Quando for um risco positivo...
 Explorar: Direciono recursos para garantir que a
oportunidade se concretize
 Compartilhar: Envolvo um terceiro na exploração da
oportunidade (por exemplo:Criação de uma joint
venture)
 Melhorar: Realizo ações para ampliar a probabilidade
ou impacto positivo da oportunidade
 Aceitar: Não tomarei ação, somente aproveitando os
resultados caso a oportunidade se concretize

72. # Descrição Criticidade
Estratégia de
Resposta ao
Risco
Plano de Ação
001
Entrega fora do
prazo
20 Mitigar O que fazer?
Como fazer?
Quem fará?
Quanto vai custar?
Quem será
envolvido?
002 Escopo não atendido 12 Mitigar
003
Não aceitação do
sistema pelos
clientes
6 Aceitar

73. SISTEMAS DE INFORMAÇÃO
Processo para Gestão de Projetos
PLANO DE RISCOS
CÓDIGO DO
RISCO
DESCRIÇÃO DO RISCO
TIPO
(Positivo ou Negativo?)
FONTE
(Qual é a origem do
risco?)
PROBABILIDADE
(De 1 até 5)
IMPACTO
(De 1 até 5)
CRITICIDADE
(Probabilidade x Impacto)
ESTRATÉGIA DE RESPOSTA AO
RISCO
PLANO DE AÇÃO
RESPONSÁVEL PELO PLANO DE
AÇÃO
(Nome e Papel no Projeto)
1 3 3 9 Eliminar
2 4 1 4 Transferir
3 5 4 20 Aceitar
4 5 5 25 Mitigar

74. SISTEMAS DE INFORMAÇÃOSISTEMAS DE INFORMAÇÃO
# DESCRIÇÃO TIPO CRITIC. SITUAÇÃO AÇÕES
1
2
3

75. Execução
Monitoramento
Encerram
ento
Iniciação Planejamento

76. 1. Monitorar
a execução
do projeto
2. Gerenciar
as mudanças
3. Divulgar a
situação do
projeto

77. 1. Monitorar
a execução
do projeto
2. Gerenciar
as mudanças
3. Divulgar a
situação do
projeto

78.  Acompanhar tudo que foi planejado!
 Todos os planos criados (por isso é fundamental
não criar planos desnecessários!)
 Reforçando: A EAP e o Cronograma são ótimos
materiais de apoio para o monitoramento!

79.  Há desvios?
 Avaliar se é necessário definir um plano de ação
para que o projeto volta ao planejado ou se é
necessário rever o planejamento
 Mudanças são necessárias?
 Etapa 2. Gerenciar as mudanças
Pior do que tomar a decisão errada é não
tomar uma decisão!

80. 1. Monitorar
a execução
do projeto
2. Gerenciar
as
mudanças
3. Divulgar a
situação do
projeto

81. Nada é permanente, exceto a
mudança. (Heráclito)

82.  Mudanças possíveis dentro de um projeto:
 Escopo
 Prazo
 Custo
 Critérios de qualidade
 Equipe
 Qualquer outro item planejado

83.  Mudanças possíveis dentro de um projeto:
 Escopo
 Prazo
 Custo
 Critérios de qualidade
 Equipe
 Qualquer outro item planejado

84. Como devemos tratar as mudanças
no planejamento do projeto?

85.  Considerando o tipo de mudança, consulte o
Mapa de Stakeholders para avaliar quem deve
ser envolvido...
 Talvez a mudança precise ser contemplada após o
término do projeto
 Talvez a mudança vá impactar em alguma premissa
ou restrição
 Talvez a mudança seja resultante de uma definição de
escopo mal feito
 Talvez o planejamento tenha sido otimista demais
 Etc...

86.  Independente da fonte e do tipo de mudança
no projeto, a atuação do Gerente de Projeto
deve ser sempre...

87.  Independente da fonte e do tipo de mudança
no projeto, a atuação do Gerente de Projeto
deve ser sempre...
1º Avaliar.
2º Negociar.
3º Decidir.
4º Executar.

88. 1. Monitorar
a execução
do projeto
2. Gerenciar
as mudanças
3. Divulgar a
situação do
projeto

89.  Executar o que foi combinado no Plano de
Comunicação
 Quais ferramentas de comunicação serão
utilizadas?
 Qual é a frequência?
 Qual é o público?
 Como o comunicado será feito?
 A comunicação é um dos fatores críticos para
o sucesso do projeto!

91. alessandro.almeida@uol.com.br
www.alessandroalmeida.com/unifieo.htm
www.slideshare.net/alessandroalmeida