Gerenciamento do Escopo

Esta é uma pré-visualização de arquivo. Entre para ver o arquivo original

1 
MÓDULO: GERENCIAMENTO DO ESCOPO 
PROF. RESPONSÁVEL: MSC. EDUARDO VASCONCELOS 
 
1 GERENCIAMENTO DO ESCOPO 
 
Após realizar os estudos relativos ao gerenciamento do escopo, você terá condições de 
responder às seguintes questões: 
a) Quais os processos que suportam o gerenciamento do escopo do projeto? 
b) Como estruturar um projeto - síntese e análise do trabalho? 
c) Quais as técnicas utilizadas para a realização do gerenciamento do escopo? 
d) Como o gerente de projetos pode se beneficiar do gerenciamento do escopo do projeto? 
 
A famosa história de Lewis Carrol, Alice no país das maravilhas, revela uma preocupação 
bastante singular de um coelho, sempre apressado. Essa preocupação pode ser resumida num 
diálogo entre Alice e o tal coelho. 
Alice - Onde fica a saída? 
Coelho - Mas para onde a senhora quer ir? 
Alice - Para qualquer lugar. 
Coelho - Para qualquer lugar, qualquer saída serve. 
As preocupações com as intenções e abrangência do projeto, com a busca efetiva de seus 
objetivos, são empreendidas através da área de conhecimento que considera o gerenciamento 
de escopo. Elas não podem ser genéricas, como no diálogo apresentado! 
O gerenciamento do escopo do projeto inclui os processos requeridos para garantir que sejam 
executadas as atividades necessárias, e apenas as atividades necessárias, para que o projeto 
seja encerrado com sucesso (PROJECT MANAGEMENT INSTITUTE, 2004). 
 
1.1 INTRODUÇÃO 
 
O conceito de escopo de projetos talvez seja um dos mais variados de todas as áreas de 
conhecimento do gerenciamento de projetos. Fala-se em alcance, esboço, intenções, objetivos, 
limites, entre outros. Escopo, na verdade, refere-se ao trabalho a ser realizado no âmbito do 
projeto. Nesse aspecto, o escopo pode estar ligado ao produto ou ao projeto. 
A disciplina gerenciamento de projetos tem se preocupado com o gerenciamento do escopo do 
projeto, uma vez que os processos de gerenciamento de escopo do produto variam conforme 
as áreas de aplicação. 
Os processos considerados pelo Project Management Institute - PMBoK®Guide (2004) no 
gerenciamento do escopo do projeto são: 
a) Coletar os requisitos: definição e documentação das necessidades das partes interessadas 
para alcançar os objetivos do projeto. 
b) Definir o escopo: desenvolvimento de uma declaração detalhada do escopo do projeto, 
como base para as futuras decisões do projeto. 
 
2 
c) Criar a Estrutura Analítica do Projeto - EAP (work breakdown structure - WBS): subdivisão 
das maiores entregas e trabalho do projeto em componentes menores, com possibilidades 
melhor de gerenciamento; 
d) Verificar o escopo: aceitação formal dos escopos do projeto; 
e) Controlar o escopo: controle das alterações de escopo do projeto. 
A área de escopo tem forte ligação com a área de integração, conforme ilustra a Figura 1. Além 
disso, a área de comunicações deve identificar e gerenciar os requisitos dos stakeholders, 
informar através dos seus Relatórios de Desempenho, ou seja, tem insumos importantes para 
a gestão do escopo do projeto e de suas mudanças. 
 
 
Figura 1: Fluxos dos processos de gestão do Escopo 
Fonte: Adaptada de PMI (2004). 
1.2 COLETAR REQUISITOS E DEFINIR O ESCOPO DO PROJETO 
 
Após a aprovação do project charter, faz-se necessário coletar os requisitos dos principais 
stakeholders e estruturar seu escopo para que ele possa ser gerenciado adequadamente. 
 
3 
O processo de coletar os requisitos do projeto é altamente dependente de processos das áreas 
de comunicações e relacionado aos processos da área de Gestão da Qualidade, assim como 
para construir a matriz de requisitos é necessário identificar os principais stakeholders, etapa 
da área de comunicações, e desdobrá-Ias em critérios de aceitação, etapa desenvolvida na 
área de qualidade. 
Dessa forma, nos dedicaremos às atividades de definição do escopo e construção da estrutura 
analítica do projeto. Para isso, devem ser consideradas duas questões: a declaração do 
escopo e sua definição. 
Fazendo-se uso de uma linguagem mais corriqueira, pode-se dizer que é agora que o gerente 
de projetos e sua equipe devem se preocupar em "armar o projeto" para seu efetivo 
gerenciamento. Isso significa gerar uma base de conhecimento, comum, dos resultados e 
trabalho a ser desenvolvidos no âmbito do projeto. Obviamente, esse conhecimento do escopo 
servirá para ser compartilhado com todos os envolvidos. 
A declaração de escopo é um processo que visa elaborar e documentar, progressivamente, 
todo o escopo do projeto para atingir seus objetivos. 
A declaração de escopo de um projeto deve incluir, essencialmente, as seguintes informações: 
a) justificativa de sua criação: essa informação servirá para que o gerente de projetos e sua 
equipe possam apresentar as necessidades de negócio que motivaram a criação do projeto. 
No âmbito de uma empresa, ajuda o gerente de projetos a negociar recursos para o projeto; 
b) objetivos do projeto: uma vez estabelecidas as justificativas, é preciso deixar claro as 
intenções do projeto, ou seja, quais suas metas quantitativas, quais os resultados esperados. 
Normalmente, projetos com objetivos bem declarados são aqueles que mostram explicitamente 
os alvos de prazo, custo e qualidade esperados. Quanto aos objetivos mais qualitativos, estes 
carregam um grau maior de risco em relação ao seu atendimento; 
c) produto do projeto: aquilo que se espera entregar no final para que o projeto tenha sucesso. 
Essa informação deverá conter uma descrição sucinta do produto do projeto. Em muitos 
projetos, essa informação poderá envolver desenhos, fluxogramas, esboços, detalhes de 
construção, etc. Ela pode ser complementada com a adição de uma lista de subprodutos, que, 
quando integrados, devem compor o produto final do projeto. Devem-se incluir também os 
critérios de aceitação do produto. 
No entanto, é bom que a declaração também explore adequadamente as fronteiras do projeto, 
o que é escopo e o que não é escopo do projeto. Além disso, é interessante estabelecer as 
premissas e restrições do projeto, quando da confecção do termo de abertura (project charter). 
Uma vez registrada a declaração do escopo, faz-se necessário iniciar o processo de 
detalhamento do escopo. Esse processo envolve a decomposição das entregas do projeto de 
tal forma que os componentes menores gerados possam ser administrados mais facilmente. 
A decomposição é um processo que pode ser expresso numa ferramenta conhecida como 
Estrutura Analítica do Projeto (EAP), que, por sua vez, vem do original Work Breakdown 
Structure (WBS). A WBS consiste na representação hierárquica de todo o trabalho do projeto 
através da decomposição de seus resultados principais. 
 
 
4 
1.3 ESTRUTURA ANALÍTICA DO PROJETO 
 
A EAP é a representação do processo de desagregação (para baixo) e integração (para cima) 
do trabalho do projeto que vai ajudar o gerente de projetos na execução e controle das 
atividades do projeto. 
Os elementos finais conseguidos nesse processo são denominados de pacote de trabalho 
(mais baixo nível). Para que os pacotes de trabalho possam ser gerenciados, associados a 
eles devem estar os seguintes elementos: 
a) objetivo: identificação do que deve ser atingível com o pacote; 
b) entregas (deliverables): produto/serviço associado ao trabalho; 
c) programação: atividades associadas com o respectivo planejamento de execução; 
d) orçamento: cronograma financeiro de desembolso e valores acumulados; 
e) responsabilidades: mão de obra (homem/hora), além de responsáveis diretos pelo trabalho. 
A construção de uma EAP faz parte de um processo que visa obter a subdivisão dos resultados 
parciais que se esperam alcançar com o projeto
em componentes menores mais facilmente 
gerenciados. 
Para fazer a EAP parte-se de uma estrutura hierárquica top-down (do todo para a parte), 
decompondo todo o trabalho do projeto até chegar no pacote de trabalho, nível mais baixo da 
estrutura analítica do projeto, mas que ainda está associado a uma entrega tangível, o que o 
diferencia da atividade, que é a decomposição que fazemos para a elaboração do cronograma. 
Nesse processo de decomposição, é importante atentar para algumas regrinhas. 
As caixinhas da EAP devem ser mutuamente excludentes, ou seja, um mesmo trabalho não se 
encontra em duas caixinhas da EAP. Lembre-se que isso não quer dizer que as caixinhas não 
tenham relação entre si, afinal são partes de um mesmo projeto e assim têm dependência, 
quer dizer apenas que não há redundância entre elas. Além disso, a soma do trabalho de todas 
as caixinhas de um determinado nível deve representar 100% do escopo do nível superior (não 
pode faltar trabalho); é o que chamamos de integração (para cima). E recomendável também 
utilizar substantivos para nomear as caixinhas da EAP. 
Além disso, você pode utilizar vários critérios de decomposição para fazer a EAP, orientada 
aos subsistemas, à geografia, às funções, às fases do ciclo de vida, às competências/aos 
recursos ou outro critério que pareça pertinente no seu contexto gerencial. 
A arte de fazer uma boa estrutura analítica é dominar a decomposição. 
Enquanto o gerente estiver inseguro quanto às estimativas, é necessário continuar 
decompondo em níveis menores de trabalho. Também procure manter um mesmo tipo de 
competências em um pacote de trabalho; é mais fácil gerenciar, embora nem sempre seja 
possível. Finalmente, lembre-se que você deve evitar os extremos, pouca decomposição pode 
significar que as estimativas dos pacotes de trabalho estão muito grosseiras, enquanto EAPs 
muito decompostas perdem a finalidade gerencial (aproximam-se do cronograma); não adianta 
fazer um mapa do tamanho do mundo! 
 
5 
Projeto
Entrega 1
Pacote de 
Trabalho (PT 1.1)
Pacote de 
Trabalho PT (1.2)
Entrega 2 Entrega n
Pacote de 
Trabalho (PT n.1)
Podemos descrever quatro passos para a decomposição do projeto ao longo da estrutura 
analítica, conforme segue: 
(1) Identificar as principais entregas (deliverables) do projeto 
 
 
 
(2) Decidir qual custo e duração do "adequado critério de aceitação" 
 
 
 
Passo 3 Passo 4 
(3) Identificar os componentes das entregas de pacotes de trabalho 
 
 
 
 
 
 
 
 
 
 
 
 
 
 
(4) Verificar se a decomposição está correta. Passo seguinte: decompor os pacotes em 
atividades; isso já faz parte da gestão de tempo, para a elaboração do cronograma 
Fazer a integração da base para o topo. A soma dos pacotes de trabalho deve conter todo o 
trabalho da entrega de nível imediatamente superior. Ex.: PT1.1 + PT1.2 = 100% da Entrega. 
 
Alguns autores consideram a EAP a espinha dorsal do projeto, pois permite a integração da 
tríade: escopo, custo e tempo, constituindo um fator crítico de sucesso para o projeto 
(GLOBERSON, 2002, BACHY; HAMERI, 1997; LAMERS, 2002). 
Utilizando-se da EAP, podem-se estabelecer relações mais claras não só entre a tríade 
mencionada, mas também com qualidade e riscos. Para entender a construção de uma EAP, 
vamos ver como foi o processo de elaboração da WBS da casa de Eduardo e Mônica. 
Projeto
Entrega 1 Entrega 2 Entrega n
Custo? / Duração? / Critério de aceitação? 
 
 
6 
 
A construção da EAP de um projeto se dá no momento em que já existe um charter aprovado e 
se faz necessário detalhar todo o trabalho necessário à realização de um projeto. Eduardo e 
Mônica, antes de abrir o computador e desenhar a estrutura analítica, dessa vez resolveram 
tomar as seguintes decisões: 
 agrupar os serviços preliminares num só grupo; 
 tratar as documentações anteriores e posteriores ao projeto num só grupo; 
 separar a construção do acabamento; e 
 ter um grupo que representasse a gerência do projeto. 
 
Feitas tais considerações, a EAP do casal ficou assim: 
(*) Ver última página deste material (Figura 2) 
 
Muitos gerentes de projetos costumam representar a WBS através de tabelas, uma vez que os 
programas de planilhas são de fácil manuseio. O Quadro 1 mostra o mesmo exemplo em forma 
de tabela. 
CASA 01. Serviços Preliminares (2%) 01.01 Limpeza 
01.02 Água / Luz 
01.03 Canteiro 
 
02. Projeto (8%) 02.01 Planta 02.01.01 Arquitetura 
02.01.02 Elétrica 
02.01.03 Hidráulica 
02.01.04 Estrutural 
 02.02 Aprovações 02.02.01 Plantas 
02.02.02 Alvará 
03. Construção (35%) 03.01 Fundação (4%) 
03.02 Estrutura (16%) 
03.03 Telhado (5%) 
03.04 Esquadrias (7%) 
03.05% Alvenaria (3%) 
 
04. Sistemas (16%) 04.01 Hidráulica (8%) 
04.02 Elétrica (6%) 
 
05. Acabamento (38%) 05.01 Pintura (5%) 
05.02 Revestimentos/ 
Acabamentos (25%) 
05.03 Vidros (2%) 
05.04 Armários (5%) 
05.01.01 Interna 
05.01.02 Externa 
05.02.01 Banheiros 
05.02.02 Cozinha 
05.02.03 Quartos 
05.02.04 Outros 
06. Serviços Complementares (1%) 06.01 Limpeza 
06.02 Jardinagem 
 
07. Gerência (05) 07.01 Plano 
07.02 Acompanhamento 
07.03 Entrega/encerramento 
 
Quadro 1: EAP Casa, representada por Tabela 
 
Várias questões decorrem do estudo das estruturas analíticas de projetos. Uma delas refere-se 
ao percentual dedicado ao gerenciamento de projetos. Sabe-se, cada vez mais, que essa é 
 
7 
uma atividade relevante e que deve ser executada com primor, visando levar o projeto ao 
sucesso. Portanto, faz-se necessário, quando há uma equipe especializada para isto, 
considerar seus custos e recursos envolvidos. Há casos em que não há necessidade de se 
formar uma equipe de gerenciamento, e a dedicação do gerente acaba sendo direcionada 
também para outras atividades de sua especialidade no projeto. É o que está ocorrendo no 
caso de Eduardo & Mônica, por exemplo. Embora o trabalho do casal esteja representado na 
EAP, seu percentual será desprezível, pois não serão contabilizadas as horas gastas e seus 
respectivos valores em gerenciamento. 
Outra questão que os estudiosos em gerenciamento de projetos têm debatido com relação às 
estruturas do trabalho dos projetos se refere às regras da decomposição. 
Parece que não há um consenso de até que nível devem-se desagregar os elementos de uma 
EAP. As atividades estão incluídas ou não? 
Essa discussão foi tratada por Berg e Colenso (2000), que apresentam uma série de pontos 
favoráveis e desfavoráveis da inclusão (ou não) de atividades na EAP. 
Alguns pontos levantados pelos autores mostram os dois lados da questão. 
 
As EAPs não incluem as atividades 
 A EAP em geral é uma ferramenta orientada aos deliverables, que, por sua vez, são 
expressos através de substantivos, ao passo que as atividades são expressas em 
verbos. 
 A EAP não chega ao detalhe de alocação de pessoas e nem de estabelecimento de 
dependências. Os membros da equipe devem ter a liberdade de exercitar a 
criatividade, escolhendo os métodos e sequência de atividades adequados para poder 
produzir os deliverables. Esses métodos e atividades não precisam estar expressos na 
EAP. 
 O processo de criação da EAP é uma atividade de planejamento separada do processo 
de criação de redes de atividades e suas dependências. Portanto, não há correlação 
direta entre esses dois processos. 
 
As EAPs incluem as atividades 
 As relações de dependência pressupõem que as atividades predecessoras entreguem 
algo (deliverable) para que se possa iniciar uma sucessora. Portanto, atividades criam 
deliverables. 
 Deliverables resultam de atividades e
são gerados de uma estrutura hierárquica (de 
deliverables), ou seja, são decompostos de deliverables de mais alto nível, vindos, em 
tese, da EAP. Portanto, há uma correlação direta entre atividades e EAP. 
 O processo de criação de uma EAP é top-down, que por fim gera uma rede de 
atividades/eventos. Mesmo sendo processos separados, um recebe influência do outro 
e têm atividades como elemento comum. 
 
 
8 
Alguns aspectos, entretanto, devem ser levados em conta, resultado dessa reflexão inicial. 
Assim: 
 O gerente de projetos deve ter, realmente, o direito de decompor a EAP visando atingir 
níveis gerenciáveis. Uma EAP é uma ferramenta que pode ser utilizada de diferentes 
formas, dependendo das necessidades dos gerentes de projetos. 
 Conforme definida no Guia de Conhecimentos em Gerenciamento de projetos do PMI - 
PROJECT MANAGEMENT INSTITUTE (2004) -, EAP é uma ferramenta que 
desmembra o trabalho de um projeto de forma hierárquica e orientada a deliverables. 
 O mais baixo nível da EAP não contém rede de atividades e mesmo schedule. 
Entretanto, o mais baixo nível pode ser conectado formando ligações com os 
diagramas de rede de atividades. Portanto, o mais baixo nível pode ser uma atividade. 
 Há um consenso de que as entradas na EAP devem ser formadas por substantivos, 
especialmente as de mais alto nível. O gerente de projetos deve ter a liberdade para 
escolher se usa substantivo ou verbo para dar uma entrada na EAP, principalmente 
nos itens de mais baixo nível. 
 A EAP pode ser elaborada como um deliverable hierárquico e pode ser estruturada 
obedecendo às fases de ciclo de vida; entretanto, pode ser formada a partir de 
substantivos que serão detalhados. 
 
Discussão à parte, é comum os gerentes de projetos se adaptarem facilmente com o uso da 
EAP. No entanto, para se fazer uso adequado da ferramenta, sua constituição deve ser 
elaborada através do uso de pequenos pedaços de papel, autocolantes, em que as 
decomposições do trabalho são representadas e explícitas aos envolvidos no planejamento. 
Percebe-se durante a construção da EAP a integração dos membros e o início do 
comprometimento com todo o trabalho do projeto. Assim, é possível pontuar as vantagens do 
uso da EAP: 
 visão de todo o escopo do projeto e suas entregas programadas; 
 associação de responsabilidades explícitas; 
 estabelecimento de estimativas de custos bottom-up; 
 facilidade de apresentação do trabalho do projeto; 
 constituição das principais fontes de risco e identificação de incertezas; 
 apresentação das estimativas do total de homens/hora do projeto; 
 identificação dos envolvidos que necessitam de informação do projeto. 
 
Um comentário importante a respeito da EAP de um projeto refere-se ao trabalho dedicado ao 
gerenciamento do projeto propriamente dito. Os gerentes de projetos devem deixar claro que 
existem trabalhos inerentes ao gerenciamento e, portanto, representá-los na EAP com os 
demais. 
A Constituição de uma EAP, por fim, deve levar em conta tanto o trabalho quanto os recursos 
das áreas funcionais da empresa. 
 
9 
Nesse sentido, vale a pena relacionar a origem dos recursos com os trabalhos envolvidos em 
cada entrega planejada na EAP. 
 
A Figura 3 mostra esta relação. 
 
Figura 3: Integração estrutura organizacional e EAP 
Fonte: Carvalho e Rabechini Jr (2013). 
 
1.4 ACORDANDO O ESCOPO DO PROJETO COM OS STAKEHOLDERS 
 
Uma vez constituída a EAP, ficam explícitas as responsabilidades dos interessados nos 
resultados do projeto. Esse é um ponto bastante importante do projeto e cabe ao gerente 
explorar bastante esse momento. Para que a WBS possa ser um instrumento bastante eficaz 
no gerenciamento faz-se necessário garantir que seu conteúdo seja devidamente aprovado, 
com comprometimento dos interessados. 
O PMI (PROJECTMANAGEMENTINSTITUTE, 2004) explora um processo de acordo com o 
escopo do projeto que visa formalizar o aceite do projeto pelas partes envolvidas. 
Uma das práticas mais comuns para efetivar os acordos com os stakeholders é a reunião de 
projetos. Nela, o gerente de projetos deverá, para cada pacote de trabalho, garantir a entrega e 
associá-Ia a um responsável. 
 
 
 
1.5 VERIFICAÇÃO E CONTROLE DAS ALTERAÇÕES DO ESCOPO 
 
Um dos processos mais importantes do gerenciamento de projetos é, sem dúvida, a verificação 
e controle de escopo através de revisões. 
 
10 
As revisões de projetos devem ser planejadas de acordo com as necessidades de verificação 
de escopo traçadas no planejamento. O Quadro 2 mostra os principais tipos de revisão em 
projetos. 
 
Revisão Objetivo 
Periódica Previstas para serem realizadas em determinados períodos do projeto. 
Fase Após cumprir determinadas fases, as revisões ocorrem com o objetivo de aprovar 
a fase anterior e, assim, iniciar a nova fase. 
Esporádicas Revisões pontuais em que o gerente de projetos e sua equipe apresentam os 
avanços alcançados. 
Quadro 2: Tipologia de Revisão 
 
As revisões de escopo de projetos devem apresentar resultados para que o gerente de projetos 
possa tomar suas decisões com base nelas. Após as revisões os gerentes terão condições de 
saber sobre os destinos de projeto. Caso o trabalho esteja atingindo o escopo, segundo o 
planejamento, a decisão do gerente deve ser manter o desenvolvimento. Caso haja 
necessidade de aumentar ou diminuir o escopo, o gerente deve optar por elaborar um novo 
planejamento. 
Nesse caso, a EAP terá de ser revista e a avaliação das implicações em prazos e custo tem de 
ser refeita. 
Por fim, caso o escopo do projeto tenha sido realizado, cabe ao gerente proceder ao 
encerramento do mesmo. Para tal, é necessária a aceitação formal do pacote de trabalho, com 
base nos critérios estabelecidos. Em geral, a aceitação formal implica liberação de 
pagamentos, portanto, é necessário que de fato tenha havido um controle e verificação da 
entrega feita, conforme vocês poderão ver no Gerenciamento de Custos e no Gerenciamento 
da Qualidade. 
Durante o desenvolvimento de um projeto, em alguns casos, ocorrem alterações de escopo. 
Em projetos grandes, em que a incidência de mudanças é frequente e intensa, cabe ao gerente 
estabelecer um sistema de controle de mudanças. 
A principal entrada para um sistema de controle de mudança é um documento denominado 
solicitação de mudanças. Seu conteúdo deve refletir, além dos dados das mudanças em si, os 
impactos que elas podem causar ao projeto, em termos de seus resultados esperados 
(normalmente, prazo, custo e qualidade). 
As solicitações de mudanças em projetos devem ser sistematicamente analisadas pelo gerente 
de projetos e sua equipe. Um sistema de controle e acompanhamento de solicitações de 
mudanças em projetos deverá conter elementos que ajudem na análise de cada uma delas, 
possibilitando assim a realização de uma espécie de triagem, em que seja possível selecionar 
as mudanças mais importantes. 
As mudanças são mais frequentes nos projetos em que o escopo não foi bem planejado, ou em 
que a análise dos interessados não foi exaustiva, ou ainda em que a avaliação dos riscos 
inerentes ao projeto não tenha sido desenhada adequadamente. No entanto, existem outras 
situações em que as mudanças são inevitáveis: são os casos de projetos inerentes a setores 
 
11 
turbulentos. Por exemplo, no Brasil, no final da década de 1990, o setor de telecomunicações 
passou por transformações profundas, fazendo com que os projetos desenvolvidos na época 
fossem muito sensíveis às mudanças seja por prazo, custo, especificações, tecnologia, 
fornecedores, etc. 
Na verdade, quanto mais diferente e único for um projeto, mais suscetível à mudança ele 
estará.
A diversidade e a temporalidade fazem com que seja requerido um planejamento forte 
em diversas áreas do conhecimento em gerenciamento de projetos. E, quando isso não ocorre, 
as mudanças aparecem, inevitavelmente. 
As mudanças ocorridas durante a execução de um projeto podem e devem ser administradas. 
Inicialmente, o gerente e sua equipe devem, ao fazer o controle do escopo do projeto, procurar 
possíveis focos de mudanças. Recomenda-se que a mudança reconhecida seja traduzida para 
um documento. Em geral, esse procedimento vem ao encontro de ser um exercício para 
melhor se terem informações do futuro enquadramento das mudanças. 
Um exemplo de preenchimento da solicitação de mudança pode ser visto através do caso 
projeto Casa Eduardo & Mônica. 
 
Eduardo e Mônica, ao longo do desdobramento dos pacotes pela equipe de engenharia, 
delegaram algumas questões técnicas e depois perceberam que o sonho da casa sustentável 
estava ameaçado. 
Mônica tinha sonhado que sua casa teria energia solar, cisterna para guardar água da chuva, 
telhado branco, sistemas hidráulicos que priorizassem o consumo eficiente da água, entre 
outros itens que tinha pesquisado. No entanto, depois da reunião inicial com os projetistas, não 
fez o acompanhamento dos projetos técnicos e descobriu que vários itens não haviam sido 
incorporados. 
Já durante a construção da casa, Eduardo e Mônica decidiram que fariam as alterações de 
escopo necessárias para alcançar o sonho da casa ecológica, que havia se perdido na fase de 
projeto. Embora soubessem que por vezes essas alterações trariam impactos nos custos e no 
cronograma do projeto, estavam certos dos retornos futuros. 
Eduardo rapidamente acessou um formulário de solicitação de mudanças dado em seu MBA e 
começou a preencher. 
Embora de fácil preenchimento, Eduardo teve que pesquisar bastante sobre as informações 
requeridas, bem como fazer uma série de simulações sobre impactos possíveis. 
O documento final ficou como mostra a Figura 4. 
 
 
 
 
Solicitação de Mudanças 
Nome do Projeto 
Casa Eduardo & Mônica 
Gerente 
Eduardo 
Patrocinador 
Mônica 
10/03/2014 
 
 
12 
Número da mudança: 01/06 Área: Hidráulica / Elétrica 
 
Solicitante: Eduardo & Mônica 
 
Objetivo da Mudança 
Instalar um sistema de aquecimento solar contendo 3 placas e boiler de 300 litros. 
 
Justificativa e Benefícios da mudança 
 Economia de energia elétrica; 
 Uso inteligente de energia. 
 
Prazo: 1 semana Custo: R$ 5 mil 
 
Impactos Positivos: Economia a longo prazo Impactos Negativos: Maior desembolso atual 
 
Importância: Razoável 
 
Urgência: Muita, dada a etapa da obra 
 
Recursos 
 Especialista Hidráulica 
Riscos 
 Equipamento 
 Instalação 
 
Premissas 
 Ser aderente ao sistema 
Restrições 
 Modelos 
 
Descrição 
 Planejamento da aquisição do sistema 
 Seleção do Fornecedor e sistema 
 Planejamento da instalação 
 Instalação (considerar o plano do projeto) 
 
Impacto no Escopo / Objetivos do Projeto 
 A mudança altera o sistema hidráulico / elétrico 
 Serão necessárias adaptações e portanto planejamento para instalação 
 
Documentação de Suporte 
 Manual do equipamento e documentos de garantia do sistema. 
Aprovações 
Patrocinador 
Mônica 
Gerente 
Eduardo 
Modelo Engenharia, Arquitetura e Construção S/C 
Ltda. 
Figura 4: Solicitação de mudança do Escopo 
 
 
Com as solicitações das mudanças em mãos, o gerente de projetos e sua equipe devem fazer 
uso de um sistema de controle de mudanças, analisando caso a caso no intuito de fazer a 
triagem das mudanças mais importantes. 
 
13 
Um sistema de controle de mudanças deverá ajudar o gerente a responder às seguintes 
questões, entre outras: 
a) quais as principais mudanças? 
b) quais eu posso fazer? 
c) quais eu não posso fazer? 
d) de quantos recursos eu preciso? 
e) qual o prazo ideal? 
Um sistema de controle de mudanças deverá, portanto, ser capaz de avaliar cada solicitação 
de mudanças e fornecer informações que darão suporte aos decisores quanto à aceitação ou 
rejeição da mudança. 
As mudanças aprovadas deverão passar pelo processo de planejamento do projeto e seus 
elementos devem ser incorporados ao plano geral de gerenciamento de projetos. 
Nesse ponto, o gerenciamento de mudanças faz uso das práticas de gerenciamento do projeto 
e "volta" a buscar novos focos de possíveis alterações em projetos, dando continuidade a todo 
o processo. 
 
Caso: cercando o escopo do projeto 
Para contribuir com o entendimento dos conceitos de escopo em projetos será retratado um 
caso bastante interessante publicado na revista PM Network, em abril de 1998. As autoras 
(PAULA;TATE, 1998) valorizam a área de conhecimento de escopo e, através do texto Fencing 
in project scope, traçam um panorama que ajuda os gerentes de projetos no delineamento das 
fronteiras dos projetos. 
 
A seguir, uma tradução livre do texto de Paula e Tate (1998). 
Qual é o componente mais importante de um projeto? Você disse escopo? Acertou. 
O escopo de um projeto define o que será feito - quais produtos ou serviços serão entregues. 
Tudo o que vem depois disto - quem participará do time do projeto, quanto tempo levará, 
quanto esforço será necessário e quanto custará - depende do escopo do projeto. 
Então, antes que você e seu time escrevam uma descrição do escopo, decida sobre as 
fronteiras desse escopo: o que está dentro e o que está fora do projeto. 
A primeira fronteira ou cerca a ser considerada são as cercas dos estágios do ciclo de vida. O 
que é um estágio do ciclo de vida? Bem, todo produto, serviço ou processo, os quais nós 
podemos genericamente nos referir como uma "coisa", passam por um ciclo de vida, do 
nascimento até a morte. No início é somente uma ideia. 
Então é dada alguma definição sobre como, no final, essa coisa ficará parecida. Então vêm os 
estágios de desenho ou redesenho, em que o produto, serviço ou processo é desenhado. Após 
completar esse estágio, o desenho será construído, testado e instalado. O próximo estágio é a 
produção. E, quando a coisa não é mais necessária, ela é aposentada, completando o ciclo de 
nascimento e morte. 
Um projeto pode abranger todos estes estágios: definir, desenhar, instalar, manter e então 
aposentar, ou pode abranger somente um ou mais estágios. É importante para o seu time 
 
14 
conhecer quais estágios do ciclo de vida de seu produto serviço ou processo estão incluídos no 
seu projeto. Por exemplo, digamos que você esteja envolvido com um projeto para desenhar 
um novo serviço. É esperado que você faça uma pesquisa de mercado ou isso já foi feito 
anteriormente? É esperado que você simplesmente desenhe o serviço ou você deve treinar os 
empregados também? Saber onde começar e acabar coloca uma cerca em volta do escopo do 
seu projeto que ajuda você a fazer o que é necessário - nem mais, nem menos. 
A próxima cerca que você precisa levantar ao redor do seu escopo é a cerca do processo. 
Quais processos estão incluídos como parte do seu escopo e quais estão de fora? Os 
processos incluídos são aqueles que produzirão os produtos ou serviços a serem entregues 
pelo projeto. Identifique esses processos. Os representantes desses processos devem ter 
representantes no time. Existem também processos que impactarão o projeto, mas que não 
estão inclusos no escopo. São os processos de suprimentos. 
Identifique os processos-chave de suprimentos que afetarão o seu projeto. Onde for 
necessária, peça a participação de um representante no time ou a designação de um 
representante para fazer a coordenação. Então,
existem os processos que serão afetados pelo 
projeto. São os processos do cliente. Identifique estes processos também. 
Eles não são parte do seu projeto, mas impactam a entrega dos produtos/serviços do projeto. 
Eles podem precisar de um representante no time também. 
Agora você tem as cercas ao redor de todo o escopo - definindo o que está dentro e o que está 
fora -, você precisará considerar as superposições no escopo. A Karen trabalhou num projeto 
uma vez, que havia sido montado para redesenhar uma parte importante de um produto, 
visando reduzir os custos de manufatura. O time trabalhou 18 meses e finalmente atingiu seu 
objetivo. Era desconhecido do time que um outro time de projeto, que estava trabalhando para 
reduzir o custo total do produto, havia decidido eliminar essa parte no desenho do produto! O 
primeiro time atingiu seu objetivo: reduzir o custo daquela parte do produto, mas aquilo não 
interessava mais. Aquela parte do produto virou história. Não deixe que isso aconteça a você. 
Descubra como outros projetos, planejados ou em execução, podem impactar o seu projeto. 
Designe alguém como representante do seu projeto nesses outros projetos para que você 
possa coordenar seus esforços. 
Uma vez que você tenha estabelecido toda a sua cerca, você estará pronto para escrever a 
descrição de seu escopo. Descreva, em detalhes, as características e funções do 
produto/serviço final a ser entregue. Descreva os critérios de aceitação por parte do cliente 
desse produto/serviço final. E descreva as fronteiras desse escopo. Consiga o "de acordo" de 
todos os interessados, em especial do cliente e do patrocinador, ou seja, o que você está 
responsável para produzir. Então será a hora de seguir adiante e planejar suas necessidades 
de recursos. 
 
Figura 2: EAP Casa Eduardo & Mônica 
 
 
15