Gerenciamento do escopo Gerenciamento do escopo Escopo pode ser definido como a soma dos produtos de um projeto, bem como a descrição de seus requisitos. O momento de definir o escopo é a hora em que o gerente de projeto e sua equipe se preocupam em armar o projeto para seu efetivo gerenciamento. A definição do escopo gera uma base de conhecimento a ser usada no decorrer das atividades de planejamento. O gerenciamento do escopo do projeto inclui os processos necessários para assegurar que o projeto inclui todo o trabalho necessário, e apenas o necessário, para terminar o projeto com sucesso. Se relaciona com a definição e controle do que está e do que não está incluso no projeto. 1
Gerenciamento do escopo A definição do escopo ajuda a evitar que as equipes do projeto percam tempo e recursos resolvendo problemas que fogem a sua alçada. Em projetos, o termo escopo pode se referir a: Escopo do produto características e funções que descrevem um produto, serviço ou resultado. Escopo do projeto o trabalho que precisa ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas. O escopo irá definir o trabalho que se será desenvolvido. Começando com a definição das atividades e sua sequência, passando pelos custos associados e os recursos necessários. Gerenciamento do escopo Fatores de insucesso de projetos: Gerentes de projeto inexperientes ou inadequadamente treinados Falha na identificação ou no gerenciamento de expectativas Liderança pobre em vários níveis Falha em identificar, documentar e acompanhar adequadamente requisitos e escopo Plano e processos de planejamento pobres Estimativas de esforço pobres Falta de alinhamentos cultural e ético Não-alinhamento entre a equipe do projeto e o negócio ou outra organização e o cliente Métodos inadequados ou mal empregados Comunicação inadequada, inclusive acompanhamento e relato de progresso 2
Gerenciamento do escopo Documentos que fazem parte do gerenciamento do escopo: Documentação de requisitos Declaração do escopo Registro de premissas e restrições Estrutura analítica do projeto (EAP) Dicionário da EAP Coleta de Requisitos A coleta de requisitos é o processo de definição e documentação das necessidades das partes interessadas para alcançar os objetivos do projeto. Incluem as necessidades quantificadas e documentadas, as expectativas do patrocinador, cliente e outras partes interessadas. Coletar requisitos é definir e gerenciar as expectativas do cliente. Exemplo de requisito: Melhorar a qualidade do produto em 20% com base no atual nível de atendimento Que o consumo da energia elétrica previsto seja 1,5% menor que o consumo do último ano Que os intervalos entre as manutenções periódicas sejam mantidos os mesmos do processo atual Todos os funcionários que deverão operar o novo processo deverão estar treinados antes do início da operação Os requisitos definem as funcionalidades e desempenho do produto que irá definir o esforço programado, se tornando o projeto que irá desenvolver e entregar o produto. 3
Coleta de requisitos Ferramentas para a coleta de requisitos: Entrevistas formal ou informal, individual ou em grupo Dinâmicas de grupo discussão interativa Oficinas reunião para definir os requisitos Técnicas de criatividade em grupo Brainstorming criação de idéias Delphi respostas de especialistas durante várias etapas Mapas mentais relações entre atributos Diagrama de afinidades organiza um grande número de ideias em grupos para análise e revisão Técnicas de tomada de decisão em grupo Unanimidade todos concordam Maioria suporte de mais de 50% do grupo Pluralidade o maior bloco do grupo decide, mesmo que a maioria não seja alcançada Ditadura um indivíduo decide pelo grupo Questionários e pesquisas Observações Protótipo 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 da 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 formado 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. 4
Documentação dos requisitos 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 regulações, 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; Premissas e restrições dos requisitos. Elementos da documentação dos requisitos Elemento do documento Parte interessada Requisito Categoria Prioridade Critérios de aceitação Descrição Nome da parte interessada. Se não houver um nome, você poderá substituir por um cargo ou empresa até ter mais informações. A condição ou capacidade que deve ser atendida pelo projeto ou estar presente no produto, serviço ou resultado para atender uma necessidade ou expectativa de uma das partes interessadas. A categoria do requisito O grupo de prioridades. Por exemplo, nível 1, nível 2 etc. ou necessário, esperado ou desejável Os critérios que devem ser atendidos para a parte interessada provar que o requisito foi atendido. 5
Declaração do escopo A declaração de escopo visa elaborar e documentar, progressivamente, todo o escopo do projeto para atingir seus objetivos. Definir o escopo é o 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 adicionados conforme necessário. O grau e 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. Declaração do escopo Ferramentas e técnicas para definir o escopo: Opinião especializada Aplicada a qualquer detalhe técnico, pode ser oferecida por qualquer grupo ou pessoa com conhecimento ou treinamento especializado e está disponível a partir de diversas fontes, inclusive outras unidades dentro da empresa, consultores, partes interessadas, associações profissionais e técnicas, setores econômicos e outros especialistas no assunto. Análise de produto Inclui técnicas como a decomposição do produto, análise de sistemas, análise de requisitos, engenharia de sistemas, engenharia de valor e análise de valor. Identificação de alternativas Usada para gerar diferentes métodos para se executar e desempenhar o trabalho do projeto. Ex: brainstorming. Oficinas 6
Declaração do escopo A declaração detalhada inclui, seja diretamente ou por referência a outros documentos, o seguinte: Descrição do escopo do produto características do produto, serviço ou resultado descrito no termo de abertura do projeto 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 incluem tanto as entradas quanto as saídas que compõem os produto ou serviço do projeto, como os resultados auxiliares, tais como relatórios e documentação de gerenciamento do projeto Exclusões do projeto identifica de modo geral o que é excluído do projeto. Declara 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, como um orçamento pré-definido ou datas impostas pelo cliente. Quando um projeto é feito sob contrato, as cláusulas contratuais geralmente são restrições. Premissas do projeto lista e descreve as premissas específicas do projeto associadas com o escopo e o impacto potencial destas se forem falsas. Elementos de uma declaração de escopo do projeto Elemento do documento Declaração do escopo do projeto/produto Entregas do projeto Critérios de aceitação do projeto/produto Exclusões do projeto Restrições do projeto Premissas do projeto Descrição Documentar as características do produto, serviço ou resultado. As informações devem ser progressivamente elaboradas a partir da descrição do projeto no termo de abertura do projeto e os requisitos na documentação dos requisitos. Identificar qualquer capacidade, produto ou resultado únicos e verificáveis para realizar um serviço que deve ser produzido para concluir um processo, fase ou projeto. As entregas incluem relatórios e documentação do gerenciamento do projeto. Documentar os critérios que precisam ser atendidos para que uma das partes interessadas aceite uma entrega. Os critérios de aceitação podem ser desenvolvidos para todo o projeto ou para cada componente do projeto. Definir claramente o que é considerado fora do escopo do projeto. Restrições são limitações. Restrições que podem afetar o projeto incluem orçamento fixo, prazos apertados ou tecnologias específicas. Documentar as premissas sobre entregas, recursos, estimativas e qualquer outro aspecto do projeto que a equipe, tem como verdadeiro, real ou certo, mas não validado. 7
Registro de premissas e restrições O registro de premissas e restrições pode ser incorporado à declaração do escopo do projeto ou pode ser um documento independente. As premissas são fatores que no processo de planejamento são considerados verdadeiros, reais ou certos, sem provas ou demonstração. Esse registro é um documento dinâmico uma vez que as premissas são progressivamente elaboradas ao longo do projeto. Com o tempo elas são validadas e não mais há premissas. As premissas podem vir de qualquer documento do projeto e podem ser determinadas pela equipe do projeto. As restrições são fatores limitantes que afetam a execução do projeto ou processo. Restrições típicas incluem um orçamento predeterminado ou marcos fixos para as entregas. As restrições geralmente são documentadas no termo de abertura do projeto e são determinadas pelo cliente, patrocinador ou agências reguladoras. Elementos de um registro de premissas e restrições Elemento do documento ID Categoria Premissa/ restrição Parte responsável Data de entrega Ações Status Comentários Descrição Identificador. Categoria da premissa. As coisas que são consideradas verdadeiras, reais ou certas, mas sem provas ou demonstração, ou uma limitação ou restrição que afeta a execução do projeto ou processo. A pessoa que tem a tarefa de validá-la deve verificar se a premissa é ou não verdadeira. A data em que a premissa precisa ser validada Ações que precisam ser tomadas a fim de validar as premissas O status atual da premissa, como ativo, pendente ou fechado Quaisquer informações adicionais sobre a premissa ou restrição 8
Estrutura analítica do projeto - EAP A EAP é usada para decompor todo o trabalho do projeto. Ela começa no nível do projeto e é dividida sucessivamente em níveis mais refinados de detalhe. O nível mais baixo é um pacote de trabalho. Representa uma entrega distinta que pode ser decomposta em atividades para produzir a entrega. As necessidades do projeto determinarão como a EAP é organizada. O segundo nível determina a organização da EAP. Algumas opções incluem a geografia, principais entregas, fases do ciclo de vida, subprojetos. A EAP deve ter um método para identificar a hierarquia, como uma estrutura numérica, pode ser mostrada como um organograma, um gráfico espinha de peixe ou uma estrutura de tópicos. É uma representação gráfica do escopo do projeto. Sua função principal é dividir o projeto em entregas menores e mais gerenciáveis. A EAP não necessita respeitar a ordem temporal, estas preocupações serão realizadas no gerenciamento do tempo Estrutura analítica do projeto - EAP Ferramenta/técnica: decomposição 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. Geralmente envolve as 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 Verificação de que o grau de decomposição do trabalho é necessário e suficiente 9
Estrutura analítica do projeto - EAP A EAP pode ser criada de várias maneiras: 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 primeiro nível de decomposição 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. 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 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 da decomposição. Exemplo de EAP com alguns ramais decompostos até o nível de pacotes de trabalho 10
Exemplo de uma EAP organizada por fases Exemplo de decomposição com entregas principais 11
Estrutura analítica do projeto - EAP Estrutura analítica do projeto - EAP 12
Estrutura analítica do projeto - EAP 1. Implantação de minipadaria 1.1 Definição do local 1.1.1 Estudo de campo para escolha do local 1.1.2 Relatório de viabilidade do local 1.1.3 Definição do local 1.2 Contratação 1.2.1 Redação de contrato 1.2.2 Assinatura de contrato 1.3 Treinamento 1.3.1 Plano de aula 1.3.2 Aula 1.3.3 Certificação Estrutura analítica do projeto - EAP Cont. Instalação de minipadaria 1.4 Transporte 1.4.1 Programação da entrega 1.4.2 Materiais entregues 1.5 Instalação 1.5.1 Freezer 1.5.2 Forno 1.5.3 Balcão 1.5.4 Luminoso 1.5.5 Testes de equipamentos 1.5.5.1 Plano de teste 1.5.5.2 Teste 1.5.5.3 Relatório de teste 13
Estrutura analítica do projeto - EAP Cont. Instalação de minipadaria 1.6 Fechamento 1.6.1 Relatório de correções do equipamento 1.6.2 Relatório de avaliação da performance do equipamento 1.6.3 Relatório de avaliação do atendimento e do produto acabado 1.6.4 Relatório de lições aprendidas na implantação 1.7 Gerenciamento de projeto (GP) Dicionário da EAP O dicionário da EAP dá suporte à EAP fornecendo detalhes sobre as contas de controle e pacotes de trabalho que ela contém. Pode fornecer informações detalhadas sobre cada pacote de trabalho ou informações de resumo no nível da conta de controle e dos pacotes de trabalho. É elaborado progressivamente à medida que os processos de planejamento avançam. 14
Elementos do dicionário da EAP Elemento do documento Nome do pacote de trabalho Código da conta Marcos Datas de entrega ID Atividade Recurso Horas de mão de obra Taxa de mão de obra Descrição Inserir uma breve descrição da entrega do pacote de trabalho a partir da EAP. Inserir o código da conta a partir da EAP. Listar todos os marcos associados ao pacote de trabalho. Listar as datas de entrega para os marcos associados com o pacote de trabalho. Inserir um identificador único de atividades, geralmente uma extensão do código de contas da EAP. Descrever a atividade a partir da lista de atividades ou cronograma. Identificar os recursos, geralmente a partir dos requisitos dos recursos. Inserir o trabalho total necessário Inserir a taxa de mão de obra, geralmente a partir das estimativas de custos. Elementos do dicionário da EAP Elemento do documento Mão de obra total Unidades de material Custo do material Total de material Custo total do pacote de trabalho Requisitos de qualidade Critérios de aceitação Informações técnicas Informações de acordos Descrição Multiplicar as horas de trabalho pela taxa de mão de obra. Inserir a quantidade de material necessário. Inserir o custo do material, geralmente a partir das estimativas de custo. Multiplicar as unidades de material pelo custo do material. Calcular a mão de obra, materiais e quaisquer outros custos associados com o pacote de trabalho. Documentar todos os requisitos de qualidade ou métricas associados ao pacote de trabalho. Descrever os critérios de aceitação para a entrega. Descrever ou referenciar quaisquer documentações ou requisitos técnicos necessários para completar o pacote de trabalho. Referenciais quaisquer contratos ou outros acordos que tenham um impacto sobre o pacote de trabalho. 15
Bibliografia Este material foi extraído de: XAVIER, Carlos M. S. Gerenciamento de projetos: como definir e controlar o escopo do projeto. 2 ed. São Paulo: Saraiva, 2009. PMBOK. Um guia do conhecimento em gerenciamento de projetos (guia PMBOK). 4 ed. Project Management Institute São Paulo: Saraiva, 2012. STACKPOLE, Cynthia. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Elsevier, 2013. MENEZES, Luís C. M. Gestão de Projetos. 3 ed. São Paulo: Atlas, 2009. CARVALHO, Marly M; RABECHINI JR, Roque. Fundamentos em gestão de projetos: construindo competências para gerenciar projetos. 3 ed. São Paulo: Atlas, 2011. KEELING, Ralph; BRANCO, Renato H. F. Gestão de projetos: uma abordagem global. 2 ed. São Paulo: Saraiva, 2012. 16