gerenciamento de escopo na gestão de projetos - ipog · conclui-se que um gerenciamento do escopo...

Gerenciamento de Escopo na Gestão de Projetos Julho 2014

ISSN 2179-5568 – Revista Especialize On-line IPOG - Goiânia - 7ª Edição nº 007 Vol.01/2014 Julho/2014

Gerenciamento de Escopo na Gestão de Projetos

Airton Eustaquio Braga Junior – [email protected]

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.



Figura 2 – Processo integrado de gerenciamento de projetos


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 2009.

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


Na finalização do trabalho, será mostrada a importância do bom gerenciamento do escopo



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


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)



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: 1.

2.

3.

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:

Produto

Escopo do Produto Critérios de Aceitação

Projeto

Principais Entregas Exclusões (Fora do

Escopo)

Restrições Premissas



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.



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.



Figura 5 – Fluxo de prioridades de mudanças


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.



Ú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

Objetivos

Negócio 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.



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: Versão

Classificação Data

Descrição

Motivo de Inclusão

Proprietário

Prioridade Status

Beneficio



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;



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


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.



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):

DICIONÁRIO DA EAP

Pacote:

Preparado por Versão:

Aprovado por [Data]

Informações básicas

Código EAP

Responsável

Prazo estimado

Custo estimado

Principais tarefas a serem realizadas:

Recursos previstos:

Predecessores principais do pacote de trabalho:

Sucessoras principais do pacote de trabalho:

Riscos associados ao pacote:

APROVAÇÕES

[Nome] [Assinatura] Data

[Data]



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



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;



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.



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.

gerenciamento de escopo na gestão de projetos - ipog · conclui-se que um gerenciamento do escopo...

Documents