Gerenciamento de Escopo na Gestão de Projetos - PDF
Download "Gerenciamento de Escopo na Gestão de Projetos"
Vasco Lisboa de Andrade
1 Gerenciamento de Escopo na Gestão de Projetos Airton Eustaquio Braga Junior MBA Gestão de Projetos em Engenharia e Arquitetura Instituto de Pos-Graduação IPOG Goiania, GO, 02 de Setembro de 2013 Resumo O gerenciamento de Escopo é um dos mais importantes e primordiais no gerenciamento de projetos, este procedimento é responsável pela definição do projeto, incluindo a definição dos trabalhos necessários para concluir o projeto. O Escopo é utilizado como guia ou ponto de referencia para determinar o que está e o que não está incluído no projeto. Este é o foco do projeto. Este estudo apresenta uma descrição e metodologia do gerenciamento de escopo e quanto o mesmo influencia na gestão do projeto com todo. Conclui-se que um gerenciamento do escopo bem elaborado e executado é diretamente ligado ao sucesso do projeto. Palavras-chave: Escopo. Projeto. Gestão. 1. Introdução O trabalho aqui apresentado tem como objetivo, mostrar como é feito o Planejamento do Escopo. Primeiramente, é necessário entender o significado deste documento para a Gestão de Projetos. Assim sendo, o trabalho será iniciado pela definição do Escopo, seguindo as orientações dadas pelo PMBOK. Figura 1 Mapa mental das nove áreas do gerenciamento de projetos segundo o PMBOK Guide 4ª Edição Fonte: Vargas (2009) Existe uma integração entre todas as áreas do gerenciamento de projeto, uma depende da outra para formar o todo, conforme apresentado na figura 2.
2 Figura 2 Processo integrado de gerenciamento de projetos Fonte: Vargas (2009) A maioria dos projetos passa por um processo para determinar seu custo e valor. Eles são selecionados com base em diversas condições: oportunidade, necessidade, exigências do cliente, mudança de legislações, entre outros. O escopo do projeto deve ser criado para dar suporte à finalidade e à necessidade do projeto. O processo de seleção baseado no valor percebido normalmente é uma relação custo/benefício. Esse tipo de estudo é comparativo, e determina se o projeto trará benefícios ao ser. Para determinar qual é o escopo do projeto, existe muito planejamento do escopo. Para isso, tanto o gerente quanto a equipe precisam ter uma visão unificada sobre quais são os componentes do projeto, dos seus requisitos, da expectativa dos patrocinadores do projeto, e de onde o projeto se encaixa na necessidade de negócio destes patrocinadores. Ainda no desenvolvimento do trabalho, serão mostrados os templates que compõem o Escopo e a separação que é feita através do PMBOK. Será mostrado um modelo para Gerenciamento de Escopo, onde será analisada cada etapa que contém o plano. Ricardo Vargas dará total apoio na execução deste artigo, visto que será utilizado como embasamento o livro Manual Prático do Plano de Projeto 4ª Edição de De inicio, Vargas (2009) separa os documentos em mapas mentais, conforme demonstração do mapa mental para gerenciamento de escopo da figura 3. Figura 3 Mapa mental do Gerenciamento de Escopo Fonte: Vargas (2009) Na finalização do trabalho, será mostrada a importância do bom gerenciamento do escopo
3 como resultado no projeto. 2. Gerenciamento de Escopo O processo de gerenciamento de escopo tem como objetivo principal definir e controlar os trabalhos a serem realizados pelo projeto de modo a garantir que o produto, ou serviço, desejado seja obtido através da menor quantidade de trabalho possível, sem abandonar nenhuma premissa estabelecida no objetivo do projeto. O PMBOK subdivide o gerenciamento de escopo em cinco processos: Coletar os requisitos Definir o escopo Criar EAP (Estrutura Analítica de Projeto) Verificar o escopo Controlar o escopo Existem dois tipos de escopo: Escopo do Produto: Que são características e funções que descrevem um produto, serviço ou resultado. Escopo do Projeto: Diz respeito ao trabalho que deverá ser realizado para entregar um produto, serviço ou resultado com as características e funções especificadas. Para Vargas (2009) os processos de gerenciamento de escopo estão distribuídos da seguinte forma: Figura 4 Processo de gerenciamento de escopo distribuídos ao longo das fases do projeto Fonte: Vargas (2009) Ainda segundo Vargas (2009), o Gerenciamento do Escopo pode ser dado com o seguinte documento: Nome do Projeto Responsável pela elaboração do plano: Descritivo dos processos de gerenciamento de escopo (regras gerais)
4 Priorização das mudanças de escopo e respostas Gerenciamento das Configurações ou Configuration Mangement Freqüência da avaliação do escopo do projeto Freqüência de atualização do plano de gerenciamento de escopo Alocação Financeira das mudanças de escopo Nome do responsável pelo plano Fluxo de Gestão de Mudança Outros assuntos relacionados ao plano Principais eventos (marcos) do projeto: Registro de Alteração do Documento Data Modificado por Descrição da Mudança Aprovações Membro do Time Assinatura Data A Declaração do Escopo, segundo Vargas (2009), pode ser realizada através do documento a seguir: Nome do Projeto Gerente de Projeto Elaborador: Data: Escopo do Produto Produto Critérios de Aceitação Principais Entregas Projeto Exclusões (Fora do Escopo) Restrições Premissas
5 Fatores Críticos de Sucesso Fluxo de Gestão de Mudança Aprovações Membro do Time Assinatura Data 3. Coletar Requisitos Visa definir e documentar as características dos produtos e serviços do projeto que irão satisfazer as necessidades e as expectativas dos patrocinadores. São condições ou capacidades que devem ser supridas pelo produto, serviço ou resultado do projeto, para satisfazer um contrato, padrão, especificação ou outro documento formal. Este processo tem como proposito definir e documentar as funções e funcionalidades do projeto do produto necessárias para atender as expectativas das partes interessadas. Os requisitos são importantes para a fundamentação da Estrutura Analítica de Projetos (EAP). Os requisitos precisam ser: Definidos; Analisados; Reportados detalhadamente; Medidos (Aceitos); Controlados. Para coletar requisitos, também é necessário fazer o Termo de Abertura do Projeto TAP, que é um documento autorizando formalmente um projeto. Este identifica, designa e concede autoridade ao gerente de projeto. É emitido por um iniciador ou patrocinador do projeto. Dentro da coleta de requisitos, também deve conter a identificação das partes interessadas, estas podem fornecer informações detalhadas sobre requisitos do projeto e do produto. A coleta de requisitos pode ser feita através de entrevistas, grupos de foco, workshops/oficinas, técnicas criativas de grupo, técnicas de tomada de decisão em grupo, técnicas de questionamento e pesquisa, observações, protótipos. A coleta de requisitos gera o Plano de Gerenciamento dos Requisitos e a Matriz de Rastreabilidade de Requisitos. A documentação dos requisitos descreve como os requisitos individuais atendem às necessidades de negócio para o projeto. Este inclui, mas não se limita a: necessidade do negocio, objetivos de negócio e do projeto, requisitos funcionais e não funcionais, requisitos de qualidade e critérios de aceitação. A documentação dos requisitos não devem ser ambíguos, variando em uma simples lista categorizada por partes interessadas, prioridades, resumo executivo, descrições detalhadas e anexos. Segundo Vargas (2009), todos os requisitos do projeto (funcionais, não funcionais ou de qualidade) serão priorizadas em três diferentes níveis. Prioridade 1 (um) ou Essenciais São os requisitos essenciais do projeto. O acompanhamento e monitoramento desses requisitos estão diretamente relacionados com a natureza do próprio projeto. Sua não observância pode afetar de modo severo o resultado do projeto.
6 Prioridade 2 (dois) ou Desejáveis São os requisitos potencialmente benéficos para o projeto e seus interessados. Eles compõem o segundo nível mais elevado de importância, perdendo apenas para os requisitos essenciais. Prioridade 3 (três) ou Opcionais São requisitos que precisam ser registrados e acompanhados pelo projeto, no entanto não são vitais ou essenciais. Sua realização e observância são facultadas ao gerente te projetos e sua equipe. É o menor nível de prioridade de um requisito identificado. Abaixo dessa prioridade os requisitos passam a não ser nem documentados. Ainda segundo Vargas (2009), todos os requisitos principais do projeto serão controlados e rastreados através da Matriz de Rastreabilidade de Requisitos, a ser atualizada juntamente com a atualização da EAP e será apresentada para o comitê do projeto. O sistema de controle de mudanças será baseado em prioridades. É importante nesse tópico diferenciar a prioridade do requisito com a prioridade da mudança do requisito. A prioridade a prioridade apresentada no fluxo a seguir é a prioridade da mudança e não a prioridade do requisito propriamente dito. A figura 5 ilustra um exemplo deste fluxo.
7 Figura 5 Fluxo de prioridades de mudanças Fonte: Vargas (2009) Vargas (2009) sugere que as mudanças dos requisitos são classificadas em quatro níveis de prioridade: Prioridade 0 ( zero): Mudanças de prioridade zero requerem uma ação imediata por parte do gerente do projeto, que deve acionar imediatamente o patrocinador, uma vez que se trata de mudança urgente, de alto impacto no projeto e em outras áreas sobre as quais o gerente não tem autonomia. Prioridade 1 (um): Mudanças de prioridade um requerem uma ação imediata por parte do gerente do projeto, independente das reuniões de controle previstas devido a urgência, acionando imediatamente o patrocinador no caso de necessidade de autorizações financeiras fora da alçada do gerente. Prioridade 2 (dois): Mudanças de prioridade dois requerem um planejamento da ação através de terceiros ou de equipes que, a princípio, tenham disponibilidade, uma vez que agregam valor ao sucesso do projeto e são urgentes, porém não têm impacto significativo nos custos e nos prazos do projeto. Prioridade 3 (três): Mudanças de prioridade três podem ser implementadas por terem influência no sucesso do projeto, porém não requerem uma ação imediata por não serem impactantes ou urgentes. 3.1 Plano de Gerenciamento de 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: 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; Estrutura de rastreabilidade, ou seja, que atributos (Escolher quais) dos requisitos serão captados na matriz de rastreabilidade e a que outros documentos de requisitos do projeto estarão ligados. O plano de gerenciamento dos requisitos, divide os recursos em três tipos: Critico: É um recurso essencial para o atendimento das necessidades do cliente. A não conclusão de um requisito desse tipo implica em atraso na entrega do produto. Importante: São recursos que podem afetar a satisfação da necessidade do cliente, mas não chegam a atrasar o projeto.
8 Útil: São recursos que podem ser implementados caso haja tempo e conveniência e podem significar um maior grau de satisfação do cliente. Vargas (2009) exemplifica os modelos a serem seguidos no gerenciamento de projetos, segue modelo de Plano de Gerenciamento dos Requisitos: Nome do Projeto Data Negócio Objetivos Projeto Atividade do Gerenciamento da Configuração Processo de Gestão de Mudanças do Produto Análise de Impactos Métricas a usar 3.2 Matriz de Rastrabilidade 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.
9 3.3 Gerenciamento de Mudanças de Requisitos Processamento e Aprovação de Solicitações de Mudança A partir da identificação da necessidade de uma mudança, essa deve ser encaminhada para o Gerente de Projeto que verifica o impacto da mudança no cronograma e faz os ajustes necessários em termos de esforço, retrabalho, benefício, etc e decide se é possível a mudança. Uma vez decidida a mudança, o analista deve ser capaz de rastrear os documentos que devem ser alterados de maneira a satisfazer a mudança. Uma vez atualizados os documentos o desenvolvedor deve implementar as alterações, criando código a partir dos novos documentos ou o alterando. Comitê de Controle de Mudança (CCB) O Comitê de Controle de Mudança será composto apenas pelo Gerente que deverá decidir e monitorar, como o devido auxílio do Analista, se as mudanças devem ser aplicadas. Fluxos de Trabalho e Atividades Revisão Tem como objetivo checar os documentos dependentes quando se tem lugar alguma mudança. Deve ser uma revista cuidadosa do impacto dessa mudança no projeto, com a alteração dos documentos convenientes e alerta aos envolvidos. Deve ser autorizada pelo gerente caso seja identificado um impacto significativo. Implementação Cuidado de seguir os documentos em que se baseiam. Apos a sua conclusão, o analista deve checar se o requisito foi corretamente implementado. Testes Deve realmente provar que o requisito solicitado foi atendido. Abaixo segue exemplo de Documento dos Requisitos, criado por Vargas (2009): Nome do Projeto Data: Negócio Necessidades Objetivo Negócio Objetivos do Projeto Regras Requisitos ID: Classificação Descrição Motivo de Inclusão Proprietário Prioridade Beneficio Versão Data Status
10 Requisitos Básicos Requisitos de Identificação Visual Requisitos de Diferenciais Competitivos Requisitos de Acessibilidade Estratégia de Implantação do Projeto Impactos Entre Outras Áreas Organizacionais Entre Outras Entidades Internas / Externas Premissas Restrições Critérios de Aceitação 4. Definir Escopo É desenvolvida a partir das principais entregas, premissas e restrições, que são documentadas durante a iniciação do projeto, na declaração do escopo preliminar do projeto. Na definição do escopo estão incluídas as necessidades, desejos e expectativas das interessadas, onde estes são analisados e convertidos em requisitos. Processo de desenvolvimento de uma descrição detalhada do projeto e do produto. Este processo é critico para o sucesso e baseia-se nas entregas principais, premissas e restrições que são documentadas durante a iniciação do projeto. Para definição de escopo é preciso dos seguintes documentos: Termo de Abertura do Projeto: Se não houver um, deverá ser criado um conjunto de informações semelhantes para desenvolver a declaração do escopo detalhada do projeto. Documentação do Escopo do Cliente Ativos de Processos Organizacionais: Politicas, procedimentos e modelos para a declaração do escopo, arquivos de projetos anteriores, lições aprendidas. A definição do Escopo é feita através da analise de produtos, onde são incluídas técnicas, como decomposição do produto, análise de valor, engenharia de valor, engenharia de sistemas e análise funcional. Identificação de alternativas, que é usada para gerar diferentes abordagens para executar e realizar o trabalho do projeto. O resultado da definição do escopo é a Declaração de Espoco, onde são descritas detalhadamente as entregas do projeto e o trabalho necessário para cria-las. A declaração do Escopo inclui: Objetivos do Projeto; Descrição do Escopo; Requisitos; Limites;
11 Entregas; Critérios de aceitação dos produtos; Restrições e premissas; Organização inicial do projeto; Riscos Iniciais definidos; Marcos; Estimativa de custos. Ainda durante a definição do escopo, será realizada a atualização dos documentos do projeto, com o registro das partes interessadas, documentação dos requisitos, matriz de rastreabilidade de requisitos. 5. Criar EAP A Estrutura Analitica de Projetos EAP é uma decomposição hierárquica orientada à entrega do trabalho a ser executado pela equipe do projeto, para atingir os objetivos do proejeto e criar as entregas necessárias. Este processo é caracterizado pela subdivisão das entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil. O processo de criação da EAP: Organiza e define o escopo total do projeto; Subdivide o trabalho em partes menores e mais facilmente gerenciáveis; Pode-se agendar, estimar custos, monitorar e controlar o trabalho planejado; O nível mais baixo da EAP representa pacotes de trabalho. O processo de criar EAP está descrito na figura 6 abaixo: Figura 6 Mapa mental do processo Criar EAP Fonte: Vargas (2009) Apesar de cada projeto ser único, uma EAP de um projeto anterior pode ser usada como modelo para um novo projeto, pois numa mesma organização haverá ciclos de vida do projeto iguais. Para a criação de uma EAP é necessária a declaração do escopo; documentação do escopo do cliente e ativos de processos organizacionais. A decomposição de uma EAP está relacionada a subdivisão das entregas do projeto em componentes menores mais facilmente gerenciáveis (pacotes de trabalho). O nível de detalhe dos pacotes de trabalho irá variar de acordo com o tamanho e complexidade do projeto.
12 Quando não é possível conhecer logo o trabalho por completo, utiliza-se o planejamento em ondas sucessivas e cada pacote de trabalho possui um responsável. O resultado da criação da EAP é uma decomposição hierárquica orientada à entrega do trabalho a ser realizado pela equipe. A EAP possui contas de controle com um ou mais pacotes de trabalho para permitir a medição de desempenho e comparação com o valor agregado ( escopo, custo e cronograma). Para que seja dado o suporte a EAP, é necessária a criação de um dicionário, onde está incluído um código identificador de conta, uma declaração de trabalho, a organização responsável, riscos envolvidos, critérios de qualidade e uma lista de marcos do cronograma. Essas especificações podem ser: De projeto; De desempenho; De funcionalidade. Vargas (2009), dá um exemplo de como pode ser o dicionário da EAP: Cód EAP Descrição do Pacote de Trabalho Produto do Pacote de Trabalho (Entregável) Recursos (RH, Materiais, Equip. etc) Predecessoras Sucessoras Data de entrega Critérios de Aceitação Ou exemplo dado por Vargas (2009): Pacote: Preparado por Aprovado por Informações básicas Código EAP Responsável Prazo estimado Custo estimado Principais tarefas a serem realizadas: DICIONÁRIO DA EAP Versão: [Data] Recursos previstos: Predecessores principais do pacote de trabalho: Sucessoras principais do pacote de trabalho: Riscos associados ao pacote: APROVAÇÕES [Nome] [Assinatura] Data [Data]
13 6. Verificar o Escopo É o processo de obtenção da aceitação formal pelas partes interessadas do escopo do projeto terminado e das entregas associadas. Formalização da aceitação das entregas concluídas do projeto. Inclui a revisão das entregas com o cliente ou patrocinador para assegurar que foram concluídas satisfatoriamente e obter deles a aceitação. Este processo inclui a revisão das entregas para garantir que cada uma delas foi determinada de forma satisfatória. Caso o projeto seja cancelado, a verificação do escopo determina o nível e a extensão do termino. A verificação do escopo está associada a qualidade do projeto a ser desenvolvido. Dentro da verificação do escopo está contido o plano de gerenciamento do projeto, que é um documento formal que consolida todo o planejamento, indicando como o projeto deve ser executado e controlado. Este deve ser usado para guiar a execução do projeto, documentar as decisões de planejamento em relação às alternativas escolhidas e facilitar a comunicação entre as partes interessadas. O plano de gerenciamento do projeto é composto pela linha de base, plano de gerenciamento do escopo, cronograma detalhado, orçamento, planos auxiliares e equipe de projeto. Vargas (2009), dá um exemplo para gerenciamento de projeto: Nome do Projeto: Gerente de Projeto: Elaborador: Data: Responsabilidade do Gerente do Projeto Objetivo do Projeto Justificativa do Projeto Prazo Orçamento (Estimativa Inicial do Custo) Designação do Gerente de Projeto, suas responsabilidade e autoridade Risco Fases X Produtos Gerados Principais partes interessadas Cronograma(Estimativas Iniciais de Prazo) Atividade Inicio Fim
14 Expectativa do cliente/patrocinador Fatores de sucesso do projeto Riscos iniciais do projeto Premissas (Iniciais): Restrições (Iniciais): Exclusões(Iniciais): Aprovação Membro do Projeto Assinatura Data O escopo deve ser verificado através de inspeções que acontecem antes das entregas, incluindo atividades como medição, exame e verificação para determinar se o trabalho e as entregas atendem aos requisitos e aos critérios de aceitação do produto. Como resultados da verificação do escopo, as entregas serão aceitas e documentadas, mesmo as que não forem aceitas deverão ser documentadas, juntamente com as razões da não aceitação. As entregas não aceitas deverão justificadas e registradas, com isso poderá ser geradas uma solicitação de mudança para corrigir o motivo. 7. Controlar o Escopo Trata-se de influenciar os fatores que criam mudanças no escopo do projeto e controlar o impacto dessas mudanças. Monitoramento do andamento do escopo do projeto e do produto e gerenciamento das mudanças feitas na linha de base do escopo. Este processo consiste em um conjunto de procedimentos para a documentação, relato, análise, custeamento, aprovação e implementação das mudanças no projeto. Garante que todas as mudanças solicitadas e ações corretivas recomendadas sejam processadas pelo controle integrado de mudanças. É necessário manter a rastreabilidade de quais mudanças foram propostas, quais foram implementadas, quais estão sob considerações, etc. As mudanças no escopo não controladas são chamadas de scope creep. Existem três estágios do processo de gerenciamento de mudanças: Problema detectado e alterações são propostas; As alterações são analisadas para identificar o impacto em termos de custos, prazo, risco e qualidade; Se forem autorizadas, será produzido um conjunto de correções nos documentos do escopo ou nova versão dos mesmos. Para controlar o escopo é utilizado o Plano de Gerenciamento de Projetos, que contém as seguintes informações: Linha de base do escopo;
15 Plano de gerenciamento do escopo; Plano de gerenciamento de mudanças; Plano de gerenciamento de configuração. Informações a respeito do progresso, tais como quais entregas foram iniciadas, os seus progressos e quais foram concluídas irão compor os relatórios de desempenho, cujos níveis de detalhamento e tipo de informação dependerão das partes interessadas, para os quais eles serão divulgados. O controle do escopo é feito através da documentação dos requisitos, da matriz de rastreabilidade de requisitos e dos ativos de processos organizacionais. A análise de variação é utilizada para avaliar a extensão das variações, inclui a determinação da causa e grau de divergência relativa à linha de base do escopo e a decisão se ações corretivas ou preventivas são necessárias. 8. Conclusão Terminar no prazo acertado, com o custo combinado e da forma como os clientes desejam é o que se espera de qualquer projeto. Porém, a experiência mostra que na maioria das vezes, esse não é um desafio fácil de ser cumprido. Inúmeras ações podem fazer com que as expectativas não se cumpram. As falhas vão deste o estabelecimento das expectativas até a execução do projeto. Ao analisar os motivos do fracasso de um projeto será notado que normalmente este fato se deve as falhas no gerenciamento do Escopo ou tempo insuficiente na definição do projeto. Assim, mesmo quando o Gerente de Projetos desenvolve um bom trabalho na definição de Escopo, gerenciar o projeto dentro do escopo estabelecido torna-se seu maior desafio. Muitas vezes são apresentados projetos cujo Escopo não é claro, que deixa margem à interpretação, assim o cliente poderá persistir que a mudança está dentro do Escopo, dificultando o cumprimento do Escopo definido. Um bom gerenciamento do escopo passa pela definição clara do que deve ser feito durante o projeto e como isso será realizado. Essa definição deve ser feita com base nos resultados esperados para o projeto e nas restrições que se terá para sua realização. Ainda mais importante é a definição do que não será feito durante o projeto. Isso serve de proteção às vontades que sempre acontecem durante a realização do projeto. Em geral, pensar antes no que será feito serve de garantia para que o resultado traçado inicialmente seja alcançado. Depois de todo o estudo acerca do gerenciamento do escopo e suas funcionalidades, pode-se concluir que para um projeto alcançar o sucesso é necessário ter um escopo bem elaborado, com requisitos bem definidos e os papeis da equipe estarem claros para todos. O escopo é o esqueleto do projeto, nele estão contidas todas as exigências para que o projeto seja feito. Quando o escopo é mal elaborado, a tendência é que ocorram falhas no decorrer da execução. Os outros planos de gerenciamento dependem diretamente do escopo, como o gerenciamento da qualidade, já que o escopo também define como será feita a medição de qualidade do projeto. O gerenciamento das aquisições e das comunicações também tem ligação direta com o escopo do projeto, que são baseados pelos requisitos.
16 O aumento das características do escopo ocorre quando o aumento do escopo é introduzido por tecnólogos que adicionam características não originalmente contempladas. Um bom gerenciamento do escopo é fundamental para uma execução tranqüila entre as partes interessadas sem discussões sobre o que está ou não incluso, culminando com a satisfação do cliente, uma vez que aumenta a probabilidade de entrega dentro do prazo, dos custos previstos e com a qualidade acordada. Consequentemente aumenta a probabilidade de sucesso do projeto. Referências INSTITUTE, Project Management: PMBOK Guide 5th Edition,(PMI, 2013). VARGAS, Ricardo Viana. Manual prático de projeto: utilizando o PMBOK Guide. 4 ed. Rio de Janeiro : Brasport, 2009.
PLANEJAMENTO DO ESCOPO Dr. rer. nat. Christiane Gresse von Wangenheim, PMP Objetivo de aprendizagem desta aula Ao final desta aula, você deverá ser capaz de: Motivar a importância do planejamento de escopo.