Planejamento - 1. Plano gerenciamento do projeto Coletar Requisitos Definição do escopo Criação da EAP. Mauricio Lyra, PMP

Transcrição

1 Planejamento - 1 Plano gerenciamento do projeto Coletar Requisitos Definição do escopo Criação da EAP 1

2 PROCESSOS DE PLANEJAMENTO Define e refina os objetivos e planeja as ações necessárias para alcançar os objetivos e o escopo definido para o projeto 1. Desenvolver plano de gerenciamento do projeto 2. Coletar requisitos 3. Descrição do escopo do projeto 4. Criação da EAP 5. Definição das atividades 6. Sequenciamento das atividades 7. Estimativa de recursos das atividades 8. Estimativa de duração das atividades 9. Desenvolvimento do cronograma 10. Estimativa de custos 11. Determinar Orçamento do projeto 12. Planejamento da qualidade 13. Desenvolver Plano de RH 14. Planejamento da comunicação 15. Planejamento das aquisições 16. Planejamento do gerenciamento do risco 17. Identificação dos riscos 18. Executar Análise qualitativa dos riscos 19. Executar Análise quantitativa dos riscos 20. Planejamento da resposta a riscos A equipe de gerenciamento de projetos usa o Grupo de processos de planejamento e seus processos constituintes e interações para planejar e gerenciar um projeto bem sucedido para a organização. O Grupo de processos de planejamento ajuda a coletar informações de muitas fontes, algumas delas mais completas e confiáveis que outras. Os processos de planejamento desenvolvem o plano de gerenciamento do projeto. Esses processos também identificam, definem e amadurecem o escopo do projeto, o custo do projeto e agendam as atividades do projeto que ocorrem dentro dele. À medida que forem descobertas novas informações sobre o projeto, as dependências, os requisitos, os riscos, as oportunidades, as premissas e as restrições adicionais serão identificados ou resolvidos. A natureza multidimensional do gerenciamento de projetos gera loops de feedback repetidos para análises adicionais. Conforme mais informações ou características do projeto são coletadas e entendidas, podem ser necessárias ações subseqüentes. Mudanças significativas que venham a ocorrer durante todo o ciclo de vida do projeto irão provocar uma necessidade de reexaminar um ou mais processos de planejamento e, possivelmente, alguns processos de iniciação. Durante o planejamento do projeto, a equipe do projeto deve envolver todas as partes interessadas adequadas, dependendo da influência delas no projeto e nos seus resultados. A equipe do projeto deve usar as partes interessadas no planejamento do projeto, pois elas possuem habilidades e conhecimento que podem ser aproveitados no desenvolvimento do plano de gerenciamento do projeto e em quaisquer planos auxiliares. A equipe do projeto deve criar um ambiente no qual as partes interessadas possam contribuir de forma adequada. 2

3 4.2 Desenvolver Plano de Gerenciamento do Projeto Plano de gerenciamento do projeto O plano de gerenciamento do projeto integra e consolida todos os planos de gerenciamento auxiliares e linhas de base dos processos de planejamento, incluindo, mas não estando limitado a: O ciclo de vida selecionado para o projeto e os processos que serão aplicados a cada fase; Resultados das adequações feitas pela equipe de gerenciamento do projeto como a seguir: Processos de gerenciamento de projeto selecionados pela equipe de gerenciamento do projeto, Nível de implementação de cada processo selecionado, Descrições das ferramentas e técnicas a serem usadas para efetuar aqueles processos, e Como os processos selecionados serão utilizados para gerenciar o projeto específico, inclusive as dependências e interações entre esses processos, e as entradas e saídas essenciais. Como o trabalho será executado para completar os objetivos do projeto; Um plano de gerenciamento de mudanças que documenta como as mudanças serão monitoradas e controladas; Um plano de gerenciamento de configuração que documenta como o gerenciamento de configuração será realizado; Como a integridade das linhas de base da medição do desempenho será mantida; Necessidades e técnicas para comunicação entre as partes interessadas e Revisões chave de gerenciamento do conteúdo, abrangência e melhor momento para facilitar o tratamento de questões em aberto e decisões pendentes. O plano de gerenciamento do projeto pode ser em nível resumido ou detalhado e pode ser composto de um ou mais planos auxiliares. Cada plano auxiliar é detalhado até o ponto requisitado pelo específico projeto. Uma vez que o plano de gerenciamento tenha sido estabelecido, somente pode ser modificado quando uma solicitação de mudança é gerada e aprovada através do processo Realizar o controle integrado de mudanças. As linhas de base incluem, mas não estão limitadas a: Linha de base do cronograma; Linha de base do desempenho de custos e Linha de base do escopo. Os planos auxiliares incluem, mas não estão limitados, a: Gerenciamento do escopo; Gerenciamento dos requisitos; Gerenciamento do cronograma; Gerenciamento dos custos; Gerenciamento da qualidade; Plano de melhorias no processo; Gerenciamento dos recursos humanos; Gerenciamento das comunicações; Gerenciamento dos riscos Gerenciamento das aquisições. Frequentemente o escopo, o cronograma e a linha de base de custos serão combinados numa linha de base de medição de desempenho que é usada como uma linha de base geral do projeto com a qual o desempenho integrado pode ser comparado. A linha de base de medição de desempenho é usada para medições de valores agregados. 3

4 4.2 Desenvolver Plano de Gerenciamento do Projeto Desenvolver o plano de gerenciamento do projeto é o processo de documentação das ações necessárias para definir, preparar, integrar e coordenar todos os planos auxiliares. O plano de gerenciamento do projeto define como o mesmo é executado, monitorado e controlado e encerrado. O conteúdo do plano de gerenciamento do projeto variará dependendo da área de aplicação e complexidade do mesmo. O plano de gerenciamento é desenvolvido através de uma série de processos integrados até o encerramento do projeto. Esse processo resulta num plano de gerenciamento do projeto que é progressivamente elaborado através de atualizações, controladas e aprovadas pelo processo Realizar o controle integrado de mudanças 4

5 Plano de gerenciamento do projeto Plano de gerenciamento do projeto inclui: Quais processos do Gerenciamento de projetos serão selecionados pela equipe; Nível de implementação de cada processo; Descrição das ferramentas e técnicas a serem utilizadas em cada processo; Como os processos serão usados para gerenciar o projeto; Como o trabalho será realizado para atender aos objetivos do projeto; Como as mudanças serão monitoradas; Como o gerenciamento da configuração será feita; Como a integridade da linha de base será mantida e utilizada; A necessidade e as técnicas de comunicação com as partes interessadas; Clico de vida e fases do projeto; 5

6 5.1 Coletar Requisitos 1 Documentação dos requisitos A documentação descreve como os requisitos individuais atendem às necessidades do negócio para o projeto. Esses podem começar em um alto nível e progressivamente se tornar mais detalhados conforme mais detalhes são conhecidos. Antes das linhas de base serem estabelecidas, os requisitos devem ser não-ambíguos (mensuráveis e passíveis de testes), investigáveis, completos, consistentes e aceitáveis para as principais partes interessadas. O formato de um documento de requisitos pode variar de uma simples lista categorizada por partes interessadas e prioridades a formas mais elaboradas contendo um resumo executivo, descrições detalhadas e anexos. Os componentes da documentação podem incluir, mas não estão limitados a: A necessidade do negócio ou oportunidade a ser aproveitada, descrevendo as limitações da situação atual e por que o projeto foi empreendido; Objetivos do negócio e do projeto para permitir rastreamento; Requisitos funcionais descrevendo processos de negócio, informações e interação com o produto de forma apropriada a ser documentada textualmente numa lista de requisitos, em modelos ou ambos; Requisitos não funcionais, tais como nível de serviço, desempenho, cuidados, segurança, atendimento a leis e regulamentos, suportabilidade, retenção/descarte, etc.; Requisitos de qualidade; Critérios de aceitação; Regras de negócio declarando os princípios diretrizes da organização; Impactos em outras áreas organizacionais tais como a central de atendimento, força de vendas, áreas de tecnologia; Impactos em outras entidades internas ou externas à organização; Requisitos de suporte e treinamento e Premissas e restrições dos requisitos. 2 Plano de gerenciamento dos requisitos O plano de gerenciamento dos requisitos documenta como os mesmos serão analisados, documentados e gerenciados do início ao fim do projeto. A relação fase a fase influencia fortemente como os requisitos são gerenciados. O gerente de projetos deve escolher a relação mais efetiva para o projeto e documentar essa abordagem no plano de gerenciamento dos requisitos. Muitos dos documentos do mesmo são baseados nessa relação. Os componentes do plano de gerenciamento dos requisitos podem incluir, mas não estão limitados a: Como as atividades dos requisitos serão planejadas, rastreadas e relatadas; Atividades de gerenciamento da configuração tais como: de que modo as mudanças dos requisitos do produto, serviço ou resultado serão iniciadas, como os impactos serão analisados, como serão rastreados, monitorados e relatados, assim como os níveis de autorização necessários para aprovar tais mudanças; Processo de priorização dos requisitos; Métricas do produto que serão usadas e os argumentos que justificam usá-las e Estrutura de rastreabilidade, ou seja, que atributos dos requisitos serão captados na matriz de rastreabilidade e a que outros documentos de requisitos do projeto estarão ligados. 3 Matriz de rastreabilidade de requisitos. Uma tabela que liga os requisitos às suas origens e os rastreia durante todo o ciclo de vida do projeto. A utilização de uma matriz de rastreabilidade ajuda a garantir que cada requisito adiciona valor de negócio através da sua ligação aos objetivos de negócio e aos objetivos do projeto. Fornece um meio de rastreamento do início ao fim do ciclo de vida do projeto, ajudando a garantir que os requisitos aprovados na documentação sejam entregues no final do projeto. Finalmente, fornece uma estrutura de gerenciamento das mudanças do escopo do produto. Esse processo inclui, mas não está limitado ao delineamento dos: Requisitos das necessidades do negócio, oportunidades, metas e objetivos; Requisitos para os objetivos do projeto; Requisitos para as entregas do escopo/eap do projeto; Requisitos para o design do produto; Requisitos para o desenvolvimento do produto; Requisitos para o teste de estratégia e de cenários e Requisitos de alto nível para requisitos mais detalhados. Os atributos associados a cada requisito devem ser registrados na matriz de rastreabilidade. Esses auxiliam a definição de informações chave a respeito do requisito. Os atributos típicos usados na matriz podem incluir: um identificador único, uma descrição textual do requisito, os argumentos para a sua inclusão, proprietário, fonte, prioridade, versão, acompanhamento atual (tal como ativo, cancelado, adiado, adicionado, aprovado) e a data de conclusão. Atributos adicionais para garantir que o requisito satisfaça às partes interessadas podem incluir estabilidade, complexidade e critérios de aceitação. 6

7 5.1 Coletar Requisitos Processo de definir e documentar as funções e funcionalidades do projeto e do produto necessárias para atender às necessidades e expectativas das partes interessadas. O sucesso do projeto é diretamente influenciado pela atenção na captura e gerenciamento dos requisitos do projeto e do produto. Os requisitos incluem as necessidades quantificadas e documentadas, e as expectativas do patrocinador, cliente e outras partes interessadas. Estes requisitos precisam ser obtidos, analisados e registrados com detalhes suficientes para serem medidos uma vez que a execução do projeto se inicie. Coletar os requisitos é definir e gerenciar as expectativas do cliente. Estes requisitos se transformam na fundação da EAP. O planejamento do custo, cronograma e da qualidade são todos construídos com base nesses requisitos. O desenvolvimento dos requisitos começa com uma análise da informação contida no termo de abertura do projeto e no registro das partes interessadas. Muitas organizações os categorizam em requisitos do projeto e requisitos do produto. Os requisitos do projeto podem incluir os de negócios, de gerenciamento do projeto, de entrega, etc. Os requisitos do produto podem incluir informações sobre os requisitos técnicos, de segurança, de desempenho, etc. 7

8 5.2 Definir escopo 1. Declaração do escopo do projeto Descreve detalhadamente as entregas do projeto e o trabalho necessário para criar as mesmas. Fornece também um entendimento comum do escopo do projeto entre as partes interessadas. Pode conter exclusões explícitas do escopo que podem auxiliar o gerenciamento das expectativas das partes interessadas. Possibilita que a equipe desempenhe um planejamento mais detalhado, direciona o trabalho da mesma durante a execução e fornece a linha de base para avaliar se as solicitações de mudança ou trabalho adicional estão contidos no escopo ou são externos aos limites do projeto. O grau e o nível de detalhe no qual a declaração do escopo do projeto define o trabalho que será executado e o que será excluído pode determinar quão bem a equipe de gerenciamento do projeto pode controlar o escopo. A declaração detalhada inclui, seja diretamente ou por referência a outros documentos, o seguinte: Descrição do escopo do produto. Elabora progressivamente as características do produto, serviço ou resultado descritos no termo de abertura do projeto e na documentação dos requisitos. Critérios de aceitação do produto. Define o processo e critérios de aceitação de produtos, serviços ou resultados concluídos. Entregas do projeto. As entregas incluem tanto as saídas que compõem o produto ou serviço do projeto, como os resultados auxiliares, tais como relatórios e documentação de gerenciamento do projeto. As entregas podem ser descritas em nível conciso ou em grande detalhe. Exclusões do projeto. Identifica de modo geral o que é excluído do projeto. Declarar explicitamente o que está fora do escopo do projeto ajuda no gerenciamento das expectativas das partes interessadas. Restrições do projeto. Lista e descreve as restrições específicas associadas com o escopo que limitam as opções da equipe, por exemplo, um orçamento pré-definido ou quaisquer datas impostas ou marcos do cronograma comunicados pelo cliente ou organização executora. Quando um projeto é feito sob contrato, as cláusulas contratuais geralmente serão restrições. Informações sobre as restrições podem ser listadas na declaração do escopo do projeto ou em um registro separado. Premissas do projeto. Lista e descreve as premissas específicas do projeto associadas com o escopo e o impacto potencial dessas premissas se forem provadas falsas. As equipes de projetos frequentemente identificam, documentam e validam as premissas como parte do seu processo de planejamento. Informações sobre as premissas podem ser listadas na declaração do escopo do projeto ou em um registro separado. 8

9 5.2 Definir escopo Definir o escopo é processo de desenvolvimento de uma descrição detalhada do projeto e do produto. A preparação detalhada da declaração do escopo é crítica para o sucesso e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto. Durante o planejamento, o escopo é definido e descrito com maior especificidade conforme as informações a respeito do projeto são conhecidas. Os riscos existentes, premissas e restrições são analisados para verificar sua integridade; riscos adicionais, premissas e restrições são adicionados conforme necessário. 9

10 5.3 Criar a EAP 1 EAP A EAP é uma decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, com cada nível descendente da EAP representando uma definição gradualmente mais detalhada do trabalho do projeto. É finalizada pela determinação de contas de controle para os pacotes de trabalho e por um identificador exclusivo de um código de contas. Esses identificadores produzem uma estrutura para a sumarização hierárquica de custos, cronograma e informações sobre recursos. Uma conta de controle é um ponto de controle do gerenciamento onde o escopo, custo e cronograma são integrados e comparados ao valor agregado para uma medição do desempenho. Essas contas são localizadas em pontos de gerenciamento selecionados na EAP. Cada uma pode incluir um ou mais pacotes de trabalho, mas cada um deles tem que estar associado a somente uma conta de controle. 2 Dicionário da EAP O dicionário da EAP é um documento gerado pelo processo Criar a EAP que a suporta. Fornece descrições mais detalhadas dos componentes da EAP, inclusive dos pacotes de trabalho e contas de controle. As informações incluem, mas não estão limitadas a: Código de identificador da conta; Descrição do trabalho; Organização responsável pela execução; Lista de marcos do cronograma; Atividades do cronograma associadas; Recursos necessários; Estimativa de custos; Requisitos de qualidade; Critérios de aceitação; Referências técnicas e Informações do contrato. 3 Linha de base do escopo A linha de base do escopo é um componente do plano de gerenciamento do projeto. Os componentes da mesma incluem: Declaração do escopo do projeto. Inclui a descrição do escopo do produto, as entregas do projeto e define os critérios de aceitação do usuário em relação ao produto. EAP. Define cada entrega e a decomposição das entregas em pacotes de trabalho. Dicionário da EAP. Possui uma descrição detalhada do trabalho e documentação técnica para cada elemento da EAP. 10

11 5.3 Criar a EAP Criar a EAP é o processo de subdivisão das entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil. A estrutura analítica do projeto (EAP) é uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela equipe para atingir os objetivos do projeto e criar as entregas requisitadas, sendo que cada nível descendente da EAP representa uma definição gradualmente mais detalhada da definição do trabalho do projeto. A EAP organiza e define o escopo total e representa o trabalho especificado na atual declaração do escopo do projeto aprovada. O trabalho planejado é contido dentro dos componentes de nível mais baixo da EAP, que são chamados de pacotes de trabalho. Um pacote de trabalho pode ser agendado, ter seu custo estimado, monitorado e controlado. No contexto da EAP, o trabalho se refere a produtos de trabalho ou entregas que são o resultado do esforço e não o próprio esforço. Para informações específicas a respeito das estruturas analíticas de projetos, consulte The Practice Standard for Work Breakdown Structures Segunda Edição 11

12 EAP Estrutura Analítica do Projeto WBS Work Breakdown Structure EDT Estrutura de Decomposição do Trabalho Deve ser construída logo no início, e revisada ao longo do projeto; Representação do trabalho a ser realizado; Organizada em uma estrutura hierárquica; Deve ter foco nas entregas Ajuda a dar uma visão clara de todo o trabalho necessário para produzir o produto do projeto; Divide o trabalho em Pacotes de Trabalho; 1 Decomposição Decomposição é a subdivisão das entregas do projeto em componentes menores e mais gerenciáveis, até que as entregas do trabalho estejam definidas no nível de pacotes de trabalho. O nível de pacote de trabalho é o mais baixo na EAP, é o ponto onde o custo e a duração das atividades para o trabalho podem ser estimados e gerenciados com confiança. O nível de detalhe dos pacotes de trabalho variará com o tamanho e complexidade do projeto. A decomposição do trabalho completo do projeto em pacotes de trabalho geralmente envolve as seguintes atividades: Identificação e análise das entregas e seu trabalho relacionado; Estruturação e organização da EAP, Decomposição dos níveis mais altos da EAP em componentes detalhados em menor nível; Desenvolvimento e designação de códigos de identificação aos componentes da EAP e Verificação de que o grau de decomposição do trabalho é necessário e suficiente. A estrutura da EAP pode ser criada de várias maneiras, tais como: Usando fases do ciclo de vida do projeto como o primeiro nível de decomposição, com o produto e entregas inseridos no segundo nível, Usando entregas principais como o primeiro nível de decomposição e Usando subprojetos que podem ser desenvolvidos por organizações externas à equipe do projeto, tal como um trabalho contratado. O fornecedor então desenvolve a estrutura de suporte da decomposição do trabalho contratado como parte do trabalho. 12

13 PACOTE DE TRABALHO As entregas que compõem o nível mais baixo da EAP são os Pacotes detrabalho que serão subdivididos em atividades Deve possuir um único responsável; Atender o critério SMART S Específico M Mensurável A Acordado R Realístico T limitado no Tempo A decomposição dos componentes do nível mais alto da EAP requer a subdivisão do trabalho para cada uma das entregas ou subprojetos em seus componentes fundamentais, onde representam produtos, serviços ou resultados verificáveis. A EAP pode ser estruturada como uma lista sumarizada, uma estrutura analítica organizacional, um diagrama de espinha de peixe ou outro método. A verificação da precisão da decomposição requer a determinação de que os componentes do nível mais baixo da EAP sejam necessários e suficientes para a conclusão das entregas do nível mais alto correspondentes. Entregas diferentes podem ter níveis diferentes de decomposição. Para se chegar a um pacote de trabalho, o trabalho de algumas entregas precisa ser decomposto somente até o próximo nível, enquanto para outras são necessários níveis adicionais de decomposição. Conforme o trabalho é decomposto em níveis maiores de detalhe, a habilidade de planejá-lo, gerenciá-lo e controlá-lo aumenta. Contudo, uma decomposição excessiva pode resultar num esforço de gerenciamento improdutivo, uso ineficiente de recursos e na diminuição da eficiência durante a execução do trabalho. A decomposição pode não ser possível para uma entrega ou subprojeto que serão efetuados num futuro distante. A equipe de gerenciamento do projeto normalmente espera até que a entrega ou subprojeto sejam clarificados para que os detalhes da EAP possam ser desenvolvidos. Às vezes, essa técnica é chamada de planejamento em ondas sucessivas. A EAP representa todo produto e trabalho do projeto, inclusive o trabalho de gerenciamento do mesmo. Todo o trabalho nos níveis mais baixos tem que escalar aos níveis mais altos para que nada seja omitido e nenhum trabalho extra seja executado. Ocasionalmente, isso é chamado da regra dos 100%. O PMI Practice Standard for Work Breakdown Structures fornece diretrizes para a geração, desenvolvimento e aplicação de estruturas analíticas de projetos. Esse padrão contém exemplos de modelos de EAP específicos de setores econômicos e que podem ser ajustados aos projetos de uma área de aplicação distinta. 13

14 Dicas para construção da EAP 1. Todos os produtos e subprodutos devem estar explicitamente incluídos na EAP; 2. Os produtos e subprodutos devem ser claramente definidos no dicionário da EAP; 3. Os subprodutos devem ser decompostos até um nível de detalhe (pacote de trabalho) que permita o planejamento e controle do trabalho (regra do 8 ou 80); 4. A decomposição não deve ser demasiada de forma a que o custo do planejamento e controle não traga o benefício correspondente; 5. Cada pacote de trabalho da EAP deve representar uma entrega tangível e verificável; 6. Cada elemento da EAP deve contribuir para o subproduto do elemento pai ao qual está subordinado; 7. A soma dos subprodutos dos elementos filho deve corresponder ao elemento do produto pai; 8. Um elemento da EAP não pode ter apenas um filho; 9. Um elemento filho não pode ter mais de um pai; 10. Os subprodutos necessários ao gerenciamento (planos, relatórios,etc) devem ser incluídos na EAP 14

15 Exemplos de EAP 15

16 Exemplos de EAP 16

17 Exemplos de EAP 17

18 18

19 Exemplos de EAP 1. Systems development 1.1 Requirements specifications Conduct information-gathering sessions Prepare logical data model Prepare logical process model 1.2 Physical design Prepare physical data model Prepare physical process model 1.3 Online system Prepare detailed design Program and unit test Document 1.4 Batch system Prepare detailed design Batch update facility Program and unit test Document Reporting system Program and unit test Document 19