Apostila de Gerenciamento em Escopo do Projetos

Prévia do material em texto

INTRODUÇÃO 
Em certo momento da minha vida profissional, deparei-me com 
um jovem engenheiro recém-formado que estava no seu primeiro 
emprego, um estágio, na verdade. Em um belo dia, depois de muitos 
esforços em prol de um detalhe simples que demandou muitas horas de 
empenho da equipe do projeto para ser realizado, escutei esse rapaz 
questionar que a vida de um profissional do gerenciamento de projetos 
era muito inconstante, sujeita a muitas variáveis. 
No primeiro momento, acreditei tratar-se da expressão do óbvio; 
afinal, se alguém havia escondido dele tal detalhe, caberia a mim 
demonstrar que isso era uma condição de muitas vidas profissionais: a 
instabilidade. Qual não foi a minha surpresa quando esse mesmo 
indivíduo desejou que a sua vida profissional fosse mais estável. Aquilo 
martelou muito tempo na minha cabeça. Afinal de contas, quem possui 
uma vida estável no trabalho? E mais: uma vida estável leva à zona de 
conforto, ao sedentarismo, à desmotivação ou até mesmo à substituição 
de determinados cargos por máquinas. 
Ora, se praticamente tudo o que a estabilidade traz é prejudicial, 
comecei a demonstrar para esse estagiário exatamente o contrário, ou seja, o 
quão bom é um ambiente instável. Pois o importante é manter uma postura 
de busca de uma identidade cultural acerca da adaptabilidade à mudança e 
estar sempre disposto a abraçar desafios. Vivendo em um ambiente em 
constante mudança, agradeça todos os dias o seu trabalho, pois do contrário, 
muito provavelmente, você já não seria uma peça necessária. 
Gerenciar projetos não é uma descoberta, nem mesmo um 
modismo. Trata-se de um tema que muito se explora há décadas, mas 
muitas organizações públicas, privadas ou do terceiro setor começaram 
apenas recentemente a perceber as benesses de uma correta aplicação 
dos seus conceitos. 
Sempre que esse assunto é visto de maneira ordenada e integrada, 
muitas são as possibilidades de desenvolver melhores produtos e serviços 
inerentes a um negócio, alinhando padrões internacionais de gestão com 
o fortalecimento de uma instituição, seja por demonstrar melhor cuidado 
com os seus processos ou por transparecer, por meio dos seus valores 
tangíveis e intangíveis, diferenciais competitivos. 
 
 
Exatamente por isso, muito se discute sobre como melhorar processos, capacitar profissionais 
e otimizar entregas, entre outros detalhes que poderão trazer retornos rápidos ou de longo prazo, 
para as organizações que adotam tais práticas. O gerenciamento do escopo é somente a ponta desse 
iceberg, pois junto com as demais áreas de conhecimento, possui o dom de provocar uma verdadeira 
revolução na maneira como as organizações veem e são vistas, com influência imediata nas pessoas, 
que vêm a ser a base de toda e qualquer estrutura. 
Segundo pesquisas atuais, as causas mais comuns de falhas em projetos em organizações 
mundo afora são: problemas de comunicação, escopo mal definido e escopo que sofre constante 
mudança. Ou seja, de todos os possíveis e imaginários problemas, o assunto “escopo” aparece por 
duas vezes nas três primeiras colocações, sendo que, se pararmos para avaliar um pouco mais de 
perto tais resultados, um escopo mal definido possui um enorme potencial para gerar problemas de 
comunicação. Em face dessa observação, começo até mesmo a questionar se as respostas dos 
entrevistados não estavam mais atentas às consequências dos problemas do que, talvez, às suas 
causas. Se essa minha teoria pudesse ser confirmada, potencialmente teríamos o escopo como 
gerador de dois dos principais problemas de falhas em projetos, apenas para nos atermos ao top 3. 
A resposta para melhorar esses índices – ou quiçá solucionar, de uma vez por todas, problemas 
como esses – está em uma correta atenção ao gerenciamento do escopo em projetos. Entretanto, 
este assunto é muitas vezes negligenciado, seja por questões estratégicas em que prevaleça um 
determinado padrão, por exemplo, privilegiar o cumprimento de um cronograma em detrimento 
daquilo que se está entregando, seja até mesmo por desconhecimento técnico. 
Este material é um compêndio importante para que profissionais da área de gerenciamento 
de projetos ou curiosos percebam cada vez mais a importância do gerenciamento do escopo em 
projetos, assim como a sua correlação com o trabalho das demais áreas de conhecimento do 
gerenciamento de projetos. 
O objetivo geral desta disciplina é apresentar o conceito de escopo e as suas peculiaridades, 
assim como demonstrar a área de conhecimento do gerenciamento do escopo em projetos, oferecendo 
um grau de compreensão que produza efeitos imediatos de utilização do assunto estudado em 
organizações, indivíduos e grupos de pessoas, que adotem o gerenciamento profissional de projetos. 
Por sua vez, os objetivos específicos são: 
 Reconhecer os principais termos e as peculiaridades que envolvam o assunto escopo 
em projetos. 
 Identificar todos os processos da área do escopo em projetos, segundo modernas 
práticas do mercado. 
 Aplicar corretamente os processos da área de escopo ao longo de um projeto real. 
 Demonstrar uma visão holística, percebendo a importância da área de escopo em relação 
às demais áreas de conhecimento de um projeto. 
 Elaborar e analisar os principais documentos relativos à área de conhecimento do escopo 
em projetos. 
 
 
Para isso, esta apostila está organizada da seguinte forma: 
 Módulo I – Escopo: conceitos fundamentais 
O escopo é um dos assuntos mais nervais em um projeto, pois possui o dom de influenciar 
direta e indiretamente as demais áreas de conhecimento. Exatamente por isso, é necessário conhecer 
os principais termos e as peculiaridades que serão demandados na condução de um bom trabalho 
do gerenciamento do escopo em projetos. Este módulo se propõe a demonstrar, em um primeiro 
momento, como o termo “escopo” nasceu e depois amadureceu, para passar a ser utilizado como 
fator crítico de sucesso em um modelo de gestão estratégica, de preferência vinculado aos objetivos 
de negócio de toda e qualquer organização. Na sequência, fará uma ponte entre o momento da 
iniciação do projeto, por meio do Termo de Abertura do Projeto e de todo o percurso que precisa 
ser percorrido para o início dos trabalhos de um bom planejamento. 
 
 Módulo II – Planejamento do escopo: parte I 
Para começar a trabalhar o escopo é interessante incorporar os conceitos primordiais de 
entrada, ferramentas e técnicas, e saídas de um processo. Em face dessa proposta, é importante que 
o time do escopo de um projeto domine esse conhecimento para construir a documentação 
necessária que influenciará todo o planejamento e, consequentemente, todo o trabalho do projeto. 
As ações do planejamento de um projeto não se iniciam necessariamente com o trabalho do escopo, 
mas, a partir do momento em que esse vespeiro é cutucado, todo o trabalho da equipe do projeto 
passa a ter outro significado. O planejamento do escopo, independentemente da abordagem 
selecionada para o trabalho do projeto, é primordial para o encadeamento do restante dos processos. 
Neste módulo, serão identificadas as regras para se trabalhar com um bom planejamento do escopo, 
assim como dos requisitos de um projeto, além de compreender como funciona o trabalho de 
elicitação – ou coleta – de requisitos e a sua importância para a saúde de um projeto. 
 
 Módulo III – Planejamento do escopo: parte II 
As regras do escopo já foram definidas, assim como as normas para o trabalho com os 
requisitos do projeto. O curioso é que não só o planejamento do escopo ainda não acabou como os 
próprios processos que já foram iniciados ainda não foram plenamente finalizados, dependendo do 
sequenciamento dos trabalhos do planejamento do escopo com a construção da sua linha de base 
de entregas. Com a proposta de dar subsídios à equipe do projeto no intuito de que não existam 
dúvidas do que será realizado e de como será realizado para entregar o produto, serviço ou resultado 
desejado pelo cliente ou usuáriofinal, a documentação do planejamento será complementada e 
atualizada com importantes informações acerca do escopo. A equipe do projeto passa a ter, então, 
conhecimento explícito e detalhado do escopo do projeto e do escopo do produto. Todas as entregas 
serão subdivididas em componentes gerenciáveis, que, por sua vez, poderão ser mais bem estimados, 
mensurados, monitorados e controlados. 
 
 
 Módulo IV – Validação e controle do escopo 
Assim como toda base de planejamento que é utilizada como referência para se executar 
algo, com o escopo não é diferente. A priori, o objetivo de um bom planejamento é conseguir que 
as entregas sejam todas aceitas no formato originalmente previsto. Esse é o papel do primeiro 
processo do escopo vinculado ao grupo de processos de monitoramento e controle, um trabalho 
que é realizado não somente pela área de trabalho do escopo, mas também com valiosas 
contribuições do time de integração e da qualidade. Quando o time do escopo consegue 
formalizar uma entrega aceita, isso significa um trabalho a menos para a equipe do projeto e 
também sinaliza que a direção para a concretização do resultado esperado é cada vez mais curta. 
Obviamente, todo projeto é um carrossel de emoções e sofre a influência de um turbilhão de 
variáveis, internas e externas, sem mencionar as constantes ações das principais partes interessadas. 
Exatamente em função disso, é necessário um trabalho atento de gerenciamento de possíveis 
alterações na linha de base do escopo. Caso ocorra uma solicitação de mudança, há que se realizar 
um trabalho de controle integrado de ações, minimizando problemas e conduzindo o resultado 
do projeto alinhado com os objetivos estratégicos organizacionais. 
 
Nas suas páginas, serão descritos todos os processos preconizados pelo Project Management 
Institute para um correto trabalho do gerenciamento do escopo em um projeto, assim como 
modelos de artefatos, técnicas e ferramentas, que poderão auxiliar o trabalho de qualquer 
profissional da área na utópica busca da perfeição, desenvolvendo competências e visando a um 
trabalho de melhoria contínua de processos. Contudo, lembre-se: sempre que possível, decorrente 
de um trabalho com muita instabilidade. 
Boa leitura! 
 
 
SUMÁRIO 
MÓDULO I – ESCOPO: CONCEITOS FUNDAMENTAIS ......................................................................... 9 
CONCEITO HISTÓRICO ...................................................................................................................... 9 
ESCOPO E CICLOS DE VIDA DE UM PROJETO ............................................................................... 11 
CONCEITOS IMPORTANTES: CICLOS ITERATIVOS, FUNCIONALIDADES, MVP, DOR, DOD, 
CRITÉRIOS DE ACEITAÇÃO E CRITÉRIOS DE VALIDAÇÃO ................................................................ 14 
DIFERENÇA ENTRE ESCOPO DO PROJETO E ESCOPO DO PRODUTO ........................................ 20 
TERMO DE ABERTURA DO PROJETO E PROCESSOS DE GERENCIAMENTO DO ESCOPO ........ 20 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 24 
MÓDULO II – PLANEJAMENTO DO ESCOPO: PARTE I ....................................................................... 27 
PROCESSO “PLANEJAR O GERENCIAMENTO DO ESCOPO”: PECULIARIDADES, ENTRADAS, 
TÉCNICAS E FERRAMENTAS ............................................................................................................ 27 
PROCESSO “PLANEJAR O GERENCIAMENTO DO ESCOPO”: SAÍDAS .......................................... 30 
PROCESSO “COLETAR OS REQUISITOS”: PECULIARIDADES, ENTRADAS, TÉCNICAS E 
FERRAMENTAS .................................................................................................................................. 36 
PROCESSO “COLETAR OS REQUISITOS”: SAÍDAS .......................................................................... 43 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 45 
MÓDULO III – PLANEJAMENTO DO ESCOPO: PARTE II ..................................................................... 47 
PROCESSO “DEFINIR O ESCOPO”: PECULIARIDADES, ENTRADAS, TÉCNICAS E FERRAMENTAS
 ............................................................................................................................................................ 47 
PROCESSO “DEFINIR O ESCOPO”: SAÍDAS ..................................................................................... 49 
PROCESSO “CRIAR A EAP”: PECULIARIDADES ............................................................................... 53 
PROCESSO “CRIAR A EAP”: ENTRADAS, TÉCNICAS E FERRAMENTAS, SAÍDAS .......................... 60 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 66 
MÓDULO IV – VALIDAÇÃO E CONTROLE DO ESCOPO ..................................................................... 67 
PROCESSO “VALIDAR O ESCOPO”: PECULIARIDADES, ENTRADAS, TÉCNICAS E FERRAMENTAS . 67 
PROCESSO “VALIDAR O ESCOPO”: SAÍDAS ................................................................................... 70 
PROCESSO “CONTROLAR O ESCOPO”: PECULIARIDADES, ENTRADAS, TÉCNICAS E 
FERRAMENTAS .................................................................................................................................. 71 
PROCESSO “CONTROLAR O ESCOPO”: SAÍDAS ............................................................................ 73 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 73 
BIBLIOGRAFIA ...................................................................................................................................... 75 
PROFESSOR-AUTOR ............................................................................................................................. 79 
 
 
 
 
 
Neste módulo, serão apresentados os principais conceitos para a compreensão do trabalho de 
gerenciamento do escopo de um projeto. Será traçado um cenário histórico para determinar como 
a fixação em busca de se definirem objetivos demonstra-se algo importante para as organizações e 
os seus indivíduos, notadamente os que desempenham funções relacionadas ao gerenciamento de 
projetos. Na sequência, os principais ciclos de vida serão demonstrados, assim como a sua relação 
com o escopo em si, para, então, os principais conceitos e as suas respectivas importâncias serem 
citados, como os de escopo do produto; escopo do projeto; minimum viable product (MVP), 
mínimo produto viável, em português; funcionalidade; ciclos iterativos; definition of ready (DoR); 
definition of done (DoD); e critérios de aceitação e de validação. Por fim, serão ilustrados os 
principais processos envolvidos no nascimento de um projeto, assim como os processos necessários 
para a compreensão e o trabalho de gerenciamento do escopo do projeto. 
 
Conceito histórico 
Gerenciar projetos é uma arte que chama atenção ao longo dos anos, pois, desde que 
indivíduos começaram a perceber a importância de um processo para encadear melhor ações de 
trabalho nas suas respectivas organizações, mais se pode fazer em função dessa arte. Portanto, 
quando Peter Drucker, na década de 1950, disse “Lembre-me de um livro sobre a anatomia humana 
que discute apenas uma junta do corpo – o cotovelo, por exemplo – sem mencionar o braço e deixar 
de fora o esqueleto e a musculatura”, o hoje conhecido como pai da administração moderna 
demonstrava que nada se faz sem uma visão sistêmica de conjunto, de preferência, visando sempre 
a um mesmo objetivo. 
MÓDULO I – ESCOPO: CONCEITOS 
FUNDAMENTAIS 
 
10 
 
Com o mundo dos negócios em ebulição após um momento histórico vivido pelo período 
das grandes guerras mundiais, a transformação inicia-se exatamente por meio de uma questão muito 
simples, afinal de contas, precisa-se entender o que é,efetivamente, gerir alguma coisa. Foi 
exatamente nesse momento em que, ainda segundo Drucker (1954), nasceu o conceito de 
Administração por Objetivos (APO). 
APO consiste em um método colaborativo entre líderes e liderados, com cada um entendendo 
perfeitamente o seu papel dentro do contexto organizacional, trabalhando para delimitarem juntos 
os objetivos que precisam ser alcançados. Há um planejamento; objetivos e formas de 
monitoramento são traçados; responsabilidades são delegadas e, constantemente, compara-se o 
resultado com o planejamento previamente estabelecido, no sentido de gerar um senso de aferição 
de resultados. Também há necessidade de se delimitarem objetivos de curto (operacionais), médio 
(táticos) e longo (estratégicos) prazo. 
Não à toa, aproveitando o êxito dessa descoberta, o conceito de gerenciamento de projetos 
nasceu nos Estados Unidos ao final dos anos 1950, quando inicialmente aplicado à análise de sistemas 
de informação e implantação de empreendimentos físicos, este último limitando-se aos componentes 
de engenharia. Os primeiros institutos em gerenciamento de projetos datam da década de 1960, e 
muitos deles foram lançar o que seria o início dos seus guias de boas práticas apenas nos anos 1980. 
Foi quando George Doran (1981), aprimorando os trabalhos de Edwin Locke (1968), 
reconheceu que muitas organizações precisavam atingir metas, objetivos, mas muitas vezes esses 
objetivos eram estabelecidos de maneiras difusas. Objetivos não deveriam ser tratados como 
inarticulados – aqui, percebe-se uma pitada do conceito inicial de Drucker –, ao invés disso 
deveriam ser tratados como coisas mensuráveis, no intuito de alavancar o sucesso de uma 
organização. Então, uma a melhor definição para o conceito de objetivo surgiu com a utilização do 
acrônimo Smart, que vem a ser: S de specific, em inglês, específico; mensurável; atingível; relevante; 
e com tempo limite. Ao adotar que um objetivo precisaria possuir todas essas cinco propriedades 
em conjunto, e não apenas uma ou outra, Doran conseguiu solidificar o conceito de 
estabelecimento de metas para gestores em muitas organizações. 
Essa jornada histórica da busca pelo entendimento do que seria o objetivo de um projeto, 
idealizado por muitas décadas de erros e acertos, foi muito importante para que os indivíduos pudessem 
reconhecer que o foco de um projeto nunca poderá ser negligenciado. Quanto mais se aprende e 
conhece o objetivo que se deseja alcançar, maior a chance de alcançar sucesso em uma empreitada. 
Hoje em dia, muito ainda se aprende com as definições dos objetivos de um projeto, e todas 
essas abordagens históricas podem auxiliar, em muito, diversos times de projetos. Contudo, a maneira 
mais simples de reconhecer o objetivo de um projeto é compreender qual é o seu escopo, que nada 
mais significa do que compreender o que precisa ser feito ou entregue pelo time do projeto. Para isso, 
precisa-se compreender um pouco mais a respeito de algumas nuances do termo “escopo”. 
 
 
 11 
 
Escopo e ciclos de vida de um projeto 
De acordo com o PMI (2017b), existem quatro tipos de ciclos de vidas de projeto. Isso 
significa que um time de projeto precisa ter conhecimento a respeito dessas variadas formas no 
intuito de selecionar uma abordagem condizente com as ações demandadas pelo produto, serviço 
ou pela condição que será gerada. Os tipos são: 
 Ciclo de vida preditivo – trata-se de processo sequencial. Talvez a abordagem mais 
tradicional de todas, com os esforços de planejamento ocorrendo em uma fase inicial do 
projeto. Depois, em uma única jornada, é realizada a execução. 
 Ciclo de vida iterativo – uma abordagem empírica, que permite aos poucos retorno dos 
principais stakeholders engajados no projeto. Os feedbacks são recebidos pelo time do 
projeto sobre trabalhos ainda não finalizados, no intuito de melhorar o produto, o serviço 
ou a condição e conseguir modificá-los antes de a versão final ser efetivamente entregue. 
 Ciclo de vida incremental – uma abordagem escalonável, que, em oportunidades pontuais 
ao longo do projeto, fornece versões do produto, do serviço ou da condição não finalizados, 
mas com possibilidade de utilização imediata, mesmo que não na sua total capacidade. 
 Ciclo de vida ágil – junção das abordagens iterativa e incremental em um único tipo de ciclo 
de vida. Ao mesmo tempo que se permitem entregas constantes de versões de produtos, 
serviços ou condições com utilização imediata, os feedbacks também são frequentes, no 
intuito de aprender com a versão disponibilizada, analisá-la e depois melhorá-la. 
 
Figura 1 – Continuidade dos ciclos de vida 
 
 Fonte: adaptado de PMI (2017b). 
 
12 
 
Nenhum ciclo de vida será perfeito para todos os tipos de projeto. Contudo, cada time deve 
encontrar um ponto de continuidade para prover equilíbrio nas ações demandadas ao trabalho do 
projeto, dependendo do contexto. 
Em ciclos preditivos, existe a vantagem de se trabalhar em um ambiente com baixo grau de 
incertezas e complexidade, permitindo poucas mudanças e poucas entregas intermediárias – às 
vezes, nenhuma –, adotando um sequenciamento previsível de ações. 
No ciclo iterativo, há possibilidade de feedbacks sobre trabalhos parcialmente concluídos, 
visando à melhoria contínua e a modificações constantes. Já no ciclo de vida incremental, o foco 
encontra-se nas entregas potencialmente escalonáveis com o cliente ou usuário final tendo a 
possibilidade de aproveitamento imediato do produto, serviço ou condição, entregue em uma versão 
inacabada. Por fim, o ciclo de vida ágil adota as características dos dois últimos ao mesmo tempo. 
Como frequentemente entregará versões parciais e receberá feedbacks, há emprego de conceitos de 
transparência de processos, confiança e engajamento entre time do projeto e cliente, ou usuário final, 
adotando o foco de priorizar as funcionalidades – veja o significado mais adiante, no item 1.4 deste 
mesmo material – mais importantes e que geram mais valor às principais partes envolvidas. 
O grande argumento para a utilização desse tipo de ciclo de vida é na questão estratégica, pois 
a visualização do Return on Investiment (ROI) – retorno sobre o investimento – será mais cedo do 
que em outros ciclos de vida, e isso facilita o processo de tomada de decisão. 
Por fim, como o gerenciamento de projetos dificilmente é tratado como uma ciência exata, 
haja vista as múltiplas variáveis no momento de desenvolver um projeto, o PMI (2017b) também 
determina que não há necessidade de utilização de um único tipo de ciclo de vida durante todo o 
projeto. É, sim, possível a combinação de elementos de abordagens distintas no intuito de criar o 
que é chamado de abordagem híbrida. 
E como o escopo se posiciona em relação a tudo isso? Para as modernas técnicas de 
gerenciamento de projetos, mais que desempenhar atividades distribuídas por processos 
sistêmicos, o verdadeiro sentido de gerenciar um projeto está em encontrar a solução para uma 
necessidade, gerar uma nova ideia ou até mesmo aproveitar uma oportunidade. A entrega precisa 
ser realizada, não mais com foco em planejamentos restritos, e, sim, com grau de adaptabilidade 
satisfatório para continuamente reconhecer onde e quando entregar valor, que precisa ser 
percebido pelo cliente ou usuário final. É, talvez, o maior desafio de todo o projeto. Afinal de 
contas, a percepção desses stakeholders em relação ao que está sendo gerado pode variar ao longo 
do projeto, principalmente com um produto, um serviço ou uma condição ganhando forma, e 
novas ideias amadurecendo o processo de concepção. 
Digamos, por exemplo, que um determinado cliente tenha solicitado a criação de uma caneta 
esferográfica. Como principais solicitações, determinou as suas características de peso, tipo de 
material, medidas, cor, etc. Porém, quando solicitou o produto, em um primeiro momento, ele 
também possuía o desejo que a caneta tivesse uma luz fraca intermitente que seria emitida no 
momento em que elaestivesse em operação. 
 
 13 
 
Ora, não podemos esquecer que a função primária de negócio detectada no desenvolvimento 
desse produto (caneta) seria escrever em superfícies como papel e que a função secundária ou com 
menor proposta de entrega de valor seria a luz intermitente. 
A partir do momento em que as entregas constantes começam a ocorrer, e a caneta, mesmo 
ainda não totalmente pronta, começa a cumprir as principais características e as suas funções de 
negócio, não é difícil um cliente abdicar de determinadas características por já verificar a principal 
funcionalidade do seu produto ocorrendo conforme desejado. Portanto, é plenamente possível que 
em determinado momento do projeto esse cliente desista da luz para economizar no prazo e, quiçá, 
nos custos do projeto, pois o valor do produto entregue já foi percebido, sem a necessidade de 
complementação futura. O escopo, então, não é tratado como fixo, e, sim, variável ou estimado. 
 
Figura 2 – Triângulo invertido das restrições 
 
Fonte: adaptado de Serpa (2016). 
 
A figura 2 demonstra que, com a utilização de parâmetros de fixação de escopo, o processo 
de gestão deve focar a variação dos controles de custos e de cronograma – tempo – para que essa 
flutuabilidade permita entregar aquilo que foi efetivamente solicitado, da maneira como foi 
solicitado, nada a mais nem a menos. Já com a proposta de entrega de valor observada na estratégia 
de condução do projeto, o foco então passa a ser outro, e isso permite que, desta vez, o escopo 
flutue, deixando as restrições para as áreas de custos e de cronograma. 
Dentro da proposta de uma limitação de cronograma, por exemplo, um time poderá dizer 
que em dois meses entregará um determinado produto de uma determinada maneira. O trabalho 
de evolução desse produto será constantemente monitorado e controlado, significando que o escopo 
poderá adaptar-se às muitas variáveis do projeto. 
Desenvolver bons produtos ou serviços demanda tempo, consome dinheiro e necessita de 
equipes especializadas para cada etapa da produção. Com o objetivo definido de entregar um 
produto final que gere valor para o seu cliente ou usuário final, a tendência é que as principais partes 
interessadas, dependentes do resultado final do projeto, fiquem satisfeitas. 
 
14 
 
É comum escutar nas organizações termos que retratam essas condições demonstradas pelo 
triângulo invertido de uma maneira ligeiramente diferente. Alguns preferem chamar de escopo 
fechado, quando a proposta é priorizar o planejamento. Ao contrário, quando o escopo demonstra-
se voltado para a proposta de entrega de valor, comumente, escuta-se o termo escopo aberto. 
Como pudemos perceber, ambas as possibilidades são boas e possuem o potencial de trazer 
os resultados esperados, sendo que a opção por uma das duas será em função da estratégia de 
condução do projeto e da correta avaliação em relação ao ciclo de vida mais recomendado a ser 
adotado – preditivo, iterativo, incremental, ágil ou híbrido –, de preferência alinhada com as 
estratégias organizacionais do ambiente onde o projeto está sendo gerado. 
O que não pode acontecer é tentar desenvolver um produto, um serviço ou uma condição 
sem a utilização de uma metodologia aderente às necessidades de desenvolvimento dos processos 
inerentes à execução do projeto e do modus operandi do time. Afinal, qualquer método, ou 
framework, é melhor do que método algum, principalmente quando falamos de algo que consome 
recursos, tempo, energia e dedicação de tantas pessoas. É muito importante escolher um método 
de trabalho apropriado, que faça sentido para o seu projeto e traga os resultados esperados. 
 
Conceitos importantes: ciclos iterativos, funcionalidades, 
MVP, DoR, DoD, critérios de aceitação e critérios de validação 
Os ciclos iterativos nasceram diante da necessidade de se gastar menos tempo inicial com 
descobertas a respeito do escopo, para que o time do projeto pudesse priorizar técnicas de 
implementações sucessivas, gerando descobertas e refinamentos constantes. 
Comparando as visões de um ciclo de vida completo em um projeto utilizador de um ciclo 
de vida preditivo e de um ciclo de vida ágil, conforme a figura 3, verificamos que em ambas as 
situações podem ser visualizados os cinco grupos de processos propostos pela metodologia 
preconizada pelo PMI. 
 
 
 
 15 
 
Figura 3 – Comparação do nível de interação entre processos nos ciclos preditivo e ágil 
 
Fonte: adaptado de Serpa (2016). 
 
No entanto, na imagem superior, pode-se perceber que existe uma única jornada sequenciada 
por processos no ciclo de vida preditivo. Por mais que em muitas ocasiões esses grupos de processos 
se sobreponham, há um encadeamento lógico e natural começando com o grupo de iniciação e 
seguindo com planejamento, execução, monitoramento e controle – aqui, há uma exceção, pois o 
mesmo ocorre ao longo de todo o projeto –, finalizando com o grupo de encerramento. 
Quando comparamos isso com a imagem da parte de baixo da figura 3, que demonstra os 
ciclos de vida ágeis, podemos perceber que há o esforço de iniciação, planejamento, execução, 
monitoramento e controle, praticamente da mesma maneira, mas percebe-se que isso funciona para 
firmar a ocorrência do primeiro ciclo de iteração. 
Isso significa que para a primeira “fase” do projeto há um planejamento de 100% do que vai 
ocorrer dentro desse período, como também uma execução completa para o trabalho proposto pelo 
planejamento e, novamente, monitoramento e controle ocorrendo ao longo de todo o ciclo, mas não se 
evidencia o trabalho de encerramento do projeto. Isso ocorre porque perto de finalizar a execução já se 
pensa no próximo ciclo de iteração, e um novo planejamento para um novo período de ações é realizado. 
O processo ocorre quantas vezes forem necessárias para que o produto, o serviço ou a condição 
sejam entregues dentro das expectativas do cliente ou do usuário final. Porém, quando se programa o 
 
16 
 
último ciclo para a entrega definitiva, é possível verificar os esforços necessários ao encerramento do 
projeto como um todo, culminando também nos trabalhos de monitoramento e controle. 
Segundo Cruz (2015), cada ciclo iterativo precisa terminar sendo capaz de responder, 
pontualmente, às seguintes questões: 
 Como podemos transformar a visão do produto em um produto real da melhor 
maneira possível? 
 Como podemos alcançar a satisfação do cliente e o ROI desejado? 
 Quando, no pior cenário, poderemos entregar a versão X do produto, serviço ou condição? 
 
Ao utilizar o conceito do ROI junto à segunda pergunta, o conceito poderá ser adaptado às 
reais necessidades da organização. Por exemplo, se uma empresa é orientada a gerir custos, o ROI 
pode ser mensurado pela relação entre lucro e custos do projeto ou da etapa do projeto, mas isso 
pode ser calculado em relação à qualidade, às partes interessadas – percepção de recebimento de 
valor de uma entrega –, ao escopo, etc. 
Um termo muito comum no momento de conduzir o trabalho do escopo ao longo de um 
projeto é o de funcionalidade. Uma funcionalidade é algo passível de execução, ou seja, algo 
definido como um comportamento ou até mesmo uma ação, delimitado por uma caixa de 
tempo – timebox –, presumindo que exista um momento de início para a execução dessa 
funcionalidade e um momento de fim, claramente definidos. 
As funcionalidades são definidas junto com o trabalho de definição do escopo do produto e 
de escopo do projeto, assunto que será estudado logo a seguir, na próxima unidade. É desejável que 
sejam criadas por meio da junção de um verbo e um substantivo. 
É um trabalho que exige do time do projeto um grau de atenção redobrado, pois um início 
mal estruturado poderá ser desastroso no momento em que o projeto evoluir e as implicações de 
um trabalho de escopo desestruturado começarem a influenciar os trabalhos das demais áreas de 
conhecimento, por exemplo, cronograma, recursos, qualidade, etc. 
Outro importante conceitoque auxilia na correta definição de funcionalidades é entender o 
que é um MVP – ou minimum viable product (service) (MVS) –, ou, na versão em português, 
mínimo produto (serviço) viável. 
Um MVP, segundo Caroli (2015), ao adaptar as ideias originais de Eric Reis, “é a versão mais 
simples de um produto que pode ser disponibilizado para o negócio, focando na entrega de valor 
de acordo com objetivos de negócios e as necessidades dos usuários”. 
O MVP serve, basicamente, para evitar desperdícios. Não se deve gastar tempo, recursos e a 
paciência dos seus principais stakeholders gerando algo que ao final pode vir a não agradar, em parte 
ou totalmente, ao seu cliente. Então, testa-se gradativamente o potencial de uma entrega, antes de 
enveredar muitos esforços no seu desenvolvimento. Assim, o time do projeto possuirá condições de 
dosar o ritmo de trabalho e focar a proposta de entrega de valor, pois funcionalidades que não são 
tão importantes ficam como últimas prioridades. 
 
 17 
 
Em muitos momentos, com a evolução natural do produto, do serviço ou da condição, essa 
funcionalidade nem mesmo é desenvolvida, pois o interesse do cliente pode mudar, e a sua linha de 
base do escopo também muda. 
 
Figura 4 – Ciclo do MVP 
 
Fonte: adaptado de Caroli (2018). 
 
Esse conceito foi amplamente utilizado por empresas gigantes nos seus segmentos, por 
exemplo, Facebook e Apple. Garantir a maximização do ROI é a proposta desse ciclo do MVP. A 
partir de uma ideia ou necessidade inicial, cria-se uma primeira versão do produto, do serviço ou 
da condição. Essa versão não é perfeita, mas consegue incluir um grau mínimo das principais 
características desejadas para o produto. 
Por exemplo, imagine que o seu projeto seja construir um kart. O cliente solicitou que o kart 
fosse seguro, bonito e ergonômico. Em determinados casos, como o item vinculado à segurança, 
existem normas legais e técnicas que permitirão o time do projeto definir o grau mínimo de padrão 
de segurança exigido para um kart. A partir do momento em que esse padrão mínimo for atingido 
em uma primeira versão do produto, já começa a surgir a ideia do MVP, apesar de não podermos 
considerá-lo como um MVP ainda. 
Explico: o kart pode ser o mais seguro desenvolvido no mundo, mas as características de 
beleza e ergonomia não estiverem ainda implementadas, não conseguimos atingir a primeira versão 
desse produto. Portanto, será considerado um MVP apenas quando conseguir unificar os padrões 
mínimos de segurança, beleza e ergonomia. Contudo, um padrão de beleza seria uma avaliação 
subjetiva, e a opinião do cliente, de pessoas ligadas a ele ou até mesmo a opinião pública terá um 
peso fundamental nessa aprovação. 
Para que o time defina isso com propriedade, deverá estabelecer padrões de beleza e então 
descobrir qual seria o padrão mínimo. Depois da primeira versão desenvolvida, podem-se então 
colher feedbacks ou medir detalhes no intuito de juntar a maior quantidade de informação válida 
 
18 
 
possível para que esses dados possam ser analisados, e novas ideias possam surgir. Assim, um novo 
ciclo do MVP poderá ser gerado. 
Trabalhar o escopo do projeto utilizando o conceito do MVP não só permitirá ao time do projeto 
um aprendizado constante em relação ao produto ou serviço que está sendo gerado, como também será 
importante para receber feedbacks intermediários, antes do produto totalmente finalizado. 
Somente por meio desses feedbacks é que o time do projeto poderá analisar detalhes 
pertinentes à implementação das funcionalidades requeridas pelo escopo do produto e então decidir 
o rumo a ser tomado em um próximo ciclo de iteração, obviamente, nunca perdendo de vista o 
objetivo de negócio com o escopo do projeto capitaneando os processos de tomada de decisão, 
conforme demonstrado no projeto donut, na figura 5. 
 
Figura 5 – Evolução do MVP 
 
Fonte: adaptado de Jeffery (2018). 
 
O MVP permitirá ao criador do donut, verificar detalhes como: se o tempo de cozimento da 
massa foi corretamente executado, se a receita conseguiu ser fielmente cumprida e os ingredientes 
agradam ao paladar dos potenciais consumidores, se o tamanho atende às expectativas, etc. Com o 
recolhimento dessas percepções, junta-se uma base de informações suficientes para o processo de 
tomada de decisão e evolução natural do produto, gerando, na sequência, novas versões que poderão 
produzir maior grau de satisfação junto ao cliente ou usuário final. 
Por fim, é necessário também compreender a importância dos termos: definition of ready e 
definition of done. O curioso é que, ambas as palavras ready e done possuem o mesmo significado 
em português: pronto. Porém, há uma grande diferença no emprego desses dois termos quando o 
trabalho do gerenciamento do escopo é exigido. 
Quando o produto, o serviço ou a condição que se vai gerar existe apenas na imaginação de 
alguém ou de um grupo de pessoas, é necessário que as suas características e condições sejam 
inicialmente definidas. Esse trabalho, ou melhor, essa visão de produto, que é elaborada antes do 
próprio produto em si estar pronto, chama-se definition of ready (DoR). É como se define o que 
seria considerado pronto em relação à visão desse produto. A partir do momento em que essa visão 
for gerada, servirá como ponto de partida para o time do projeto. É como se dissessem: “Já temos 
condições de compreender a ideia e estamos prontos para gerar o produto”. Normalmente, quando 
se define uma característica ou condição, define-se também o seu critério de validação. 
 
 19 
 
Aqui, cabe um aparte para diferenciar critério de validação e critério de aceitação. O primeiro 
trata de garantir que a condição ou característica desejada foi efetivamente cumprida, e o segundo 
trata de realizar a formalização da entrega do produto – ou parte do produto, do serviço ou da 
condição –, também conhecido como handover. 
Em termos práticos, digamos que o seu projeto tenha sido entregar uma ponte com 5 metros 
de comprimento, 2 metros de altura, além de dois pilares de sustentação. Como validar se a ponte 
possui realmente 5 metros de comprimento? Existem diversas maneiras de se fazer isso, desde um 
processo de observação ou até mesmo uma medição com instrumentos de precisão. A questão não é 
fazer juízo de valor se o critério de validação é bom ou ruim, mas, sim, que exista um ou mais critérios. 
Logicamente, quanto mais preciso for(em) o(s) critério(s), maiores as chances de garantir 
que o produto foi desenvolvido conforme as orientações desejadas. Além disso, como ter certeza 
de que os 5 metros de comprimento foram aceitos pelo cliente do projeto e que o time do projeto 
não precisa – em tese – preocupar-se mais com esse detalhe? É necessário, por exemplo, que haja 
uma lista de verificação de características do produto e o cliente chancele de tempos em tempos 
os avanços das entregas. 
O “de acordo” ou a ciência explícita do cliente em relação às entregas do projeto são 
considerados critérios de aceitação. Ferramentas como relatórios de inspeção são bem eficazes nesse 
momento. Os critérios de aceitação podem ser estipulados para entregas intermediárias, mas o mais 
famoso de todos é, sem dúvidas, o Termo de Encerramento do Projeto (TEP), onde ocorre a entrega 
final do produto, do serviço ou da condição. 
 
Figura 6 – Fluxo DoR/DoD 
 
Para encerrar essa parte dos nossos ensinamentos, faltou definir o que vem a ser o termo DoD – 
definition of done, que nada mais é, então, do que conferir se o produto, o serviço ou a condição, depois 
da sua conclusão – em parte ou no todo –, está de acordo com as características desejadas no momento 
do DoR, a situação clássica de verificar se o realizado está de acordo com o que foi previsto. Em linhas 
gerais, então, temos o pronto “de antes” (DoR), que funciona como uma visão de futuro; e o pronto 
“de depois” (DoD), que confirma se o que foi desenvolvido está de acordo com a definição inicial – ou 
modificada ao longo do projeto – do produto.20 
 
Diferença entre escopo do projeto e escopo do produto 
Segundo o PMI (2017a), o termo escopo pode ser utilizado, dentro do contexto do 
gerenciamento de projetos, de duas maneiras: 
 Escopo do Produto – os recursos e as funções que caracterizam um produto, serviço 
ou resultado. 
 Escopo do Projeto – o trabalho realizado para entregar um produto, serviço ou resultado 
com os recursos e as funções especificados pelo escopo do produto. 
 
Em termos mais simples, para cumprir o escopo do produto, o time do projeto precisa 
compreender o que se pede para ser desenvolvido ou gerado e precisa caracterizar corretamente as 
suas propriedades no intuito de entregar uma versão final, de acordo com o que é esperado pelo 
cliente do projeto ou pelo usuário final. Já em relação ao escopo do projeto, depois de o time do 
projeto conseguir compreender o que precisa ser gerado, agora é o momento de definir como isso 
será gerado. É necessário definir as atividades de planejamento e de gerenciamento que garantam a 
realização – e não mais a definição – da entrega. 
Na prática, como perceber melhor essa diferença? Vamos utilizar como exemplo um projeto 
fictício de lançar um curso on-line de gerenciamento de projetos. O escopo do produto seria definir 
as características do curso, como carga horária, conteúdo e tipo de ambiente virtual a ser adotado, 
entre outras características. Já o escopo do projeto seria definir como conseguir as licenças 
necessárias para registrar o curso nos órgãos competentes, contratar mão de obra, alugar servidores 
de internet, etc. Ainda utilizando o exemplo do curso on-line, apenas para corroborar alguns 
ensinamentos da unidade anterior, algumas funcionalidades possíveis seriam: desenvolver 
conteúdo, estruturar trilha – do curso – e definir pré-requisitos. 
Em determinados momentos, pode haver uma confusão natural entre os dois termos. Isso 
ocorre quando o escopo do projeto é visto como incluindo o escopo do produto na sua definição 
de trabalho. Não é uma prática proibida, mas é sempre importante o time do projeto compreender 
como lidar com determinadas caracterizações do escopo, no intuito de não ocorrerem problemas 
de interpretação desses conceitos durante o andamento do projeto. 
 
Termo de abertura do projeto e processos de 
gerenciamento do escopo 
O gerenciamento do escopo possui influência direta no sucesso – assim como no fracasso – 
de um projeto. Exatamente por isso, costuma ser um dos temas mais explorados entre os 13 
capítulos do Guia PMBOK®. Um escopo precisa ser extremamente bem definido e mais ainda, bem 
 
 21 
 
controlado. Todo o restante do projeto depende disso. O gerenciamento do escopo possui o dom 
de potencialmente influenciar todas as demais áreas de conhecimento de um projeto. 
Sendo assim, um correto emprego dos processos de gerenciamento do escopo é visto como 
fator crítico de sucesso e visa a garantir que o time do projeto realize todo o trabalho requerido no 
intuito de assegurar a fiel entrega de todos os objetivos do projeto, da melhor maneira possível, de 
preferência com reconhecimento de valor junto às principais partes envolvidas. 
Antes mesmo de a área de escopo iniciar propriamente os trabalhos, o time do projeto já 
arregaçou as mangas e providencia detalhes que serão importantes para o futuro do trabalho. De 
acordo com o PMI (2017a), todo projeto inicia formalmente os seus trabalhos após a aprovação de 
um Termo de Abertura do Projeto (TAP). 
 
Os projetos são iniciados por uma entidade externa ao projeto, tais como 
um patrocinador, programa, escritório de gerenciamento de projetos 
(EGP) ou dirigente do órgão diretivo do portfólio ou o seu representante 
autorizado. O responsável pela iniciação do projeto ou patrocinador do 
projeto deve estar em um nível apropriado para captar o financiamento e 
dedicar recursos para o projeto (PMI, 2017a, p. 113). 
 
Como primeiro documento do projeto, o TAP representa o esforço inicial do time do projeto – 
time esse que provavelmente ainda não estará completo – para depositar todas as informações possíveis, 
e passíveis de serem transmitidas, a respeito do projeto, de maneira sumarizada, por meio de um 
documento de autorização formal. Ele deve corroborar a autoridade do gerente de projeto selecionado 
para liderar as ações, definindo o seu grau de autonomia, para que ele tenha toda a autoridade necessária 
para aplicar os recursos organizacionais em prol do trabalho do projeto, além de demonstrar também o 
grau de compromisso da organização com o trabalho que será desempenhado. 
Existe vida antes do projeto. Esforços já foram cometidos no sentido de avaliar cenários, 
pesquisar mercados, realizar estudos de viabilidade e o que mais for necessário para minimizar 
surpresas após a formal implementação do projeto. Tudo o que é realizado antes do projeto e que 
se relacione com o escopo que será gerado transforma-se em informação para auxiliar no início dos 
trabalhos do projeto. Na maioria das vezes, o TAP vem recheado de anexos contendo valiosos 
documentos pré-projeto (veja as “entradas” descritas na figura 7). Dependendo do grau de 
importância e de investimento do projeto, é comum, por exemplo, a realização de pré-projetos ou 
projetos-base para investigar melhor possíveis condições futuras. 
O processo que visa à elaboração de um TAP é veiculado à área de conhecimento de integração 
e encontra-se descrito no processo 4.1 – Desenvolver o Termo de Abertura do Projeto, constante do 
grupo de processos de iniciação, ou seja, antes do planejamento, no Guia PMBOK® (PMI, 2017a). 
 
 
22 
 
Para que se possa confeccionar um TAP de qualidade é importante que sejam observadas as 
entradas, ferramentas/técnicas e saídas demonstrados na figura 7, abaixo: 
 
Figura 7 – Processo 4.1: desenvolver o termo de abertura do projeto 
 
Fonte: PMI (2017a). 
 
É de bom tom que o TAP seja aprovado pelo patrocinador do projeto e, mesmo que não 
exista um formato ou template específico para confeccioná-lo, deve haver muita atenção no 
momento de gerar essa importante etapa do projeto. 
O Guia PMBOK® preconiza que “ele documenta informações de alto nível sobre o projeto e 
sobre o produto, serviço ou resultado que o projeto deve satisfazer” (PMI, 2017a) e, exatamente 
por conta disso, possui a capacidade de garantir um grau ótimo de entendimento comum aos 
principais stakeholders, descrevendo quais são as entregas e os marcos mais importantes, além de 
clarificar a visão do produto – que será melhorada quando o time de escopo do projeto der sequência 
aos trabalhos –, do serviço ou da condição que será gerada. 
Segundo Massari (2016), da mesma maneira que um TAP serve para definir a visão de um 
produto e formalizar o início dos trabalhos com foco em um planejamento mais detalhado, muitas 
outras técnicas podem ser utilizadas, por exemplo: inception enxuta, tweet charter, vision box, project 
model canvas, press release, elevator statement ou exploração 360º. 
Já em relação ao conteúdo de um TAP, o quadro 1 descreve o que é desejado e, se for o caso, não 
somente isso, mas quaisquer outros detalhes que forem julgados pertinentes pelo elaborador do artefato. 
 
 
 
 23 
 
Quadro 1 – Informações de alto nível requeridas em um TAP 
 finalidade do projeto; 
 objetivos mensuráveis do projeto e critérios de sucesso relacionados; 
 requisitos de alto nível; 
 descrição de alto nível do projeto, seus limites e entregas-chave; 
 risco geral do projeto; 
 resumo do cronograma de marcos; 
 recursos financeiros pré-aprovados; 
 lista das partes interessadas chave; 
 requisitos para aprovação do projeto (ou seja, o que constitui o sucesso do projeto, 
quem decide se o projeto é bem-sucedido e quem autoriza o encerramento do projeto); 
 critérios de término do projeto (ou seja, quais são as condições que devem ser 
cumpridas para encerrar ou cancelar o projeto ou a fase); 
 gerente do projeto designado, responsabilidade e nível de autoridade e 
 nome e autoridadedo patrocinador ou outra(s) pessoa(s) que autoriza(m) o termo de 
abertura do projeto. 
Fonte: PMI (2017a). 
 
Depois do advento do TAP, os esforços serão voltados ao Plano de Gerenciamento do Projeto 
(PGP), e um dos componentes principais desse documento é o Plano de Gerenciamento do Escopo 
(PGE), que será a base para o gerenciamento do escopo do projeto, definindo todas as regras 
inerentes ao trabalho do escopo para o time do projeto. 
Segundo o PMI (2017a), o gerenciamento do escopo do projeto encontra-se presente apenas 
em dois grupos de processos: planejamento, com quatro processos; e o de monitoramento e 
controle, com outros dois processos, conforme pode ser verificado no quadro a seguir. 
 
Quadro 2 – Processos do gerenciamento do escopo (Adaptado de PMI (2017a) 
 
iniciação planejamento execução 
monitoramento 
e controle 
encerramento 
 
5.1 Planejar o 
gerenciamento do escopo. 
 
5.5 Validar o 
escopo. 
 5.2 Coletar os requisitos. 
5.3 Definir o escopo. 5.6 Controlar o 
escopo. 5.4 Criar a EAP. 
 
 
24 
 
A integração da área de escopo com as demais áreas de conhecimento preconizadas pelo Guia 
PMBOK® é essencial, pois a partir do momento em que as quatro etapas de planejamento do escopo 
começam a gerar informações para o time do projeto, as ações passam a girar em função do fiel 
cumprimento do que estiver estipulado para ser entregue. 
Cumprem-se então todas as atividades necessárias para estruturar, definir e conscientizar as 
principais partes interessadas a respeito do trabalho necessário à concretização do escopo do projeto 
e paulatinamente os processos são realizados. Inicia-se com o processo 5.1, que fornecerá 
informações para o 5.2, o 5.3 e o 5.4. Mesmo que não haja uma versão final de um PGE, essas 
informações já geram energia suficiente para que os requisitos possam começar a ser colhidos, 
documentados, analisados e priorizados. 
Por sua vez, as informações do processo 5.2 também serão importantes para os trabalhos do 
5.3 e do 5.4, que trabalharão artefatos como a declaração do escopo do projeto e a linha de base de 
entregas, também conhecida como Estrutura Analítica do Projeto (EAP). 
O curioso é que, depois da conclusão de uma primeira versão aplicável da EAP, as 
informações retornam aos pontos de origem, ou seja, uma linha de base pronta no processo 5.4 
retorna informações para o 5.3, para o 5.2 e para o 5.1. Então, o ciclo se fecha, pois todo o fluxo 
de ida e de volta foi realizado por meio de mútuas ações do time do projeto, visando ao 
planejamento do escopo. Com o planejamento do escopo do projeto pronto, outras áreas também 
vão reforçar os seus respectivos planos complementares no intuito de gerar um único e grande 
documento: o PGP. 
Quando uma entrega encontra-se pronta para validação, há uma sincronia da área de escopo 
com a área de qualidade. Somente após o “ok” do time de qualidade é que o escopo, ou parte dele, 
poderá ser validado – processo 5.5. Entretanto, sempre que houver algum tipo de problema ou 
desconformidade em relação àquilo que foi planejado nos processos iniciais – 5.1 a 5.4 –, há a 
possibilidade de controlar o escopo – processo 5.6 – acionando o controle integrado de mudanças 
do projeto, processo vinculado à área de integração. 
Uma visão mais detalhada a respeito desses processos nos será fornecida nas próximas 
unidades do nosso material. 
 
Retrospectiva do módulo 
O Módulo I iniciou a sua trajetória trazendo a evolução histórica do conceito de escopo. 
Desde as primeiras abordagens vinculadas a Peter Drucker e o conceito de Administração por 
Objetivos, passando pela evolução de uma melhor definição e mensuração de objetivos, até 
chegarmos aos dias de hoje e à massiva importância destinada a esse conceito por meio dos 
principais institutos de gerenciamento de projetos do mundo. 
 
 25 
 
Atualmente, por advento do Agile Practice Guide – Guia das Práticas Ágeis –, orientado para 
ser utilizado em conjunto com o Guia PMBOK®, pudemos visualizar que o tratamento destinado 
ao escopo precisa ser determinado logo no momento de optar pelo ciclo de vida do projeto e como 
ele será trabalhado. As opções variam entre ciclos preditivos, com maior previsibilidade e segurança 
para trabalhar um escopo fechado com foco em uma documentação de planejamento restrita em 
muitas situações, até ciclos ágeis, onde a palavra de ordem é “mudança”, e o time precisa estar 
preparado para adaptar-se às múltiplas variáveis de um projeto, com um escopo aberto e flexível, 
voltado para a satisfação das principais partes interessadas, por meio da proposta de entrega de valor. 
Essas considerações puderam ser observadas por meio de uma avaliação junto à teoria do triângulo 
invertido das restrições em projetos. 
Na sequência, os principais conceitos vinculados ao gerenciamento do escopo em projetos 
foram tratados e tivemos a oportunidade de conhecer os ciclos iterativos, que exigem um 
planejamento e uma execução para cada etapa de evolução, visando sempre às entregas parciais com 
o objetivo de colher feedbacks e melhorar o produto, o serviço ou a condição que está sendo gerada, 
de maneira gradativa e muitas vezes, empírica. 
Também avaliamos os conceitos de DoR, a versão de “pronto” antes de o produto ser gerado, 
e DoD, a versão de “pronto” depois da geração do produto, que exige uma comparação entre 
planejado X realizado para que se obtenham os resultados do projeto. A importância de trabalhar o 
conceito de um MVP foi demonstrada por mais de um exemplo, sendo possível verificar que quanto 
mais informação tem-se a respeito de um determinado produto, maior a chance de evoluírem os 
trabalhos com redução de gastos e desperdícios. 
A aplicação desse conceito proporciona não só um alto grau de aprendizado, como também 
objetiva proposta de entrega de valor – percebido –, gerando versões com características mínimas 
implementadas, para validá-las e melhorá-las. 
Também foram estudados os conceitos de funcionalidade e de caixa de tempo – timebox –, 
assim como a diferença entre critério de aceitação e critério de validação, termos extremamente 
importantes e que, até hoje, são muito confundidos por profissionais do mercado. 
A diferenciação entre escopo do projeto e escopo do produto também é vital para o bom 
andamento dos trabalhos do gerenciamento do escopo em um projeto. Foi então, possível observar 
que o escopo do produto são as características inerentes ao produto, ao serviço ou à condição que 
está sendo gerada como objetivo do projeto, e o escopo do projeto é o meio para se chegar a esse 
fim, determinando todos os trabalhos que precisam ser realizados para alcançar a entrega final. 
Por fim, adentramos nos processos descritos pelo Guia PMBOK®, onde primeiro foi-se verificado 
o que é essencial para que um projeto possa ser formalmente iniciado, os esforços de uma fase pré-
projeto e o principal documento do grupo de processos de iniciação: o TAP. Não só foram ilustrados 
os processos e procedimentos envolvidos para o nascimento de um projeto como também foi 
demonstrado o princípio dos trabalhos com os processos do gerenciamento do escopo, incluindo os 
grupos de processos do planejamento e de monitoramento e controle, onde a parceria com as áreas de 
conhecimento da qualidade e da integração são fundamentais para o sucesso do bom trabalho do escopo. 
 
 
 
 
 
 
Neste módulo, serão evidenciados os dois processos iniciais do gerenciamento do escopo em 
projetos, ambos alocados no grupo de processos do planejamento, conforme preconiza o Guia 
PMBOK® (PMI, 2017a). Por consequência, visando a uma boa compreensão dos trabalhos do 
gerenciamento do escopo em projetos, também serão demonstrados os principais artefatos inerentes 
a esses processos, quais sejam: o PGE, o plano de gerenciamento dos requisitos, o registro de 
requisitos e a matriz de rastreabilidade dos requisitos. Além disso, mergulharemos também em um 
melhor entendimento do termo “requisitos” e dos seus possíveis desdobramentos. Algunsnovos 
conceitos e abordagens foram introduzidos por meio da última versão do Guia PMBOK®. Esses 
detalhes precisarão de uma atenção especial na condução do módulo, pois fazem parte do cotidiano 
de qualquer profissional que trabalhe com o gerenciamento do escopo. 
 
Processo “Planejar o Gerenciamento do Escopo”: 
peculiaridades, entradas, técnicas e ferramentas 
Sempre que estou diante de um novo grupo tratando do assunto gerenciamento do escopo 
em projetos, uma pergunta que frequentemente faço nos momentos iniciais é: “Quem aqui já viu 
ou fez um plano de gerenciamento do escopo?”. No início da implementação desse hábito, a minha 
surpresa era grande, por nenhum, ou no máximo um ou dois indivíduos, conhecer algo sobre esse 
documento em particular. Porém, com o passar do tempo, aliado aos constantes trabalhos de 
gerenciamento de projetos realizados profissionalmente, pude deixar essa surpresa de lado. 
Afinal de contas, na prática, tal documento é realmente uma das coisas mais difíceis de 
encontrar em um projeto. Não que o documento não seja eficiente, muito pelo contrário, mas a 
realidade, notadamente a brasileira, salvo melhor juízo, não é de se perder muito tempo com 
MÓDULO II – PLANEJAMENTO DO 
ESCOPO: PARTE I 
 
28 
 
documentações de projetos em demasia, a menos que os colaboradores de uma determinada 
organização sejam impelidos a isso, por motivo de lei, por exemplo. 
Em muitos casos, as próprias empresas já possuem normas internas ou recomendações de 
processos que asseguram um cumprimento do trabalho de um gerenciamento do escopo alinhado 
com boas práticas organizacionais, mesmo que isso não seja amplamente divulgado. A sensação 
então é que os representantes do time do projeto sabem o que precisa ser feito para um correto 
gerenciamento do escopo, mas não sabem explicar como chegaram às vias de fato. 
Passa a ser um intangível, muitas vezes enraizado por meio de uma cultura organizacional. 
Por fim, na grande maioria das vezes, não sentem a necessidade de gerar um PGE. Como essa etapa 
é “pulada”, às vezes até negligenciada, sem mais delongas, apenas os demais processos do 
planejamento do escopo demonstram-se nítidos e compreendidos mais facilmente para o dia a dia 
das atividades de um gerenciamento do escopo, por exemplo, lidar com os requisitos de um projeto. 
 Então, o que eu tenho feito para conseguir explicar a incrédulos alunos e profissionais do 
gerenciamento de projetos a respeito da importância de um bom PGE em projetos? Simples: basta 
demonstrar o que, efetivamente, é um PGE em projetos, a sua importância e o que ele pode trazer 
de benefícios quando corretamente utilizado em um projeto. A partir do momento em que 
profissionais de projetos conhecem o artefato – o PGE –, conseguem compreender detalhes que 
antes se perdiam potencialmente ao longo de trabalhos até mesmo bem gerenciados, mas, de alguma 
forma, ficava a sensação de ter deixado algo para trás. 
Sendo assim, a grande função de um PGE é tratar a maneira ou, melhor dizendo, as normas 
ou condições por meio das quais o assunto “escopo” – escopo do projeto e escopo do produto – 
será conduzido ao longo de um projeto específico, por exemplo, como serão definidos, validados e 
controlados. Isso se faz necessário para que o time do projeto não tenha dúvidas a respeito de como 
construirá a sua EAP ou qual software poderá ser utilizado para registrar o avanço dos trabalhos, 
apenas para citar rápidos exemplos. 
Como o próprio PMI (2017a, p.166) preconiza, “as tendências e práticas emergentes para o 
gerenciamento do escopo do projeto incluem, mas não estão limitadas a, um foco em colaborar 
com os profissionais de análise de negócios para facilitar a implementação bem-sucedida do 
produto, serviço ou resultado final do programa ou projeto”. 
Isso denota maior preocupação do instituto com um trabalho de gerenciamento do escopo 
não sendo meramente realizado dentro da esfera do projeto, mas, sim, em um ambiente de 
governança corporativa em que colaborações de setores de análises de negócio podem trazer grandes 
benefícios. Além disso, como cada projeto é exclusivo, o time do projeto, com auxílio do gerente 
do projeto, precisará ajustar a maneira como os processos do gerenciamento do escopo do projeto 
são conduzidos no intuito de melhor adaptar o trabalho realizado com o modelo de continuidade 
do ciclo de vida do projeto: preditivo, iterativo, incremental, ágil ou híbrido. 
 
 29 
 
O processo de planejar o gerenciamento do escopo do projeto será realizado uma vez ou, 
então, em momentos definidos previamente, ao longo do projeto. A figura 8 dimensiona quais são 
as entradas, ferramentas e saídas, conforme orientação do PMI (2017a). 
 
Figura 8 – Processo 5.1: planejar o gerenciamento do escopo 
 
Fonte: PMI (2017a). 
 
A partir daqui, cabem algumas considerações, pois apesar de o PMI preconizar a saída de dois 
artefatos – o PGE e o plano de gerenciamento dos requisitos –, em alguns casos, o segundo pode 
estar contido dentro do primeiro, e teríamos um único documento servindo como componente de 
um PGP. A opção por redigir dois documentos ou um só é mais uma customização que poderá ser 
vivenciada pela equipe do projeto, contanto que seja mantido o foco na melhoria de processos 
internos e não afete uma boa condução dos trabalhos do gerenciamento do escopo ao longo do 
projeto ou do programa. 
O TAP é a uma das principais fontes de informação no momento de confecção de um PGE; 
afinal de contas, é o documento mais atualizado e completo até esse momento do projeto. Sendo 
assim, é muito comum que seja considerado como primeira referência de entrada para recebimento 
de informações. Na sequência, vemos a preocupação do PMI com um componente importante – 
possivelmente, ainda não finalizados – do plano de gerenciamento do próprio projeto, por meio do 
plano de gerenciamento da qualidade, que influencia diretamente como o escopo do projeto e o 
escopo do produto poderão ser gerenciados. 
Uma empresa detentora de um determinado padrão ISO de qualidade poderá influenciar como 
o trabalho de condução do escopo – escopo do projeto – será determinado, por exemplo. Além, 
obviamente, da descrição do ciclo de vida do projeto e, por consequência, qual será a abordagem de 
desenvolvimento escolhida pelo time do projeto, por exemplo, iterativa ou ágil. Essas definições serão 
fundamentais para determinar as orientações de como o escopo será tratado – gerenciado – ao longo 
do projeto ou programa. Também, não podendo deixar de avaliar as informações constantes nos 
fatores ambientais da empresa, aqui notadamente representados por cultura organizacional, padrão 
 
30 
 
de infraestrutura, condições de mercado e modus operandi de administração. Por fim, avaliam-se 
políticas, procedimentos, históricos pertinentes de informações e lições aprendidas, todos 
considerados possíveis ativos de processos organizacionais de uma organização. 
Como ferramentas e técnicas, há sugestão para a utilização de opinião especializada, que vem a 
ser, nesse caso, não só a experiência de indivíduos ou de coletividades com conhecimento ou capacitação 
especializada vinculada a projetos de mesmo porte ou estrutura anteriores, mas também informações 
sobre o setor, a disciplina e a área de aplicação do projeto ou programa a ser desenvolvido. Em conjunto, 
recomenda-se a utilização de técnicas de análises de dados, com maior enfoque na análise de alternativas, 
e de reuniões, podendo incluir qualquer parte interessada com responsabilidade por conduzir quaisquer 
dos processos do gerenciamento do escopo, entre outros, mediante necessidade. 
Já as saídas, caracterizadas como os artefatos já citados anteriormente, serão tratadas com mais 
propriedades na unidade seguinte. 
 
Processo “Planejar o Gerenciamento do Escopo”: saídas 
Os dois artefatos preconizados como saídas para o processo “planejar o gerenciamento do escopo” 
são, conforme figura 8, o PGE e o plano de gerenciamento de requisitos, ambos componentesdo PGP. 
Segundo o PMI (2017a), o PGE inclui: 
 
Quadro 3 – Itens desejáveis em um PGE 
 o processo de preparação da declaração do escopo do projeto; 
 o processo que possibilita a criação da EAP a partir da declaração do escopo do 
projeto detalhada; 
 o processo que define como a linha de base do escopo será aprovada e mantida e 
 o processo que especifica como será obtida a aceitação formal das entregas do 
projeto concluídas. 
Fonte: PMI (2017a). 
 
Como todo documento de projeto, o que se demonstra por meio desta unidade é uma 
proposta de artefato para contemplar os trabalhos recomendados no processo “planejar o 
gerenciamento do escopo”, sendo que, como todo documento constante em um plano de 
gerenciamento de projeto, trata-se de mera sugestão, no entanto, com observância às 
recomendações preconizadas pela versão mais recente do Guia PMBOK®. 
Contudo, é preciso recordar que cada projeto possui as suas próprias especificidades, e é sempre 
recomendável que um template não seja absoluto para a confecção de artefatos em todos os projetos 
possíveis e imaginários. Talvez aqui, contemple-se a grande dificuldade do ambiente do 
gerenciamento profissional de projetos: determinar templates padrões para todas as ocasiões. É de bom 
 
 31 
 
tom que o time do projeto possa utilizar um template padronizado, mas, que acima de tudo, avalie a 
correta aplicação dos seus itens e o atualize conforme as necessidades do projeto em que será aplicado. 
Adaptando os itens recomendados via Guia PMBOK®, assim como o modelo demonstrado 
por Snyder (2013), esse material sugere um PGE como descrito no quadro a seguir. 
 
Quadro 4 – Template proposto para um PGE 
plano de gerenciamento do escopo 
título do projeto: ___________________________________________________________ data: ___/___/___ 
1 – desenvolvimento da declaração de escopo 
(itens essenciais e desejáveis) 
2 – estrutura da EAP 
(Como será organizada? Qual ferramenta será utilizada?) 
3 – dicionário da EAP 
(Identificar os campos e o nível de detalhes que serão utilizados) 
4 – manutenção da linha de base do escopo 
(Quais tipos de mudanças de escopo precisam passar pelo processo formal de controle? Qual 
é a frequência de avaliação do escopo do projeto?) 
5 – priorização das mudanças de escopo e respostas 
(Como as mudanças serão gerenciadas? Diferenciar o que é mudança e o que é revisão 
de escopo) 
6 – aceitação da entrega 
(Identificar como a entrega será aceita, incluindo documentos para aprovação) 
7 – integração entre escopo e requisitos 
8 – administração do PGE 
Fonte: adaptado de Snyder (2013). 
 
No item 1, é interessante descrever não só o que se deseja em uma futura construção de uma 
declaração de escopo (artefato que será gerado como saída do processo 5.3 – Definir o escopo), mas 
também, na medida do possível, como ela será desenvolvida, incluindo quaisquer análises de 
alternativas, pesquisas ou, por exemplo, entrevistas com uma parte interessada importante do projeto. 
O item 2 descreve que tipo de EAP será confeccionada – piramidal, em tabela, mapa mental, 
etc. –, além de descrever se ela será norteada, ou seja, a maneira de o time do projeto enxergar as 
 
32 
 
entregas do projeto, que poderá ser descrevendo as fases do projeto, geografia, principais entregas 
ou ainda de qualquer outra maneira que julgar necessária. 
Diretrizes para estabelecer contas de controle e pacotes de trabalho poderão ser, por 
exemplo, também descritos nesse item. O item 3 determina como será redigido o dicionário da 
EAP, e o item 4 é autoexplicativo, determina o intervalo de tempo em que é realizado o trabalho 
de avaliação do escopo do projeto, bem como as necessidades de realizá-lo mediante um processo 
formal e como documentá-lo. 
No item 5, caracterizar corretamente o que é uma mudança de escopo e o que é uma revisão 
de escopo, além dos trâmites para aprovação e documentação dessas subetapas. Aqui, dependendo 
do ciclo de vida do projeto determinante para a abordagem a ser empregada, poderá haver alguma 
distinção na maneira de se apresentar esse conceito. 
No item 6, podem-se incluir os termos de aceite para as entregas mais importantes ou 
determinados milestones do projeto. 
No item 7, descrever como os itens de escopo do projeto e do produto serão abordados na 
declaração de escopo do projeto e na EAP, além de identificar os pontos de integração entre 
validação de requisito e do escopo do produto. 
No item 8, determinar quem é o responsável pela administração e manutenção do PGE 
devidamente atualizado e, na sua ausência, quem poderá ser considerado como substituto habilitado 
para exercer a sua função. Por fim, assinaturas, especificação de versões e chancelas são 
determinações específicas de cada organização. 
Já o plano de gerenciamento de requisitos, segundo o PMI (2017a), deve incluir: 
 
Quadro 5 – Itens desejáveis em um plano de gerenciamento de requisites 
 como as atividades dos requisitos serão planejadas, acompanhadas e reportadas; 
 atividades de gerenciamento da configuração, tais como: a maneira como as mudanças 
serão iniciadas; como os impactos serão analisados; como serão rastreados, 
monitorados e reportados; assim como os níveis de autorização necessários para 
aprovar tais mudanças; 
 processo de priorização dos requisitos; 
 métricas que serão usadas e os argumentos que justificam o seu uso; e 
 uma estrutura de rastreabilidade que reflita quais atributos dos requisitos serão 
capturados na matriz de rastreabilidade. 
Fonte: PMI (2017a). 
 
Segundo PMI (2017c), 47% dos projetos malsucedidos não atingem as metas originais 
devido à falta de gerenciamento de requisitos. No relatório de 2017 da pesquisa The Pulse of the 
Profession, 39% dos projetos malsucedidos identificam a coleta de requisitos imprecisos como causa 
principal dessa falha. O trabalho de gerenciamento de requisitos se inicia, normalmente, de uma 
 
 33 
 
maneira muito sutil e é comum vê-lo negligenciado por muitos times de projeto. A vontade ou 
necessidade de fazer, na maioria das vezes, suplanta o ato de fazer da maneira apropriada. Requisitos 
são a essência de qualquer projeto, e sempre que forem tratados de maneira imprópria, haverá uma 
chance altíssima de trazer infortúnios e dissabores com as principais partes interessadas do projeto. 
Exatamente por isso, é recomendável a utilização de um plano de gerenciamento de requisitos desde 
os primórdios do planejamento do escopo. 
 
Quadro 6 – Template proposto para um plano de gerenciamento de requisitos 
plano de gerenciamento de requisitos 
título do projeto: ___________________________________________________________ data: ___/___/___ 
1 – coleta 
2 – análise 
3 – categorias (identificação: requisitos de negócios, qualidade, PI, etc.) 
4 – documentação 
5 – priorização 
6 – métricas 
7 – estrutura de rastreabilidade de requisitos (Identificar as informações que serão 
utilizadas para conectar a origem do requisito até a sua entrega) 
8 – rastreamento (frequências e técnicas) 
9 – geração de relatórios (ferramentas, periodicidade, etc.) 
10 – critérios de validação 
11 – gerenciamento da configuração e sistema de controle de mudanças nos requisitos 
(Define níveis de autorização, de visualização, de documentação, etc.) 
12 – administração do PGR 
Fonte: adaptado de Snyder (2013). 
 
No item 1, define-se como os requisitos serão coletadas, os momentos – ciclos – e as técnicas 
que poderão ser utilizados. 
No item 2, deve-se descrever como será realizado o processo de análise desses requisitos já 
coletados, verificando o impacto sobre a abordagem do produto ou do projeto. 
No item 3, determinar como os requisitos serão organizados e classificados. 
Já no item 4, demonstrar como os requisitos serão documentados. A maneira de documentar 
os requisitos pode variar de uma planilha em Excel para um template mais elaborado, contendo 
macros, descrições e anexos detalhados. 
 
34 
 
Em relação ao item 5, existemmuitas técnicas de priorização de requisitos, desde as mais 
simples de determinar níveis alto-médio-baixo ou por números, por exemplo, mas o importante é 
caracterizar como se demonstrarão os requisitos inegociáveis, no intuito de traçar uma estratégia de 
priorização de entrega de valor. 
Ainda como maneiras de priorização de requisitos, existem técnicas simples que podem ser 
facilmente adotadas pelo time do projeto e poderão agregar muito valor ao trabalho do 
gerenciamento de requisitos. Neste material, serão descritas apenas duas, das muitas possíveis: a 
matriz de importância X urgência e a técnica conhecida como MoSCoW. 
 
Quadro 7 – Matriz importância X urgência 
 urgentes não urgentes 
im
po
rt
an
te
s 
Acrescentam valor e resultados e são 
de resolução imediata. 
Não são de resolução imediata, mas 
acrescentam valor e resultados. 
nã
o 
im
po
rt
an
te
s 
São de resolução imediata, mas não 
acrescentam valor. 
Não acrescentam valor nem são de 
aplicação imediata. 
 
A matriz de importância X urgência é uma técnica simples que utiliza os quadrantes de uma 
matriz com o eixo de grau de importância – alta/baixa ou sim/não – e o outro eixo de grau de 
urgência para os requisitos serem implantados (idem). A técnica é simples, pois consiste basicamente 
em separar os requisitos determinando se uma funcionalidade, por exemplo, é considerada com alto 
ou baixo grau de importância e com alto ou baixo grau de urgência. 
Os requisitos que forem classificados com alta importância e alta urgência são aqueles que 
visivelmente acrescentam valor ou resultado imediato e possuem um grau de resolução também 
imediato. Serão considerados requisitos essenciais, e precisam ser implantados o mais rápido 
possível. Os requisitos classificados com baixo grau de importância e alta urgência são considerados 
secundários, pois, apesar de serem de resolução imediata, não geram valor aos olhos dos principais 
stakeholders. Os requisitos classificados entre alto grau de importância e baixo grau de urgência 
também serão considerados secundários. A diferença é que, apesar de não serem considerados como 
resolução rápida ou imediata, possuem a possibilidade de acrescentar valor ou resultados ao projeto. 
Por fim, os requisitos que não são nem importantes nem urgentes, pois não agregam valor nem são 
de resolução imediata. Precisam ser mapeados, mas dificilmente serão implantados, dependendo de 
um processo estruturado de tomada de decisão. 
 
 35 
 
Figura 9 – Técnica MoSCoW 
 
Fonte: Cruz (s/d). 
 
Segundo PMI (2016), cada requisito levantado pela equipe do projeto tem a possibilidade de 
ganhar uma classificação de prioridade determinada pela utilização do acrônimo formado pela 
palavra MoSCoW. 
A letra M significa must have ou, em português, algo como “precisa ter”. Serão os requisitos 
tratados em primeiro nível, aqueles imprescindíveis e que trazem uma relação de retorno alto. Por 
conta disso, possuem a capacidade de agregar valor ao produto, serviço ou resultado que está 
sendo gerado e, quando corretamente implementados, afetar diretamente os níveis de satisfação 
dos principais stakeholders. 
A letra S significa should have ou “deveria ter”. São os requisitos secundários. Não serão 
tratados como vitais ao projeto, mas são importantes e quando implantados corretamente 
podem influenciar diretamente níveis de qualidade, tornando operacional um determinado 
detalhe de um produto, por exemplo. 
A letra C significa could have ou “poderia ter”. Serão tratados como requisitos terciários 
e, apesar de poder trazer algum diferencial àquilo que estará sendo gerado pelo time do projeto, 
não são tão imprescindíveis. Costumam ser implementados apenas em caso de sobra de recursos 
ou folga de cronograma. 
Por fim, há a letra W, de won’t have ou “não terá”. Requisitos que não trazem qualquer tipo 
de valor agregado para o produto, serviço ou resultado que está sendo desenvolvido e serão 
implementados apenas em último caso. 
Retomando o template demonstrado para o plano de gerenciamento de requisitos, no item 6 
devem-se determinar as métricas pelas quais os requisitos serão comparados. Significa estabelecer os 
padrões de DoR para que no futuro o DoD possa ser comparado. No item 7, identificar as 
informações que serão utilizadas para acompanhar o requisito desde o início da sua identificação e 
catalogação, até a validação da sua entrega. No item 8, descrever como deverá ser conduzido o 
progresso da implantação dos requisitos. No item 9, descrever como os relatórios da gestão dos 
 
36 
 
requisitos serão realizados, a sua frequência, tipo, entre todos os detalhes pertinentes. No item 10, 
identificar quais os critérios de validação dos requisitos, por exemplo, testes, inspeções, 
demonstrações, etc. No item 11, descrever qual sistema de gerenciamento de configuração será 
atrelado para controlar os requisitos, a sua documentação, assim como o processo de gerenciamento 
de mudanças. Por fim, tal como o PGE, determinar quem será o responsável pela administração e 
manutenção do plano de gerenciamento de requisitos, além de definir o responsável imediato no 
caso de ausência do principal. 
 
Processo “Coletar os Requisitos”: peculiaridades, entradas, 
técnicas e ferramentas 
Em primeiro lugar, é importante salientar que o PMI (2016, p. 2, tradução nossa) define 
requisito como “uma condição ou capacidade que é necessário estar presente em um produto, 
serviço ou resultado, para satisfazer um contrato ou especificação formalmente imposta”. Essas 
especificações podem ser normas ou metas organizacionais estratégicas. É comum que os requisitos 
expressem necessidades, desejos, anseios, temores e expectativas explicitadas por partes interessadas 
específicas – clientes internos, externos, patrocinador, usuário final, organizações, cliente, time do 
projeto, etc. – e sempre que relacionados podem vir a gerar novas funcionalidades que precisarão 
ser implementadas, muitas vezes agregando trabalho ao gerenciamento de estruturação, que será 
realizado mais adiante. 
Exatamente por que os requisitos nascem de informações que estarão diretamente vinculadas 
ao sucesso ou fracasso do projeto, o seu gerenciamento é algo que demanda uma especial atenção 
por parte do time do projeto. Aqui estão alguns fatores críticos de sucesso que precisam ser 
observados no momento de lidar com o assunto requisito: 
 Engajamento organizacional – todo trabalho que envolve um viés estratégico demanda que 
a organização esteja comprometida e alinhada com as propostas de entrega de valor e os 
objetivos do projeto. O representante maior desse engajamento é o sponsor (patrocinador) 
do projeto, pois existe a constatação de que falta de apoio de um patrocinador é um dos 
principais fatores que contribuem para o fracasso de um projeto (PMI, 2018). 
 Reconhecimento do valor de um plano de gerenciamento de requisitos – um plano de 
gerenciamento de requisitos corretamente elaborado e ativo, por meio do qual se possa 
não avaliar um trabalho de planejamento, mas, sobretudo, um trabalho de monitoramento 
e controle, será percebido como um domínio valioso com um potencial de alavancar o 
ROI do projeto e, por consequência, da organização capitaneadora do projeto. 
 Engajamento das partes interessadas – as partes interessadas devem ser engajadas com 
devida antecedência e com frequência ao longo do ciclo de vida do projeto, 
independentemente do ciclo de continuidade escolhido pelo time para executá-lo. As 
 
 37 
 
partes interessadas serão analisadas e gerenciadas de perto, com frequência, no intuito de 
que o time do projeto possa perceber os impactos e as influências dos principais 
stakeholders no processo de gerenciamento de requisitos o mais cedo possível, 
minimizando ou eliminando potenciais problemas. 
 Integração com as atividades do gerenciamento do projeto – o gerenciamento de requisitos 
não ocorre de maneira isolada. É necessário que todas as principais ações do time do 
projeto, bem como