ajmestgf.ipp.pt

2. História da Gestão de Projectos Actualmente A visão das organizações como organismos vivos, tem uma importante implicação Para que uma organização sobreviva e prospere, todas as suas partes funcionais devem trabalhar, de forma coordenada para atingir objectivos específicos ou realizar projectos Nas década de 1980 esta abordagem de gestão de projectos cimentou-se nas suas diversas formas Os vários modelos de negócios partilham uma estrutura subjacente comum (em especial para empresas maiores) O projecto é gerido por um chefe de projecto, que reúne uma equipa e assegura a integração e comunicação do fluxo de trabalho ao longo entre diferentes departamentos e unidades de negócio

3. O Que É um Projecto? As organizações realizam trabalho O trabalho envolve, geralmente, operações ou projectos, embora os dois se possam sobrepor Operações e projectos partilham várias características. Ambos são: Realizados por pessoas Constrangidos por recursos limitados Planeados, executados e controlados.

4. O Que É Um Projecto? Principal diferença entre operações e projectos: Operações são contínuas e repetitivas Projectos são temporários e únicos Definição de projecto [PMBOK 2000]: empreendimento temporário levado a efeito com o objectivo de produzir um produto ou serviço único Temporário significa que todo o projecto tem um início e um fim definidos Único significa que o produto ou serviço é diferente, de algum modo, de outros produtos ou serviços similares

5. Exemplos de Projecto Desenvolver um novo produto ou serviço Efectuar uma alteração na estrutura, no pessoal, ou no estilo de uma organização Desenhar um novo veículo de transporte Desenvolver, ou adquirir, um sistema de informação novo, ou modificado Construir um edifício Levar a cabo uma campanha eleitoral Implementar um novo processo, ou procedimento empresarial

6. Um Projecto É Temporário Um projecto atinge o seu término quando os seus objectivos são alcançados, ou quando se torna claro que os objectivos não podem ser alcançados, e o projecto é cancelado A maioria dos projectos tem um intervalo de tempo limitado para produzirem o respectivo produto, ou serviço A equipa de projecto raramente sobrevive ao projecto, enquanto equipa A maioria dos projectos são implementados por uma equipa criada com o objectivo único de realizar o projecto Logo que o projecto termina, a equipa é desmembrada e os membros são atribuídos a outro projecto

7. Produto/Serviço Único Um produto ou serviço pode ser único, embora a categoria a que pertence seja ampla Milhões de edifícios têm sido desenvolvidos, mas cada um é individual e único – diferente proprietário, diferente projecto, diferente design, diferente localização, etc. Características que o distingem devem ser elaboradas progressivamente, isto é, por passos A elaboração das características do produto devem ser cuidadosamente coordenadas com o adequado âmbito do projecto, especialmente se este for realizado sob um contrato

11. Projecto e Programa Os termos PROJECTO e PROGRAMA são muitas vezes usados para significar o mesmo Para o PMI, os termos designam realidades diferentes Programa = Grupo de projectos logicamente relacionados Os projectos são geridos em conjunto Para ganhar benefícios que não estariam disponíveis com a gestão dos projectos em separado Porque incluem processos similares que beneficiarão da gestão simultânea Os programas Normalmente duram mais tempo que os projectos Muitas vezes têm um ponto de conclusão menos definido Podem incluir elementos de operações correntes

12. Project Stakeholders Segundo o PMI [PMBOK® 2000, p. 6] A gestão de projectos é a aplicação do conhecimento, aptidões, ferramentas e técnicas às actividades do projecto, de modo a satisfazer, ou exceder, as necessidades e expectativas de todos os indivíduos, ou organizações, que estão envolvidos no projecto, ou podem ser por ele afectados Stakeholders – Todos aqueles que têm um interesse pessoal no projecto (têm algo a ganhar ou perder com o projecto)

13. Project Stakeholders Os stakeholders têm muitas vezes interesses conflitantes É responsabilidade do chefe de projecto compreender esses conflitos e tentar resolvê-los Identificar e reunir com todos os stakeholders no início do projecto, para compreender todas as suas necessidades e limitações Quando em dúvida, os conflitos entre stakeholders devem ser sempre resolvidos em favor do cliente

14. Características Comuns dos Projectos São únicos São temporários por natureza e têm uma data de início e fim definitiva Estão concluídos quando os objectivos do projecto são alcançados Um projecto de sucesso é aquele que satisfaz ou excede as expectativas dos seus stakeholders

15. Será um Projecto? Um Administrador aborda-o com uma ideia que ele acha fabulosa Quer implantar quiosques em centros comerciais, funcionando como mini escritórios. Estes escritórios irão oferecer aos clientes a possibilidade de adquirir novos serviços telefónicos sem fios, pagar as suas facturas de telemóvel e comprar equipamentos e acessórios. Ele acredita que a localização em centros comerciais irá aumentar a consciência do público sobre a oferta da companhia. A administração já aprovou o projecto e ser-lhe-ão dedicados todos os recursos possíveis. Quer os novos quiosques a funcionar em 12 locais até ao fim do ano. Você vai liderar o projecto.

17. O Que É a Gestão de Projectos? A equipa de projecto gere o trabalho dos projectos, o qual envolve tipicamente Exigências concorrenciais por: âmbito, tempo, custo, risco e qualidade Stakeholders com diferentes necessidades e expectativas Requisitos identificados (necessidades) Requisitos não identificados (expectativas) Muitos dos processos da gestão de projectos são iterativos por natureza – devido em parte à necessidade de elaboração progressiva ao longo do ciclo de vida do projecto Quanto mais sabemos sobre o projecto, melhor o podemos gerir

19. Apresentação da estrutura da equipa do projecto (OBS)

22. Restrições dos Projectos Triângulo de Restrições dos Projectos

23. Restrições dos Projectos Uma, duas ou as três restrições podem ser limitadas O orçamento pode ser ilimitado (quase!) mas o tempo é uma limitação Podemos ter todo o tempo necessário para concluir o projecto, mas o orçamento é limitado Os recursos e o tempo podem ser limitados O Chefe de Projecto tem de equilibrar as três restrições, ao mesmo tempo que procura satisfazer ou exceder as expectativas dos seus stakeholders Nunca se conseguem optimizar as três restrições em simultâneo – no máximo duas

24. Processos da Gestão de Projectos Os projectos são compostos por processos Conjunto de acções que conduzem a um resultado Os processos dos projectos são geralmente divididos em duas grandes categorias

25. Influência das Estruturas Organizacionais As organizações em que os projectos se desenvolvem são únicas, à semelhança dos projectos Tipos de estruturas organizacionais Funcionais Por projectos (projectized) Matriz Podem existir variações e combinações destas estruturas Por projectos dentro de uma funcional Matriz fraca, equilibrada e forte (Weak, Ballanced, Strong)

26. Influência das Estruturas Organizacionais É importante conhecer a estrutura organizacional e a cultura da entidade para que o chefe de projecto trabalha Companhias com cultura agressiva e que estão em sectores de ponta, embarcam mais facilmente em projectos de risco Estruturas organizacionais avessas ao risco e que preferem seguir o líder, dificilmente embarcam em projectos inovadores e de risco O nível de autoridade do chefe de projecto depende da estrutura organizacional Numa organização funcional tem pouca ou nenhuma autoridade formal e o seu título pode ser responsável de equipa, coordenador de projecto, etc.

27. Influência das Estruturas Organizacionais Organização funcional Centrada em especialidades e agrupada por função Cada pessoa reporta a um só gestor e existe uma cadeia de comando estrita Cada departamento/grupo é gerido de forma independente e tem uma extensão de controlo limitada

28. Influência das Estruturas Organizacionais Organização funcional Vantagens Estrutura organizacional duradoira Carreiras claras com separação de funções permitindo que apareçam aptidões especializadas Cadeia de comando clara Desvantagens Chefe de projecto tem pouca ou nenhuma autoridade formal A competição por recursos pode tornar-se feroz quando há projectos múltiplos Membros da equipa de projecto são leais ao gestor funcional

29. Influência das Estruturas Organizacionais Organização orientada por projectos (projectized) O enfoque é no projecto Desenvolvimento de lealdade ao projecto, não ao gestor funcional Recursos organizacionais dedicados aos projectos Chefes de projecto reportam ao Director Geral

30. Influência das Estruturas Organizacionais Organização orientada por projectos (projectized) Vantagens Chefes de projecto com autoridade última sobre o projecto Recursos organizacionais concentrados em projectos e no trabalho de projecto Membros da equipa são “colocados” Lealdades formadas para com o projecto Desvantagens Membros da equipa de projecto podem encontrar-se sem trabalho no final do projecto Ineficiências no tocante à utilização dos recursos (um recurso especializado pode estar desocupado por períodos de tempo)

31. Influência das Estruturas Organizacionais Organização matricial Procuram minimizar as diferenças e tirar partido dos pontos fortes e fracos das outras duas estruturas organizacionais Empregados reportam a um gestor funcional e, pelo menos, a um chefe de projecto Gestores funcionais assumem a parte administrativa dos deveres e atribuem empregados a projectos monitoram o trabalho dos seus vários funcionários nos diversos projectos Os chefes de projecto são responsáveis pela execução dos projectos e atribuição de tarefas aos membros da equipa

32. Processos/Ciclo de Vida da Gestão de Projectos(PMBOK? 2000)

33. Ciclo de Vida da Gestão de Projectos Como os projectos são únicos, envolvem um grau de incerteza As organizações que realizam projectos dividem-nos em diversas fases com o objectivo de Melhorar o controlo de gestão Proporcionar ligações com as operações continuadas da empresa As fases do projecto são globalmente conhecidas como ciclo de vida do projecto

34. Ciclo de Vida da Gestão de Projectos

35. Ciclo de Vida da Gestão de Projectos Processos de Iniciação Autorizam o projecto ou fase Processos de Planeamento Definem e refinam objectivos e seleccionam o melhor curso de acção para atingir os objectivos estabelecidos para o projecto Processos de Execução Coordenação de pessoas e outros recursos, para executar o plano Processos de Controlo Assegurar que os objectivos do projecto são satisfeitos, através da monitorização e medida regular do progresso, para identificar variâncias ao plano e permitir as acções de correcção necessárias Processos de Encerramento Formalizar a aceitação do projecto ou fase

36. Processos da Gestão de Projectos Os processos estão ligados pelos resultados que produzem

37. Processos da Gestão de Projectos As interacções dos grupos de processo também atravessam fases, de modo que encerrar uma fase fornece o input para iniciar a seguinte Encerrar uma fase de desenho exige aceitação do cliente sobre o documento de desenho. Em simultâneo, o documento de desenho define a descrição do produto para a fase de implementação

38. A prática de uma gestão de projecto rigorosa traz benefícios No entanto, a sua prática não é fácil, nem isenta de problemas Pressões do trabalho Prazos aparentemente irrealistas, impostos muitas vezes constituem uma forte tentação no sentido de se começar imediatamente o trabalho, sem despender o tempo necessário para o preparar O chefe de projecto deve resistir à pressão de iniciar o trabalho, sem ter antes despendido algum tempo a desenvolver um plano detalhado A Curva do Esforço

39. Tem-se demonstrado que um planeamento pobre tem um custo posterior no projecto, em termos de: Derrapagem dos prazos Qualidade baixa e Expectativas não satisfeitas A Curva do Esforço

40. Áreas de Conhecimento da G.P.

41. Áreas de Conhecimento da G.P. Gestão do âmbito Processos necessários para assegurar que o projecto inclui todo o trabalho exigido, e apenas o trabalho exigido, para concluir o projecto com sucesso Gestão do custo Processos necessários para assegurar que o projecto é concluído dentro do orçamento aprovado Gestão do tempo Processos necessários para assegurar a execução oportuna (no prazo definido) do processo Gestão da qualidade Processos necessários para assegurar que o projecto irá satisfazer as necessidades para as quais foi proposto

42. Áreas de Conhecimento da G.P. Gestão dos recursos humanos Processos necessários para fazer o mais eficaz uso das pessoas envolvidas no projecto Gestão da comunicação Processos necessários para assegurar a oportuna geração, recolha, disseminação, armazenamento e disponibilização da informação do projecto Gestão dos riscos Processos relativos à identificação, análise e resposta aos riscos do projecto Gestão dos fornecedores Processos necessários para adquirir bens e serviços ao exterior da organização que executa o projecto Gestão da integração Processos necessários para assegurar que os diversos elementos do projecto são adequadamente coordenados

43. Áreas de Conhecimento da G.P.

44. Planeamento e Calendarização do Projecto Gestão de Projectos

46. Enquadramento Um projecto de software apresenta duas dimensões fundamentais Engenharia Gestão do projecto A dimensão da engenharia trata da construção do sistema e centra-se nas questões técnicas Que modelo de processo usar Como desenhar, codificar, testar, etc. A dimensão da gestão do projecto trata do modo de planear e controlar adequadamente as actividades de engenharia, de modo a cumprir os objectivos do projecto em termos de custo, prazo e qualidade

47. O Que É a Gestão de Projectos?

50. Modelos de Processo do Software Modelo em Cascata

51. Modelos de Processo do Software Modelo em Cascata Vantagens Introduz uma disciplina no desenvolvimento Amplamente utilizado (a metodologia SSADM usa este modelo como base) Desvantagens Não reconhece explicitamente a necessidade de revisão – retornar a fases anteriores e refazer coisas, à luz da informação obtida durante o desenvolvimento Por ser sequencial e linear, tem dificuldade em acomodar a incerteza existente no início da maioria dos projectos O utilizador tem de esperar, por vezes bastante tempo, até lhe ser entregue uma versão operacional do sistema de software

59. Modelos de Processo do Software Modelo de Prototipagem

60. Modelos de Processo do Software Modelo de Prototipagem – Quando usar Quando há incertezas, a prototipagem é a medida de redução do risco mais usada Sempre que existirem riscos relacionados com questões abertas acerca da funcionalidade, ou da exequibilidade, devem usar-se protótipos no processo de desenvolvimento Prototipar – construir algo que ajuda a estabelecer um aspecto de um sistema que queremos construir, ou para obter informação Um protótipo propicia informação sobre alguma característica, a qual é depois utilizada para realimentar o processo de desenvolvimento

61. Modelos de Processo do Software Modelo de Prototipagem Vantagens Ajuda a eliminar riscos e incertezas Permite um maior diálogo utilizador – Engos de Sistemas Permite ter mais cedo uma ideia do sistema final Desvantagens Pode provocar expectativas incorrectas no utilizador O protótipo não é o sistema final Pode levar a escolhas técnicas menos eficientes, com consequências problemáticas Escolha de uma linguagem de programação menos eficiente, por motivos de pressa em ter o protótipo pronto

62. Modelos de Processo do Software Modelo de Entrega Incremental

63. Modelos de Processo do Software Modelo de Entrega Incremental Combina elementos do modelo sequencial com a filosofia iterativa do modelo de prototipagem As sequências lineares estão desfasadas no tempo e cada uma delas produz um incremento utilizável do software O fluxo do processo para cada incremento pode incorporar a prototipagem Cada entrega ao cliente é utilizável, embora possua apenas uma funcionalidade parcial Cada produto entregue é idêntico ao anterior, mas com novas funcionalidades

64. Modelos de Processo do Software Modelo de Entrega Incremental Vantagens Útil quando: Só se consegue visualizar, no início, uma parte da funcionalidade, ou Não se consegue entregar toda a funcionalidade, no mesmo dia, ou O negócio não consegue suportar toda a mudança, de uma só vez Desvantagens Baseia-se na capacidade do engenheiro de software criar uma arquitectura que suporte todos os incrementos e não obrigue, em algum ponto, a uma reengenharia maciça do sistema

65. Que Modelo de Processo Usar? Quando os requisitos são estáveis e o utilizador é um bom interlocutor que sabe o que pretende Modelo em Cascata Quando há dúvidas quanto à funcionalidade a implementar, ou o negócio não pode esperar muito tempo Modelo de Prototipagem Quando é importante colocar rapidamente um produto em exploração/no mercado, mesmo que sem as funcionalidades todas Modelo de Entrega Incremental

66. Especificação de entregas e milestones

67. Plano Detalhado do Projecto

68. A WBS A Estrutura de Decomposição do Trabalho (WBS) é uma descrição hierárquica do trabalho que tem de ser realizado para concluir o projecto como está descrito na definição do trabalho dos Termos de Referência A estrutura da WBS define todo o trabalho contratualmente autorizado

69. A WBS

70. A WBS Níveis da Estrutura de Decomposição do Trabalho

71. A WBS Exemplo de WBS

72. A WBS Exemplo de WBS

74. Work Breakdown Structure Regras Básicas de Construção Decomposição completa: Não deve existir nenhum trabalho e custo no projecto que não seja atribuível a uma tarefa na WBS Decomposição hierárquica: O âmbito e custo de uma tarefa é exactamente igual à soma do âmbito e custos das suas subtarefas Ou seja, não fica retida nenhum custo ou trabalho retido na tarefa-mãe Consistência dos critérios de decomposição: Quando uma componente é decomposta para o nível seguinte, deve ser utilizado apenas um critério para todas as suas subcomponentes

75. Work Breakdown StructureRegras Básicas de Construção Critérios de decomposição mais comuns: Sub-produto: com base na PBS Tipo de trabalho: e.g. análise, programação Fases cronológicas: e.g. avaliação, desenvolvimento, instalação Localização geográfica Responsabilidades dos executantes

76. Work Breakdown Structure Verificabilidade Diz-se que o âmbito de uma tarefa está definido de forma verificável quando: A sua consecução completa pode ser verificada de acordo com um critério objectivo, ausente de ambiguidades Recomenda-se que o critério assente na identificação de entregas (outputs) bem definidos Uma forma eficaz (nem sempre possível) de assegurar a verificabilidade consegue-se através da quantificação das entregas

77. Work Breakdown Structure Processo de construção: orientações 1º - Assegurar a Gestão de Projecto: separar trabalho de gestão de projecto (que deve estar no plano), do trabalho tecnológico de construção do produto. 2º - Facilitar o Rolling Wave: decompor “Gestão do Projecto” e “Construção do Produto” nas fases cronológicas, as quais podem ser identificadas através dos ciclos de vida da Gestão de Projecto e do processo tecnológico. Por exemplo: Gestão do Projecto: planeamento, controlo e encerramento. Processo tecnológico: desenho, construção, integração e instalação 3º - Deliverable oriented: integrar a PBS na WBS, identificando os deliverables que serão produzidos em cada fase cronológica. 4º - Executar o Rolling Wave + Deliverable Oriented: para as fases próximas, identificar as actividades que irão fabricar ou produzir os deliverables (processo 6.1).

78. Product Breakdown Structure Processo de Construção Decomposição progressiva do Produto do Projecto em subcomponentes elementares

79. Estrutura de decomposição do produto (PBS)

80. Product Breakdown Structure Processo de Construção Decomposição progressiva do Produto do Projecto em subcomponentes elementares Cada componente elementar deve: (1) originar um entendimento comum entre todas as partes envolvidas (2) permitir uma definição dos requisitos e qualidade de forma verificável Quando uma componente não respeita estes dois princípios, então deve ser decomposta em mais sub-componentes

81. Product Breakdown Structure Objectivos Definição dos Requisitos e Qualidade do Produto do Projecto de forma Verificável

82. Product Breakdown Structure Requisitos e Qualidade Cada componente elementar deverá ser acompanhada de uma descrição que a defina de forma clara e concisa Para cada componente, elementar ou composta, deverão ser definidos os critérios de verificabilidade da qualidade: Estes critérios definem as propriedades que a componente deverá ter para ser aceite – i.e. são critérios de aceitação No último caso, tratar-se-á de “propriedades do todo” que serão aplicáveis a todas as suas partes (i.e. “herança”)

83. Product Breakdown Structure Verificabilidade Diz-se que os requisitos de uma componente estão definidos de forma verificável quando: A sua consecução pode ser verificada de acordo com um critério objectivo do tipo “Sim/Não”, ausente de ambiguidade Em face da especificação dos critérios do produto desenvolvido, duas partes independentes tirariam a mesma conclusão (i.e. Sim/Não) sem necessidade de realizarem pressupostos A forma mais eficaz (nem sempre possível) de assegurar a verificabilidade consegue-se através da quantificação dos critérios

84. Product Breakdown Structure Regras Básicas de Construção Decomposição completa: Não deve existir nada que seja esperado pelo cliente que não seja atribuível a uma componente da PBS Decomposição hierárquica: O âmbito de uma componente é exactamente igual à soma do âmbito das suas subcomponentes Ou seja, não fica retida nenhuma funcionalidade na “componente mãe” (nota: poderá não ser aplicável aos critérios de qualidade) Consistência dos critérios de decomposição: Quando uma componente é decomposta para o nível seguinte, deve ser utilizado apenas um critério para todas as suas sub-componentes

85. Product Breakdown Structure Regras Básicas de Construção Critérios de decomposição mais comuns: Natureza do produto: e.g. documentos, software, serviços Arquitetura técnica do produto: e.g. capítulos Funcionalidade / item a ser entregue ao cliente Versões do produto: e.g. temporal, geográfica

86. Estimar Custos, Prazos e Recursos A estimação do projecto a partir do conhecimento das actividades de nível mais baixo da WBS – os pacotes de trabalho – é um processo com três passos elementares: Estimar o esforço em pessoas–meses, pessoas–dias ou pessoas–horas Estimar a duração em meses de calendário Estimar o custo do projecto

87. Estimar Custos, Prazos e Recursos Estimar o Esforço Uma vez estimada a dimensão do software a produzir, pode deduzir-se a estimativa do esforço necessário para realizar cada uma das actividades A conversão de dimensão do software para esforço total do projecto, só pode ser realizada se tiver sido definido o ciclo de vida do desenvolvimento e o modelo de desenvolvimento que é seguido para especificar, desenhar, desenvolver, testar e instalar o software

88. Estimar Custos, Prazos e Recursos Estimar a Duração das Actividades A duração de um projecto é o período de tempo em dias de trabalho úteis, excluindo fins de semana, feriados, períodos de férias, tempo de formação, períodos de doença, etc. É diferente de esforço de trabalho, o qual é o trabalho necessário para concluir uma actividade (este esforço pode ser efectivado em períodos consecutivos, ou não)

89. Estimar Custos, Prazos e Recursos Estimar a Duração das Actividades – Pressupostos O uso de estimativas aos níveis mais baixos (pacote de trabalho) é fundamental para responder às seguintes questões: Quem vai trabalhar nesta fase? Quando se juntam ao projecto? Quando abandonam o projecto? O que devem fazer? Quanto tempo precisam?

90. Estimar Custos, Prazos e Recursos Estimar o Custo Muitos factores a considerar quando se estima o custo total de um projecto Trabalho da equipa Aquisições e alugueres de hardware e software Viagens para reuniões ou testes Telecomunicações (por exemplo, chamadas interurbanas e internacionais, videoconferências, linhas dedicadas para testes, etc.) Cursos de formação Espaço de escritório Etc.

91. Estimar Custos, Prazos e Recursos Estimar o Custo A forma exacta como se calcula o custo total do projecto, depende do modo como a organização distribui os custos Pode obter-se um custo do trabalho mais preciso se for usada uma taxa específica para cada tipo de posição no projecto (por exemplo, Técnico, Gestão da Qualidade, Gestão do Projecto, Documentação, Suporte, etc.) O chefe de projecto terá de determinar qual a percentagem do esforço total do projecto que deverá ser atribuída a cada posição Mais uma vez, os dados históricos ou os modelos da indústria podem ajudar

92. Avaliação Financeira Um projecto tem custos e receitas ao longo do tempo Somar custos e receitas dos diversos anos ignora a capitalização do dinheiro Dinheiro gera mais dinheiro: 1€ hoje vale 1+t € no próximo ano Quanto tenho de ter hoje para ter 1€ no próximo ano? 1€ hoje quanto vale daqui a 10 anos? Solução: converter tudo para euros do instante 0! O Valor Actual Líquido é igual à soma de todos os custos e receitas convertidos para o instante 0

93. Exemplo 1, t=0.05

94. Outras Taxas Taxa de … actualização juro (empréstimo, depósito) inflação O dinheiro vai desvalorizando: 1€ no ano passado vale hoje 1-i € Quanto teria de ter o ano passado para ter 1€ hoje?

95. Taxa Interna de Rentabilidade TIR = taxa de actualização tal que VAL=0 Tem de ser calculado por tentativa erro Os projectos com maior TIR são os mais rentáveis Este método tem a vantagem de não necessitar de parâmetros Para calcular o VAL é necessária da taxa de actualização

96. Construção de Diagramas de Rede

97. Porquê Diagramas de Rede? Neste ponto do ciclo da gestão do projecto estão identificadas As actividades do projecto A duração das actividades A tarefa seguinte da equipa de planeamento é determinar a ordem em que essas actividades devem ser executadas O calendário do projecto A duração do projecto Duas formas de construir o calendário do projecto Gráfico de barras (Gantt) Diagrama de rede

98. Ferramentas de Calendarização Program Evaluation and Review Technique (PERT) Método (probabilístico) de construção de redes de projectos Ênfase em satisfazer prazos, com flexibilidade nos custos Três estimativas por actividade – pessimista (p), mais provável (m) e optimista (o) – com ênfase no cálculo da estimativa mais provável, isto é: (p + 4m + o)/6 Critical Path Method (CPM) Método (determinista) de construção de redes de projectos desenvolvido nos anos 1950 para o programa militar Polaris Ênfase no controlo do custo, com flexibilidade nos prazos Uma estimativa por actividade Orientado para a actividade (float – folga de actividades)

99. Ferramentas de Calendarização Precedence Diagramming Method (PDM) Método de construção de redes de projectos, oriundo da Universidade de Stanford (1960’s) em que as actividades são representadas por rectângulos (nós) e as dependências por setas unindo os nós – activity-on-node Arrow Diagramming Method (ADM) Método de construção de redes de projectos Mais antigo e menos usado que o PDM Usa setas para representar actividades – activity-on-arrow – e nós (círculos) para representar dependências Usa apenas dependências finish-to-start Pode ser necessário usar actividades fictícias (dummy activities) para definir correctamente todas as relações lógicas

100. Ferramentas de Calendarização Construção de redes Todas as actividades num diagrama de rede têm, pelo menos, um antecessor e um sucessor (excepto as actividades de início e fim) Para cada actividade, é necessário calcular duas datas Datas mais cedo (early schedule) – data de início mais cedo e data de fim mais cedo Data mais tarde (late schedule) – data de início mais tarde e data de fim mais tarde Estas datas mostram a janela temporal dentro da qual uma actividade se pode iniciar e concluir, a fim de concluir o projecto no prazo Caminho crítico – sequência de actividades que determina a data de conclusão do projecto Tempo mais curto em que o projecto pode ser realizado Caminho mais comprido ao longo da rede

101. Ferramentas de Calendarização Cálculo de datas mais cedo Earliest start time (ES) de uma actividade – momento mais cedo em que todas as actividades antecessoras terminaram e a actividade em questão pode ser iniciada A ES da 1ª actividade é igual a 1 A ES de uma actividade com um antecessor é igual à ES do antecessor mais a duração do antecessor menos 1 unidade de tempo A ES de uma actividades com vários antecessores, é igual à maior ES que resulta do cálculo com os diversos antecessores A ES de todas as actividades é calculada percorrendo a rede do início para o fim (forward pass)

102. Ferramentas de Calendarização Cálculo de datas mais cedo Earliest finish time (EF) de uma actividade – momento mais cedo em que uma actividade pode ser concluída A EF de uma actividade com um antecessor é igual à ES mais a duração menos 1 unidade de tempo [ES = (ES + Duração) – 1 unidade de tempo] Uma actividade começa no início de uma unidade de tempo (hora, dia, etc.) e termina no final de uma unidade de tempo (uma actividade que começa no dia 1 e dura um dia, é concluída no fim do dia 1)

103. Construção de uma Rede Método “activity-on-node” Exemplo com 10 actividades

104. Construção de uma Rede Cálculo de datas mais cedo – forward pass 1º passo – construir o desenho da rede mostrando as dependências e durações

105. Construção de uma Rede Cálculo de datas mais cedo 2º passo – calcular todas as ES (ES da actividade anterior + duração da actividade anterior)

106. Construção de uma Rede Cálculo de datas mais cedo 3º passo – calcular todas as EF (ES + duração – 1 unidade de tempo)

107. Construção de uma Rede Cálculo de datas mais tarde Latest start time (LS) de uma actividade – momento mais tarde em que a actividade pode iniciar-se, sem causar um atraso no projecto Latest finish time (LF) de uma actividade – momento mais tarde em que a actividade pode ser concluída, sem causar um atraso no projecto Estas datas calculam-se percorrendo a rede do fim para o princípio (backward pass) 1º passo – estabelece-se a LF da última actividade igual à respectiva EF 2º passo – calcula-se a LS da última actividade igual a: [LF – duração) + 1 unidade de tempo] 3º passo – a LF de todas as actividades imediatamente precedentes é determinada pelo mínimo da LS menos 1 unidade de tempo

108. Construção de uma Rede Cálculo de datas mais tarde LF da última actividade

109. Construção de uma Rede Cálculo de datas mais tarde LS da última actividade

110. Construção de uma Rede Cálculo de datas mais tarde LF e LS de todas as actividades

111. Construção de uma Rede Folga (Slack/float time) Slack (ou float) é o tempo que uma dada actividade pode ser atrasada sem atrasar o resto do projecto É a diferença LF – EF Folga livre Espaço máx. de tempo que uma actividade pode ser atrasada sem causar um atraso na data de início mais cedo de quaisquer actividades suas sucessoras imediatas Folga total N.º máx. de períodos de trabalho que uma actividade pode ser atrasada sem atrasar a data de conclusão do projecto

112. Diagramas de Precedência Tipos de dependências de tarefas Finish-to-start – o início da actividade sucessora depende da conclusão da actividade antecessora Finish-to-finish – a conclusão do trabalho do sucessor depende da conclusão do trabalho do antecessor Start-to-start – o início do trabalho do sucessor depende do início do antecessor Start-to-finish – a conclusão do sucessor depende do início do antecessor

113. Relações Lógicas Entre Actividades FINISH-TO-START (FS) Relação mais comum (menor risco) Duas actividades relacionadas deste modo formam um “caminho”

114. Relações Lógicas Entre Actividades FINISH-TO-FINISH (FF) Sucessor não pode terminar antes do antecessor terminar Pode acabar mais tarde (por ex., se for maior ou for exigido por outra lógica)

115. Relações Lógicas Entre Actividades START-TO-START Sucessor não pode começar antes de o antecessor começar (por ex., + 2 dias) Pode começar mais tarde, se for exigido por outras relações

116. Relações Lógicas Entre Actividades START-TO-FINISH Muito pouco comum, muitas vezes uma Finish-to-Start disfarçada O sucessor não pode acabar antes de o antecessor começar

117. Variáveis Atraso Num diagrama de rede as pausas ou atrasos entre actividades são indicadas por intermédio de variáveis atraso (lag variables) Numa dependência sart-to-start (SS) posso atribuir um intervalo de tempo entre o início das duas actividades Exemplo Há duas actividades: (A) envio de inquéritos e (B) início de recolha de dados para o sistema informático Posso estabelecer um prazo (10 dias, por ex.) entre o início da actividade A e o início da actividade B

118. Análise da Rede Inicial do Projecto Após a criação da rede inicial do projecto, pode apresentar-se uma de duas situações: A data inicial de conclusão do projecto satisfaz a data de conclusão requerida A data inicial de conclusão do projecto é posterior à data de conclusão requerida. A segunda situação é a mais provável, o que significa que teremos de retirar algum tempo às actividades do projecto. Necessitaremos eventualmente de tratar de duas questões: A data de conclusão do projecto e A disponibilidade de recursos à luz do calendário revisto do projecto

119. Compressão do Prazo Quase sem excepção, os cálculos iniciais do projecto resultam numa data de conclusão do projecto posterior à requerida A equipa de projecto tem de encontrar formas de reduzir a duração total do projecto de modo a satisfazer a data exigida Analisa-se a rede para identificar áreas em que se pode comprimir a duração do projecto Procuram-se pares de actividades que permitam converter actividades realizadas actualmente em série para modelos de trabalho mais paralelos – o trabalho na actividade sucessora pode iniciar-se quando a actividade antecessora tiver alcançado um determinado grau de conclusão

120. Compressão do Prazo Técnicas de compressão Crashing Adicionar mais recursos ás actividades no caminho crítico, de modo a executar o trabalho mais depressa É uma técnica que aumenta sempre o custo do projecto e não constitui sempre uma alternativa viável Fast tracking Executar, em paralelo, actividades que seriam normalmente feitas em sequência Resulta frequentemente em necessidade de refazer trabalho, devido a erros (rework ) e aumenta o risco Diferente de engenharia concorrente (fases inteiras em paralelo)

121. Nivelamento de Recursos Optimizar o uso de pessoas e equipamento atribuídos ao projecto Começa com o pressuposto de que é mais produtivo fazer um uso consistente e contínuo do menor n.º possível de recursos – evitar a repetida adição e remoção de recursos ao longo do projecto É o último passo na criação de um calendário realista – confronta a realidade de pessoas e equipamentos limitados e ajusta o calendário, para compensar Usar a folga disponível em caminhos não-críticos, para arranjar um calendário de trabalho que nivele os picos e vales de recursos Resulta muitas vezes num aumento da duração do projecto

122. Nivelamento de Recursos Técnicas para reduzir a duração de actividades Redistribuir recursos de actividades não-críticas para críticas Uso de horas extra, fins de semana e turnos múltiplos Aumento da produtividade pelo uso de diferentes equipamentos Fast tracking (actividades em paralelo)

123. Gestão do Risco Gestão de Projectos

124. Enquadramento Os riscos aumentaram devido À acrescida complexidade À conectividade global e À dependência de sistemas e pessoas de confiabilidade desconhecida Desenvolvimento de produtos/sistemas complexos revela-se, muitas vezes, de gestão quase impossível Projectos tendem a atrasar-se, exceder os orçamentos e não satisfazer os requisitos dos utilizadores. Em alguns casos são simplesmente cancelados

125. O Conceito de Risco. Evolução

126. Processos da Gestão do Risco

128. Identificação dos Riscos

129. Identificação dos Riscos Categorias de Riscos A classificação dos riscos em categorias que reflictam fontes comuns, facilita a sua identificação Riscos técnicos, de qualidade ou de desempenho Depender de tecnologias complexas ou não testadas; objectivos de desempenho irrealistas; alterações à tecnologia usada; etc. Riscos de gestão do projecto Má atribuição de tempo e recursos; inadequada qualidade do plano do projecto; uso fraco de disciplinas de gestão de projectos Riscos organizacionais Objectivos de tempo, custo e âmbitos internamente inconsistentes; falta de priorização dos projectos; inadequação ou interrupção do financiamento de projectos; conflitos de recursos com outros projectos da organização; etc. Riscos externos Alterações na legislação ou regulamentação; problemas laborais; alterações de prioridades do cliente; risco do país

130. Identificação dos Riscos Ferramentas para identificação de riscos Brainstorming Entrevistas Análise SWOT Comparação com checklists de riscos Documentar os riscos de forma eficiente Usar formulários

131. Identificação dos Riscos – Checklists

132. Avaliação dos Riscos

133. Avaliação Qualitativa dos Riscos Avaliação dos atributos dos riscos Classificação dos riscos Priorização (ordenação) dos riscos

134. Avaliação Qualitativa dos Riscos Matriz de Exposição ao Risco (Matriz de Probabilidade – Impacto ) Matriz que atribui classificações (Muito Baixo, Baixo, Moderado, Alto, Muito Alto) aos riscos com base em escalas combinadas de probabilidade e impacto Esta matriz é uma forma muito usada de combinar duas dimensões para determinar se um risco é considerado muito baixo, baixo, moderado ou alto A classificação, ou exposição do risco, ajuda a colocar o risco numa categoria que irá guiar as acções de resposta

135. Avaliação Qualitativa dos Riscos Matriz de Exposição ao Risco (Matriz de Probabilidade – Impacto ) Uma vez certos que há suficiente informação sobre os riscos, determina-se a PROBABILIDADE e o IMPACTO cada risco Trata-se de estimativas subjectivas

136. Avaliação Qualitativa dos Riscos Exemplo de escala de impacto [PMBOK 2004]

137. Avaliação Qualitativa dos Riscos Matriz de Exposição ao Risco

138. Avaliação Qualitativa dos Riscos Outputs da Análise Qualitativa Risco global do projecto Soma-se o valor das probabilidades ? impactos dos riscos todos e depois divide-se pelo N.º de riscos O risco global do projecto é o padrão pelo qual os esforços de gestão do risco são medidos Pode ser usada para Atribuir pessoal ou outros recursos a projectos com diferentes classificações de risco Fazer uma decisão sobre o benefício/custo do projecto Suportar uma recomendação para o arranque, a continuação ou o cancelamento do projecto Lista priorizada de riscos Agrupamento dos risco por classificação ou por urgência de resposta Lista de riscos para posterior análise adicional (Análise Quantitativa) Riscos elevados ou moderados são fortes candidatos a uma análise mais cuidada, incluindo análise quantitativa

139. Avaliação dos Riscos Cálculo do risco global do projecto

140. Planeamento da Resposta aos Riscos

141. Planeamento da Resposta aos Riscos A fase de planeamento responde às questões: Quem é responsável por um risco? (atribuir responsabilidades) O que se deve (ou pode) fazer? (definir a abordagem) O que se deve fazer e em que medida? (definir o âmbito e as acções) Planear implica desenvolver acções para enfrentar os riscos individuais, ou conjuntos de riscos estabelecer prioridades para as acções e criar um plano integrado de gestão dos riscos

142. Planeamento da Resposta aos Riscos Estratégias de resposta a riscos Evitar um risco Eliminar uma ameaça específica através da alteração do plano do projecto Escolhida se um determinado risco for inaceitável (por exemplo, probabilidade muito elevada e consequências severas) Uma ferramenta útil é a adopção de uma estratégia alternativa Usar um modelo de desenvolvimento alternativo (prototipagem) Evitar fornecedores desconhecidos Reduzir o âmbito para evitar actividades de alto risco

143. Planeamento da Resposta aos Riscos Estratégias de resposta a riscos Transferir um risco Passar o risco e a responsabilidade de desenvolver uma resposta ao risco para uma terceira parte Não elimina o risco, apenas dá a outra parte a responsabilidade por ele Envolve quase sempre o pagamento de um prémio de risco à parte que o toma Seguro, prémios de desempenho, garantias Os contratos são usados para transferir riscos Um contrato de preço fixo pode transferir risco para o vendedor se o desenho do projecto for estável Um contrato de reembolso de custos deixa mais risco do lado do cliente, mas pode ajudar a reduzir custos e houverem alterações a meio do projecto

144. Planeamento da Resposta aos Riscos Estratégias de resposta a riscos Mitigar um risco Tomar acções específicas para reduzir a probabilidade e/ou as consequências de um risco, para um nível aceitável Os custos da mitigação devem ser proporcionados à probabilidade e às consequências do risco Exemplos de mitigação da probabilidade Usar tecnologia provada para diminuir os riscos técnicos ou de prazo Adoptar processos menos complexos Escolher um fornecedor mais estável Quando não é possível reduzir a probabilidade, a mitigação deve tratar do impacto Desenhar redundância num subsistema pode reduzir o impacto da falha da componente original

145. Planeamento da Resposta aos Riscos Estratégias de resposta a riscos Aceitar um risco A equipa decide aceitar as consequências do risco Aceitação activa Desenvolver um plano de contingência a ser executado se o risco ocorrer Definir limiares do risco e monitorá-los Aceitação passiva Não fazer nada. Aceitar, por exemplo, um lucro menor se algumas actividades derraparem Reserva de contingência (contingency allowance) Incluir reservas de tempo, dinheiro ou recursos para fazer face a riscos conhecidos (designados também por project buffers) Plano de retirada (fallback plan) Plano a seguir, se a estratégia de contingência não for eficaz Pode incluir um seguro, o desenvolvimento de opções alternativas, ou a alteração do âmbito do projecto (eliminação de partes do projecto)

146. Planeamento da Resposta aos Riscos Plano de Resposta aos Riscos Elaborar um documento que seja aceitável e utilizável por todos os intervenientes, sem entrar em burocracia Os riscos não-top não têm responsável atribuído – o Chefe de Projecto é responsável pela sua monitoria

147. Monitoria e Controlo dos Riscos

148. Monitoria e Controlo dos Riscos Processos de Monitoria dos riscos identificados e dos riscos residuais Identificação de novos riscos Execução dos planos de resposta Avaliação da eficácia dos planos ao longo da vida do projecto São objectivos desta fase, determinar se: As respostas aos riscos foram implementadas conforme o plano As acções de resposta ao risco são tão eficazes quanto esperado Os pressupostos e a exposição do projecto ainda são válidos Ocorreu um risk trigger São seguidos os procedimentos e políticas adequados Ocorreram riscos não previamente identificados

149. Monitoria e Controlo dos Riscos Ferramentas de monitoria e controlo dos riscos Revisões dos riscos (reuniões de project review) Earned value analysis Medições do desempenho técnico

150. Análise preliminar de riscos

151. Planeamento e Gestão da Qualidade Gestão de Projectos

152. Enquadramento O objectivo da gestão da qualidade durante os processos de gestão do projecto, é: Identificar as necessidades do cliente, para desenvolver objectivos com base nessas necessidades Identificar factores que impeçam a consecução dos objectivos do projecto Manter o projecto no calendário planeado, o que ajuda a evitar o sacrifício da qualidade no interesse do prazo e do custo O PMBoK? define qualidade como: A totalidade das características de uma entidade que sustentam a sua capacidade de satisfazer necessidades explícitas ou implícitas

153. Enquadramento A área de conhecimento da gestão da qualidade assegura que o projecto satisfaz os requisitos que conduziram ao seu lançamento Estes processos Medem o desempenho global Monitoram os resultados do projecto Comparam esses resultados com padrões da qualidade estabelecidos no processo de planeamento para garantir que o cliente irá receber o produto/ serviço que pensou ter comprado

154. Definição de Qualidade “Adequação ao objectivo, ou uso” [Duran 1952] “A totalidade dos aspectos e características de um produto, ou serviço, que se relacionam com a sua capacidade de satisfazer necessidades explícitas ou implícitas” [ISO 9000] Organizações vêem a Qualidade como um PROCESSO Processo contínuo de melhoria, em que as lições aprendidas são usadas para melhorar produtos e serviços futuros, para: Reter os clientes actuais Ganhar novos clientes Recuperar clientes perdidos

155. Efeito Multiplicador dos Erros Os custos dos defeitos aumentam de forma quase exponencial à medida que permanecem nos produtos

156. Atributos da Qualidade Atributos funcionais (o que o software deve FAZER) Aqueles que se aplicam a peças de software, desde os menores componentes até sistemas inteiros. Exemplos: A pedido de um utilizador num menu, a situação da conta deve ser empressa com os seguintes dados, conforme é mostrado na figura 4.6: ... Todos os dados relevantes devem ser guardados em disco, antes que qualquer transacção seja terminada Se x ? 0, a componente deve tomar o valor zero

157. Atributos da Qualidade Atributos não funcionais (o que o software deve PARECER) Aqueles que se podem aplicar a qualquer produto do processo de desenvolvimento: especificações, código, manuais, cursos de formação, ou o próprio sistema final. Exemplos: O sistema deve ser capaz de operar num computador com 64 MB de memória O sistema deve estar pronto para uso em 23 de Abril do próximo ano O sistema deve ter um custo de desenvolvimento inferior a 2,5 M€

158. Atributos da Qualidade O custo e a oportunidade são simplesmente atributos não funcionais. Quando se entrega um sistema, os atributos da qualidade orientados para o utilizador vão ser verificados através de alguma forma de teste de aceitação, para garantir que foi entregue a qualidade contratada

159. Atributos da Qualidade Para o cliente, a qualidade não é gratuita Existe um nível de qualidade – ou, mais precisamente, um conjunto de atributos da qualidade – que ele está disposto a pagar e que, de algum modo, tem um sentido económico para ele A definição de qualidade de um sistema pertence ao cliente O que é que ele está preparado para pagar? Quanto é que é economicamente útil para ele? O que é que o seu negócio exige e qual é o retorno esperado?

160. Normas da Qualidade do Software

161. Decomposição dos Atributos da Qualidade Durante o desenvolvimento, os atributos da qualidade de todos os produtos intermédios, devem ser derivados dos atributos da qualidade do sistema a ser entregue É a noção de decomposição da qualidade Os atributos da qualidade exigidos para o sistema final, são decompostos em atributos da qualidade para o desenho, para o código, para os manuais do utilizador, para as especificações dos testes, para os planos do projecto, etc.

162. Modelo de Sistema de Gestão da Qualidade (ISO 9001/2000)

163. Custos da Qualidade Custos da Prevenção Custos visíveis orientados para a satisfação dos requisitos do cliente (revisões de desenho, treino, planeamento da qualidade, inspecções a fornecedores, etc.) Custos da Avaliação Custos associados com a avaliação do produto ou processo, para garantir que satisfaz os requisitos do cliente (inspecções, testes, etc) Custos de Falhas Internas Custos associados com a falha de processos de fazer produtos aceitáveis para o cliente (desperdícios, reparações, acções correctivas, etc.) Custos de falhas Externas Custos associados com a determinação, pelo cliente, de que os seus requisitos não foram satisfeitos (devoluções, tratamento de reclamações, visitas ao cliente para resolução de queixas, etc.)

164. Custos da Qualidade

165. Processos da Gestão da Qualidade

166. Âmbito da Gestão da Qualidade A gestão da qualidade do projecto tem de tratar da gestão do projecto e do produto do projecto Falhas na satisfação dos requisitos da qualidade em qualquer destas dimensões podem ter sérias consequências negativas para qualquer dos stakeholders do projecto Satisfazer os requisitos do cliente sobrecarregando a equipa pode ocasionar atritos laborais e stress Satisfazer os objectivos de prazo apressando as inspecções da qualidade planeadas, pode fazer com que passem para o cliente erros não detectados

167. Gestão Moderna da Qualidade A gestão moderna da qualidade e a gestão de projectos reconhecem a importância de Satisfação do cliente – Misto de conformidade com os requisitos (o projecto tem de produzir o que disse que produziria) e adequação ao uso (o produto/serviço deve satisfazer necessidades reais) Prevenção acima da inspecção – O custo de prevenir erros é sempre muito menor que o custo de os corrigir Responsabilidade da gestão – O sucesso exige a participação de todos os membros da equipa, mas a gestão é responsável por fornecer os recursos necessários ao sucesso Processos dentro de fases – Os processos repetidos planear-agir-verificar-agir de Deming são similares às fases e processos do PMBoK®

168. Planeamento da Qualidade O PMI define o planeamento da qualidade para o projecto como A identificação dos padrões da qualidade que são relevantes para o projecto e a determinação do modo como os alcançar A qualidade deve ser planeada, não inspeccionada Embora as inspecções sejam certamente parte da gestão da qualidade do projecto, o aumento das inspecções não é considerado o melhor caminho para aumentar a qualidade O PMI realça a importância de existir uma política da qualidade para o projecto As intenções e direcção global de uma organização relativamente à qualidade, conforme expressa pela gestão Se a organização que desenvolve o projecto não tiver uma política da qualidade, ou se houverem diversas organizações envolvidas, a equipa de projecto deve desenvolver uma política da qualidade para o projecto

169. Planeamento da Qualidade Política da Qualidade Intenções e direcção globais de uma organização relativamente à qualidade, conforme expresso pela gestão de topo [PMBOK 2004] Se a organização de desenvolvimento não possuir uma política formal da qualidade, ou se o projecto envolve várias organizações (por ex., uma joint venture) a equipa de projecto precisa desenvolver uma política da qualidade para o projecto Normas e Regulamentos A equipa de projecto deve considerar quaisquer normas e regulamentos específicos da indústria que podem afectar o projecto

170. Planeamento da Qualidade Plano de Gestão da Qualidade do Projecto Descrição do sistema de gestão da qualidade do projecto Estrutura organizacional Procedimentos Processos Recursos necessários para implementar a política da qualidade [ISO 9000] Pode ser Formal ou informal Altamente detalhado ou formulado de forma ampla de acordo com os requisitos do projecto

171. Garantia da Qualidade Função de gestão que trata de todas as actividades planeadas e sistemáticas, implementadas dentro do sistema da qualidade e destinadas a dar confiança que o projecto irá satisfazer os relevantes padrões da qualidade É um processo fundamentalmente reactivo [PMBOK 2000] Auditorias da Qualidade Processo de revisão de dados específicos em pontos chave do ciclo de vida do projecto Objectivo: identificar lições aprendidas que possam ser usadas para melhorar o desempenho deste projecto e de outros

172. Controlo da Qualidade Função técnica que envolve a monitoria de resultados específicos do projecto para determinar se estão conformes com os padrões da qualidade, e Identificar formas de eliminar causas de resultados insatisfatórios Deve ser realizada ao longo de todo o projecto A equipa de projecto deve possuir um conhecimento prático de controlo estatístico da qualidade, em especial Amostragem Probabilidade de modo a poderem avaliar cabalmente os outputs do controlo da qualidade

173. Controlo da Qualidade Inputs Resultados do trabalho Plano de Gestão da Qualidade Ferramentas e Técnicas Inspecções e revisões (peer reviews) Testes Gráficos de controlo Diagramas de Pareto Análise de tendências Outputs Melhorias na qualidade Decisões de aceitação Ajustamentos de processos Trabalhos adicionais de correcção (rework)

174. Controlo da Qualidade – Técnicas Inspecções Incluem actividades como Medir Examinar Testar levadas a cabo para determinar se os resultados estão conformes com os requisitos Podem ser conduzidas em qualquer nível Podem inspeccionar-se os resultados de uma única actividade Pode inspeccionar-se o produto final do projecto Conhecidas também como Reviews/Product Reviews Walkthroughs Auditorias

175. Controlo da Qualidade – Técnicas Gráficos de controlo Gráficos dos resultados de um processo, ao longo do tempo Usados para determinar se o processo está “sob controlo” São diferenças causadas por variações aleatórias, ou são eventos invulgares que estão a ocorrer e cujas causas devem ser identificadas? Usados para monitorar Variações de custos e prazos Volume e frequência de alterações ao âmbito Erros em documentos do projecto

176. Controlo da Qualidade – Técnicas Exemplo de Gráfico de Controlo

177. Controlo da Qualidade – Técnicas Diagramas de Pareto Histogramas, ordenados por frequência de ocorrência, que mostram quantos resultados foram gerados por tipo de categoria ou causa identificada A ordem de classificação é usada para guiar as acções correctivas Relacionam-se com a Lei de Pareto Um n.º relativamente pequeno de causas é responsável produz tipicamente a maioria dos problemas ou defeitos (princípio 80/20)

178. Controlo da Qualidade – Técnicas Exemplo de Diagrama de Pareto

179. Controlo da Qualidade – Técnicas Amostragem estatística Escolher parte de uma população de interesse, para inspecção Por exemplo, seleccionar 10 desenhos de engenharia de uma lista de 25 Se adequada, pode reduzir o custo do controlo da qualidade Análise de tendências Usar técnicas matemáticas para prever resultados futuros, com base em resultados históricos Usada com frequência para monitorar Desempenho técnico – quantos erros ou defeitos foram identificados, quantos permanecem por corrigir Desempenho do custo e do prazo – quantas actividades com variâncias significativas foram concluídas por período

180. Controlo de Alterações ao Projecto Gestão de Projectos

181. Objectivos da Gestão de Alterações À medida que um projecto progride ao longo de várias fases do processo, os custos das alterações podem crescer muito O controlo de alterações é uma técnica para revisão e aprovação formal de alterações ao projecto através de um processo ordenado Devidamente implementado, o controlo de alterações dá Níveis adequados de revisão e aprovação de alterações Um ponto focal para quem procura efectuar alterações Um ponto de entrada único para as alterações aprovadas

182. Objectivos da Gestão de Alterações Garantir que, para qualquer alteração proposta o respectivo impacto é devidamente considerado e avaliado a sua incorporação no sistema é controlada e documentada Qualquer Sistema de Gestão de Alterações deve ser capaz De prevenir alterações não autorizadas De prevenir possíveis danos de qualquer alteração De garantir a avaliação completa do impacto da alteração, antes de esta ser aprovada De incorporar as alterações de um modo planeado e controlado

183. Estabelecer Procedimentos As regras para o controlo das alterações devem ser estabelecidas no início do projecto encaradas como uma parte do modelo e disciplina do projecto É da responsabilidade do Chefe de Projecto usar procedimentos standard (se existirem) construir sobre técnicas já testadas é mais rápido ajuda a fazer comparações entre projectos garantir que são acordados por todas as partes envolvidas

184. Estabelecer Procedimentos Estabelecer QUEM tem autoridade para autorizar alterações O PROCESSO que conduz à aprovação / rejeição das alterações Tipicamente a aprovação é dada pelo Comité de Controlo do Projecto pelo Comité de Controlo de Alterações pelo Director de 1º nível do utilizador/cliente A decisão final é de carácter empresarial, não técnico

185. Âmbito e Impacto Necessidade da alteração Prioridade para o negócio Benefícios da alteração no negócio Impacto no negócio, se a alteração não for implementada Custo da alteração Efeito da alteração no desempenho do sistema Efeito da alteração no prazo do projecto Impacto em outros sistemas Impacto em outros projectos Risco associado à alteração

186. Âmbito e Impacto Âmbito/Contexto do Pedido de Alteração ao Sistema Antecedentes do pedido Motivos do pedido Prioridade em termos empresariais Benefícios e Inconvenientes da alteração Quantificados e expressos em termos de Desempenho empresarial Redução de custos Redução dos riscos

187. Âmbito e Impacto Impacto nos recursos Esforço necessário para desenvolver a alteração Refazer outros trabalhos Impacto em outras partes do sistema Testes da alteração Implementar a alteração Documentar a alteração Outros recursos envolvidos Abordagem cautelosa e precisa

188. Âmbito e Impacto Impacto no desempenho Não é fácil de prever Obter uma indicação das possíveis implicações Pedir conselho de peritos Impacto em outras áreas Directa ou indirectamente (interface alterado, por exemplo) Tempo extra tem efeito sobre outros projectos Incluir benefícios perdidos / custos de oportunidade

189. Autorização das Alterações Quem autoriza? Estabelecer uma estrutura adequada, investida de autoridade Representantes de todas as partes envolvidas Comité de Controlo do Projecto Comité de Controlo de Alterações Uma pessoa (Chefe de Projecto ?)

190. Autorização das Alterações Estabelecer um modelo formal, antes do arranque do projecto Conjunto de critérios para revisão de cada P.A.S. Prioridade empresarial mínima Máximo custo e tempo Data a partir da qual não há mais nenhum P.A.S. N.º máximo de alterações Nível máximo de impacto neste sistema, ou noutros Estabelecer mecanismo para decidir prioridades e distinção entre importante e urgente

191. Autorização das Alterações Estabelecer esquema de classificação para urgências Após ponderação de todos os factores, o Comité toma uma decisão Aceita a alteração Rejeita a alteração Pede mais informação Adia a decisão

192. Autorização das Alterações Quando fazer É uma carga muito pesada rever cada P.A.S. que é produzido Não podem ficar pendentes até ao fim do projecto Orientação geral Projectos de > 6 meses – rever os PAS numa base mensal Projectos mais curtos – rever os PAS numa base semanal Projectos muito curtos (< 1 mês) – rever à medida que aparecem Agrupar pedidos dá tempo para “assentar a poeira” e permite combinar alterações Estabelecer um “atalho” para pedidos realmente urgentes

193. Implementação Uma vez aprovado um P.A.S. tem de ser gerida a respectiva implementação Ênfase ligeiramente diferente do resto do projecto Controlo do impacto deste novo trabalho sobre o actual Usar o diagrama de rede do projecto para identificar dependências e consequências Estabelecer um dossier separado, para as alterações Cada P.A.S. é registado, avaliado e controlado Modelo de P.A.S.

194. P.A.S. – Ficheiro de Registo

195. Monitorização e Controlo do Projecto Gestão de Projectos

196. Enquadramento O trabalho do projecto iniciou-se e o chefe de projecto quer assegurar que este está a progredir conforme planeado São instituídos um certo número de relatórios desenhados de modo a mostrarem a coerência entre o realizado e o plano, e a indicarem o modo de corrigir os desvios face a esse plano

197. Enquadramento A primeira questão que o chefe de projecto deve considerar é a profundidade do controlo que quer manter através dos relatórios que exige Antes do progresso do projecto poder ser registado pela primeira vez, deve ser constituída e registada uma baseline do projecto, a qual permitirá observar as alterações efectuadas ao plano original

198. Enquadramento Um projecto é um sistema Enquanto tal, pode sair do equilíbrio, havendo por isso necessidade de estabelecer um plano para o recuperar Quanto mais o chefe de projecto esperar para executar o plano de correcção, mais tempo necessitará o sistema para readquirir o equilíbrio Os controlos devem ser desenhados com o objectivo de descobrir, o mais cedo possível, situações de desequilíbrio e colocar rapidamente em acção planos de recuperação

199. Objectivos dos Controlos Monitorização do progresso Sistema de relatórios periódicos – pelo menos cada duas semanas, embora o ideal seja semanalmente – que identifiquem a situação de todas as actividades cujo trabalho está planeado executar desde o último relatório de progresso Estes relatórios resumem o progresso para o período corrente, bem como o progresso acumulado para todo o projecto

200. Objectivos dos Controlos Detecção de desvios face ao plano Os relatórios de desvios constituem uma excelente ferramenta para avaliar rapidamente a saúde do projecto Para detectar os desvios, o chefe de projecto precisa comparar o desempenho planeado com o desempenho real É muito importante proporcionar à gestão a informação estritamente necessária, num formato conciso, para que as decisões possam ser oportunas e bem informadas relatórios de excepções relatórios de desvios e relatórios gráficos constituem excelentes instrumentos de gestão

201. Objectivos dos Controlos Tomada de acções correctivas Para tomar acções correctivas, é necessário saber onde está o problema e dispor dessa informação a tempo de poder actuar Quando se detecta um desvio face ao plano, o passo seguinte é determinar se é necessária uma acção correctiva e depois agir em conformidade Em projectos complexos isto exige a análise de numerosos “what ifs” Quando ocorrem problemas num projecto, há atrasos consequentes em actividades e mesmo eventualmente no projecto global Para que o projecto regresse à situação do plano, pode haver necessidade de redistribuir recursos

202. Equilíbrio do Sistema de Controlo Existe um compromisso entre o nível de controlo que se pode alcançar e o nível de protecção que podemos obter contra as situações indesejáveis que podem surgir e afectar desfavoravelmente os níveis de risco aceites para o projecto O risco do projecto pode ser reduzido apenas pelo incremento do controlo Saber que o projecto está com problemas, a tempo de poder formular e implementar um plano de recuperação, é crítico para o sucesso do projecto

203. Equilíbrio do Sistema de Controlo A resposta à questão Quanto tempo é que aceito esperar antes de descobrir que existe um problema? pode fornecer uma pista sobre o nível de controlo a implementar O chefe de projecto necessita encontrar um equilíbrio entre a profundidade do sistema de controlo e o risco de resultados desfavoráveis

204. Equilíbrio do Sistema de Controlo Quanto mais controlos implementarmos, menor o risco do projecto e menor a probabilidade de o projecto vir a ter problemas No entanto, existe um ponto a partir do qual a rentabilidade decresce

205. Equilíbrio do Sistema de Controlo O controlo implica igualmente rigidez e estrutura, e ambas tendem a limitar a criatividade O chefe de projecto deve permitir aos membros da equipa alguma latitude para exercerem a sua individualidade O custo do controlo deve ser ponderado face ao valor de dar poder aos membros da equipa para serem proactivos – e, portanto, assumirem riscos

206. Relatórios de Progresso Sistema de relatórios que mantém o chefe de projecto informado acerca das múltiplas variáveis que descrevem o modo como o projecto se está a desenrolar em comparação com o plano Características: Informação de situação oportuna, completa e precisa Não adiciona muito trabalho burocrático, ao ponto de se tornar contraproducente Rapidamente acessível à equipa de projecto e à gestão de topo Facilmente compreendido por todos aqueles que têm uma necessidade de conhecer a situação do projecto

207. Relatórios de Progresso Tipos de Relatórios de Progresso Relatórios do período corrente Relatórios cumulativos Relatórios de excepção Relatórios spotlight

208. Relatórios de Progresso Relatórios do Período Corrente Cobrem apenas o período completado mais recentemente Relatam o progresso naquelas actividades que foram abertas ou calendarizadas para trabalho durante o período Devem evidenciar as actividades concluídas e os desvios entre datas de conclusão reais e planeadas Dois tipos Relatório semanal dos chefes de equipa para o chefe de projecto Relatório mensal do chefe de projecto para o cliente e a gestão de topo (em períodos críticos – testes – a frequência pode aumentar)

209. Relatórios de Progresso Exemplo de Relatório Semanal

210. Relatórios de Progresso Relatórios Cumulativos Contêm a história do projecto desde o início até ao final do corrente período São mais informativos que o Relatório do Período Corrente, pois mostram tendências no progresso do projecto Estes relatórios podem ser realizados ao nível da actividade ou ao nível do projecto

211. Relatórios de Progresso Relatórios de Excepção Relatam desvios ao plano Destinam-se tipicamente à gestão de topo – ou ao Comité de Controlo do Projecto – e são desenhados de modo a permitirem uma leitura e uma interpretação rápidas Informação distribuída por três colunas – o número planeado, o número real e o desvio, ou variação, entre ambos – e poderá ser apresentado segundo dois formatos Relatório numérico Representação gráfica dos dados numéricos Três colunas Valor planeado Valor real Desvio

212. Relatórios de Progresso Exemplo de Relatório de Excepção

213. Relatórios de Progresso Relatórios Spotlight Variante que pode ser usada em qualquer dos relatórios anteriores. É fundamental ser-se parcimonioso no processo de elaboração de relatórios Quando tudo parece estar a correr conforme planeado, coloca-se um traço grosso verde no canto superior direito da primeira página do relatório de situação do projecto Isto indicará aos gestores que tudo está a correr de acordo com o plano e que não necessitam ler o relatório detalhado anexo

214. Relatórios de Progresso Relatórios Spotlight Quando o projecto encontrou um problema – deslizamento do prazo, por exemplo – pode colocar-se um traço grosso amarelo no canto superior direito da primeira página do relatório de progresso do projecto O projecto não está a progredir de acordo com o planeado, mas que se implementou um plano de recuperação A primeira página pode conter um resumo do problema e do plano de recuperação

215. Relatórios de Progresso Relatórios Spotlight Um traço vermelho grosso no canto superior direito da primeira página do relatório de situação indica que o projecto corre sérios riscos O projecto encontrou um problema e não há um plano de recuperação ou mesmo uma recomendação para a gestão Os gestores de topo irão obviamente ler estes relatórios, porque eles assinalam um problema sério que está fora do controlo do chefe de projecto

216. Relatórios de Progresso Gráficos de Marcos do Projecto Os marcos (milestones) do projecto são eventos significativos na vida do projecto que se pretendem monitorar Esses eventos são actividades com duração zero e representam apenas uma certa condição existente no projecto Os eventos marco são planeados no projecto do mesmo modo que todas as actividades do projecto e possuem tipicamente relações FS com as actividades que lhes sucedem e com as que os precedem

217. Relatórios de Progresso. Detalhe Há sempre dúvidas e questões sobre qual o adequado nível de detalhe e a frequência da informação a incluir nos relatórios de progresso do projecto Quanto mais detalhe se incluir nos relatórios, mais provável é que alguém objecte ou encontre alguma razão para fazer micro-gestão do projecto Quem necessita de relatórios de progresso O chefe de equipa O chefe de projecto A gestão de topo

218. Relatórios de Progresso. Detalhe Chefe de Equipa Quer dispor da informação mais detalhada que puder É directamente responsável pela execução do trabalho Como gere os recursos que são usados para concluir o trabalho do projecto, vai querer saber o que aconteceu o que estava planeado acontecer quem fez o quê (ou não fez o quê) porque é que aconteceu da forma que aconteceu que problemas surgiram que soluções podem ser usadas e que alterações precisam ser efectuadas

219. Relatórios de Progresso. Detalhe Chefe de Projecto Preocupa-se com a informação sobre a situação de todas as actividades em que está a ser realizado trabalho durante o período do relatório Apresentam dados ao nível da actividade e mostram os efeitos no calendário do projecto Como estes relatórios possuem um elevado nível de detalhe, a sua distribuição para fora da equipa não é adequada Em muitas situações, pode tratar-se de relatórios “for project manager’s eyes only”

220. Relatórios de Progresso. Detalhe Gestores de Topo Os gestores de topo dispõem apenas de alguns minutos para rever qualquer relatório de projecto individual Recomenda-se o uso de uma estrutura de relatório de excepção gráfico para apresentar a situação dos projectos à gestão de topo Para projectos de grande dimensão, é mais eficaz apresentar relatórios ao nível dos marcos do projecto ou de grupos de actividade Relatórios com 1 página é o ideal Se o projecto está em apuros, juntar um plano de recuperação com uma página, que contenha uma curta narrativa do problema, soluções alternativas, a acção recomendada e quaisquer outros detalhes relevantes para o assunto a ser tratado

221. Reuniões de Project Review Duração limitada (Máx. = 1 H) Revisão da situação e não fóruns de discussão Dois tipos de reuniões Chefes de equipa + chefe de projecto (semanal) Chefe de projecto + gestão de topo / cliente Elaborar sempre acta da reunião Decisões Responsabilidades Datas

222. Tecnicamente, consideram-se várias abordagens para se produzir uma estimativa Podem-se considerar quatro abordagens principais Expert judgement (peritagem) Estimação bottom-up Estimação por analogia Macro-estimação (modelos paramétricos) A Estimação do ProjectoTécnicas de estimação

223. A fonte de informação é a descrição geral do projecto (e problema), num formato predominantemente qualitativo A “técnica” utilizada é o modelo mental do especialista, que recorre ao seu conhecimento pessoal acerca da lógica dos processos de trabalho e à sua experiência passada, para produzir a estimativa A Estimação do ProjectoExpert Judgement

224. A fonte de informação é um plano detalhado do projecto, o qual é decompõe (através da WBS) o projecto num conjunto de tarefas simples A técnica consiste em estimar por Expert Judgement os resultados destas tarefas elementares e calcular o todo a partir da sua soma A Estimação do ProjectoEstimação Bottom-Up

225. A fonte de informação é geralmente uma descrição geral do projecto num formato predominantemente qualitativo A “técnica” consiste em identificar o projecto passado mais semelhante ao novo projecto, acerca do qual se conhecem os resultados. Esses resultados constituem a base da estimativa. A Estimação do ProjectoEstimação por analogia

226. A fonte de informação é uma descrição quantitativa e qualitativa gerais acerca do projecto e do seu ambiente de implementação A técnica consiste em desenvolver fórmulas matemáticas de estimação, com base em análise de regressão, a partir de uma base de dados histórica de projectos – a memória da organização. A Estimação do ProjectoModelos paramétricos

227. Outros links de interesse: NASA : www.jsc.nasa.gov/bu2/PCEHHTML/pceh.htm ISPA : www.ispa-cost.org/PEIWeb/newbook.htm ISPA : www.ispa-cost.org/dodltr.htm SEI : www.sei.cmu.edu/ Modelos mais populares na indústria da TI: COCOMO (1980-2000) : www.softstarsystems.com KnowledgePLAN : www.spr.com SLIM : www.qsm.com A Estimação do Projecto Modelos paramétricos

228. A fonte de informação é uma descrição quantitativa e qualitativa acerca do projecto e do seu ambiente de implementação Esta descrição deverá especificar os seguintes elementos acerca do projecto: (1) tipo de projecto, (2) indicador da dimensão do âmbito, (3) níveis de factores qualitativas (e.g. complexidade) Macro-Estimação do ProjectoModelos paramétricos

229. Earned Value Management - EVM É uma técnica de controlo do projecto focalizada na análise de produtividade (performance e custo) e rapidez da execução do projecto (performance da duração). Métricas do EVM:

230. Earned Value Management

231. Earned Value Management

232. Earned Value Management – As métricas e os indicadores de performance do método EVM

233. Earned Value Management – implemantação do processo

234. Earned Value Management

235. Earned Value Management - Exemplo

236. Variâncias do EVM As variâncias no EVM permitem identificar o desvio existente entre o custo real e o custo do trabalho realmente realizado (CV) e o valor do trabalho realizado com o valor planeado (SV). CV – (BCWP – ACWP) SV – (BCWP - BCWS) CV = 300 – 450 = -150€ SV = 300 – 400 = -100€ O valor negativo destas variâncias indica que os custos estão a ser superiores do que previsto e está a acontecer um atraso no trabalho a efectuar.

237. Indicadores de custo e calendarização Os principais indicadores do EVM e os que nos dão uma informação mais directa são o SPI e CPI: CPI = BCWP / ACWP Se o projecto decorrer como planeado o CPI será igual a 1, se os custos forem superiores o CPI será menor do que 1, se os custos forem inferiores o CPI será maior do que 1. SPI = BCWP / BCWS Se o projecto decorrer como planeado o SPI será igual a 1, se o esforço estiver atrasado o SPI será menor do que 1, se o esforço estiver adiantado o SPI será maior do que 1.

238. Indicadores de custo e calendarização Analisando o exemplo anterior, pode-se concluir que: CPI = 300 / 450 = 0,67 SPI = 300 / 400 = 0,75 Pelo CPI pode-se concluir que por cada 1 euro gasto, está-se a ter um retorno de 0,67€, o que é um mau indicador.