Your SlideShare is downloading. ×
  • Like
Gerenciamento de projetos de sistemas   2012.1
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×

Now you can save presentations on your phone or tablet

Available for both IPhone and Android

Text the download link to your phone

Standard text messaging rates apply

Gerenciamento de projetos de sistemas 2012.1

  • 2,434 views
Published

Material do Curso de Gestão de Projetos de Sistemas

Material do Curso de Gestão de Projetos de Sistemas

Published in Education
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Be the first to comment
No Downloads

Views

Total Views
2,434
On SlideShare
0
From Embeds
0
Number of Embeds
0

Actions

Shares
Downloads
34
Comments
0
Likes
1

Embeds 0

No embeds

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
    No notes for slide

Transcript

  • 1. 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)  
  • 2. 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;  
  • 3. 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    
  • 4. 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.  
  • 5. 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    
  • 6. 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  
  • 7. 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  
  • 8. Avaliação  
  • 9. Contato     marcelopvh1@hotmail.com     marcelopvh@gmail.com     8119-­‐1133    
  • 10. 1ª  Parte  Pressupostos  Gerais  sobre    Gerenciamento  de  Projeto  
  • 11. Um  Projeto  é  assim?  
  • 12. 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.    
  • 13. 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.    
  • 14. 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  (          )  
  • 15. 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.  
  • 16. 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    
  • 17. 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.    
  • 18. 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.  
  • 19. 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.  
  • 20. 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.    
  • 21. 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.    
  • 22. Estudo  de  Caso  E-­‐commerce  para  um  supermercado  pequeno  
  • 23. 2ª  Parte  Gestão  de  Projetos     Filosofia  
  • 24. 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.  
  • 25. Metodologia  das  Aulas    
  • 26. 1.  PROCESSO  DE  INICIAÇÃO  DO  PROJETO   PROCESSOS DE INICIAÇÃO Desenvolver o termo de 1.1  Termo  de  abertura  do  projeto   abertura do projetoSão  documentadas  as  necessidades  de  negócio  e  os  requisitos   Identificar asprincipais  do  produto  serviço,  ou  sistema;    apresenta  a  jusLficaLva  do   interessadas partesprojeto;  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?  
  • 27. PROCESSOS DE INICIAÇÃO Desenvolver o termo de 1.  PROCESSO  DE  INICIAÇÃO  DO  PROJETO   abertura do projeto Identificar as partes interessadas5.  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?  
  • 28. 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.  
  • 29. 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:  
  • 30. 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.  
  • 31. 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.  
  • 32. 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.  
  • 33. 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.  
  • 34. Exemplo:  Diagrama  de  Rede  
  • 35. 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.    
  • 36. 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  
  • 37. 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.    
  • 38. Como  fazer  um  EAP?     Por  onde  começo?    O  que  tenho  que  fazer?  
  • 39. Modelo  Genérico  de  EAP  para  Desenvolvimento  de  SoNware  
  • 40. Modelo  de  EAP  com  detalhamento  de  níveis,  dos  executores  (RH)  e  das  fases  
  • 41. 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    
  • 42. 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  
  • 43. Exemplo:  Dicionário  EAP  
  • 44. 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.    
  • 45. 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.  
  • 46. 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  
  • 47. 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.    
  • 48. 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.  
  • 49. 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)      
  • 50. 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  
  • 51. 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...      
  • 52. 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      
  • 53. 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.      
  • 54. 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.    
  • 55. Desenvolvimento  do  plano  de  gerenciamento  de  projeto  Orçamentação  
  • 56. 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.    
  • 57. 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.    
  • 58. 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.    
  • 59. 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    
  • 60. Desenvolvimento  do  plano  de  gerenciamento  de  projeto  
  • 61. 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  
  • 62. 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.  
  • 63. 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.  
  • 64. 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.  
  • 65. 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.  
  • 66. 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.  
  • 67. 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:  
  • 68. 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.  
  • 69. Desenvolvimento  do  plano  de  gerenciamento  de  projeto   Exemplo  de  Fluxograma   Processo ???   Operações ???  
  • 70. 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.  
  • 71. 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.  
  • 72. 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.  
  • 73. 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  
  • 74. 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.  
  • 75. 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  
  • 76. 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  
  • 77. 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  
  • 78. 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).  
  • 79. 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.        
  • 80. 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.       +  +   +  +  
  • 81. 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.    
  • 82. Desenvolvimento  do  plano  de  gerenciamento  de  projeto   Planejamento  das  Comunicações  
  • 83. 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  
  • 84. 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.  
  • 85. 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…  
  • 86. 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
  • 87. 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.  
  • 88. 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.      
  • 89. 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)  
  • 90. 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.      
  • 91. 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  
  • 92. 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.  
  • 93. 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  
  • 94. 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)  
  • 95. 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  
  • 96. 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.  
  • 97. 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.    
  • 98. 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.      
  • 99. 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  
  • 100. 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.  
  • 101. 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.      
  • 102. 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.    
  • 103. 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
  • 104. 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__RiscosProjetados no Alta probabilidade de impactoquadrante 1 –seriamaceitáveis paraa organizaçãoRiscos noquadrante 2 e 4precisam depropostas de Baixa probabilidade de impactoestratégias deprevenção.Riscos noquadrante 3seriamconsideradosinaceitáveis
  • 105. 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 ImpactoRisco Risco Descrição do Risco Probabilidade n. custo cronograma escopo qualidade geral alta média Baixa 01 02 03Impacto do risco no custo do PROBABILIDADEprojeto. 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ÇÃO1. Aumento insignificante no FOR TOMADA 1. Impacto insignificante no escopo do 1. Impacto insignificante na qualidadecusto (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 demenos 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 de3. 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 de4. 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)
  • 106. 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.    
  • 107. 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.  
  • 108. 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.    
  • 109. 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)  
  • 110. 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  
  • 111. 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.  
  • 112. 3)  PROCESSO  DE  EXECUÇÃO  
  • 113. 4)  PROCESSO  DE  MONITORAMENTO  E  CONTROLE  
  • 114. 4)  PROCESSO  DE  ENCERRAMENTO  
  • 115. Seminário  –  Project  –  Modelos  Ágeis  de  Gestão  de  Projetos   Feature*DrivenDevelopment*(FDD) DesenvolvimentoGuiadopor Agile*Project*Management*(APM)C Funcionalidades. GerenciamentoÁgildeProjetos UnifiedProcess(UP)–ProcessoUnificado Seminário de Gestão de Projetos Scrum–ProcessodeDesenvolvimentoExtreme*Programming(XP)– Intera7voeIncrementaldeProgramaçãoextrema GerenciamentodeProjetos