A apresentação está carregando. Por favor, espere

A apresentação está carregando. Por favor, espere

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

Apresentações semelhantes


Apresentação em tema: "Revisão - Projeto Físico e Lógico de Rede"— Transcrição da apresentação:

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

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 O trinômio do gerenciamento de projetos
Qualidade Custo Tempo

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 projeto Project 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 projeto Reconhecendo 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 projeto Especificaçõ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: Regras para crashing:
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 Avaliação
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 Edifício Planejamento Levantamento de dados Legislação
Estudo de Viabilidade Projetos Plantas Estrutural Elétrica Telecomunicação Hidráulica Documentações Habite-se Alvará Aprovação Esquemas técnicos gráficos Construção Limpeza Canteiro de Obra Infra-Estrutura Estrutura Alvenaria Esquadrias Cobertura Sistemas Hidráulico Elétrico Telecomunicações Som Imagem Acabamento Revestimento Pintura Arremates Finais (Ajustes) Serviço Final Gerenciamento Controles Acompanhamento Entrega Termo de Aceite

37 O Linha de Base ou Baseline do projeto
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 Cronograma Final Baseline do projeto Nivelamento dos recursos

38 Gerenciamento de Riscos
É o processo de identificar, analisar e responder aos riscos do projeto. Inclui maximizar os resultados de eventos positivos e minimizar as conseqüências dos eventos adversos. A resposta aos riscos pode ser: Mitigar‏ Evitar Aceitar‏ Transferir

39 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. Produto do projeto não tem utilidade para o cliente Redução inaceitável para o cliente Redução requer aprovação do cliente Somente Degradação imperceptível Qualidade Produto do projeto não tem utilidade para o cliente Redução de funcionalidade s inaceitável para o cliente Áreas importantes são afetadas Diminuição em áreas de menor relevância Decréscimo imperceptível Funciona lidades > 20 % de atraso 10 – 20 % de atraso 5 – 10 % de atraso < 5% de atraso Atraso insignificante Cronogram a > 20 % aumento de custos 10 – 20 % aumento de custos 5 – 10 % aumento de custos < 5% o aumento de custos Insignificante aumento de custos Custo 5 Muito alto 4 Alto 3 Médio 2 Baixo 1 Muito baixo

40 Probabilidade de ocorrência de um risco
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 Sua chance para alterar o resultado é praticamente zero Você ficará surpreso se o risco não ocorrer 5 Seus recursos e autoridade não são suficientes para impedir que o resultado seja impactado Mais provável que ocorra 4 Tempo e esforço adicional deverá ser empregado para que o resultado seja aceitável Igual chance de ocorrer ou não 3 Uma supervisão adicional no processo de gerenciamento provavelmente trará um resultado aceitável Mais provável que não ocorra 2 O processo normal de gerência facilmente assegurará um resultado aceitável Você ficará surpreso se ocorrer 1 Dificuldade de intervenção Probabilidade de ocorrência Nível Revista PM Network – Out – 2000 pag

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 , 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 Plano de projeto Informações sobre o Documento Revisado Por:
Data da Revisão: <<Nome PM>> Preparado Por: Data da Preparação: Revisão de Qualidade: Data da Versão: Fase do Projeto: Versão do Documento: Gerente de Projeto: Nome do Projeto:

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

51 Plano de projeto Aviso de Propriedade do plano de projeto
Este documento é de propriedade da ABC. As informações contidas são confidenciais e não devem ser copiadas ou divulgadas sem antes o consentimento formal, por escrito, da ABC, podendo somente ser utilizada dentro do (a) <<Nome Cliente>>, para os seus empregados e terceiros que estejam envolvidos nas tarefas do projeto, o qual este documento relata. <<Nome Cliente>> será responsável por garantir que todos seus empregados e terceiros envolvidos estejam de acordo e acatem estas condições e ainda, está autorizada para usar as informações contidas neste documento, somente para propósitos de avaliação e acompanhamento.

52 Plano de projeto Introdução
O Plano de Projeto é um documento ou uma coletânea lógica de documentos elaborados pela equipe do projeto para planejar, executar, controlar e encerrar o projeto com sucesso. O Plano de Projeto incorpora as melhores práticas de mercado quanto ao gerenciamento de atividades, sendo estruturado de acordo com a metodologia da ABC, baseada nas melhores práticas adotadas pelo “PMI – Project Management Institute” , dos Estados Unidos, reconhecido mundialmente como formulador dos mais altos padrões de qualidade na gestão de projetos e, de acordo com a ISO 9001 – versão 2000.

53 Amplitude do Plano de Projeto
Missão e Objetivo do Projeto; Premissas Gerais; Declaração de Escopo; Principais Resultados; Work Breakdown Structure; Cronograma do Projeto; Plano de Recursos; Plano de “Entregas”; Plano de Gerenciamento de Mudanças; Plano de Garantia;

54 Amplitude do Plano de Projeto
Plano de Comunicação; Plano de Gerenciamento de Riscos; Plano de Qualidade; Plano de Testes; Plano de Escalação; Fatores Críticos para o Sucesso do Projeto; Exclusões; Glossário; Anexos; e Aceitação do Plano de Projeto.

55 Premissas Gerais As seguintes premissas foram consideradas pela ABC na preparação dos custos, tempo, “Principais Resultados” e nas estimativas de recursos contidos neste Documento: A XYZ deverá nomear uma equipe de trabalho, com um gerente do projeto e especialistas previamente determinados. Esta equipe será responsável pela facilitação do trabalho da ABC, disponibilização de informações necessárias e a absorção de conhecimento. A XYZ deverá disponibilizar as informações requeridas pela ABC no prazo previsto no cronograma, de modo a não impactar os prazos propostos para o projeto.

56 Principais resultados: deliverables do projeto
Nome do deliverable Descrição do deliverable Recursos Atividades Ferramentas Responsabilidades da ABC Responsabilidades da XYZ Premissas Específicas Critério de Aceitação Deliverable 2: Nome do Deliverable .

57 Plano de Gerenciamento de Mudanças
No contexto deste Projeto, “Mudanças” podem ocorrer por diversos motivos. Os fatores que originam estas “Mudanças” podem ser: Mudanças na legislação; Mudanças solicitadas pela XYZ para incrementar ou reduzir funcionalidades na solução desenvolvida; Mudanças solicitadas pela XYZ para responder às necessidades ou direcionamento de negócios; Mudanças propostas pela ABC a fim de atender as particularidades técnicas que podem surgir durante o desenvolvimento do projeto; Para introduzir/alterar um novo componente (software ou hardware) a fim de atender as necessidades do negócio. Estas alterações impactam diretamente no escopo, tempo e qualidade do Projeto. A fim de estabelecer procedimentos claros e formais, se faz necessário a criação do processo de Gerenciamento de Mudanças.

58 Plano de Gerenciamento de Mudanças: Pedido de Mudança.
É o processo utilizado quando se identifica uma “Mudança”, a qual necessita de aprovação para ser executada. O Pedido de Mudanças é usado sempre que se identifica uma “Mudança” e, que pode ser incorporada ao Projeto. O propósito é registrar a totalidade da “Mudança”, identificar o impacto, tempo, custos, determinar a melhor alternativa para efetuar a mudança e, obter a aprovação das partes implicadas previamente, antes de iniciar qualquer ação associada.

59 Plano de Gerenciamento de Mudanças: Processo de uma mudança
Preenchimento formal do formulário de pedido de mudança Avaliação da mudança solicitada Aprovação da mudança Implantação da mudança Verificação do aceite da mudança Registro do processo

60 Plano de Garantia Deverá ser reportado no plano de projeto as informações sobre a garantia dos serviços ou produtos desenvolvidos no projeto. Deve constar ao mínimo as seguintes informações: Início e encerramento da Garantia de cada deliverable Cobertura da Garantia de cada deliverable Processo de solicitção de Garantia Exclusões de Garantia Processo de escalação durante o período de garantia Processo para extensão de Garantia de cada deliverable

61 Finalização do projeto

62 Objetivos: Diagnosticar o projeto e determinar se ele deve ser finalizado Avaliar a finalização do projeto Documentar e registrar as lições aprendidas

63 Finalização do projeto:
Finalização envolve levar o projeto à sua conclusão de uma forma ordenada Com a finalização das tarefas, o trabalho de maior interesse já foi realizado Os membros da equipe podem encontrar dificuldades em focar na finalização das tarefas restantes e finalizar o projeto de forma adequada

64 Tarefas na finalização:
Desalocação dos membros da equipe Retorno dos recursos materiais Análise das obrigações contratuais Avaliação com o cliente se o objetivo do projeto foi atingido Exercício de lições aprendidas Preparação para manutenção Transição para operação

65 Avaliação da finalização do projeto:
Apresenta um problema fundamental Como podemos nos assegurar que as lições são comunicadas e utilizadas por outras equipes de trabalho? Como podemos conseguir que as lições aprendidas sejam bem documentadas e postas em uso?

66 Finalização prematura:
Algumas causas de finalização prematura: A avaliação pode demonstrar que o projeto desviou-se demasiado dos objetivos iniciais Os objetivos iniciais do projeto podem não ser mais válidos Recursos podem ter se extinguido ou não serem mais disponíveis Morte do “sponsor” do projeto Fusões de empresas mostram redundância de projetos Por decisão corporativa ou mudança de direção

67 Finalização prematura:
Quando uma decisão é feita em terminar um projeto, o evento mais perceptível é que toda atividade na substância do projeto cessa. Um grande esforço administrativo ainda necessita ser realizado. Atividades devem ser desenvolvidas para uma finalização ordenada: revisão de contratos, liberação de equipe, devolução de materiais, instalações e equipamentos.

68 Decisão: go/no-go: Custos já gastos são vistos como despesas já realizadas e que por isso são irrelevantes no processo decisório de continuidade do projeto 80.000 60.000 Tempo 1 Tempo 0 Benefício Esperado Custo adicional estimado para finalizar o projeto Custo até a presente data Caso em Análise Tempo 0  BCR = 2,0 Tempo 1  BCR = 1,5 Decisão: Terminar o projeto BCR = Benefit-cost ratio

69 Finalização com integração:
Esta é a forma mais comum de finalizar um projeto bem sucedido. A propriedade, equipamentos, materiais, pessoal e funções do projeto são distribuídos entre os elementos existentes da organização. O produto do projeto passa a ser parte integrante da operação do cliente. Em alguns casos o problema de transição para produção é pequeno em outros casos é grande. O time de projeto que instalou, desenvolveu e instruiu o cliente na sua operação e manutenção partiu e uma nova equipe deve realizar a operação do sistema no dia-a-dia.

70 Finalização por falta de recursos:
Trata-se de um “slow-down” devido à falta de orçamento suficiente para dar continuidade ao projeto na velocidade projetada Projetos de média e longa duração podem sofrer deste problema conforme cortes no orçamento são realizados São comuns e frequentemente visam mascarar o fim de um projeto Razões possíveis para isto: Politicamente perigoso admitir que um projeto falhou. Terminar um projeto mal sucedido ou obsoleto é admitir a falha. Em tal caso, o orçamento do projeto recebe um corte – ou uma série de pequenos cortes – grande o suficiente para impedir avanços no projeto e forçar a alocação de muitos componentes da equipe em outros projetos.


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

Apresentações semelhantes


Anúncios Google