Revisão - Projeto Físico e Lógico de Rede

1. Professor Kleber kleberaristides@gmail.com Revisão - Projeto Físico e Lógico de Rede

2. Introdução Definição do PMBOK • Um empreendimento temporário, com um início e fim definidos, para criar um produto ou serviço com objetivos específicos que quando atingidos significam que está finalizado • Em geral: • É direcionado para atingir um resultado específico • Envolve a coordenação do empreendimento de atividades inter relacionadas • Tem uma duração limitada – um início e fim • É único

3. Definição do PMBOK • A aplicação de conhecimento, habilidades, ferramentas e técnicas nas atividades do projeto de forma a atingir ou exceder as necessidades e expectativas dos stakeholders do projeto • O que dizem os gerentes de projetos: • Gerenciamento de projetos relaciona-se em obter o trabalho realizado: • De acordo com o cronograma • Dentro do orçamento previsto • De acordo com as especificações

4. Custo Tempo Qualidade O trinômio do gerenciamento de projetos

5. Áreas de conhecimento do PMBOK • Escopo • Deve assegurar que no projeto estejam as tarefas necessárias, e somente as necessárias para completá-lo de uma forma bem sucedida. O gerenciamento do escopo significa definir e controlar o que será incluído ou não no projeto. • PMBOK – Project Scope Management: • Iniciação • Planejamento do escopo • Definição do escopo • Verificação do escopo • Controle de mudanças do escopo

6. Áreas de conhecimento do PMBOK • Prazo • Determina os processos necessários para assegurar o andamento e a conclusão do projeto no tempo planejado • PMBOK – Project time management: • Definição de atividades • Sequenciamento de atividades • Estimativa de duração das atividades • Desenvolvimento de cronograma • Controle do cronograma

7. Áreas de conhecimento do PMBOK • Qualidade • Determina os processos necessários para assegurar que o projeto atinja a qualidade planejada • PMBOK – Project quality management: • Planejamento da qualidade • Asseguramento da qualidade • Controle da qualidade

8. Áreas de conhecimento do PMBOK • Custo • Determina os processos necessários para assegurar que o projeto seja conduzido e concluído dentro do orçamento aprovado. • PMBOK – Project Cost management: • Planejamento de recursos • Estimativa de custos • Orçamento dos custos • Controle dos custos

9. Áreas de conhecimento do PMBOK • Comunicação • Determina os processos necessários para assegurar a edição, coleta, divulgação, armazenamento e disposição de informações do projeto a tempo e de forma adequada. • PMBOK – Project Communications management: • Planejamento de comunicação • Distribuição da informação • Performance dos relatórios • Fechamento administrativo

10. Áreas de conhecimento do PMBOK • Riscos • Determina os processos necessários para assegurar a identificação, análise e respostas aos riscos do projeto. • PMBOK – Project Risk management: • Planejamento do gerenciamento dos riscos • Identificação dos riscos • Análise qualitativa dos riscos • Análise quantitativa dos riscos • Planejamento de resposta aos riscos • Monitoração e controle dos riscos

11. Áreas de conhecimento do PMBOK • Aquisições • Determina os processos necessários para assegurar a obtenção de bens e serviços de terceiros. • PMBOK – Project Procurement management: • Planejamento das aquisições • Planejamento das solicitações • Solicitações • Seleção de fornecedores • Administração de contratos • Finalização dos contratos

12. Áreas de conhecimento do PMBOK • Recursos Humanos • Determina os processos necessários para assegurar a administração eficiente do pessoal disponível alocado ao projeto. • PMBOK – Project HR management: • Planejamento organizacional • Alocação da equipe • Desenvolvimento da equipe

13. Áreas de conhecimento do PMBOK • Integração • Determina os processos necessários para assegurar que os vários componentes do projeto sejam devidamente coordenados. • PMBOK – Project Integration management: • Desenvolvimento do plano de projeto • Execução do plano de projeto • Controle de mudanças integrado

14. Iniciação do projeto

15. Iniciação do projetoProject Charter • É o documento que reconhece formalmente a necessidade de um projeto • Exemplo de um formulário ou sistema para o registro do início de um projeto: • Nome do projeto: • Patrocinador: • Gerente alocado: • Cliente: • Contato: • Posição do contato: • Escopo: • Metas: • Restrições: • Riscos: • Prazo: • Investimento: • Recursos

16. Iniciação do projetoReconhecendo as necessidades do cliente • Requer uma análise em profundidade das necessidades reais do cliente • Serve de base para o desenvolvimento de especificações funcionais • Cinco passos para esta articulação: • Solicite ao cliente para definir suas necessidades tão claramente quanto possível • Examine todos os aspectos da necessidade • Pesquise a necessidade para assegurar-se que está totalmente entendida • Descreva a necessidade tão precisamente quanto for possível • Solicite ao cliente para avaliar a descrição do entendimento da necessidade e revisá-la caso seja necessário

17. Iniciação do projetoEspecificações do projeto • Após determinar as necessidades do cliente, construa as especificações • Funcionais: • Descreva as características do deliverable em linguagem clara • Utilize gráficos ou diagramas para tornar isto mais claro • Técnicos • Emergem dos requerimentos funcionais • São escritos pela equipe técnica

18. Controle e execução do projeto

19. Objetivos • Desenvolvimento da equipe • Controle do gerenciamento de mudanças • Monitorar o progresso do projeto • Examinar evolução de custos e cronograma • Usar técnicas: fast tracking e crashing • Controlar e monitorar os recursos

20. Importância da documentação: • Boa documentação é frequentemente um componente crucial de sucesso nos projetos • Documentação é necessária para controle, análise do histórico e coordenação dos esforços do projeto entre os membros da equipe • Documentação é vital para a manutenção do sistema • Documentação é frequentemente um elemento de resistência nas equipes de projeto, que a vêem como falta de criatividade e excessivamente burocrática • Os documentos do projeto deverão estar definidos no plano de projeto como entregáveis

21. Crashing Tarefas: • Requer a adição de recursos ao projeto para acelerar o cronograma ou para lutar contra escorregamento do cronograma • Invariavelmente requer custos adicionais • Crashing é feito nas tarefas que estão no caminho crítico • Significa diminuir o tempo de execução de uma tarefa adicionando-se recursos. • Ex: A instalação física de equipamentos requer 5 dias com 1 recurso. Com a adição de dois recursos o seu tempo de execução pode baixar para 2 dias • Regras para crashing: • Crash somente as tarefas que estão no caminho crítico • Escolha as tarefas com o menor custo

22. Fast tracking: • Significa fazer em paralelo atividades que antes estavam em série de forma a acelerar a execução do cronograma • Ex: projeto e construção • Deve ser acompanhado por um controle de mudanças de forma a analisar os riscos envolvidos com esta forma de execução do projeto

23. O que monitorar em um projeto: • Periodicamente deve-se monitorar: • Recursos humanos – compromisso e disponibilidade • Custos do projeto – mdo e materiais • Cronograma – cumprimento das tarefas e entrega dos deliverables • Terceiros – seus contratos e suas atividades • Riscos – monitorar regularmente os riscos • Mudanças sutis que lentamente alteram o escopo • Mudanças aprovadas e não aprovadas • Periodicidade dos relatórios de avanço • Controle dos contratos que fazem parte do projeto

24. Avaliação do projeto: • É realizada periodicamente • Está preocupada se os objetivos básicos do projeto estão sendo realizados • O resultado da avaliação pode conduzir a: • Manutenção dos objetivos do projeto • Mudanças leves na direção do projeto • Reavaliação dos objetivos do projeto • Abandono do projeto

25. Avaliação x Controle: • Controle • Foco na atingimento dos elementos individuais do plano de projeto • Monitoração contínua no cronograma e orçamento • Cada um dos controles é relativamente barato • Avaliação • Revisão periódica do projeto • Foco no atingimento dos objetivos básicos do projeto

26. Pontos a considerar: • Controle do projeto é o processo de monitorar o projeto e determinar o quanto efetivo estamos sendo no seguimento do plano de projeto • Gerenciamento do controle de mudanças fornece um processo formal de identificar pedidos de mudança, processá-las e determinar o curso da ação da mudança • O progresso do projeto deve ser feito efetivamente utilizando a documentação, indicadores e ferramentas de medida • Fast tracking e crashing são duas formas de acelerar o cronograma • Earned value é um conceito chave de determinar a variância e projeções futuras do cronograma e custo do projeto

27. Planejamento do projeto

28. Objetivos: • Responder às questões mais críticas ao realizar o planejamento do projeto • Identificar o escopo do projeto • Desenvolver uma WBS • Avaliar os riscos do projeto • Desenvolver o custo estimado do projeto • Alocar os recursos do projeto • Elaborar o plano do projeto

29. Planejamento: • Processo de planejar e programar o como e quando implantar o projeto • Esforço contínuo / dinâmico ao longo do ciclo de vida do projeto • Para um projeto ser bem sucedido, é imprescindível ter um bom planejamento

30. Principais processos: • Planejamento do escopo • Detalhamento do escopo • Definição das atividades • Planejamento dos recursos • Sequenciamento das atividades • Estimativa de duração das atividades • Estimativa de custos • Planejamento de riscos • Desenvolvimento de cronogramas • Orçamento de custos • Desenvolvimento do plano do projeto

31. Processos auxiliares: • Planejamento da qualidade • Planejamento organizacional • Formação de equipe • Planejamento das comunicações • Identificação de riscos • Análise qualitativa dos riscos • Análise quantitativa dos riscos • Desenvolvimento de resposta aos riscos • Planejamento de aquisições

32. Declaração do escopo: • A declaração do escopo é uma base documental para análises e discussões futuras e para confirmar o entendimento comum entre os stakeholders do projeto. • Deve incluir: • Descrição do produto do projeto • Todos os deliverables do projeto • Recursos necessários para o atendimento do deliverable • Atividades a serem desenvolvidas para cada deliverable • Ferramentas utilizadas para a realização do deliverable • Responsabilidades do cliente e do fornecedor • Premissas específicas para o deliverable • Critério de aceitação do deliverable

33. WBS – Work Breakdown Structure • Uma organização hierárquica de atividades necessárias e suficientes para desenvolver os produtos do projeto. • O tamanho e o número de níveis da WBS varia com a natureza do projeto. • A WBS é a fundação para o planejamento do projeto e para o seu controle. • “Work packages” são o nível mais baixo da WBS onde os recursos são designados e o progresso é medido. • O WBS é o elemento mais crítico para fazer o orçamento do projeto • Se os “work packages” forem omitidos, o cronograma será otimista e de uma forma não realista e o orçamento do projeto será inadequado. • Recomenda-se que os “work packages” não sejam maiores do que 40 horas (uma semana de trabalho)‏ • Work packages maiores de 40 horas. Ex: Operação assitida por 30 dias.

34. WBS • A WBS é um agrupamento dos elementos do projeto orientado pelos produtos, que organiza e define o escopo total do projeto. • Trabalho não incluso na WBS está fora do escopo do projeto. • É representativa do trabalho, com resultado tangível • • É uma estrutura hierárquica • • Os objetivo (resultados tangíveis) se referem aos Deliverables

35. WBS – Orientado a Tarefas • Revisar a declaração de escopo do projeto • Identificar as maiores atividades do projeto que devem ser completadas para alcançar os objetivos do projeto • Identificar todas sub-atividades que devem ser completadas para finalizar cada atividade maior • Dividir cada sub-atividade em tarefas que devem ser realizadas para completar as atividades • Continuar neste processo até que os nível requerido de detalhes é alcançado • Reunir-se com o cliente e stakeholders para validar a WBS • Buscar pontos que foram esquecidos e ajuste se necessário

36. WBS

37. O Baseline deve ser utilizado como referência para acompanhamento do avanço e para todas as reprogramações. Ajustes, incrementos, atrasos nas atividades devem ser relacionadas ao Baseline Cronograma Inicial Nivelamento dos recursos Cronograma Final Baseline do projeto O Linha de Base ou Baseline do projeto

38. Gerenciamento de Riscos • É o processo de identificar, analisar e responder aosriscos do projeto. • Incluimaximizarosresultados de eventospositivos e minimizar as conseqüências dos eventosadversos. • A respostaaosriscospodeser: • Mitigar‏ • Evitar • Aceitar‏ • Transferir

39. 1 Muito baixo 2 Baixo 3 Médio 4 Alto 5 Muito alto Custo Insignificante aumento de custos < 5% o aumento de custos 5 – 10 % aumento de custos 10 – 20 % aumento de custos > 20 % aumento de custos Cronograma Atraso insignificante < 5% de atraso 5 – 10 % de atraso 10 – 20 % de atraso > 20 % de atraso Funciona lidades Decréscimo imperceptível Diminuição em áreas de menor relevância Áreas importantes são afetadas Redução de funcionalidades inaceitável para o cliente Produto do projeto não tem utilidade para o cliente Qualidade Degradação imperceptível Somente Redução requer aprovação do cliente Redução inaceitável para o cliente Produto do projeto não tem utilidade para o cliente O impacto de um risco (às vezes chamado de conseqüência) é definido em termos de uma escala discreta: 1 = muito baixo, 2 = baixo, 3 = médio, 4= alto e 5 = muito alto.

40. Nível Probabilidade de ocorrência Dificuldade de intervenção 1 Você ficará surpreso se ocorrer O processo normal de gerência facilmente assegurará um resultado aceitável 2 Mais provável que não ocorra Uma supervisão adicional no processo de gerenciamento provavelmente trará um resultado aceitável 3 Igual chance de ocorrer ou não Tempo e esforço adicional deverá ser empregado para que o resultado seja aceitável 4 Mais provável que ocorra Seus recursos e autoridade não são suficientes para impedir que o resultado seja impactado 5 Você ficará surpreso se o risco não ocorrer Sua chance para alterar o resultado é praticamente zero Probabilidade de ocorrência de um risco. Podemos definir o impacto em uma escala de cinco níveis: 1 = muito improvável, 2 = pouco provável, 3 = provável, 4 = muito provável e 5 = praticamente certo Revista PM Network – Out – 2000 pag 61 - 63

41. Estimativa de custos • Elementos de custos na vida de um projeto: • Custos associados às tarefas, como custos do trabalho e serviços contratados, locomoção, estadia, refeições • Custos administrativos que são demandados pelo projeto tais como: PMO, compras, secretárias, equipamentos, etc.

42. Desafios na estimativa de custos • Más estimativas técnicas em tempo e custos • Estimativas realizadas por pessoas inexperientes ou otimistas • Mudanças no projeto durante a implementação • superação de problemas técnicos • ajuste nas condições mutantes do mercado • acomodação de mudanças do cliente nas especificações do produto • Fatores do ambiente • Fatores psicológicos • Fornecimento de um valor baixo para ganhar o contrato – obtêm-se prejuízo ou longos dias de trabalho sem compensação financeira para a equipe • Pressões políticas

43. Estimativa de duração de tarefas usando PERT • PERT = Program Evaluation Review Technique • e(t) = otimista + 4 x mais provável + pessimista • 6 • Melhores práticas: • desenvolva o melhor possível a WBS em work packages < 40 horas • consulte o histórico de outros projetos anteriores • consulte os especialistas na área • valide as premissas para obter as estimativas • permita work packages > 40 hs somente para atividades em que não há incertezas. Ex: operação assistida de 30 dias

44. Qualidade • Inclui um conjunto de processos exigidos para assegurar que o projeto satisfará as necessidades para o qual ele foi criado. • Deve estar declarado no plano do projeto quais serão os processos para garantir a qualidade do produto e a qualidade da condução do projeto • Exemplo de texto que pode constar no plano de qualidade do projeto: A fim de garantir a qualidade dos projetos gerenciados pela nossa companhia, este projeto será submetido a Revisão (ões) de Garantia da Qualidade, elaborado pelo nosso Escritório de Projetos, de acordo com a nossa metodologia. O produto deste trabalho será sintetizado em relatório.

45. Comunicação • Inclui os processos requeridos para garantir a geração apropriada e oportuna, a coleta, a distribuição, o armazenamento e o controle básico das informações do Projeto. • O Plano de Comunicação, também, identifica o nível da informação, o formato e a freqüência da comunicação necessária para todos envolvidos do Projeto.

46. Comunicação • Formato - Os formatos dos documentos a serem gerados no decorrer do Projeto deverão atender aos níveis organizacionais, sendo: • Comitê Executivo: apresentações de avanço do projeto; • Comitê do Projeto: cronogramas, planilhas e atas de reuniões • Frequência - A freqüência da comunicação também está relacionada com os níveis definidos, onde: • Comitê Executivo: a cada período de ..... semanas/meses • Gestão do Projeto: a cada período de...... dias • Conteúdo – Especificar o conteúdo de acordo com o destino: • Comitê Executivo: progressos, necessidades e problemas • Gestão do Projeto: atas, progressos, cronogramas e comunicados diversos. • Importante: Todas as Atas devem ser assinadas ou aprovadas eletrônicamente, por e-mail, pelos Gerentes de Projeto ou seu representante designado; • As Atas de Reunião deverão estar identificadas com números seqüenciais: 1, 2, 3…

47. Aquisições (procurement)‏ • Processo para adquirir bens e serviços de terceiros • Para projetos de maior complexidade há necessidade de ter recurso exclusivo para a administração dos contratos de terceiros • Um ponto muito importante é que os T&C sejam back to back com os terceiros: • - Um contrato T&M com nosso cliente deve ter um T&M com o terceiro • Um contrato de escopo fechado com nosso cliente deve ter o escopo fechado com o terceiro • Escopo fechado com o cliente e T&M com o terceiro é uma armadilha que deve ser evitada

48. Plano de projeto • O Plano de Projeto é uma série de documentos ou uma coletânea lógica de documentos compilados pelo Gerente de Projetos para planejar, controlar, executar e encerrar um projeto com sucesso. • Quanto maior e mais complexo for o Projeto, mais estruturados serão os processos e exigências para gerenciá-lo. • O PP é necessário para assegurar que todas as atividades serão desenvolvidas para satisfação da expectativa do cliente e que todos os serviços do projeto atinjam as exigências estabelecidas, bem como os planos adicionais necessários para o desenvolvimento da solução e os mecanismos de entrega e aceitação

49. Nome do Projeto: Gerente de Projeto: <<Nome PM>> Versão do Documento: Fase do Projeto: Data da Versão: Revisão de Qualidade: Data da Preparação: Preparado Por: <<Nome PM>> Data da Revisão: Revisado Por: Plano de projeto Informações sobre o Documento

50. De Data Fone/Fax <<Nome PM>> Para Ação: Aprovar / Revisar Data Esperada Fone/Fax Ver. Nº. VersãoData Revisado Por Descrição Nome do Arquivo 1.0 2.0 Plano de projeto