IMPRESSÃO AULAS GERENCIAMENTO DE ESCOPO EM PROJETOS 2020

Prévia do material em texto

AULA 1 
GERENCIAMENTO DE ESCOPO 
EM PROJETOS
Prof. Marcelo Bellon Ferreira 
 
 
02 
CONVERSA INICIAL 
Nosso objetivo nesta disciplina é entender a importância que o escopo 
tem para o projeto. Afinal, sem conhecê-lo não podemos nem mesmo dizer que 
se trata de um projeto. 
Nesse primeiro momento, precisamos compreender a importância de 
fazermos uma boa gestão de escopo, desde a sua definição até o seu controle, 
para que o projeto alcance o sucesso esperado. Veremos que uma má gestão 
pode levar a consequências que simplesmente tornam o projeto um grande 
fracasso e até impedem que ele seja concluído. 
Também fazem parte desta aula o entendimento dos processos de gestão 
de escopo e o planejamento da gestão de escopo. 
CONTEXTUALIZANDO 
Imagine que você foi contratado para executar uma tarefa qualquer de 
seu cotidiano, como é o caso de um projeto. Nesse caso hipotético, a tarefa é a 
construção de uma parede em uma residência; entretanto, a pessoa interessada 
no resultado apenas lhe disse que quer uma parede, e mais nada. Não informou 
o tipo de material que deve ser usado, o acabamento desejado, o tamanho da 
parede, a quantidade de tomadas de que precisa etc. Ou seja, ela não lhe 
informou o escopo. Como você poderia executar a tarefa? Impossível, não é 
mesmo? 
Um outro exemplo: essa mesma pessoa que mencionamos anteriormente 
passou a dimensão desejada da parede, o tipo de material a ser utilizado, a cor 
do acabamento etc. Que bom, não é mesmo? Mas, durante a execução do 
trabalho, foram solicitadas mudanças e, ao final, o resultado ficou bem diferente 
daquilo que tinha sido combinado em primeiro lugar. Será que o projeto foi um 
sucesso no que se refere a escopo? 
TEMA 1 – INTRODUÇÃO AO GERENCIAMENTO DE ESCOPO 
O PMBOK® (Project Management Body of Knowledge)1, em sua 5ª edição 
(2014), nos diz que: 
 
1 O PMBOK® (Project Management Body of Knowledge) é o conjunto de boas práticas sugeridas 
para o gerenciamento de projetos. É organizado pelo Project Management Institute. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
03 
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. O 
gerenciamento do escopo do projeto está relacionado principalmente 
com a definição e controle do que está e do que não está incluso no 
projeto (Project Management Institute, 2014). 
Um grande desafio para o gerente de projetos é definir com clareza qual é 
o escopo das entregas e a forma como isso será feito, bem como quais etapas 
de trabalho devem ser conduzidas para esse fim. 
Aqui pode nos parecer que falamos apenas de algo tangível, que pode 
ser tocado e analisado. Porém o gerenciamento do projeto e, em especial, o 
gerenciamento de escopo, é muito mais que isso. 
Um plano de gerenciamento de escopo deve definir processos que, se 
não forem seguidos, poderão acarretar problemas de gestão em todo o projeto. 
Apenas se seguirmos esses processos poderemos definir nosso escopo e o que 
fazer com ele. Ele pode não ser imutável, pode sofrer alterações; mas elas 
devem ser controladas. 
Processos de validação permitem que haja satisfação por parte do cliente 
a cada pequena entrega e garantem que o produto final seja aquele esperado. 
Dito isso, podemos perceber a importância do gerenciamento de escopo e de 
seus processos no sucesso das entregas planejadas e acordadas com os 
interessados no projeto. Não basta apenas definir, mas também validar e 
controlar. 
TEMA 2 – A IMPORTÂNCIA DO ESCOPO 
No tema anterior, vimos como é importante o gerenciamento de escopo. 
Mas, afinal, o que é escopo? 
Escopo é a definição de tudo o que deve ser entregue ao final do projeto, 
incluindo-se aí o produto2, e também todo o trabalho necessário. Além disso, ele 
deve incluir uma lista com todos os itens que NÃO fazem parte das entregas; 
eles também devem ser explicitados para não haja nenhuma dúvida quanto ao 
assunto. 
Ricardo Vargas, em seu podcast sobre gerenciamento de escopo23, diz 
que o "escopo é a chave de tudo". Se ele não for muito bem definido, não será 
 
2 O termo produto é utilizado aqui de forma genérica; pode também se referir a um serviço ou a 
uma atividade. Depende do projeto. 
2 
3 O podcast de Vargas está disponível em: <https://ricardo-
vargas.com/pt/podcasts/scopemanagement/>. Acesso em: 8 de nov. 2017. 
https://ricardo-vargas.com/pt/podcasts/scopemanagement/
https://ricardo-vargas.com/pt/podcasts/scopemanagement/
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
04 
possível pensar em custos ou cronogramas. Todas as demais áreas do 
gerenciamento de projetos precisam de, pelo menos, informações sobre o 
escopo. Com isso, podemos vislumbrar claramente a sua importância, já que 
uma definição ou um gerenciamento com problemas gerariam impactos 
profundos em todas as áreas e entregas. 
O escopo se mescla com o projeto de uma tal maneira que parece que 
apenas ele existe. Se nosso projeto é o de construir uma parede, o escopo 
nesse caso é, de maneira macro, construir uma parede. É claro que as demais 
características e tudo o que é necessário para que o sucesso seja atingido 
também deve ser definido e detalhado. 
Outro exemplo de escopo e sua importância que consolidará de vez o 
entendimento sobre esse assunto é o de um projeto para uma viagem. É 
impossível começar a concebê-lo sem antes definir o escopo, que pode ser “uma 
viagem de férias para as praias do litoral norte do Rio de Janeiro por 15 dias a 
partir de 5 de janeiro de 2018”. Veja que temos nesse exemplo uma ideia muito 
clara de quais objetivos queremos atingir, e já é possível imaginar os detalhes e 
requisitos nos quais teremos que pensar para fazer todo o planejamento. Sem 
alguma das definições anteriores, o que poderia ser feito? Certamente, dúvidas 
existiriam, e se o projeto fosse executado ele dificilmente teria sucesso. 
Quando falamos de escopo de projeto, precisamos lembrar que ele pode 
ser constituído de pelo menos dois tipos de escopo: o de produto e o de 
trabalho. 
O escopo de produto é aquele que define o que deve ser entregue. Ele 
informa quais são as características técnicas que o produto deverá apresentar 
ao final do projeto. Geralmente é o que se visualiza. É aquilo que distingue um 
projeto dos demais, tornando-o único, e tem muita importância. Se o projeto, por 
exemplo, trata da reestruturação do departamento jurídico de uma empresa, o 
escopo será a entrega de um novo departamento, possivelmente como novos 
processos definidos, com novas tecnologias de auxílio aos empregados e 
qualquer outra definição que se deseje. 
Já o escopo de trabalho apresenta o conjunto de atividades que devem 
ser executadas para que o projeto seja realizado. 
Assim, podemos dizer que o escopo de produto são as características 
daquilo em que o trabalho irá resultar. 
Como dissemos anteriormente, não podemos nos esquecer de que 
quando falamos de escopo e sua definição é muito importante definirmos o que 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
05 
NÃO iremos entregar. Arrisco a dizer que em muitos projetos o que não faz parte 
do escopo é mais importante do que aquilo que faz. 
Muitos projetos, mesmo com boas definições de escopo, podem deixar 
dúvidas sobre suas entregas. Algo que parece inerente ao projeto pode 
simplesmente não fazer parte das entregas. Vejamos um exemplo: a NASA foi 
contratada pelo Brasil para o projeto de colocar em órbita um novo satélite de 
monitoramento climático. Certamente, a NASA fará todo o planejamento da 
missão eexecutará o lançamento de um foguete, tudo conforme o que foi 
detalhado. Mas veja que não falamos em nenhum momento que a NASA 
construirá o satélite ou mesmo que ela o monitorará após seu posicionamento 
em órbita. 
Por mais que aquilo que faz parte do escopo pareça estar claro para 
todos, se um único envolvido no projeto tiver dúvidas, isso pode ser o suficiente 
para gerar algum tipo de problema. Então, não custa nada deixar muito claro e 
documentado o que está e o que não está incluído em nosso produto final. 
TEMA 3 – PROBLEMAS ORIGINADOS DA MÁ GESTÃO DO ESCOPO 
Fazendo uma reflexão sobre o tema anterior sobre a importância do 
escopo do projeto, conseguimos perceber de imediato que problemas ocorrerão 
se houver má gestão. 
Figura 1 ‒ A importância de uma boa gestão de escopo 
 
Fonte: Bovolini Jr., 2011. 
Candido Marcelo
Realce
 
 
06 
O cartoon anterior é engraçado, mas pode se tornar muito real se o 
processo de gestão de escopo não for bem conduzido. E o que interessa nesse 
nosso exemplo? Aquilo que o nosso cliente realmente quer, é claro. Aqui fica 
óbvio que não houve definição e validação do escopo inicial e nem de entregas 
intermediárias. 
Um escopo mal definido traz prejuízos que muitas vezes não podem ser 
compensados. Perde-se dinheiro, tempo e até mesmo reputação, ou seja, bens 
tangíveis e intangíveis. A perda de um cliente pode até significar a morte de uma 
empresa. 
Também é possível encontrar um escopo bem elaborado, mas mal 
validado e controlado. Por isso, não podemos nos esquecer de que nosso plano 
de gerenciamento de escopo deve conter todas as informações sobre como 
cuidar do escopo durante todo o ciclo de vida do projeto. 
Com um bom plano, alguns problemas relacionados ao escopo podem ser 
evitados, como por exemplo, a alteração descontrolada deste. Esses problemas 
são basicamente de dois tipos: 
1. Scope creep: distorção do escopo do projeto sem levar em conta os 
reflexos em custo, prazo, qualidade etc. São alterações solicitadas pelo 
cliente e aceitas pela equipe do projeto sem antes passá-las pelos 
processos de controle de mudanças; 
2. Gold plating: semelhante ao scope creep, mas feito com a iniciativa da 
equipe de projetos. Talvez seja um problema provocado na tentativa de 
agradar o cliente ou de criar um produto mais robusto. 
Vejam que as duas definições anteriores se referem a não conduzir os 
processos de gerenciamento de escopo de projeto de maneira adequada. O 
produto final será diferente daquele que foi planejado. E não podemos dizer, de 
forma alguma, que isso “melhorou” o produto. Afinal, o projeto "não entregou" o 
que foi contratado. 
A figura a seguir apresenta os custos das mudanças em um projeto, que 
crescem na medida em que as atividades são desenvolvidas. Fica bem claro que 
uma entrega não planejada ou a alteração em uma entrega têm custos que 
podem extrapolar os valores orçados inicialmente. 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
07 
Figura 2 ‒ Custos de mudanças em um projeto 
 
Fonte: Project Management Institute (2014, p. 40). 
Então, vamos cuidar bem do escopo de nossos projetos para evitar que 
as outras áreas tenham algum tipo de problema ou prejuízos em razão de má 
gestão. 
TEMA 4 – PROCESSOS DE GESTÃO DE ESCOPO 
Para realizar uma boa gestão de escopo, temos antes que definir alguns 
processos que deverão ser utilizados. Além do planejamento de gerenciamento 
de escopo ‒ que vimos no Tema 1 desta aula ‒ há alguns outros que você deve 
conhecer, e que abordaremos nas seções a seguir. 
4.1 Coleta e gerenciamento de requisitos 
Existe uma variedade de técnicas que podemos explorar para coletar e 
gerenciar os requisitos e as necessidades dos interessados no projeto. Por isso 
é importante definir qual plano deverá ser utilizado. Vejamos alguns exemplos: 
 Alguns projetos são fundamentados em uma venda de produto ou na 
prestação de um determinado serviço. Nesse caso, uma ótima fonte de 
informação que podemos buscar é o contrato, ou mesmo a proposta e os 
prospectos apresentados ao cliente. É uma boa maneira de conseguir 
informações sobre os requisitos e também de definir o escopo; 
 Na área de contratações públicas, o que define o escopo das entregas é o 
edital de licitações. Certamente é nele que se encontrarão os requisitos 
iniciais do projeto; 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
08 
 Reuniões são ótimas oportunidades para se fazer coleta de requisitos e 
definição de escopo. Aqui é importante ressaltar que a documentação é 
fundamental. Uma ata de reunião que informe o que foi tratado e decidido 
certamente evitará questionamentos no futuro. 
4.2 Definição de escopo 
Com os requisitos levantados e documentados, podemos partir para a 
definição de escopo. Novamente, a capacidade técnica do gerente do projeto, de 
sua equipe e de outros envolvidos especializados no assunto deve ser utilizada. 
Já vimos que um escopo mal construído pode trazer uma série de 
problemas; então, a atenção nessa fase deve ser muito grande. 
4.3 Criação da estrutura analítica do projeto (EAP) 
Com o escopo bem definido, devemos detalhá-lo, construindo uma 
estrutura com entregas menores que facilitarão o gerenciamento e a 
visualização do todo. Um dos produtos de gerenciamento que serão gerados 
aqui é a estrutura analítica do projeto (EAP), que abordaremos com detalhes 
mais adiante. 
A EAP também é conhecida pelo seu equivalente na língua inglesa, work 
breakdown structure (WBS). 
4.4 Validação de escopo 
A validação garante, pelo menos em um determinado momento, que o 
escopo foi definido de maneira correta. O que, no entanto, não quer dizer que 
mudanças não ocorrerão, ou que estas não possam acontecer. Isso não quer 
dizer que houve um erro na definição do escopo, apenas que os processos e os 
negócios podem mudar com o tempo, de acordo com a necessidade ou com 
uma alteração legislativa etc. 
A validação do escopo acontece também durante todo o ciclo de vida do 
projeto, em que processos de validação de entregas também devem ser 
executados para que possamos verificar se o que foi entregue está de acordo 
com o escopo previsto para cada fase. Essas validações intermediárias ajudam 
a evitar surpresas que seriam descobertas só no fim do projeto. Além do mais, 
são necessárias para registrar a aceitação formal daquilo que foi entregue. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
09 
4.5 Controle de escopo 
O controle de escopo reúne ações que permitem mudanças naquilo que 
foi planejado inicialmente. Novamente, não existe nenhum problema em se 
alterar um escopo, desde que o protocolo para isso seja seguido. Documentos 
deverão ser gerados para auxiliar no entendimento das alterações e para 
registrar a concordância dos responsáveis pela autorização desse procedimento. 
Quando mudanças no escopo são solicitadas, existe uma chance muito 
grande de outras áreas (de custos, tempo, recursos humanos etc.) do projeto 
também sofrerem mudanças. Assim, uma requisição de mudança de escopo 
deverá desencadear um processo de mudança integrada. 
Todos esses processos de gerenciamento de escopo devem estar 
desenhados e documentados no plano de gerenciamento de projeto. Os 
artefatos que serão produzidos devem ter modelos e exemplos de 
preenchimento. É burocrático? Sim, mas essa é a boa burocracia, que garante 
que os processos sejam seguidos de acordo com a padronização de tarefas. 
Assim, toda a equipe envolvida saberá o que esperar e o que fazer durante todo 
o projeto. 
Nas próximas aulas, estudaremos com mais profundidade cada um dos 
processos citados anteriormente. 
TEMA 5 – PLANEJAMENTO DA GESTÃO DE ESCOPO 
O escopo é uma parte do projeto,talvez a mais importante, pois define o 
que deve ser entregue. Mas, mesmo assim, é apenas uma parte do projeto. Por 
isso, é necessário que se conheçam mais informações para que o 
gerenciamento seja possível. 
Um exemplo de documento que podemos utilizar aqui é o de formalização 
de abertura do projeto. Muitas empresas usam o chamado termo de abertura do 
projeto (mais conhecido como TAP), no qual constam informações em alto nível 
para que o gerente do projeto possa elaborar o plano de gerenciamento de 
escopo. Além disso, o conhecimento da realidade dos envolvidos ‒ empresa, 
fornecedores, cliente, estrutura organizacional, procedimentos internos e lições 
aprendidas de projetos anteriores, entre muitas outras variáveis ‒ servirão de 
apoio para a elaboração desse plano. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
010 
Outro documento importante para subsidiar o trabalho do gerente do 
projeto é o próprio plano de gerenciamento. Informações relevantes serão 
conhecidas, como por exemplo, artefatos e ferramentas que deverão ser 
elaborados. 
O plano de gerenciamento de escopo é um conjunto de processos, e esse 
entendimento deve ficar claro para todos os envolvidos. A especificação do 
escopo, seu detalhamento, como ele será mantido e como poderá ser alterado, 
além de quem poderá aceitar as entregas ou mesmo sugerir ou solicitar 
mudanças fazem parte desse plano, e acompanhará o projeto até o seu fim. 
Ao planejarmos o gerenciamento de escopo, podemos definir quais 
processos e ferramentas são mais adequados para um determinado projeto. É 
importante dizer que ao se construir metodologias internas ou seguir alguma 
metodologia externa para a criação e condução de projetos, elas devem ser 
flexíveis o suficiente para se adequarem aos vários tipos de demandas. Um 
projeto de grande porte não exigirá o mesmo tempo de planejamento que um de 
pequeno porte. 
Esse trabalho, que resultará no plano de gerenciamento de escopo, pode 
ser conduzido pelo gerente do projeto e contar com a colaboração de outras 
pessoas. Um gerente de projetos não precisa ser necessariamente especialista 
na área do projeto que ele irá conduzir. Ok, sabemos que se ele for especialista 
tudo será mais fácil, mas que ele deve ser bom mesmo é em gestão. Assim, 
contar com a opinião de especialistas no assunto ajuda na definição do melhor 
processo para gerenciar o escopo. A colaboração de outros envolvidos também 
pode ser útil. Afinal, se alguém com a responsabilidade de validar as entregas 
não concordar com a forma como isso será feito, o projeto enfrentará 
dificuldades. 
O plano de gerenciamento de escopo também deve dar uma atenção 
especial aos requisitos, que são as informações coletadas e administradas para 
se detalhar todo o escopo do projeto, buscando e entendendo as necessidades 
de todos os interessados. Teremos uma aula específica para falar deles, dada a 
sua importância. Até mesmo um plano de gerenciamento de requisitos pode ser 
elaborado. 
O plano de gerenciamento de escopo e o plano de gerenciamento de 
requisitos fazem parte do plano de gerenciamento de projeto, o que deixa claro a 
forma como todo projeto deve ser conduzido, monitorado e controlado, 
consolidando e integrando todas as informações. 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
011 
FINALIZANDO 
Verificamos nesta aula que o gerenciamento de escopo é fundamental 
para o sucesso de nosso projeto. Um escopo bem definido e conduzido fará com 
que as outras áreas de gerenciamento de projeto sejam executadas sem 
maiores problemas. 
Os processos aqui envolvidos devem ser bem definidos com todos os 
participantes do projeto, e devem ser documentados de forma a facilitar toda a 
gestão do trabalho e das entregas. 
Não podemos confundir a formalização necessária com uma burocracia 
que não seja boa. Para isso, a condução do planejamento do escopo deve estar 
de acordo com seu porte e complexidade. 
Leitura obrigatória 
Em vez de ler, vamos escutar. Acesse o podcast do professor Ricardo 
Vargas sobre gerenciamento de escopo. Disponível em: <https://ricardo-
vargas.com/pt/podcasts/scopemanagement/>. 
 
 
https://ricardo-vargas.com/pt/podcasts/scopemanagement/
https://ricardo-vargas.com/pt/podcasts/scopemanagement/
Candido Marcelo
Realce
 
 
012 
REFERÊNCIAS 
BOVOLINI JR., I. Gestão de projetos: o escopo, este menosprezado. TI 
especialistas: desenvolvendo ideias. Disponível em: <https://www.tiespecialista
s.com.br/2011/04/gestao-de-projetos-o-escopo-este-menosprezado/>. Acesso 
em: 9 nov. 2017. 
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em 
gerenciamento de projetos: Guia Pmbok®. 5. ed. São Paulo: Saraiva, 2014. 
XAVIER, C. M. S. Gerenciamento de projetos: como definir e controlar o 
escopo do projeto. São Paulo: Saraiva, 2006. 
VARGAS, R. V. Gerenciamento de escopo. Podcast. Disponível em: 
<https://ricardo-vargas.com/pt/podcasts/scopemanagement/>. Acesso em: 9 nov. 
2017. 
_____. Manual prático do plano de projeto: utilizando o PMBOK® Guide. 3. ed. 
rev. Rio de Janeiro: Brasport, 2007. 
AULA 2 
GERENCIAMENTO DE ESCOPO 
EM PROJETOS
Prof. Marcelo Bellon Ferreira 
 
 
02 
CONVERSA INICIAL 
 Em nossa primeira aula, dissemos que analisaríamos com mais detalhes 
alguns dos processos indicados para uma boa gestão de escopos. Então, como 
prometido, na aula de hoje falaremos de coleta e gerenciamento de requisitos. 
Para começar, recomendamos que um plano de gerenciamento de requisitos 
seja elaborado. Esse plano deve conter todas as informações de como os 
requisitos devem ser tratados: como podem ser levantados (técnicas, 
documentação etc.), quais procedimentos de análise de impacto devem ser 
usados em caso de mudanças de escopo ‒ que geralmente ocorrem quando há 
alteração de um requisito ‒ e como devem ser mensurados para que saibamos 
se o objetivo de um determinado requisito foi cumprido. 
 Assim, nesta aula, daremos continuidade à anterior, analisando como o 
escopo e os requisitos devem ser integrados ao projeto, de quem é a 
responsabilidade pela coleta e pela escolha dos requisitos e porque é tão 
necessário rastreá-los ao longo de todo o trabalho. 
CONTEXTUALIZANDO 
 Imagine que você tivesse sido contratado como gerente de projetos de 
uma das obras nos estádios da Copa do Mundo de Futebol e tivesse recebido o 
seguinte escopo de projeto: construir o corredor de mobilidade do aeroporto até 
o estádio da cidade do Rio de Janeiro. Isso teria sido suficiente para fazê-lo 
entender quais deveriam ter sido as suas entregas? E mais, no documento do 
projeto estava escrito que as obras não deveriam ser muito caras e nem 
demorar muito tempo para ficarem prontas. 
 Percebemos aqui que faltaram detalhes, e que para que uma definição do 
escopo pudesse ter sido ser feita teria sido necessário obter mais informações. 
 É em uma situação como essa que entra o conhecimento de gestão de 
requisitos. Eles é que nos dizem quais as características dos produtos que 
devemos utilizar para que o projeto seja um sucesso. 
 A objetividade é fundamental para evitar que haja diferentes 
interpretações do mesmo escopo. Então, se para o nosso projeto da Copa do 
Mundo pediu-se que as obras não fossem muito dispendiosas, o correto teria 
sido ouvir os patrocinadores e envolvidos no projeto para que eles definissem 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
03 
"caro" e "barato", e o que mais estivesse no planejamento prévio de custo da 
obra. 
Então, vamos ser objetivos em nosso levantamento de requisitos e 
documentá-los de maneira correta? 
TEMA 1 – COLETA DE REQUISITOS 
 O Project Management Body of Knowledge (PMBOK®),1 em sua 5ª 
edição, define coleta de requisitos como: 
[...] o processo de determinar, documentar e gerenciar as necessidades 
e requisitos das partes interessadas a fim de atender aos objetivosdo 
projeto. O principal benefício deste processo é o fornecimento da base 
para definição e gerenciamento do escopo do projeto, incluindo o 
escopo do produto. (Project Management Institute, 2014, p. 109) 
 A partir dessa definição, podemos perceber que são os requisitos que 
orientam e detalham o trabalho a ser feito da forma que os interessados 
esperam, atendendo suas expectativas em relação ao produto e também em 
relação ao processo de gerenciamento de projeto. 
 Para realizarmos as tarefas necessárias e atingirmos os objetivos de um 
projeto, devemos ter conhecimento das informações básicas sobre ele. 
Precisamos saber quem são as partes interessadas e quais são os seus papéis, 
quais requisitos de alto nível já foram repassados pelo cliente e como deverão 
ser os processos de gerenciamento desses requisitos que nortearão a condução 
dos trabalhos. 
 Um bom conjunto de requisitos deve conter características que 
possibilitem definir e gerenciar com mais detalhes o escopo do projeto. Ele deve 
ser: 
 Objetivo: definir com clareza o que se deseja, não deixando margem para 
ambiguidades. 
 Verificável: esta é uma característica que complementa a anterior. Os 
requisitos devem ser verificados ao longo do projeto. Por exemplo: os 
registros contábeis do sistema devem ser armazenados segundo a 
temporariedade exigida pela lei. 
 Útil: os requisitos devem ter relação com o escopo macro do projeto e 
atender as necessidades das partes interessadas. Deve-se tomar o 
 
1 O PMBOK® é o conjunto de boas práticas sugeridas para o gerenciamento de projetos. É 
organizado pelo Project Management Institute. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
04 
cuidado de não especificar algo que jamais será usado e só trará mais 
custos e complexidade ao projeto. O levantamento de requisitos ajudará 
inclusive o cliente a entender melhor o que ele mesmo espera do projeto. 
 Mensurável: além de verificar os requisitos, também temos de poder 
medi-los. Em alguns casos é necessário que o projeto atenda 100% dos 
requisitos, como no exemplo dos registros contábeis que demos 
anteriormente; em outros casos, atingir um percentual preestabelecido é 
suficiente. Um exemplo deste último caso poderia ser o percentual 
mínimo de empregados que aderiram ao programa de incentivo ao 
esporte oferecido pela empresa. 
 Essas são apenas algumas sugestões de características que podemos 
estabelecer para um conjunto de requisitos. Muitas outras podem ser 
imaginadas para agregar qualidade à coleta. 
 Também podemos pensar em tipos ou categorias de requisitos. Essa 
classificação pode ajudar quando há prioridades na implementação. Os tipos 
podem ser: necessidades do negócio, necessidades das partes interessadas, 
características do produto, características não funcionais (por exemplo, o nível 
do serviço esperado), requisitos de qualidade etc. 
 Vejamos agora um exemplo de como seria um documento de coleta de 
requisitos: 
Tabela 1 ‒ Exemplo de documento de coleta de requisitos 
 
A partir da coleta, construímos nosso projeto com detalhes que auxiliam 
outras áreas, como as de custos, aquisições, qualidade, recursos humanos etc. 
Um erro aqui ou uma coleta superficial ali podem conduzir a um fracasso total. 
Às vezes, um único requisito menosprezado é suficiente para isso. Um exemplo? 
Se o requisito relacionado à licença ambiental de um projeto de construção de 
uma nova planta industrial for esquecido ou considerado subentendido pelas 
partes, atrasos podem ocorrer, ou pode-se mesmo verificar a inviabilidade do 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
05 
negócio em um estágio no qual recursos financeiros já foram investidos e já não 
exista nenhuma chance de recuperá-los. 
TEMA 2 – RESPONSABILIDADES NA COLETA DE REQUISITOS 
 O plano de gerenciamento de requisitos deve informar quem são os 
responsáveis pela coleta. Basicamente, podemos imaginar que o gerente de 
projetos é quem deve fazer isso. 
 Mas, dependendo do porte do projeto, uma equipe pode ser necessária 
para executar esse trabalho. Assim, o escopo preliminar deve ser dividido para 
que assuntos correlatos sejam analisados em conjunto e para que a equipe 
incumbida da coleta possa levantar requisitos associados àquela parte do 
escopo total estabelecida no início do projeto. Mesmo nesse caso, a 
responsabilidade final é do gerente do projeto, que não executará a coleta 
propriamente dita, mas verificará o andamento dos trabalhos, se a técnica 
utilizada está de acordo com os processos e se o resultado pode ser utilizado no 
restante do projeto. Sua preocupação maior será a forma da coleta, e não o seu 
conteúdo. 
 Uma boa equipe é aquela formada por especialistas. Se o projeto trata da 
construção de uma nova plataforma de serviços eletrônicos para hospitais, o 
responsável pela coleta de requisitos deve ser um analista de sistemas que 
tenha tido alguma vivência na área de sistemas de saúde. Ou o analista de 
sistemas responsável pode simplesmente contar com a colaboração de algum 
especialista que o auxiliará com as técnicas aplicadas à coleta. 
 Vejam a grande responsabilidade que é a coleta de requisitos: é durante 
esse processo que temos uma visão clara daquilo que o projeto deve entregar. 
Uma coleta malfeita ou incompleta pode resultar em algo que não atenderá as 
necessidades do cliente e poderá simplesmente inutilizar o produto que for 
desenvolvido. 
 Para conhecer os requisitos do projeto, o gerente ou a equipe formada 
para executá-lo devem estar atentos à qualidade das informações levantadas. 
Lembre-se das características mencionadas no tema anterior! E, caso existam 
divergências sobre os requisitos entre os interessados no trabalho, todas as 
versões da informação precisam ser registradas para que uma análise posterior 
seja feita quando o escopo for definido. Afinal, todas as ideias e opiniões são 
importantes. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
06 
 O ideal é que o registro das informações de coleta seja feito por uma 
única pessoa; isso garante um padrão de escrita, o que facilitará o entendimento 
da relação entre os requisitos no futuro. 
 Há outros responsáveis pelos procedimentos de coleta: o cliente, o 
patrocinador e outras pessoas e instituições interessadas no projeto. Colher as 
informações corretas e apresentar documentos são exemplos das 
responsabilidades atribuídas a todos os participantes no projeto. 
 Enfim, podemos dizer que a responsabilidade pela lista de requisitos é do 
cliente, que é aquele que conhece, ou deveria conhecer, o negócio que se quer 
estabelecer ou a problemática que se quer resolver. A responsabilidade do 
gerente de projeto é conduzir as coletas de requisitos de modo que o processo 
seja obedecido, propiciando condições ideais para que o cliente exponha suas 
necessidades e anseios. 
TEMA 3 – TRATAMENTO DAS PARTES INTERESSADAS E SUA REPERCUSSÃO 
NO ESCOPO 
 Para entendermos este tema, primeiramente precisamos saber quem são 
os stakeholders. Uma tradução livre para essa palavra seria “partes 
interessadas”. No caso do gerenciamento de um projeto, as partes interessadas 
são aquelas que, de alguma forma, não só têm interesse no projeto, mas 
também participam dele e o influenciam, ou são afetadas direta e indiretamente 
por ele. Essa interação pode tanto ocorrer de maneira positiva quanto negativa. 
Como exemplos de stakeholders, podemos citar o corpo diretor do cliente, os 
empregados, os fornecedores, o conselho fiscal, os consumidores do produto, a 
comunidade local, os gestores públicos etc. 
 Assim, podemos perceber que é vital conhecer quem são as partes 
interessadas em nosso projeto e de quemaneira elas podem afetar o 
entendimento do escopo. 
 Todo projeto deve ter um plano de gerenciamento das partes 
interessadas. Esse documento é importante para que o gerente do projeto 
entenda o papel de cada um dos envolvidos no planejamento e na execução do 
trabalho, e também as atitudes que cada um deve tomar em determinadas 
situações. Um exemplo de atitude é o que deve ser feito no caso da ausência de 
determinada parte interessada em reuniões de validação. Muitas outras 
situações devem ser previstas e respondidas pelo plano. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
07 
 Uma boa prática é que o registro das partes interessadas seja feito pelo 
patrocinador do projeto, que pode passar informações relevantes para o gerente. 
Dessa forma, será possível entender como cada interessado interagirá durante 
as atividades e até mesmo o que se pode esperar de cada um deles. Há alguém 
resistente ao projeto? Há alguém altamente motivado e interessado nos 
resultados? Há um especialista no negócio? Essas são apenas algumas das 
considerações que podem ser feitas, há muitas outras possíveis! Veja que é 
mais fácil trabalharmos quando temos uma expectativa de como cada 
interessado pode se portar. 
 Esse registro pode conter uma série de informações, como: nome, 
telefone, endereço de e-mail, local de trabalho, cargo, idiomas que fala, grau de 
importância na tomada de decisões (se é um decisor ou apenas alguém que 
passará informações), se possui preferências por algum tipo de comunicação 
etc. 
 O plano também deve mostrar como se dará a comunicação entre os 
participantes, com quais periodicidade e grau de confidencialidade. Algumas 
informações podem ser tão sensíveis que apenas um grupo de interessados 
poderá decidir o que fazer com elas ou acessá-las. Outras informações poderão 
ficar abertas a todos os interessados. O fato de o projeto ter um plano de 
gerenciamento de comunicações pode ajudar nesse processo. 
 Conhecidas as partes interessadas, podemos entender como cada uma 
delas influencia a coleta e a validação de requisitos e, consequentemente, o 
escopo do projeto. Você se lembra de que no tema anterior falamos que podem 
existir divergências entre as partes interessadas durante a coleta? Bem, quando 
conhecemos o grau de influência de cada um dos envolvidos, podemos saber 
como será tomada a decisão sobre qual requisito é realmente válido para a 
implementação do projeto. Nesse momento podem existir conflitos, e o gerente 
de projeto deve ter a capacidade de negociar nesses casos, já que não há nada 
pior do que o descontentamento de uma das partes interessadas. 
Provavelmente, se a situação não for resolvida, essa mesma "parte" pode se 
tornar um entrave e influenciar negativamente o desenrolar do trabalho. 
 Não podemos nos esquecer de que cada projeto é único e deve gerar um 
resultado também único. Assim, um interessado que seja uma pessoa-chave em 
um trabalho, com grande grau de influência, pode não sê-lo no próximo. Temos 
que avaliar novamente os requisitos de alto nível, o plano de gerenciamentos 
das partes interessadas e entender o novo papel que esse indivíduo terá. 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
08 
TEMA 4 – TÉCNICAS DE COLETA DE REQUISITOS 
 Existem diversas técnicas que podem ser utilizadas na coleta de 
requisitos. Serão usadas as que, preferencialmente, já estejam definidas no 
plano de gerenciamento de requisitos. Veremos a seguir algumas que podem 
ser utilizadas. É só uma lista exemplificativa, pois existe uma infinidade delas! 
 Entrevista: uma das técnicas mais tradicionais em que uma série de 
perguntas previamente elaboradas direcionam a conversa com os 
interessados. Podem participar mais de um entrevistador e também mais 
do que um entrevistado. 
 Grupo de discussão: técnica parecida com a da entrevista, mas reúne 
interessados e especialistas que respondem perguntas relacionadas aos 
requisitos. Um moderador conduz as sessões para que conflitos sejam 
dirimidos. 
 Sessão de brainstorming: a intenção aqui é reunir interessados e coletar o 
máximo de ideias. A única restrição é que elas estejam relacionadas ao 
escopo macro do projeto. Difere do grupo de discussão por ser totalmente 
livre quanto ao que pode ser sugerido. Em um segundo momento, essas 
ideias são classificadas e o grupo detalha aquelas que tiveram uma 
aceitação maior, dando origem aos requisitos do projeto. 
 Mapas mentais: técnica que coloca em um diagrama todo o conjunto de 
ideias sobre um tema, conectando as semelhantes para facilitar a 
visualização. Seu conteúdo pode ser alimentado pelo resultado de 
qualquer outra técnica. Hoje existe uma grande variedade de softwares 
para o desenho dos mapas, e muitos são gratuitos. Vejamos um exemplo 
de mapa mental: 
Figura 1 ‒ Mapa mental 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
09 
 Questionário e pesquisa: técnica útil quando existe um número muito 
grande de envolvidos que precisam ser ouvidos. Após receber as 
respostas, podemos fazer uma tabulação e, por meio de métodos 
estatísticos, conhecer a informação desejada; 
 Análise de documentos: os documentos da organização são uma 
importante fonte de informação para a geração de requisitos, e não 
podem ser ignorados. Muitas vezes, a história da empresa, representada 
em seus documentos, influencia o modo como o projeto será gerenciado 
e fornece requisitos importantes para o detalhamento do escopo; 
 Observação: observar o comportamento das pessoas quando realizam 
suas atividades pode ajudar a entender melhor o negócio e os requisitos, 
pois elas podem ter dificuldade em explicar o que fazem ou o trabalho 
pode ser muito complexo; 
 Prototipagem: técnica para se obter informações iniciais sobre o produto, 
pois facilita a visualização e a realização de testes básicos. Por meio 
dessa técnica também se pode abordar o desenvolvimento de um produto 
mínimo viável (MVP, do inglês minimum viable product), que é uma 
versão simplificada, mas funcional, do produto desejado. A partir de 
protótipos ou MVPs, as partes interessadas podem imaginar e 
incrementar os requisitos para o produto final. 
 Benchmarking: por meio desta técnica, busca-se projetos ou casos 
semelhantes para que seja feita uma comparação com o que se espera 
de um novo projeto. A ideia aqui é aproveitar lições aprendidas e técnicas 
já consolidadas. As referências para comparação podem ser encontradas 
tanto dentro quanto fora da organização. 
 Nenhuma técnica é melhor que a outra. Todas possuem vantagens e 
desvantagens. A escolha de uma delas deve ser adequada ao escopo do 
projeto, ao perfil e à disponibilidade das partes interessadas, e até mesmo ao 
conhecimento da equipe do projeto para aplicá-la. A combinação com outras 
técnicas também é importante para se levantar o máximo de informações 
possível para a elaboração dos requisitos. 
TEMA 5 – RASTREABILIDADE DE REQUISITOS 
 O conhecimento dos requisitos do projeto faz com que a equipe entenda o 
negócio e como o escopo foi construído. Um componente importante para nosso 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
010 
projeto e para a equipe é a matriz de rastreabilidade dos requisitos. É por meio 
dela que se faz a ligação dos requisitos com os objetivos de negócio que o 
projeto deve atender. Ela também possibilita o acompanhamento do projeto, 
fazendo com que os requisitos aprovados nas documentações sejam entregues 
durante ou ao final do trabalho. 
Tabela 2 ‒ Matriz de rastreabilidade de requisitos 
 
 A Tabela 2 é um exemplo de documento utilizado para rastrear requisitos. 
Note que ela nos ajuda identificara relação do requisito e suas entregas 
rapidamente. Veja também que ela é muito parecida com a Tabela 1, aquela 
sobre levantamento de requisitos; inclusive, poderíamos pensar em juntar as 
duas em um único documento. Mas um documento com muitos atributos por 
requisito pode dificultar a leitura e o manuseio, por isso decidimos usar folhas 
separadas, uma complementando a outra. 
 Muitos outros cruzamentos de informação podem ser válidos e utilizados 
para rastrearmos os requisitos e suas implicações no projeto. Vamos a outro 
exemplo: 
Tabela 3 ‒ Matriz de rastreabilidade de requisitos X requisitos 
 
 Aqui a ideia é identificarmos como um requisito afeta o outro. A 
interpretação que podemos fazer é que quando validamos um requisito, outros 
sofrem impacto e podem necessitar de controle e validação também. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
011 
 Outro uso importante da matriz de rastreabilidade se dá quando uma 
alteração de requisitos é efetuada, o que pode acontecer ainda na fase de 
elaboração do projeto ou durante a sua implementação. Isso é algo que está fora 
do controle de qualquer gerente de projetos: mudanças! O que podemos fazer é 
estar preparados par elas. 
 A alteração de um requisito deve desencadear ações por parte do 
gerenciamento e do controle integrado de mudanças do escopo, que só serão 
eficazes se pudermos rastrear o impacto que aquele requisito tem em nosso 
projeto. Se utilizarmos os documentos de que tratamos anteriormente, a 
alteração se dará de maneira simples: se o negócio sofreu alguma mudança (por 
exemplo, se foi promulgada uma nova lei), saberemos quais requisitos terão de 
ser reavaliados; já se a alteração se deu em algum requisito (por exemplo, o 
cliente mudou de ideia sobre a obrigatoriedade do fornecimento de uma 
informação no novo sistema de contabilidade da empresa), saberemos qual 
parte do negócio e das entregas deverão sofrer mudanças. 
 O processo de controle de mudanças deve prever como será feita a 
atualização da documentação referente aos requisitos. Ele deve incluir o controle 
de versões do documento, a origem das mudanças, a data de execução etc. 
 Como dito anteriormente, a complexidade e a dimensão do projeto é que 
determinam os artefatos que serão utilizados em seu planejamento, controle e 
execução. Essa determinação já pode ser sugerida nos documentos iniciais do 
projeto, que são repassados para as equipes responsáveis pela coleta de 
requisitos. Aqui é importante deixar claro que artefatos ‒ como a matriz de 
rastreabilidade de requisitos, por exemplo ‒ podem não ser necessariamente 
uma planilha eletrônica, mas eventualmente um software de controle. 
FINALIZANDO 
 Nesta aula, pudemos compreender a importância dos requisitos e seu 
impacto no escopo de nosso projeto. Verificamos que o tratamento das partes 
interessadas está diretamente ligado às responsabilidades de coletas e análise 
de requisitos. 
 Vimos alguns exemplos de técnicas que podem ser utilizadas na coleta de 
requisitos e a documentação mínima que auxilia no entendimento do negócio 
gerado pela análise dos requisitos. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
012 
 A rastreabilidade é fundamental para que os requisitos sejam controlados 
ao longo de todo o projeto e auxiliem na importante e delicada tarefa de analisar 
o impacto de mudanças de escopo. 
 Um conjunto de requisitos com qualidade permite que o projeto tenha 
uma chance ainda maior de sucesso. 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
013 
REFERÊNCIAS 
BELTRÃO, G. 7 dicas de como fazer um mapa mental de sucesso. Blog do 
Curseduca. Disponível em: <https://curseduca.com/blog/7-dicas-para-fazer-um-
mapa-mental-eficiente/>. Acesso em: 9 nov. 2017. 
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em 
gerenciamento de projetos: Guia PMBOK®. 5. ed. São Paulo: Saraiva, 2014. 
REY, B. Como fazer um brainstorm eficiente. Revista Exame, 26 jun. 2013. 
Disponível em: <http://exame.abril.com.br/carreira/como-fazer-um-brainstorming-
eficiente/>. Acesso em 9 de nov. 2017. 
XAVIER, C. M. S. et al. Metodologia de gerenciamento de projetos ‒ 
Methodware®: abordagem prática de como iniciar, planejar, executar, controlar e 
fechar projetos. Rio de Janeiro: Brasport, 2014. 
VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais 
competitivos. 8. ed. Rio de Janeiro: Brasport, 2016. 
 
https://curseduca.com/blog/7-dicas-para-fazer-um-mapa-mental-eficiente/
https://curseduca.com/blog/7-dicas-para-fazer-um-mapa-mental-eficiente/
http://exame.abril.com.br/carreira/como-fazer-um-brainstorming-eficiente/
http://exame.abril.com.br/carreira/como-fazer-um-brainstorming-eficiente/
AULA 3 
GERENCIAMENTO DE ESCOPO 
EM PROJETOS
Prof. Marcelo Bellon Ferreira 
 
 
2 
CONVERSA INICIAL 
Nesta aula, analisaremos o momento em que o escopo é definido. Com 
base nos requisitos coletados, podemos detalhar aquilo que nosso projeto 
entregará. 
Aprenderemos que nem sempre é possível atender a todos os requisitos 
coletados, pelo menos em um primeiro momento. 
Restrições e premissas serão estudadas, e a relação entre elas e os riscos 
do projeto será evidenciada. 
Ao definir o escopo, podemos entendê-lo e controlá-lo. Uma linha base (ou 
baseline) será nossa referência na comparação com os resultados que obtivermos 
durante a execução do projeto. 
CONTEXTUALIZANDO 
Quando alguém imagina um projeto, geralmente o faz, em um primeiro 
momento, em um mundo ideal. Nele, há todo o dinheiro do mundo, recursos 
humanos disponíveis e capacitados, prazos de entrega com muitos dias sobrando 
para contingências. Mas o mundo real é um “pouco” diferente do ideal. 
No mundo real, provavelmente nossos clientes sempre vão querer "tudo", 
mas a um custo baixo (acredite, alguns podem até querer de graça) e com entrega 
para ontem. E uma boa definição de escopo é que vai ajudar o gerente de projeto 
a "puxar" as partes interessadas e os patrocinadores de volta à realidade, 
mostrando que deve existir uma priorização do que será entregue, que o projeto 
vai ter custos e que eventualmente desvios pelo caminho poderão surgir e deverão 
ser controlados. Esta aula vai ajudar o gerente a traçar o melhor caminho para 
lidar da melhor forma possível com isso. 
TEMA 1 – DEFINIÇÃO DE ESCOPO 
A definição de escopo de um projeto deve descrever em detalhes o produto, 
o serviço ou o resultado a ser entregue, além de todo o trabalho que deverá ser 
executado. Esses detalhes devem suficientes para que se possa compreender 
com exatidão toda a amplitude do projeto. Um nível menor de detalhamento pode 
fazer como que não se compreenda exatamente o que deve ser entregue, 
enquanto um nível muito grande de detalhamento, realmente exagerado, pode 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
3 
aumentar em muito o trabalho de planejamento e não ser útil. Assim, cabe ao 
gerente de projeto balancear o nível de detalhes realmente necessário. 
Outro fator que influencia o detalhamento de escopo é a abordagem de 
execução que será adotada pela equipe. Em uma abordagem mais tradicional, o 
escopo é mais detalhado, pois é definido na fase de planejamento e alterado 
apenas por fatores não previstos ou conhecidos e gerenciados por um processo 
de controle de mudanças. Já se é utilizada uma metodologia ágil, muito comum 
principalmente em projetos de software, o detalhamento é construído de acordo 
com as diversas interações da equipe com as partes interessadas. Nesse caso, o 
mais importante é saber até onde os resultados dos trabalhos devem chegar. 
A definição de escopo deve seguir as regras e diretrizes estipuladas pelo 
projeto. Esse regramento está presente no plano de gerenciamento de escopo,que estabelece como ele será definido, monitorado e verificado. 
Também será necessário utilizarmos as informações do termo de abertura 
do projeto, que contém definições de alto nível sobre os resultados esperados e 
sobre como o trabalho deve ser conduzido. Veja que aqui estamos ainda no nível 
macro, aquele que foi “vendido” pelo patrocinador e que nosso processo de 
gerenciamento do projeto está planejando. 
Até aqui, já sabemos como será o processo para detalhar o escopo (plano 
de gerenciamento de escopo) e, em linhas gerais, o que o nosso projeto deverá 
entregar (termo de abertura do projeto); provavelmente, também algumas 
premissas e restrições. Falaremos delas um pouco mais à frente. 
Outro conjunto de informações que já devemos ter a essa altura, e que são 
fundamentais nessa etapa do planejamento, é a documentação dos requisitos. Na 
aula anterior foi apresentado todo o processo que os envolve e a sua importância. 
E é nesse momento que eles são efetivamente utilizados. 
Se voltarmos às técnicas e ferramentas de coleta de requisitos, 
lembraremos que, nesse momento, o importante é conhecer tudo o que os 
interessados veem como fundamental para o negócio e para o projeto, sem 
colocarmos nenhum tipo de limite. Agora, na definição do escopo isso muda. A 
análise deve ser ampla e levar em consideração outros aspectos, como prazo, 
riscos e limitação da equipe, por exemplo. 
Para o detalhamento do escopo também é essencial o uso dos chamados 
ativos de processos organizacionais. Podemos dizer que eles são o conjunto de 
políticas e históricos da empresa que devem ser utilizados em todos os projetos. 
É a personalidade empresarial que influencia a forma como os trabalhos devem 
 
 
4 
ser conduzidos, a qualidade daquilo que deve ser entregue, os fornecedores que 
podem ser contratados, os modelos de documentos utilizados, as lições 
aprendidas e qualquer outro conhecimento histórico. 
Os ativos de processos organizacionais são complementados pelo plano 
de gerenciamento do projeto, que não deve ir contra aquele, salvo por exceções 
fundamentadas e aprovadas. 
Assim, ao descrever o escopo, priorizamos aquilo que realmente importa 
para o projeto, levando em conta tudo o que já foi produzido em questão de 
processos e de informações organizacionais. Sempre vale enfatizar que a 
documentação de escopo de projeto deve incluir tudo aquilo que faz parte das 
entregas e também tudo aquilo que não será entregue. Isso evita mal-entendidos 
com as partes interessadas quanto ao produto final a ser entregue. 
TEMA 2 – TÉCNICAS DE PRIORIZAÇÃO DE ESCOPO 
Certamente, os projetos têm ao menos uma premissa: a de que não 
existem recursos (dinheiro, tempo, pessoas etc.) em número ilimitado. Em razão 
disso, temos de saber priorizar os itens do escopo. O gerente de projeto trabalhará 
para criar uma sequência lógica de entregas ou mesmo informar o que não será 
entregue a partir de uma análise de requisitos combinada com a análise de outros 
fatores que já foram comentados no tema anterior. A definição de escopo deve 
informar isso. 
Os critérios para a análise devem ser claros e formais, definidos nos 
documentos do projeto e/ou ativos da empresa. O que interessa ser entregue 
primeiro? Requisitos com menor risco ou aqueles que trazem maior visibilidade 
para a empresa? O projeto terá toda a mão de obra qualificada para já começar 
com 100% de geração de resultados desde o seu primeiro dia? Os fornecedores 
têm capacidade de entrega total desde o início do projeto? Os consumidores ‒ ou 
o mercado ‒ está pronto para já absorver toda a oferta que será feita? Veja que 
existe uma série de perguntas que precisam ser respondidas antes de iniciar a 
priorização do escopo. Essas são apenas algumas! 
Na priorização, outro fator é fundamental para a decisão: o interesse dos 
envolvidos. Se o gerente de projeto falar com cada uma das partes interessadas 
e pedir que elas classifiquem por importância cada um dos requisitos, certamente 
haverá uma lista diferente gerada por cada uma delas. Assim, o processo deve 
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
5 
envolver todos aquele que serão impactados e estão ativos no processo. Não é 
uma tarefa fácil, mas é necessária se o gerente de projeto quiser evitar problemas. 
Vejamos algumas técnicas para definir o escopo e priorizar os requisitos: 
 opinião especializada: nada melhor do que ouvir aqueles que já conhecem 
o negócio ‒ partes interessadas, consultores externos, associações 
profissionais etc.; 
 análise de produto: utilizando as informações de alto nível do produto, 
pode-se fazer uma análise que o componha a partir dos requisitos. Com 
isso, é possível priorizar e identificar aquilo que realmente faz parte dele, 
em sua essência ou de modo coadjuvante; 
 geração de alternativas: geralmente, não existe apenas uma maneira de se 
desenvolver um produto ou um serviço. Para cada alternativa podem existir 
diferentes sequências de entrega, com impactos também diferentes. 
Visualizar essas alternativas ajuda o gerente de projeto a selecionar a 
melhor das hipóteses; 
 oficinas facilitadas: aqui são reunidos os diversos interessados no projeto 
para que juntos, e conduzidos pelo gerente, indiquem os requisitos que 
devem fazer parte do detalhamento de escopo. É uma maneira de alinhar 
as diversas áreas da empresa envolvidas. 
Esses são alguns meios de organizar a priorização e de se chegar ao 
detalhamento do escopo. 
Uma das técnicas de priorização de requisitos é a recomendada pelo 
método PRINCE21. A técnica chamada de "MoSCoW", da DSDM Agile Project 
Framework, é utilizada para classificar e priorizar requisitos tendo como base o 
valor para o negócio da empresa. Vejamos o que significa cada letra em destaque: 
 M (must have, "deve ter"): o que é essencial. Sem esses requisitos, 
simplesmente o produto não existe; 
 S: (should have, "deveria ter"): é importante, mas o produto pode ser 
lançado/produzido sem esses requisitos, com pequena perda de valor 
percebido; 
 
1 PRoject IN Controlled Enviroment (projetos em ambiente controlado). Saiba mais sobre o 
PRINCE2 em: <https://www.axelos.com/best-practice-solutions/prince2>. Acesso em: 18 dez. 
2017. 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
6 
 C (could have, "poderia ter"): seria até bom que o produto/serviço tivesse 
determinada característica, mas será que clientes pagariam mais só por 
isso? 
 W (won’t have this time, "não terá agora"): no futuro, é provável que esses 
requisitos sejam implementados, mas no momento, não, por não 
representarem um real valor agregado. 
Saiba mais 
Dê uma olhada no site da Agile Business Consortium (em inglês) e 
descubra um pouco mais sobre a técnica MoSCoW. Disponível em: 
<https://www.agilebusiness.org/content/moscow-prioritisation>. Acesso em: 17 
dez. 2017. 
Com essas técnicas e ferramentas, podemos definir e priorizar com 
objetividade aquilo que o projeto deverá entregar em cada fase. 
TEMA 3 – RESTRIÇÕES E PREMISSAS 
Podemos entender as restrições e premissas também como requisitos de 
nosso projeto. São como requisitos especiais, que podem afetar o escopo, o custo, 
a qualidade, o tempo etc. 
Segundo o PMBOK®,2 uma restrição é “um fator limitador que afeta a 
execução de um projeto, programa, portfólio ou processo”. Pode ser imposta pelo 
cliente ou mesmo colocada pelas partes interessadas e pela equipe do projeto 
como resposta a algum risco. 
Esses fatores podem ser internos ou externos à organização e moderam 
as opções que a equipe de projetos pode ter para conduzir os trabalhos e as 
entregas. Um exemplo de fator interno? O número de empregados especialistas 
à disposição do gerente de projeto. Um de fator externo? A data de lançamentodo produto em função das vendas esperadas para o Natal. 
Vamos a outro exemplo: se existir um risco aumentado de demissão de 
empregados-chave para o negócio em razão do excesso de horas extras 
trabalhadas, uma restrição de projeto seria que nenhum empregado poderia fazer 
horas extras para finalizar as entregas. Mitigamos o risco! Aqui fica bem claro que 
o impacto ficará no tempo, no custo e, talvez, até no escopo, o que pode limitá-lo. 
 
2 Project Management Body of Knowledge. 
https://www.agilebusiness.org/content/moscow-prioritisation
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
7 
Uma premissa, segundo o PMBOK®, é “um fator do processo de 
planejamento considerado verdadeiro, real ou certo, sem a necessidade de prova 
ou demonstração”. 
Podemos perceber claramente a geração de risco! Como considerar algo 
verdadeiro sem a necessidade de provas? Estamos apenas supondo que algo vai 
ou não ocorrer. Basicamente, são tomadas decisões com inferências do que pode 
ser o mais próximo da realidade, pois não temos todas as informações 
necessárias naquele momento. 
Um exemplo: assumimos como premissa que o cliente fará todos os 
pagamentos em dia. Se isso não ocorrer e a premissa não for confirmada como 
verdadeira, como ficará o fluxo de caixa da empresa? Como ela pagará 
funcionários e fornecedores? Esse é o risco, que deve ser planejado e ter uma 
resposta adequada. 
Premissas e restrições podem já ser identificadas desde o nascimento do 
projeto, quando é emitido o termo de abertura de projeto. Mas lá é só o início! 
Durante outras fases de planejamento e execução, riscos podem ser 
identificados, e uma restrição pode ser imposta pela equipe do projeto de modo a 
oferecer uma resposta adequada a eles. 
Também, se principalmente durante o planejamento do projeto algumas 
decisões não são tomadas, ou respostas não são conseguidas em tempo hábil, e 
para não atrapalhar o desenvolvimento do restante dos trabalhos, pode-se ter uma 
ideia (premissa) de algo que ajude a não interromper ou atrasar o cronograma. 
Lembre-se do risco gerado e da ligação que isso deve ter com o plano de 
gerenciamento de riscos. 
O quadro a seguir nos ajuda a lembrar das principais características e 
consequências das restrições e premissas do projeto. 
 
Candido Marcelo
Realce
 
 
8 
Quadro 1 ‒ Resumo das diferenças entre restrições e premissas 
Restrição Premissa 
Resposta a um risco Gera um risco 
"Tem que" “Acho que” 
Muda o plano do escopo Muda o plano de riscos 
Não existem dúvidas Não existem certezas 
Certezas Suposições 
TEMA 4 – CONSTANTE TRIPLA E LINHA BASE (BASELINE) 
A constante tripla, ou restrição tripla, é o equilíbrio que deve existir entre o 
escopo, o custo e o prazo do projeto, de maneira que a qualidade seja 
assegurada. A pirâmide a seguir demonstra exatamente essa relação, facilitando 
o nosso entendimento. 
Figura 1 ‒ Constante (ou restrição) tripla 
 
Cada aresta representa uma área do gerenciamento de projeto, sendo o 
resultado (o equilíbrio da pirâmide) a qualidade esperada. Fica claro que elas 
devem ser pensadas em conjunto, e, se alguma delas sofre alguma mudança, o 
impacto é imediato nas demais. 
Assim, um escopo maior implica um tempo maior ou um custo maior. Da 
mesma forma, se existir pressão para que o projeto seja acelerado, o custo e/ou 
escopo sofrerão de alguma forma. E, se o cliente quiser um projeto com um custo 
menor, não será possível manter o prazo e o escopo. Devemos sempre ter em 
mente que a qualidade deve ser mantida. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
9 
Com o equilíbrio estabelecido entre as áreas, pode-se gerar as linhas base, 
ou baselines, do projeto. As linhas base são os acordos aprovados sobre o que 
se quer do projeto entre as partes envolvidas, e em todas as áreas envolvidas. Na 
prática, são os planos do projeto estabelecidos em um determinado momento. 
Então, teremos linhas base de escopo, de tempo, de custo, de riscos etc. 
Talvez a linha base mais conhecida seja a que representa o cronograma do 
projeto; mas não são apenas as informações sobre tempo e prazos que precisam 
ser controladas. 
Uma linha base é a referência que será utilizada para analisar e medir se o 
projeto está de acordo com o planejado, entender desvios e iniciar ações para que 
os trabalhos e resultados voltem ao que se esperava inicialmente. A análise e a 
comparação do projeto de seu início até o seu fim são ótimas fontes de lições para 
iniciativas futuras. E só podemos fazer comparações se tivermos as informações 
sobre o que se esperava inicialmente, ou seja, as linhas base! 
Quando o projeto não está atingindo o resultado esperado em uma 
determinada fase, devemos parar e analisar as linhas base para investigar o que 
pode estar acontecendo. Afinal, se o planejamento foi feito e não está sendo 
seguido, dificilmente podemos esperar que os resultados sejam aqueles 
desejados. 
Uma linha base pode ser alterada! No processo de gerenciamento de 
mudanças deve estar claro quando as linhas base poderão ser novamente 
gravadas. Não é qualquer modificação que gerará isso. Você incluir uma tela de 
cadastro ‒ que não foi identificada no processo de coleta de requisitos ‒ em um 
novo sistema não é tão grave assim; é aceitável, e deixará um pequeno desvio na 
linha base do escopo, talvez até mesmo sem alterações no cronograma ou nos 
custos. Mas, se em vez de uma simples tela estivermos falando de uma mudança 
na arquitetura de um sistema, que não mais atenderá apenas 100 usuários mas, 
sim, 5 mil, aí, sim, novas linhas base deverão ser geradas. (Isso poderia ocorrer, 
por exemplo, por uma falha na informação de um requisito, por uma alteração de 
processo da empresa ou mesmo em decorrência de uma alteração legislativa.) 
Quando uma nova linha base é gerada, as anteriores não devem ser 
descartadas. Elas são uma fonte valiosa de informação e nos ajudarão a entender 
como o projeto se comportou. Seus próximos projetos agradecerão pelo 
conhecimento e pelas lições aprendidas. 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
10 
TEMA 5 – DOCUMENTAÇÃO PARA A DEFINIÇÃO DE ESCOPO 
Com o escopo definido, deve ser gerado o documento de declaração de 
escopo, ou a especificação de escopo. Ele deve reunir todas as informações de que 
tratamos nos temas desta aula. 
Assim, teremos a formalização do escopo do projeto, seus produtos, serviços 
ou resultados, e também do trabalho a ser realizado para alcançar os objetivos 
propostos. 
A declaração de escopo deve incluir, ao menos: 
 descrição de escopo do projeto: o termo de abertura do projeto já contém essa 
informação, mas em alto nível. No processo de definição do escopo é feito o 
seu detalhamento, que apresenta progressivamente quais serão as 
características do projeto, baseando-se nos requisitos coletados e analisados; 
 critérios de aceitação: lista de condições que devem ser realizadas para que 
cada entrega seja considerada aceita. Em metodologias ágeis é utilizado o 
termo “pronto”, do inglês done, e sua definição é muito importante para o time 
compreender quando uma tarefa está concluída e dentro dos parâmetros de 
qualidade. 
 lista de entregas: o que efetivamente o projeto entregará. Pode ser a descrição 
do produto, do serviço (que deve ser único, verificável e ter data de início e 
fim, que são as características de um projeto) ou do resultado que deve ser 
alcançado. As entregas acessórias, como relatórios de gerenciamento e 
controle do projeto, também devem ser descritas. 
 descrição de escopo não incluído: é bom reforçar isso. O que não será 
entregue! Assim, já é feita a gestão da expectativa do cliente e ele mesmo 
sabe o que, de maneira expressa, não receberáao final do trabalho. 
 restrições: algumas são impostas pelo patrocinador ou pelas partes 
interessadas. Mas a própria equipe do projeto pode identificá-las a partir da 
análise dos requisitos coletados. 
 premissas: assim como ocorre com as restrições, elas são informadas pelo 
patrocinador ou pelas partes interessadas, mas podem ser geradas a partir 
dos trabalhos de detalhamento de escopo e refletir na lista de riscos 
identificados. 
 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
11 
Outras informações podem fazer parte da documentação gerada, 
complementando ou detalhando o que já consta no termo de abertura do projeto: 
orçamento básico, prováveis fornecedores, expectativa dos envolvidos, marcos de 
entrega (prazo e escopo) etc. 
Outra tarefa que deve ser realizada durante o processo de definição do escopo 
é a atualização dos documentos do projeto. Nas atividades desenvolvidas podem ser 
identificados outros requisitos, partes interessadas etc. Então, o gerente de projeto 
deve providenciar para que esses documentos estejam sempre atualizados. 
Não podemos esquecer que todos os documentos do projeto precisam ser 
aprovados. O plano de gerenciamento de projeto deve estabelecer o nível de 
autoridade necessária para cada documento. 
Saiba mais 
No blog da MPM você vai encontrar um exemplo bastante interessante de 
declaração de escopo. Disponível em: 
<https://projectdesignmanagement.com.br/blog/declaracao-do-escopo-projeto-
exemplo/>. Acesso em: 18 dez. 2017. 
FINALIZANDO 
Vimos que a definição de escopo é o produto gerado a partir da análise e da 
priorização de requisitos, informações históricas da empresa, restrições e premissas. 
Restrições e premissas merecem um cuidado especial em razão de seu 
impacto nos riscos. Enquanto a primeira é resposta a um risco, a segunda gera um 
risco. 
A documentação gerada durante o processo de definição gerará uma linha 
base ao menos do escopo, mas outras linhas base devem ser gravadas, de modo a 
se ter uma referência para comparação e controle do projeto em todo o seu ciclo de 
vida. 
 
Curiosidade 
Em um dos episódios de seu podcast, Ricardo Vargas fala sobre priorização 
aplicada a projetos da empresa petrolífera Sonangol de Luanda, Angola. Não perca! 
Disponível em: <https://ricardo-vargas.com/pt/podcasts/luandaangola/>. Acesso em: 
11 nov. 2017. 
 
https://ricardo-vargas.com/pt/podcasts/luandaangola/
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
12 
REFERÊNCIAS 
BLOG MPM. Declaração do escopo: projeto (exemplo). Disponível em: 
<https://projectdesignmanagement.com.br/blog/declaracao-do-escopo-projeto-
exemplo/>. Acesso em: 11 nov. 2017. 
PROJECT IN CONTROLLED ENVIRONMENT. Disponível em: 
<https://www.axelos.com/best-practice-solutions/prince2>. Acesso em: 11 nov. 
2017. 
PROJECT MANAGEMENT INSTITUTE. Um guia do conhecimento em 
gerenciamento de projetos: Guia PMBOK®. 5. ed. São Paulo: Saraiva, 2014. 
OFFICE OF GOVERNMENT COMMERCE. Gerenciando Projetos de Sucesso 
com PRINCE2. Grã-Bretanha: TSO, 2011. 
VARGAS, R. V. Gerenciamento de projetos: estabelecendo diferenciais 
competitivos. 8. ed. Rio de Janeiro: Brasport, 2016. 
 
 
AULA 4 
GERENCIAMENTO DE ESCOPO 
EM PROJETOS
Prof. Marcelo Bellon Ferreira 
 
 
2 
CONVERSA INICIAL 
Veremos nesta aula um dos documentos mais importantes do projeto, 
aquele que foca as entregas: a estrutura analítica do projeto (EAP). Também é 
conhecida como estrutura analítica do trabalho (EAT), ou mesmo por seu nome 
em inglês, work breakdown structure (WBS). 
A EAP demonstra graficamente todo o trabalho que será realizado ao longo 
do projeto, facilitando o entendimento da equipe, das partes interessadas ou de 
qualquer outra pessoa. 
Veremos que a EAP tem atributos que complementam o diagrama (que 
veremos mais adiante), assim como um dicionário e contas de controle. 
Ao final do trabalho de geração da EAP e seus atributos é possível que os 
documentos tenham de ser atualizados. Isso acontece por que a equipe 
"amadurece" com relação ao que deve ser entregue em razão do trabalho de 
produção da EAP e da melhor visualização do escopo que ela propicia. 
CONTEXTUALIZANDO 
Após o processo de detalhamento do escopo, o gerente de projetos e sua 
equipe já devem ter condições de saber o que se espera das entregas. 
Mesmo assim, uma visualização gráfica ajuda a entender as relações entre 
cada entrega, e também a analisar os itens de maneira individual visando o 
entendimento do todo. É aqui que a estrutura analítica do projeto (EAP) auxilia. 
Os itens que compõe a EAP possuem atributos que permitem planejamento 
e controle em outras áreas do projeto, como as de custos, tempo e até mesmo 
qualidade. 
TEMA 1 – CRIAÇÃO DA ESTRUTURA ANALÍTICA DO PROJETO (EAP) 
A criação da EAP resulta de um processo que decompõe o escopo em 
“pequenos escopos”, o que facilita, principalmente, o gerenciamento do trabalho. 
Essa divisão não ocorre em apenas um nível, mas, sim, em quantos níveis forem 
necessários para que se conheça com mais exatidão quem executará cada tarefa, 
quanto elas custarão e quanto tempo levarão para serem executadas. 
Cada pequeno escopo, que é a menor medida de trabalho a que se pode 
chegar, é chamado de pacote de trabalho. 
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
3 
A representação da EAP deve demonstrar a divisão do trabalho. Ela pode 
ser feita na forma de um organograma ou de um texto indentado, por exemplo. A 
primeira maneira é certamente a mais utilizada. Vejamos exemplos dessas 
representações: 
Figura 1 ‒ Divisão de trabalho em um projeto: organograma x texto indentado 
 
 
 Casa 
 Fundação 
 Terraplanagem 
 Base de concreto 
 Paredes 
 Colocação dos tijolos 
Nesse exemplo, nos referimos à decomposição de entregas em termos de 
produto. Outra maneira seria identificar as fases do produto, como 
desenvolvimento, testes, homologação e produção. As opções de estrutura da 
EAP podem ser definidas nos documentos de gerenciamento do projeto ou nos 
manuais da empresa. 
Segundo o manual de EAP da NASA1, ela é desenvolvida identificando-se 
primeiramente o sistema ou o item final do projeto a ser estruturado e, em seguida, 
subdividindo-o sucessivamente em produtos ou elementos de trabalho 
subsidiários cada vez mais detalhados e gerenciáveis. Assim, consegue-se 
planejar, executar, monitorar e controlar com mais facilidade não só o escopo do 
projeto, mas também as informações sobre prazo e custo. É importante ressaltar 
que o objetivo da EAP é apresentar todo o trabalho que será entregue, e não ser 
um cronograma. Ela também ajuda a identificar aquele trabalho que não tem 
relação com o escopo e que, por isso, não gera nenhum pacote de trabalho. 
Então, para construirmos a EAP, devemos começar de cima para baixo. 
Nosso primeiro nível (o chamado nível 0) deve conter o nome do projeto; no nível 
seguinte, temos as fases; em outro, podemos já ter pacotes de trabalho ou 
 
1 O manual de EAP da NASA, work breakdown structure (WBS), está disponível em: 
<https://evm.nasa.gov/handbooks.html>. 
1 Casa
1.1 Fundação
1.1.1 
Terraplanagem
1.1.2 Base de 
concreto 
1.2 Paredes
1.2.1 Colocação 
dos tijolos
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
4 
subfases; e assim por diante. Discutiremos até que nível chegar em um dos 
próximos temas. 
Além das fases pertinentes ao produto que será entregue pelo projeto, a 
EAP também deve conter uma fase de gerenciamento de projeto. Afinal, serão 
desenvolvidos produtos de gerenciamento, como documentos (termos de entrega, 
atas de reunião,planos etc.). O exemplo a seguir mostra isso. 
Figura 2 ‒ Fase de gerenciamento de projeto 
 
Uma boa prática na criação da EAP é reutilizar estruturas de projetos 
anteriores. Por mais que cada projeto seja único, aqueles que já passaram por 
todo o processo de execução, amadurecimento e mudanças gerarão ganho de 
produtividade. 
TEMA 2 – ATRIBUTOS DA ESTRUTURA ANALÍTICA DO PROJETO (EAP) 
Vamos entender agora quais são as características (ou os atributos) da 
EAP. Para facilitar essa compreensão, nosso modelo básico aqui será o gráfico 
que se assemelha a um organograma (mas o mesmo se aplica a listas 
indentadas). 
Qualquer caixa de nossa EAP é um item, e não um pacote de trabalho. A 
diferença é que os itens ainda sofrerão "decomposição" até se transformarem em 
pacotes de trabalho. 
Os pacotes de trabalho também são itens, mas são os menores níveis da 
EAP, sem nenhum outro nível abaixo deles. Eles contêm informações sobre 
tarefas a serem realizadas. 
As tarefas são efetivamente o conjunto de ações que devem ser 
executadas para se cumprir o trabalho e obter o resultado esperado. Assim, 
geralmente são representadas por um verbo, enquanto os itens podem ser 
representados por um substantivo. 
Projeto Carro 
Elétrico
Gerenciamento 
do Projeto
Design Homologação Fabricação Comercialização
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
5 
E para entender os detalhes da tarefa, utiliza-se o dicionário da EAP. Para 
cada pacote, o dicionário da EAP terá um item explicativo sobre o trabalho 
necessário ali e outras informações. 
É importante ressaltar que se um item tem apenas um novo subitem ‒ um 
pacote de trabalho ‒, ele não tem razão de existir; nesse caso, as tarefas devem 
ficar alocadas nele, ganhando, assim, o status de "item pacote de trabalho". 
Figura 3 ‒ Item pacote de trabalho 
 
Na EAP da Figura 3, podemos ver o que foi informado no parágrafo anterior. 
A Tarefa 1 não tem razão de existir, e o trabalho alocado a ela deverá ser mantido 
na Fase 1, que poderia receber a nomenclatura utilizada para os pacotes de 
trabalho. 
Como a EAP deve conter todas ‒ e apenas ‒ as tarefas necessárias 
relacionadas ao escopo do projeto, temos aqui informações para gerar a linha 
base de escopo. O item 5.4.3.1 do PMBOK® (2014) diz: “A linha de base do 
escopo é a versão aprovada de uma especificação de escopo do projeto, de uma 
estrutura analítica do projeto (EAP) e seu dicionário da EAP associado, que só 
pode ser mudada através de procedimentos de controle formais, e é usada como 
uma base de comparação”. 
A importância da EAP é tão grande que ela é uma das principais entradas 
nos processos de gerenciamento de custo, de gerenciamento de prazos e até 
mesmo de identificação de possíveis riscos. 
TEMA 3 – REGRAS DE OURO PARA A CRIAÇÃO DE UMA ESTRUTURA 
ANALÍTICA DO PROJETO (EAP) 
Dada a importância já informada do processo de criação da EAP, 
sugerimos que algumas regras sejam seguidas. 
Projeto 1
Fase 1
Tarefa 1
Fase 2
Tarefa 3
Tarefa 4
Tarefa 5
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
6 
Falamos muito em decomposição em vários níveis. Mas quantos níveis são 
necessários? Na verdade, não existe uma quantidade certa, mas, sim, um 
resultado esperado. Em projetos pequenos, talvez três ou quatro níveis sejam 
suficientes, mas grandes projetos (como, por exemplo, colocar em órbita uma 
nova estação espacial) exigem uma decomposição muito maior. 
O último nível, o de pacotes de trabalho, deve permitir que identifiquemos 
quem é o responsável por ele (não estamos falando aqui da equipe, que pode 
conter mais do que uma pessoa), para que possamos estimar seu custo e o tempo 
de execução com certo grau de precisão. E o escopo do pacote de trabalho deve 
ser preferencialmente único. Mas, no caso de pacotes muito pequenos, podemos 
aglutinar as entregas para que o custo de gerenciamento não fique 
desproporcional ao valor entregue. 
O tamanho de cada pacote de trabalho e seu prazo de execução podem 
ser limitados por regras do projeto ou por regras da empresa; então, é importante 
que o gerente de projeto saiba até onde pode ir. Pacotes pequenos podem 
encarecer demais o gerenciamento, e pacotes muito grandes podem não ser tão 
efetivos quanto se espera. 
Uma sugestão para os pacotes de trabalho é que fiquem entre oito horas 
(um dia de trabalho) e 40 horas (uma semana). Temos aqui então uma escala que 
facilita o gerenciamento. Dois pacotes de quatro horas se transformam em um 
pacote de oito horas, juntando-se o escopo; um pacote de 60 horas pode ser 
dividido em dois pacotes de 30 horas, quebrando-se o escopo para facilitar o foco 
da equipe naquela tarefa e facilitar a visualização do tempo do projeto. 
Vejamos o exemplo a seguir. A duração dos pacotes de trabalho chamados 
de Parede A, Parede B, Parede C e Parede D foi estimada em duas horas para 
cada um deles. Assim, seguindo nossa regra “8-40”, devemos alterar a EAP para 
que o item Quarto 1 seja o nível final, um pacote de trabalho, com duração 
estimada de oito horas. 
Figura 4 ‒ Pacote de trabalho: regra "8-40" 
 
Pintura da casa
Quarto 1
Parede A
Parede B
Parede C
Parede D
Quarto 2
Sala
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
7 
Perceba que, de acordo com o resultado final nesse nosso exemplo, temos 
a mesma efetividade ao executarmos a tarefa e fazermos a validação e o controle 
do resultado. É claro que exceções podem existir, desde que sejam devidamente 
justificadas e tragam benefícios para o projeto. 
Outra regra que pode ser seguida diz respeito à nomenclatura dos itens. A 
EAP deve demonstrar que existe um trabalho a ser feito, mas não precisa explicá-
lo. Para isso serve o seu dicionário. Assim, nomes curtos, e não frases, são o ideal 
para as caixas dos itens. O que pode ser colocado ‒ e que ajuda na identificação 
e na organização dos itens ‒ é a utilização de uma numeração hierárquica. Assim, 
a EAP que vimos na Figura 4 ficaria da seguinte forma: 
Figura 5 ‒ Nomenclatura dos itens 
 
Saiba mais 
Veja o videocast de Ricardo Vargas sobre a elaboração de uma EAP, 
disponível em: <https://www.youtube.com/watch?v=TS9eciG-Ddw>. Acesso em: 
18 dez. 2017. 
TEMA 4 – DICIONÁRIO DA ESTRUTURA ANALÍTICA DO PROJETO (EAP) 
O dicionário da EAP é complementar ao diagrama gerado. Ele contém 
informações sobre os itens da EAP, em especial sobre os pacotes de trabalho: 
escopo, entregas, prazos, custos estimados, responsabilidades etc. 
Para cada item da EAP deve haver um item no dicionário que explique com 
clareza as tarefas que devem ser cumpridas em cada um dos pacotes de trabalho, 
além de sua identificação e relação com outros pacotes. 
Da mesma forma que ocorre com outros documentos de gerenciamento de 
projeto, o ideal é que exista um modelo para o dicionário da EAP, mostrando os 
atributos que devem ou que podem ser abordados. Essa uniformidade de 
informação faz com que toda a equipe saiba o que esperar do projeto antes 
mesmo de ter acesso ao documento. 
1. 0 Pintura da casa
1.1 Quarto 1
1.1.1 Parede A
1.1.2 Parede B
1.1.3 Parede C
1.1.4 Parede D
1.2 Quarto 2
1.3 Sala 
https://www.youtube.com/watch?v=TS9eciG-Ddw
Candido Marcelo
Realce
Candido Marcelo
Realce
Candido Marcelo
Realce
 
 
8 
A seguir, veremos parte do conteúdo da EAP de um projeto de pintura de 
casa. Foram omitidas as seções de versionamento, descrição e aprovação do 
documento. Em um documento real, essas seções são fundamentais. 
Quadro 1 ‒ Conteúdo parcial de um projeto de pintura de uma casa 
Código 
EAP 
Item Descrição 
1.0 Pintura da casa 
1.1 Quarto 1 
1.1.1 Parede A Parede com 18 m2 que deverá receber uma demão 
de tinta na cor verde-claro. É a parede da esquerda 
ao se entrar no quarto.