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ário final, 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
MÓDULO I – ESCOPO: CONCEITOS
FUNDAMENTAIS

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

10
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).

11
 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 ela estivesse em operação.

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

13
 É 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.

14
 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

15
ú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 conceito que 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.

16
 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

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

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

19
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

20
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).

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

22
 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 autoridade do 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)

monitoramento
iniciação planejamento execução encerramento
e controle

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

5.4 Criar a EAP. escopo.

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

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

25
MÓDULO II – PLANEJAMENTO DO
ESCOPO: PARTE I

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. Alguns novos
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
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.

28
 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

29
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 componentes do 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

30
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

31
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

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

33
 Em relação ao item 5, existem muitas 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

importantes

Acrescentam valor e resultados e são Não são de resolução imediata, mas

de resolução imediata. acrescentam valor e resultados.
importantes

São de resolução imediata, mas não Não acrescentam valor nem são de
não

acrescentam valor. 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.

34
 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

35
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

36
 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 das principais partes interessadas estejam conectadas, de alguma
maneira, com o trabalho conduzido pelo time de requisitos, descrito no PGP.

Requisitos podem ser classificados de diferentes maneiras para auxiliar no processo de

transparência de informações, clareza, e prover um melhor contexto para o seu gerenciamento. De
acordo como um determinado requisito, vem a ser classificado, muito se pode dizer a respeito do
trabalho que virá a ser realizado, notadamente, na questão da descoberta da fonte da informação e
do futuro processo de elicitação – ato de obter as informações das principais partes interessadas.
Essas classificações, por sua vez, podem ser:
 Requisitos de negócio – são a verdadeira justificativa do por que um projeto é iniciado.
Descrevem as necessidades ou ideias de alto nível estratégico organizacional para que possa
ser resolvido um problema ou atender a uma necessidade.
 Requisitos de partes interessadas – descrevem as necessidades de um determinado
stakeholder ou de um grupo de stakeholders. Costumam revelar as expectativas desse
stakeholder com o que será gerado pelo projeto e são a base para identificar os
requerimentos de solução.
 Requisitos de solução – descrevem as funcionalidades e recursos que o produto, serviço ou
resultado a ser gerado precisam exibir no intuito de atender aos requisitos de negócio e aos
requisitos das partes interessadas. Assim como é importante compreender o que precisa
ser exibido, muitos autores também defendem que o que não precisa ser exibido deve ser
tratado da mesma maneira. São comumente conhecidos como:
 Requisitos funcionais – são comportamentos que precisam ser exibidos ou operações
específicas que a solução vai executar.
 Requisitos não funcionais – são condições ambientais ou atributos exigidos, não
necessariamente obrigatórios, para que a solução gerada funcione de maneira eficaz.
 Requisitos de transição – descrevem as capacidades temporárias essenciais para migrar de
um estado atual para um estado futuro, incluindo conversão de dados e formações de
preenchimento de lacunas.
 Requisitos de qualidade – descrevem os padrões necessários para prover a conclusão das
entregas do projeto, demonstrando conformidade das funcionalidades estipuladas ao longo do
planejamento com as que foram ou serão implantadas, assim como as métricas de qualidade.

37
  Requisitos do projeto – descrevem as ações ou quaisquer condições necessárias para que o
time do projeto possa executar o trabalho e entregar a solução proposta.
 Requisitos do programa – descrevem as especificações e saídas necessárias para entregar os
benefícios propostos pelo gerenciamento do programa.

O PMI (2017a, p. 174) define o processo de coletar os requisitos como “determinar,

documentar e gerenciar as necessidades e requisitos das partes interessadas a fim de cumprir os
objetivos” e ainda afirma que “o principal benefício deste processo é que o mesmo fornece a base
para definição e gerenciamento do escopo do produto e do projeto”.
Antes da publicação do Requirements Management: a practice guide (PMI, 2016), muito se falava
e pouco se fazia em relação ao gerenciamento de requerimentos em um projeto. O próprio Guia
PMBOK® sempre trabalhou com dezenas de processos interligados, mas o assunto requisito era relegado
a uma única menção, junto ao grupo de processos de planejamento, quando se tratava o escopo.
Independentemente de diversas pesquisas e apelos em relação a um correto e detalhado
gerenciamento de requisitos, pouco se fez para auxiliar um momento tão crucial ao projeto. No
entanto, desde o lançamento da primeira versão do The PMI Guide to Business Analysis, em 2015 –
hoje, encontra-se na sua segunda edição –, o assunto requisito começou a ganhar o tratamento que
merece, culminando com o advento da publicação em 2016, do Requirements Management.
Esses dois guias são hoje essenciais para qualquer indivíduo que pretenda dominar o trabalho
do escopo em um projeto, notadamente, a questão dos requisitos. Juntos com o Guia PMBOK® e
o Agile Practice Guide, ambos de 2017, servem como referência no assunto e pautam como deve ser
realizado o importante trabalho de gerenciamento de requisitos.
Assim como o processo anterior, o processo de coletar os requisitos será realizado uma vez
ou, então, em momentos definidos previamente, ao longo do projeto. A figura 10 demonstra quais
são as entradas, ferramentas e saídas, conforme orientação do PMI (2017a).

38
 Figura 10 – Processo 5.2: coletar requisitos

Fonte: PMI (2017a).

O TAP continua sendo uma das principais fontes de informação no momento de coletar os
requisitos. Mesmo que o PGE e o plano de gerenciamento dos requisitos estejam plenamente
prontos, o momento do planejamento do projeto ainda é mais próximo do insipiente, portanto,
ainda se baseia muito na documentação formulada no momento da iniciação do projeto, e não só
nesse momento, pois também vai buscar informações pré-projeto, como o caso de um possível
business case que tenha sido idealizado ou quaisquer outros documentos de estudo de viabilidade ou
pesquisa de mercado, por exemplo.
Além disso, obviamente, estará se baseando em informações provenientes dos planos que
foram confeccionados no processo passado com a também referência de informações provenientes
do plano de engajamento das partes interessadas. Sim, afinal de contas, se o time do projeto vai a
campo para colher requisitos, nada mais justo que possuir as informações constantes desse plano
para compreender quais são as regras destinadas ao tratamento das partes interessadas, assim como
o registro das partes interessadas que também fornecerá informações preciosas, por exemplo, nomes,
telefones, e-mails e horários para contato.
Cabe ressaltar que a última edição trouxe uma novidade interessante para o auxílio da gestão
do conhecimento do projeto – função da área de conhecimento de integração – que afeta
diretamente o trabalho de coletar os requisitos. As premissas e restrições do projeto possuem
artefatos exclusivos que registram essas informações desde o momento da iniciação e agora
aparecem nominalmente indicados como entradas para o processo de coleta de requisitos. Essas
informações são localizadas junto a um repositório oficial de acesso do time do projeto – e quem

39
interessar possa – e permitem que os status e as listagens de premissas e restrições, de qualquer
nível, possam ser verificadas ou alteradas em qualquer momento.
Essa visualização não só facilitou o dia a dia do time do projeto como também evitou uma série
de discussões improfícuas a respeito de como fazer e onde fazer o registro dessas informações. Então,
como uma única referência, as informações sobre premissas e restrições podem ser acessadas pelo time
do projeto a qualquer momento, servindo de base para que isso facilite os trabalhos de coleta de
requisitos. Por fim, devem-se também avaliar os acordos, oriundos da área de conhecimento das
aquisições, os fatores ambientais da empresa e os ativos de processos organizacionais.
Observando-se as entradas determinadas para esse processo é chegado então o momento de
executar a elicitação dos requisitos, e muitas são as técnicas destinadas para tal. Por mais que o Guia
PMBOK® tenha sido generoso na lista de técnicas e ferramentas sugeridas, há uma dezena de boas
práticas ou subconjunto delas que poderiam estar elencadas nesse momento. Então, a melhor dica
possível para esse tipo de trabalho é não se prender a modelos, pois, às vezes, um ato de
informalidade pode render ao time do projeto a descoberta de uma funcionalidade importante.
Por exemplo, pode ser de grande valia alocar um quadro branco e uma caneta em uma copa e
permitir que os utilizadores desse ambiente deixem as suas ideias ou impressões a respeito do que
precisa ser executado por um determinado projeto em que eles são partes interessadas na solução.
Indivíduos estariam protegidos por um relativo grau de anonimato e sem juízo de valor em relação às
suas sugestões ou ideias, mas, independentemente de listar todas as técnicas possíveis não tratadas pelo
Guia PMBOK®, vamos descrever as ferramentas e técnicas que foram descritas para esse processo.
Há sugestão para utilização de opinião especializada, mas não perderemos tempo em explicá-
las, pois as recomendações são semelhantes às verificadas na unidade destinada ao processo anterior,
com uma clara indicação de que as especialidades sejam voltadas para análise de negócio, obtenção
e análise de requisitos, documentação de requisitos, requisitos de projetos em projetos similares,
técnicas de diagramas, técnicas de facilitação e gerenciamento de conflitos. Contudo, há também a
sugestão por utilização de coleta de dados por meio de brainstorming, entrevistas, grupos de
discussão, questionários, pesquisas e benchmarking.
Todas são consideradas abordagens metódicas. Na primeira, com a utilização de um
facilitador ou moderador, podem-se levantar ideias de maneira aleatória ou ordenada, em que um
conjunto de técnicas é aplicado junto a um grupo de indivíduos para que o pensamento criativo
possa ser estimulado e surja uma orientação final do que precisa ser feito ou uma direção a ser
tomada. Nada é descartado, pois não existe o conceito de errado ou absurdo. A mera citação de algo
absurdo pode levar a um insight em outro indivíduo e protagonizar a ideia de uma funcionalidade
para um determinado produto.
Na utilização de entrevistas, são formuladas perguntas relevantes e as respostas são
documentadas, para posteriormente serem analisadas pelo time do projeto. Podem ser estruturadas,
com um determinado grau de planejamento ou então desestruturadas, com as perguntas sendo
formuladas após o resultado das respostas anteriores.

40
 Grupos de discussão, normalmente, protagonizam sessões estruturadas com times
multidisciplinares com viés de identificar os requisitos necessários por meio de consenso entre os
participantes. É uma excelente técnica para auxiliar o gerenciamento de conflitos do time.
Questionários e pesquisas são utilizados para um grupo específico ou quando se necessita de
informação em larga escala para uma futura análise de dados, no intuito de determinar padrões ou
preparar futuras elicitações. O cuidado a ser tomado é que as muitas variadas maneiras de se
apresentar um questionário ou realizar uma pesquisa podem afetar direta e indiretamente os seus
resultados, por exemplo, realizar uma pergunta ao vivo para uma pessoa ou solicitar resposta por
meio de um e-mail ou uma ligação telefônica.
Já a técnica de benchmarking visa a comparar produtos, serviços ou resultados para a
verificação de status e a criação de uma base de referência.
Nenhuma dessas técnicas é excludente ou considerada sequencial de outra. Elas podem ser
utilizadas em separado, em conjunto ou, ainda, complementarmente. Quando se menciona, por
exemplo, a utilização de análise de dados por meio de análise de documentos, significa dizer que
uma substancial quantidade de informação pode ser coletada ou descoberta, basicamente,
revisitando ou analisando documentação pré-existente, mas, se for o caso, essa documentação
poderá ser gerada por outras técnicas e ferramentas, como as mencionadas no parágrafo anterior e,
então, na sequência, analisadas por meio de técnicas de análises de documentos.
Junto a essas técnicas, em determinados momentos o time do projeto precisará tomar decisões
que direcionarão o trabalho de gerenciamento dos requisitos. Para isso, há sugestão de utilização de
técnicas de votação – nas suas múltiplas maneiras – ou análises de decisão envolvendo critérios
múltiplos. Neste último, a definição dos critérios pode vir a ser subjetiva, e é importante que esses
critérios sejam bem selecionados, explicados aos participantes e corretamente ponderados.
Há também a opção por representação de dados por meio de diagramas de afinidades por
meio dos quais se pode perceber o acúmulo de determinados dados no intuito de avaliar tendências,
evidências ou erros de amostragens, assim como técnicas de mapeamento mental que evidenciam,
novamente um processo criativo, segmentado e interligado, com a proposta de destrinchar
problemas ou ideias no sentido de melhor compreendê-las, mas também para gerenciar o fluxo de
informações de um determinado sistema, produto, serviço ou resultado a ser buscado.

41
 Figura 11 – Exemplo de diagrama de contexto

Fonte: ResearchGate (2016).

Ainda há menção para técnicas de habilidades interpessoais de equipe, como grupo

nominal, observação ou conversação e facilitação. Grupo nominal consiste em uma técnica
estruturada que é considerada uma vertente do brainstorming, assim como o brainwriting, porém
muito utilizada quando não se deseja que a opinião de um participante influencie a dos demais.
O resultado deverá ser consensual.
A técnica de observação – conversação – consiste em permitir que um determinado tipo de
trabalho ou procedimento, por exemplo, seja observado, discutido, por um ou mais indivíduos que
tomarão notas, farão medições e registrarão o momento observado, discutido. Comumente
utilizada para verificar como um indivíduo utiliza um determinado produto ou serviço e quando
determinados stakeholders possuem dificuldade de expressão das necessidades em relação a um
determinado produto ou serviço.
As técnicas de facilitação são utilizadas para deixar procedimentos, reuniões ou discussões mais
eficientes, sem que haja perda de foco dos participantes, e as participações de todos sejam estimuladas.
Por fim, existem os diagramas de contexto e técnicas de prototipagem. A primeira vem a ser
uma ferramenta muito utilizada para modelar o escopo, tanto do projeto quanto do produto, por
meio de referências visuais, conforme se pode visualizar um exemplo na figura 11. Já a segunda, é
uma técnica utilizada para receber feedbacks e evitar desperdícios, pois serve para agilizar a definição
de funcionalidades, testar opções e reduzir futuros problemas com mudanças inadvertidas do escopo.

42
Processo “Coletar os Requisitos”: saídas
Em relação às saídas preconizadas para o processo “coletar os requisitos”, temos dois artefatos
interessantes e extremamente importantes, que podem ditar todo o sucesso do projeto: o primeiro é um
documento de documentação de requisitos; e o segundo, uma matriz de rastreabilidade de requisitos.
Requisitos podem ser detalhados inicialmente em um formato e, gradativamente, alcançar
níveis de detalhes mais complexos, por exemplo, a partir do momento em que novas informações
são recebidas pelo time do projeto ou novas funcionalidades são demandadas pelo cliente. Sendo
assim, é importante que todos os requisitos sejam documentados com a utilização das técnicas que
melhor convierem às necessidades da situação requerida pelo projeto e às restrições de tecnologia,
podendo variar de uma simples listagem, de preferência com os requisitos categorizados e
priorizados, até a utilização de sistemas de informações complexos ou sharepoints, contendo
descrições detalhadas e anexos.
O mais importante é que não haja espaço para interpretações equivocadas e, sempre que
possível, já descrever critérios de aceitação e de validação no intuito de conduzir, tanto os trabalhos
do time de escopo como os trabalhos do time da qualidade.

Quadro 8 – Template para documentação de requisitos

título do projeto data da versão

parte grau de critério de critério de

ID requisito categoria
interessada priorização aceitação validação

Fonte: adaptado de Snyder (2013).

Uma boa documentação de requisitos diz muito sobre o grau de atenção que o time do projeto
dedica a implantar a solução que está sendo gerada. Definir, às vezes, o básico, mas seguir e manter
atualizada essas informações com grau de atenção suficiente é determinante para que os demais
membros alocados nas demais áreas de conhecimento do projeto possam desempenhar os seus papéis e
responsabilidades com eficácia. Uma atualização de uma priorização de requisito não documentada
pode colocar todo um período de trabalho em xeque, com consequências em curto e em longo prazo.
O template sugerido é simples, porém de grande valia. Começa-se identificando o requisito
com um código que poderá ser numérico ou de qualquer outro tipo e logo na sequência entra a
descrição do requisito. Imagine que o projeto seja um grande concerto de música. Um dos
patrocinadores comerciais solicitou ao time do projeto um palco suficientemente alto para que a

43
 sua marca, quando apresentada na face frontal do palco, pudesse ser vista por toda a área do evento.
Um dos requisitos que poderia estar vinculado a esse desejo seria, por exemplo, altura do palco
mínima de 30 m de altura. O requisito técnico passa a corroborar então o requisito de negócio, ou
seja, a função do palco. Para preencher o campo inerente à parte interessada, basta descrever de
onde veio a solicitação ou ideia para a implantação de um determinado requisito. Se não houver
um nome específico para essa parte interessada, pode-se alocar, por exemplo, o nome de um setor,
de um cargo ou de uma pessoa jurídica, apenas para que a informação não permaneça incompleta
e, posteriormente, possa ser atualizada.
Na sequência, podem-se categorizar os requisitos como requisitos temporários, de solução,
de qualidade, etc., conforme estudado no item 2.3 deste mesmo material.
Em relação às prioridades, pode-se simplesmente elencá-las como alta-média-baixa ou utilizar
qualquer ferramenta de priorização de requisitos e adotar as suas terminologias. Apenas para citar
um dos exemplos trazidos na unidade anterior, se a técnica utilizada fosse a MoSCoW, bastaria a
utilização das iniciais M, S, C ou W, como códigos.
Encerrando a tabela, descreve-se o critério de aceitação, determinando como ficará
caracterizado o aceite – ou handover – daquele requisito e o critério de validação, onde será descrito
como ter certeza de que o requisito alcançou precisão correta.
No exemplo acima, como ter certeza de que o palco possui no mínimo 30 m de altura? O
desejo do patrocinador não era ter a sua marca visualizada em toda a área do evento? Então, como
validar que a marca, depois de pendurada, será de fato vista por toda a área do evento? Aqui, temos
técnicas de medições ou de inspeções que podem ser realizadas e até mesmo adoção de técnica de
observação. Pendura-se algo do tamanho do logotipo da marca e percorre-se toda a área do evento
para avaliar se o material consegue ser visualizado.
Atenção, a ideia aqui não é gerar juízo de valor se um determinado critério é bom ou ruim.
Essa análise será realizada pelo time do projeto, com auxílio do gerente do projeto, em um momento
futuro. O importante é que existam critérios de aceitação e de validação, ao menos, para as
principais etapas ou entregas do projeto. Lembrando sempre que um requisito sem critério de
validação pode vir a transformar-se em um belo problema. Determinar ao menos um critério de
validação é uma maneira de o time do projeto se resguardar objetivamente, e não subjetivamente.

Quadro 9 – Template para a matriz de rastreabilidade de requisitos

título do projeto data da versão

parte entrega critério de

ID requisito prioridade categoria objetivo métrica
interessada da EAP validação

Fonte: adaptado de Snyder (2013).

44
 Assim como uma boa documentação dos requisitos é importante, uma correta rastreabilidade
dos vários atributos dos requisitos ao longo de todo o ciclo de vida do projeto também é um fator
crítico de sucesso do projeto. Trata-se de um documento muito utilizado no momento de avaliar a
aceitação de entregas parciais e definitivas de produtos, serviços ou resultados, assim como muito
útil no momento de solicitação de mudanças.
As informações inseridas no registro original dos requisitos (quadro 8) servirão como base de
informação para esse novo artefato. O template que se encontra demonstrado no quadro 9 é apenas um
exemplo dos muitos estilos que uma matriz de rastreabilidade de requisito pode ter. O template sugerido
encontra-se baseado quanto aos objetivos do projeto, entregas da EAP, métricas e critérios de validação,
mas é possível, por exemplo, gerar uma matriz com base em requisitos funcionais e não funcionais, entre
requisitos técnicos e de segurança ou até mesmo entre requisitos técnicos e de negócio.
É possível, em alguns casos, ver esses exemplos citados em materiais especializados com o
nome de Matriz de Rastreabilidade Inter-requisitos. Uma vez mais, como o template demonstrado
trata-se de uma sugestão, poderá ser customizado às necessidades de cada projeto, de acordo com o
que o time do projeto julgar cabível de ser rastreado.
Em relação às cinco colunas iniciais, o tratamento é o mesmo destinado ao template de
documentação de requisitos; exatamente por isso, a base inicial de informações dessa matriz utiliza
a documentação pré-confeccionada, mas a partir da sexta coluna, com o item “objetivo”, muda-se
um pouco a maneira de tratar a informação, pois aqui se começa a descrever que tipo de objetivo
será cumprido ou está relacionado ao correspondente requisito.
Um exemplo de objetivo seria “visibilidade plena da marca do patrocinador master”, que
poderia estar vinculado a um requisito de tamanho de palco com características de 30 m de altura.
A coluna seguinte determina em que lugar da EAP esse requisito está vinculado. Na sequência, para
garantir a correta entrega desse requisito, demonstra-se então como será realizada a medição para
atender às suas condições ou características.
Por fim, qual será a técnica destinada para validar o fato de o requisito atender às condições
ou características elencadas? Utilizando ainda o exemplo do palco do evento, pode-se simplesmente
dizer, por exemplo, trena digital – para a medição da altura em metros – e técnica de inspeção.

Retrospectiva do módulo
O Módulo II iniciou a sua trajetória demonstrando os dois primeiros processos da área de
conhecimento escopo, ambos vinculados ao grupo de processo do planejamento. Foram exploradas as
suas entradas, técnicas e ferramentas para a transformação do processo, e as suas respectivas saídas. Os
entregáveis produzidos nas saídas dos dois primeiros processos foram tratados e demonstrados por meio
de templates sugeridos, entremeando a explicação com algumas sugestões de técnicas de priorização de
requisitos, por exemplo, a ferramenta da matriz importância X urgência e a técnica MoSCoW.

45
 Demonstramos a importância de um PGE e de um plano de gerenciamento dos requisitos,
as suas implicâncias, os cuidados a serem tomados e as possíveis formas de confeccionar esses
artefatos. Essas formas, sempre que a necessidade demandar, poderão ser customizadas no intuito
de melhor atender às características de um determinado projeto.
Na sequência, foram citados os fatores críticos de sucesso para tratar o assunto requisito em
um ambiente de projeto, quando vinculado a uma organização, a saber: engajamento
organizacional, reconhecimento do valor de um plano de gerenciamento dos requisitos,
engajamento das partes interessadas e integração com as atividades do gerenciamento do projeto.
O termo “elicitação” também ganhou uma atenção especial. Não que a palavra não existisse
ou não fosse utilizada anteriormente, mas ganhou uma nova proporção com o advento do novo
Guia PMBOK®, pois significa o ato de obter as informações das principais partes interessadas. Uma
função de extrema importância para o trabalho com requisitos.
Também se pode demonstrar a importância de trabalhar em conjunto com a observância de
publicações recentes do PMI, não somente com a utilização do Guia PMBOK®, como é comum
observar em muitas organizações que acreditam que estão trabalhando o gerenciamento profissional
de projetos da maneira correta. É necessário que haja uma correta integração dos preceitos
transmitidos pelo Guia PMBOK®, pelo Requirements Management: a practice guide, pelo The PMI
Guide to Business Analysis e pelo Agile Practice Guide, minimamente.
Os diferentes tipos de requisitos também foram explorados e permitiu-se visualizar melhor
como classificar um requisito como funcional ou não funcional, de negócio, de partes interessadas,
de solução, de transição, de qualidade, do projeto ou do programa.

46
MÓDULO III – PLANEJAMENTO DO
ESCOPO: PARTE II

Nesta unidade, serão evidenciados os dois últimos processos dos grupos de processos do
planejamento, vinculados ao gerenciamento do escopo em projetos: o processo “definir o escopo”
e o processo “criar a EAP”. Os processos serão meticulosamente descritos, com orientação pautada
pelas boas práticas preconizadas pelo Guia PMBOK® (PMI, 2017a), contendo todas as informações
necessárias para o correto entendimento das suas entradas, ferramentas e técnicas, e saídas. Além
disso, serão evidenciados os detalhes de um bom planejamento do escopo do projeto, notadamente,
por descrever a importância de uma Declaração do Escopo e de uma EAP, contemplando a correta
maneira de confeccionar e utilizar ambos os artefatos, bem como o de todos os componentes
acessórios às suas aplicações em uma situação de gerenciamento de projetos.

Processo “Definir o Escopo”: peculiaridades, entradas,

técnicas e ferramentas
Tão necessária a um projeto como um TAP, a Declaração do Escopo (DE) é elaborada no
processo “definir o escopo” e, por meio de uma descrição detalhada, serve para auxiliar, definir,
desenvolver e restringir o escopo do projeto e do produto. Considerado como um dos artefatos mais
importantes do PGP, em face de trazer informações cruciais acerca do entendimento comum do
escopo do projeto, bem como das partes interessadas, utilizará para a sua confecção informações
trazidas no TAP, no PGE e na documentação dos requisitos.
Segundo o PMI (2017a) “o principal benefício desse processo é que ele descreve os limites
do produto, serviço ou resultado e os critérios para aceitação”. O fluxo de entradas, ferramentas e
técnicas, e saídas poderá ser evidenciado por meio da figura a seguir.

47
 Figura 12 – Processo 5.3: definir o escopo

Fonte: PMI (2017a).

O TAP continua cumprindo a sua função preliminar de repositório de informações nesse

momento de definições do projeto. Notadamente, é por isso que ele vem a ser o primeiro artefato
vinculado como entrada para o processo de “definir o escopo”. O PGP está presente com o
fornecimento de diretrizes para a confecção da DE, constantes do PGE. Alguns documentos do
projeto, uns elaborados desde o momento da iniciação e outros oriundos do planejamento, também
se fazem úteis, como o registro de premissas, o registro de restrições e a documentação dos requisitos.
Não há como definir detalhes importantes do escopo sem avaliar corretamente o que existe
de premissas e restrições até o presente momento. Imagine o seguinte projeto: reforma de um hotel,
localizado em uma ilha. Uma das restrições definidas pelo patrocinador do projeto desde os
momentos iniciais poderia ser que todo e qualquer material relativo à obra deverá ser transportado
exclusivamente por barcos, ou seja, via marítima. Sendo assim, no momento de definir como a
estratégia do escopo do projeto será implementada, não adianta vincular materiais helitransportados
para ganhar tempo ou facilitar algum tipo de operação; afinal de contas, restrição é restrição.
A documentação dos requisitos precisa estar presente porque trata dos primeiros esforços de
coleta, análise e priorização dos requisitos e influenciará diretamente nos trabalhos de definição do
escopo do produto, pois foram definidos, progressivamente, escutando as principais partes
interessadas do projeto. É muito provável que nem todos os requisitos do projeto e do produto
tenham sido plenamente registrados até o presente momento, principalmente se o trabalho será
realizado por meio de ciclos iterativos, em que a coleta de requisitos vem a ser constante, em
intervalos regulares, durante todo o ciclo de vida do projeto.
Por isso, a declaração do escopo sofrerá influencia constante desse processo de coleta de requisitos,
sujeita a alterações ao longo da execução do projeto. O importante é que a descrição seja, sempre que
possível, para o momento vivido pelo time do projeto, a mais fiel em relação às descrições do produto,
serviço ou resultado a ser gerado. Isso ocorre porque o escopo do projeto é continuamente descrito com
mais detalhes conforme novas informações a respeito do projeto são trazidas a bordo.

48
 Por fim, obviamente, o time do projeto não pode esquecer-se de levar em consideração os
fatores ambientais da empresa – cultura organizacional, estrutura da empresa, níveis de tecnologia,
administração de pessoal, condições de mercado, etc. – e os ativos de processos organizacionais,
representados por políticas, procedimentos e templates pré-validados para a confecção de uma DE,
documentação arquivada de projetos anteriores ou de projetos similares de outras organizações e
lições aprendidas, entre outros.
Como ferramentas e técnicas, o processo ainda sugere as mesmas técnicas de opinião
especializada que são conhecidas desde os primórdios do trabalho do planejamento do escopo. A
diferença é que, para esse processo específico, a técnica visa ser empregada em relação a um grau de
experiência de indivíduos ou grupos que tenham trabalhado ou possuam referências de projetos do
mesmo porte ou tipo.
No que tange à questão da análise de dados, sugere-se uma que pode ser útil ao cumprimento
dos requisitos e objetivos constantes desde o TAP: trabalhar análises de alternativas para a condução
do escopo do projeto, avaliando cenários, por exemplo, fazer, comprar ou alugar. Em relação à
técnica de tomada de decisão, com análise de decisão envolvendo critérios múltiplos, é sugerida a
utilização de uma matriz decisória que propicie uma avaliação analítica e sistemática, visando a
estabelecer critérios para os requisitos e o trabalho de refinamento do escopo produto e do projeto.
A técnica de facilitação também volta a ser demonstrada, pois poderá ser amplamente
utilizada em momentos do cotidiano do trabalho do time do projeto, visando a alcançar um grau
de entendimento único e multifuncional a respeito das entregas do projeto, os marcos e limites.
Por fim, técnicas de análise de produto, que são muito conhecidas para o setor de indústria,
mas que poderão ser facilmente adaptadas para o contexto de qualquer projeto. Os exemplos
sugeridos pelo Guia PMBOK® são os que utilizam técnicas de decomposição, por exemplo, estrutura
analítica do produto ou ouras como análise de requisitos, análise ou engenharia de sistemas e análise
ou engenharia de valor.

Processo “Definir o Escopo”: saídas

Como saídas, o processo “definir o escopo” preconiza que seja realizada a especificação do
escopo do projeto, e o instrumento proposto para tal é justamente a DE. Será esse artefato que vai
trazer a descrição do escopo do projeto, as suas principais entregas, já visando ao processo de
confecção de uma futura EAP; premissas e restrições, do escopo, e não de todo o projeto, pois estas
ficam alocadas nos registros de premissas e no registro de restrições. Além disso, é de bom tom que
contenha as exclusões ao escopo – o não escopo do projeto –, que possuem a função de resguardar
o time do projeto no gerenciamento de algumas das principais partes interessadas.
Existem termos que são comuns a determinados segmentos ou profissões e que podem ser
interpretados de diferentes maneiras. Em um recente caso real de um projeto, presenciei uma

49
empresa indo avaliar a entrega da construção de um galpão, e os seus funcionários foram dotados
de uma lista de verificação – checklist – para avaliarem a finalização da obra.
Em um determinado momento, um dos representantes da empresa perguntou onde estava o
lançamento do sistema hidráulico do galpão, assim como outros detalhes, como o sistema de água
e esgoto. O executor da obra correu às especificações que tinha em mão e apontou o termo:
infraestrutura básica.
Sim, eles eram responsáveis por entregar a obra do galpão com a infraestrutura básica pronta.
Na sua maneira de ver o mundo, infraestrutura básica era piso, pilares, cobertura, canteiro de obra,
etc., mas nunca sistemas hidráulicos e afins.
O curioso é que depois de presenciar essa situação, eu, comumente, pergunto a engenheiros
civis o que se pode considerar como infraestrutura básica de uma obra, e a resposta é sempre variada.
Ou seja, o time do projeto não atentou para diferentes interpretações de um mesmo requisito. Para
isso, a saída é sempre determinar as exclusões ao escopo, que aqui poderiam estar explicitamente
descritos os sistemas hidráulicos e o que mais não julgassem característica do termo “infraestrutura
básica” de uma obra.
O problema é que muitos bons profissionais confundem no dia a dia do projeto os termos
“exclusão do escopo” e “restrição de escopo”. São coisas completamente distintas. Quando alguém
disser que está proibido para o seu time de obra trabalhar após um determinado horário, por
qualquer que seja o motivo, isso deverá ser tratado como restrição e não exclusão. Tudo aquilo que
lhe é imposto por terceiros, deve ser verificado como restrição.
Trabalhar corretamente as exclusões do escopo permitirá ao time do projeto estar atento para
melhor avaliar solicitações de mudança ou trabalhos adicionais, pois será possível verificar se os itens
frutos dessa análise estarão contidos na linha de base de escopo ou se serão considerados externos
aos limites do projeto.
Aqui, cabe um aparte a respeito de comparação entre dois dos importantes documentos de
que já tratamos ao longo dos nossos estudos: o TAP e a DE. Por muitas vezes, são confeccionados
ou considerados como redundantes, mas é importante salientar que o Guia PMBOK® sugere que
esses documentos possuam graus diferentes no que tange ao nível de detalhes. Uma comparação
mais minuciosa poderá ser realizada pela figura a seguir.

50
 Figura 13 – Elementos sugeridos para o TAP e para a DE

Fonte: PMI (2017a).

A versão mais simples e eficaz de uma declaração do escopo passa a ser, então, conforme o
próprio PMI (2017a) assim a define, de acordo com o template proposto na figura 13.
Na descrição do escopo do projeto, além do trabalho presumido para efetivar as ações de entrega
do produto, serviço ou resultado a ser gerado pelo projeto, é natural que ocorra também uma descrição
do escopo do produto, pois detalhes das características do produto acabarão sendo, progressivamente,
descritas. Isso ocorre em função da utilização da documentação de requisitos na elaboração da DE.

51
 Em relação às entregas, o Guia PMBOK® diz que se definem como “qualquer produto,
resultado ou capacidade de realizar um serviço, que seja único, verificável e necessário para concluir
um processo, fase ou projeto”. Fica a cargo do time do projeto ou da situação em que o projeto
ocorre definir se essas entregas serão descritas de maneira detalhada ou sucinta. Já os critérios de
aceitação são a maneira como a área de escopo conseguirá avaliar se as entregas possuem condições
para serem recebidas, aceitas. Além disso, como já bem dimensionado nos parágrafos anteriores,
significa definir o não escopo, ou seja, aquilo que não faz parte do projeto.

Quadro 10 – Template de declaração do escopo

declaração de escopo
título do projeto: _______________________________ data: ___/___/___

descrição do escopo do projeto

definição das entregas ou etapas do projeto

critérios de aceitação (do projeto e das suas principais entregas)

exclusões do projeto

obs.: pode conter também, em separado, critérios de validação do projeto ou das

principais etapas ou entregas do projeto.

Alguns detalhes devem ser observados no momento de confeccionar uma declaração do

escopo do projeto:
 Utilização de escuta ativa – cuidado ao ouvir aquilo que o cliente do projeto ou o usuário
final quer. Tente entender não somente aquilo que ele lhe pede para ser feito, mas,
sobretudo, aquilo que precisa ser realizado para solucionar o problema ou a necessidade
que originou o projeto.
 Definição do não escopo – nem sempre um escopo do projeto ou do produto consegue
ser perfeitamente caracterizado nos momentos iniciais dos trabalhos de um projeto. Uma
saída para isso é focar o que não precisa ser feito e o que o cliente ou o usuário final não
deseja sob hipótese alguma. Saber o que não deve ser feito já é um belo auxílio para o time
do projeto poder orientar os trabalhos iniciais de execução. De preferência, estabeleça o
que não será feito, de maneira documentada ou então nos momentos em que o cliente ou
o usuário final estiver disponível.
 Adoção de transparência nos processos – de tempos em tempos, assegure-se de que todas
as principais partes interessadas do projeto compreendam aquilo que está sendo gerado

52
 pelo time do projeto. Consenso não é necessário, mas é importante ao menos na questão
dos objetivos finais, para que o time do projeto esteja alinhado com o propósito do projeto.
 Pés no chão – acima de tudo, ser realista. Quanto mais “pé no chão” forem as estimativas
que envolvem o trabalho do escopo e as definições das funcionalidades que o compõem,
maior será a chance de sucesso do projeto. Não há necessidade de se prometer aquilo que
não se poderá cumprir.
 Cuidado com o gold platting – a prática de “folhear a ouro” (em tradução livre do termo
original em inglês), por incrível que pareça, ainda é verificada em determinados setores.
Tentam entregar proposta de valor sem que o cliente ou o usuário final perceba esse valor
no momento da entrega. Sempre que ocorrer uma ideia ou proposta de mudança do
escopo, se essa proposta não vier de quem está demandando o projeto ou então de quem
vai utilizar o produto, serviço ou resultado que será gerado pelo projeto, torna-se
necessário que o assunto seja propriamente discutido, as implicações da mudança
explicadas claramente e registradas na documentação do projeto. Isso fará com que as
linhas de base possuam novas versões atualizadas e que suportem as mudanças efetivadas.
Funcionalidades novas podem ser perfeitamente bem-vindas, mas no intuito de evitar o
gold platting, devem ser discutidas em momentos apropriados, avaliadas em função dos
seus impactos nas demais áreas de conhecimento do projeto e, por fim, documentadas
com a ciência do patrocinador, cliente, usuário final e outras partes interessadas
importantes para a decisão da mudança.

Processo “Criar a EAP”: peculiaridades

A EAP é o artefato referencial que define o trabalho que será necessário para que se possam
cumprir os objetivos do projeto, assim como a base que provê as principais informações para gerenciar
o trabalho do projeto, do início até a sua conclusão, servindo como fonte primária de métricas em
relação ao escopo e como instrumento de comunicação entre as principais partes interessadas.
As estimativas de trabalho do escopo de um projeto são mais bem percebidas quando
gerenciadas de uma maneira visual e decomposta, demonstrando uma estrutura única de elementos
encadeados, que posteriormente se comunicarão com as demais áreas de conhecimento, tais como
cronograma, qualidade, custos, aquisições, etc.
Portanto, a EAP consiste em uma estrutura hierárquica, não necessariamente cronológica –
essa cronologia será visualizada no cronograma do projeto e não na EAP –, decomposta e com a
intenção de guiar o time do projeto à execução do trabalho necessário para que os objetivos
estipulados possam ser cumpridos fielmente.
Ela não só servirá de linha de base para o trabalho do time do projeto em relação ao escopo,
pois representará as informações disponibilizadas por meio da DE, como também auxiliará em um

53
melhor trabalho de estimar esforços do planejamento do projeto, quando as informações
começarem a ser integradas com as demais áreas de conhecimento, por exemplo, informações a
respeito dos custos.
É muito mais fácil estimar os custos de reforma de um cômodo de uma casa do que de uma
casa inteira. Todo o planejamento do projeto passa a ser orientado por uma EAP, mesmo que
seja apenas a primeira versão desta que tenha sido elaborada. Exatamente por isso, mudanças na
linha de base de escopo tendem a infligir impactos nos trabalhos de muitas outras áreas de
conhecimento de um projeto.
O trabalho de “criar a EAP”, conforme preconiza o Guia PMBOK® (PMI, 2017a, p. 192
193) “é o trabalho de decompor as entregas e o trabalho do projeto em componentes menores e
mais facilmente gerenciáveis [...] o trabalho planejado é contido dentro do nível mais baixo de
componentes da EAP, que são denominados pacotes de trabalho”. A EAP deverá incluir todo o
trabalho a ser realizado no projeto, independentemente de o trabalho ser realizado pelo time do
projeto, pelas partes interessadas ou por participantes internos ou externos, por exemplo, membros
de outros setores da organização ou subcontratados.
Na figura 14, é possível visualizar um modelo simples de como é realizada a decomposição
hierárquica de uma EAP. A estrutura é decomposta em níveis, cada vez menores, e os últimos níveis
serão conhecidos como pacotes de trabalho. Um pacote de trabalho poderá ser agendado, estimado –
nível de esforço, custos, entre outras possibilidades –, monitorado e controlado.
Para o time de escopo do projeto, o trabalho acaba na descrição dos pacotes de trabalho, mas
na verdade ainda existem informações que precisarão ser complementadas pelo time de cronograma
do projeto. Quando se alcança um último nível em uma EAP, o time de cronograma do projeto
precisará estimar as atividades, ou tarefas, inerentes à realização desse pacote de trabalho, com novas
estimativas de esforço e cronologia própria, sempre alinhadas ao trabalho inicial de decomposição
das entregas, preconizado pelo planejamento da linha de base do escopo do projeto.
O número de níveis exigidos por uma EAP dependerá do tamanho e do grau de
complexidade do projeto e do nível de detalhamento necessário para o seu efetivo planejamento
e gerenciamento. Em suma, o número específico de níveis deve ser apropriado para gerenciar
efetivamente o projeto em questão.

54
 Figura 14 – Pacotes de trabalho

Dificilmente, uma EAP não passará por um trabalho de revisão ao longo do projeto, não só
pelas muitas variáveis que assolam um projeto ao longo da sua realização, mas também porque nem
sempre todas as informações estarão disponíveis ou serão totalmente conhecidas do time do projeto
no momento da sua confecção original. Portanto, de tempos em tempos, rever a estrutura da EAP
e avaliar o que pode ser alterado em prol de um melhor trabalho da equipe do projeto é uma ação
que deve ser realizada periodicamente pelos responsáveis pela elaboração dessa linha de base.
As EAPs também podem ser confeccionadas de muitas maneiras, que, no final, acabarão
representando a mesma coisa, mas em formatos diferentes. O PMI (2006) cita a possibilidade de
utilização de formatos gráficos, textuais ou tabulares.
Exemplo de formato gráfico, que é um dos mais conhecidos no mercado, seria o modelo
piramidal ou em blocos, representado por figuras em formato de “quadrados” que, sempre que
necessário, decompõem-se e formam os níveis subsequentes, proporcionando uma base sempre
maior que o topo, por isso a analogia com o formato de uma “pirâmide” (figura 15).

55
 Figura 15 – Exemplo de EAP gráfica piramidal

Fonte: adaptado de Xavier (2009).

Um modelo de mapa mental também se demonstra uma excelente maneira de desenvolver

uma EAP gráfica, conforme demonstrado na figura 16. Além de ser uma ferramenta de fácil
utilização, pode vir a ser uma proposta de trabalho colaborativo junto ao time do projeto, desde o
início dos primeiros movimentos do planejamento do escopo. O importante é que, assim como o
formato gráfico piramidal, seja possível a visualização decomposta e hierárquica de todas as entregas
que visam à realização do trabalho para alcançar os objetivos do projeto.

Figura 16 – Exemplo de EAP gráfica em mapa mental

Fonte: Ribeiro (s/d).

56
 Em relação ao formato textual, poderíamos utilizar o modelo da figura 16 para representar a
EAP da seguinte forma (quadro 11):

Quadro 11 – Exemplo de EAP textual

1. projeto novas fronteiras

1.1. diagnóstico
1.2. software
1.2.1. sistema operacional
1.2.2. banco de dados
1.2.3. gerenciamento de projetos
1.2.4. gerenciamento eletrônico de documentos (GED)
1.2.5. teste integrado
1.3. hardware
1.3.1. servidor
1.3.2. clientes/usuários
1.4. treinamento
1.4.1. palestra
1.4.2. treinamento GP
1.4.3. treinamento software
1.5. padronização
1.5.1. templates (modelos)
1.5.2. GED
1.5.3. relatórios
1.5.4. modos de exibição
1.6. piloto
1.6.1. definição projeto-piloto
1.6.2. planejamento projeto-piloto
1.6.3. execução e avaliação projeto-piloto
1.6.4. ações corretivas
1.7. resultados

Por fim, o mesmo exemplo, se confeccionado em um formato tabular, estaria representado

como demonstra o quadro a seguir.

57
 Quadro 12 – Exemplo de EAP tabular (ou tabelada)

nível 1 nível 2 nível 3

1. projeto novas fronteiras

1.1. diagnóstico

1.2. software

1.2.1. sistema operacional

1.2.2. banco de dados

1.2.3. gerenciamento de projetos

1.2.4. gerenciamento eletrônico

de documentos (GED)

1.2.5. teste integrado

1.3. hardware

1.3.1. servidor

1.3.2. clientes/usuários

1.4. treinamento

1.4.1. palestra

1.4.2. treinamento GP

1.4.3. treinamento software

1.5. padronização

1.5.1. templates (modelos)

1.5.2. GED

1.5.3. relatórios

1.5.4. modos de exibição

1.6. piloto

1.6.1. definição projeto-piloto

1.6.2. planejamento projeto-piloto

1.6.3. execução e avaliação

projeto-piloto

1.6.4. ações corretivas

1.7. resultados

58
 Alguns detalhes importantes devem ser levados em consideração no momento de desenvolver
uma boa EAP, a saber:
 Regra dos 100% – esta regra representa a característica mais importante de todas, em uma
EAP. Em primeiro lugar, ela preconiza que uma EAP, por ser uma linha de base de entregas
do projeto, deve conter 100% do trabalho necessário, definido pelo escopo do projeto,
incluindo o trabalho do gerenciamento do projeto, pois envolve hora de trabalho da equipe
do projeto. Nada a mais, nem a menos. Isso significa dizer que uma EAP não pode exceder
em nada o que precisa ser feito e também não deve faltar nada do que precisa ser feito. A
regra deve ser aplicada em todos os níveis da hierarquia de uma EAP, incluindo os níveis das
atividades ou tarefas. Em segundo lugar, a mesma regra preconiza que sempre que um item
da EAP é decomposto, a soma dos seus subitens decompostos (nível “filho”), deve ser
exatamente a soma dos trabalhos do nível da entrega decomposta (nível “pai”), não devendo
incluir mais ou menos do que 100% do trabalho proposto (HAUGAN apud PMI, 2006).
 Ciclo de vida do projeto representado no segundo nível – todo projeto é único e possui
um conjunto de características únicas. Já se pôde perceber que nem todo item de uma
EAP representado em um nível 2 será passível de decomposição. Por mais que seja uma
tentação decompor toda a mesma estrutura em níveis iguais, é possível avaliar que a
decomposição deverá ser definida pelo contexto do projeto que a EAP precisará suportar
como linha de base do escopo. No entanto, uma coisa muito importante é conseguir
visualizar o ciclo de vida do projeto presente no passo a passo das entregas, ou fases, do
nível 2, quando lido da esquerda para a direita. Não há necessidade de ordem cronológica,
mas, sim, que o entendimento das entregas demonstradas faça parte de um encadeamento
natural de um projeto específico, e não de uma estrutura ou sequência, padronizada, que
possa servir para qualquer tipo de projeto. Na figura 15, por exemplo, lendo o nível 2, da
esquerda para a direita é possível entender que se trata de um projeto de melhoria de
processos, independentemente de ler o título disposto no nível 1, porque essas entregas
serão específicas para esse tipo de projeto.
 Técnica de decomposição – para uma correta utilização de uma técnica de decomposição
é necessário que, quando um item – de uma EAP, por exemplo – é “quebrado”, ou seja,
decomposto, o novo nível deve possuir, minimamente, dois subitens. Gerar dois ou mais
subitens é garantir que a técnica de decomposição estará preservada. Não existe
decomposição em um único elemento.

59
 Figura 17 – Três coisas essenciais em uma EAP

Além disso, como a área de conhecimento do escopo possui os seus trabalhos extremamente
ligados com a área de conhecimento da qualidade, existem ainda dois princípios de qualidade que
uma EAP precisa conter. Isso ocorre porque, ao planejar e desenvolver o que precisa ser feito para
alcançar os objetivos do projeto, e depois garantir os critérios de aceitação, quando necessários, a
área do escopo exerce o seu trabalho. Porém, a área da qualidade será responsável pelos critérios de
validação, ou seja, dizer que as entregas foram validadas ou ainda, os requisitos descritos no
momento do processo 5.2 – coletar os requisitos – alcançaram a precisão desejada das suas métricas.
Somente depois de a área da qualidade definir que uma entrega foi validada é que a área de escopo
poderá definitivamente promover a entrega total ou parcial de um produto, serviço ou resultado.
O primeiro princípio da qualidade de uma EAP diz que “uma EAP de qualidade é uma
EAP construída de tal forma que satisfaça todos os requisitos para seu uso em um projeto”
(PMI, 2006, p. 19, tradução e grifo do autor). Para que um projeto atenda às necessidades do seu
cliente ou de um usuário final, assim como às expectativas dos seus principais stakeholders, é
importante que um bom trabalho de elicitação de requisitos tenha sido realizado no intuito de
refletir em uma EAP a importância desses requisitos. Quando o trabalho descrito na EAP for de
fato implantado, devem existir condições de mensurar, avaliar, testar e controlar uma entrega, para
refletir se os requisitos inerentes a essa entrega foram, ou serão, devidamente atendidos, da maneira
como foram elicitados.
Já o segundo princípio da qualidade de uma EAP diz que “as características de qualidade de
uma EAP aplicam-se a todos os níveis de definição do escopo” (PMI, 2006, p. 22, tradução e
grifo do autor). Significa dizer que não há qualquer tipo de diferença conceitual, por exemplo, entre
a EAP de um projeto ou a EAP de um portfólio. Uma EAP de qualidade será elaborada, dentro dos
mesmos preceitos e técnicas, para garantir que as mesmas características e atributos necessários à
idealização do trabalho do projeto – ou, no caso da comparação, do portfólio – sejam implantados.

Processo “Criar a EAP”: entradas, técnicas e ferramentas, saídas

Conforme a figura 18 sugere, as entradas sugeridas para a confecção de uma boa EAP são
inicialmente baseadas no trabalho prévio do planejamento do escopo. Praticamente, todas as saídas
determinadas pelos processos anteriores – 5.1, 5.2 e 5.3 – são utilizados para confecção da EAP,

60
com exceção da matriz de rastreabilidade de requisitos, por ser um artefato muito próprio para o
momento da execução dos trabalhos.
Percebe-se a menção do PGP, aqui representado pelo PGE. Sim, afinal de contas, todas
as informações necessárias ao tipo de EAP, como ela será organizada ou até mesmo o software
que será utilizado para a confecção da sua estrutura precisam estar previamente determinados
por meio desse documento.
Na sequência, podemos perceber a importância do processo de documentação de requisitos
como referência para se determinar como esses requisitos serão implantados ao longo do projeto,
assim como a referência da DE, descrita como “especificação do escopo do projeto”, para que nada
seja desenvolvido sem estar devidamente alinhado com o que foi proposto dentro da especificação
do que precisa ser realizado, ou seja, entregue pela equipe do projeto.
Em relação aos fatores ambientais, levar em consideração determinados padrões que possam
ser específicos de uma ou mais áreas da organização e que possam servir como referência para a
confecção da EAP.
Por fim, o PMI (2017a) cita que os ativos de processos organizacionais que devem ser levados
em conta no momento da confecção de uma EAP são arquivos de projetos semelhantes anteriores,
lições aprendidas – não necessariamente de projetos da mesma organização – e políticas,
procedimentos ou modelos de uma EAP.

Figura 18 – Processo 5.4: criar a EAP

Fonte: PMI (2017a).

Como ferramentas e técnicas, preconiza-se que a experiência de profissionais da organização
ou então de grupos de profissionais deve ser levada em consideração no momento da confecção de
uma EAP, assim como a observância das corretas técnicas de decomposição.
O PMI (2017a) descreve que uma EAP poderá ser confeccionada por meio de diferentes
abordagens. As mais utilizadas seriam a abordagem descendente – top-down – em que o processo de
decomposição depende da “quebra” de um item – pai – para verificar como os seus respectivos
componentes – filhos – serão tratados. Há também a abordagem ascendente – bottom-up – que é

61
comumente utilizada quando o processo é realizado com o raciocínio invertido, agrupando-se
subcomponentes. O elemento “pai” precisará corresponder às exatas junções de todos os subelementos
“filhos”. Não é difícil verificar, por exemplo, uma EAP que seja confeccionada por meio de uma
abordagem top-down e revisada por meio de uma abordagem bottom-up, ou o contrário.
Ainda conforme a figura 18, as saídas sugeridas após a confecção de uma EAP são
relativamente simples, pois o resultado de se “criar uma EAP” é a possibilidade de atualizações na
documentação do projeto, aqui citadas explicitamente por meio do registro de premissas e da
documentação de requisitos, mais a geração de uma linha de base do escopo do projeto.
Em relação às atualizações, no primeiro caso, far-se-ão necessárias caso sejam identificados
novos elementos ao longo do processo de criação da EAP. No segundo, pode ser que existam
mudanças, devidamente avaliadas e aprovadas, ao longo do processo de criação da EAP. Essas
mudanças podem acarretar atualizações na documentação dos requisitos. Essa linha de base estará
representada pela própria EAP em si, contendo os pacotes de planejamento e os pacotes de trabalho
necessários para a condução dos esforços no sentido de implantar o escopo, a Declaração do Escopo
do projeto e o dicionário da EAP. Sobre o dicionário da EAP, podemos afirmar que:

O dicionário da EAP é um documento que fornece informações detalhadas

sobre entregas, atividades e agendamento de cada componente da EAP. O
dicionário da EAP é um documento que dá suporte à mesma. A maioria das
informações incluídas no dicionário da EAP é criada por outros processos e
adicionadas a este documento em um estágio posterior (PMI, 2017a, p. 198).

62
 Quadro 13 – Exemplo de um trecho de um dicionário da EAP preenchido
código item da EAP descrição
 Treinamento presencial
para toda a equipe do
projeto sobre plano de
emergência contra
incêndios a fim de
cumprir norma interna
nº 023/2014.
 O instrutor será o GP.
Não há necessidade de
roupas específicas,
apenas traje de dia a dia
da jornada normal de
trabalho.
 Realizado na sede da
empresa, sala 808, das 8h
treinamento às 18h, com intervalo de
1.2.1.4.3
da equipe uma hora para almoço,
na primeira segunda-feira 
do mês de outubro do
corrente ano.
 Será realizado um coffee
break (1.2.1.4.5) na parte
da manhã e um na parte
da tarde. Cada um com
duração de 15 minutos.
Horário a critério do
instrutor.
 Material didático
(1.2.1.4.4.) será fornecido
no dia da aula.
 Haverá entrega de
certificados (1.2.1.4.9.).
nível de
critério de validação
esforço
 Cobrir todos os
procedimentos da
metodologia proposta
pela norma interna
nº 023/2014.
 A turma deverá ter
presença mínima de
80% da equipe do
projeto.
 A participação no
treinamento deverá ser
confirmada pelo ramal
4548, com até 72 horas
da data prevista para a
9 horas
sua realização.
A avaliação do
treinamento (1.2.1.4.6)
não poderá ter média
inferior a 8,0, sob pena
de repetição.
 O controle de
frequência será
obrigatório (1.2.1.4.8. e
1.2.1.4.9).
 A avaliação dos alunos
(1.2.1.7) não pode ser
inferior a 7,0, sob pena
de reprovação.
63
 O dicionário da EAP vem a ser um documento complementar à EAP, que, pela sua essência,
precisa ser clara e concisa, abordando uma macrovisão das entregas do projeto no intuito de auxiliar
o trabalho do time de gerenciamento do escopo do projeto. Esse documento deverá descrever todos
os detalhes inerentes a cada item da EAP. Para cada item da EAP, haverá uma potencial descrição
para uma declaração de trabalho resumida ou ainda, uma definição do escopo daquele componente.
Além disso, quando for o caso e de acordo com o grau de complexidade das informações do
projeto, definir para cada item da EAP, uma possível lista de atividades ou marcos da implantação
do componente, responsabilidades, estimativas de esforço de cronograma – em alguns casos,
períodos de início e término –, estimativas de recursos, de custos, número identificador associado
ao item da EAP, informações contratuais, requisitos de qualidade, critérios de aceitação, referências
técnicas, premissas e restrições.
Utilizar corretamente uma linha de base do escopo vai permitir ao time do projeto evitar uma
prática comumente conhecida no mercado, como scope creep. Em tradução literal, do inglês para o
português, algo similar ao termo “escopo assustador”. Isso ocorre quando há uma descontrolada
expansão do escopo do projeto ou do escopo do produto, na maioria das vezes não autorizada pelas
principais partes interessadas do projeto, desencadeando uma série de efeitos não previstos sobre
demais áreas do projeto, por exemplo, recursos, cronograma e custos. Gerenciar de perto, por
exemplo, as exclusões ao escopo do projeto – não escopo do projeto – é uma boa prática que poderá
auxiliar o time do projeto na não incidência do scope creep.
Entre muitas práticas que podem, potencialmente, desencadear o fenômeno do scope creep
em um projeto, as principais são:
 má definição do escopo ou um escopo em desalinho com a realidade, quiçá não refinado;
 ausência de um escopo formalizado ou de um gerenciamento dos requisitos para o projeto;
 processos inconsistentes para coletar os requisitos do produto;
 baixo grau de engajamento das principais partes interessadas – pode ser, por exemplo, falta
de patrocínio – e
 projeto com cronograma muito extenso.

64
 Figura 19 – Scope creep

Trabalhar em recursos não aprovados de um projeto pode levar uma equipe a dedicar esforços
a alterações não autorizadas e que possuem a potencialidade de não agregar valor ao cliente ou
usuário final do produto, serviço ou resultado que estará sendo gerado pelo projeto.
Duas coisas podem ocorrer com a prática do scope creep: desalinho completo com
potencialidade para gerar atrasos de cronograma, despertar novos riscos, anomalias no controle dos
custos – em decorrência de trabalhar em partes não autorizadas sem a certeza de que elas serão
incorporadas ao trabalho do projeto – ou desenvolver um produto, serviço ou resultado final
completamente diferente daquilo que foi originalmente previsto, sem um histórico de controle de
mudanças que justifique tais ações.

65
Retrospectiva do módulo
O Módulo III iniciou a sua trajetória demonstrando os dois últimos processos da área de
conhecimento escopo, ambos vinculados ao grupo de processo do planejamento. Foram
evidenciadas as suas entradas, técnicas e ferramentas para a conversão do processo, culminando com
as suas respectivas saídas. Os entregáveis produzidos nas saídas dos dois últimos processos foram
tratados e demonstrados por meio de exemplos e templates sugeridos, unindo explicações com
princípios para a confecção de importantes artefatos que possuem o poder de ditar todo o sucesso
de um projeto, pelo potencial de influenciar o planejamento de todas as demais áreas de
conhecimento de um projeto.
Vivenciamos as diferenças conceituais entre trabalhar um TAP e uma DE, em que os
momentos vividos pelo time do projeto são substancialmente diferentes, e a necessidade de que
ambos os artefatos possam coexistir, cada um desempenhando a sua função específica, sem que se
repitam em redundância de informações ou desagreguem informações para as muitas partes
interessadas no projeto.
Ainda em relação à DE, presenciamos os detalhes que precisam ser levados em consideração
para confeccionar esse artefato como descrito nas boas práticas preconizadas pelo PMI, como a
utilização de escuta ativa, adoção de princípios de transparência e de realismo – “pés no chão” –,
definição das exclusões ao escopo – não escopo – e, por fim, evitar a realização do gold platting, que
visa a entregar algo a mais, acreditando que o seu cliente ou usuário final verá valor nesse acréscimo,
e os dissabores poderão ser maiores que os esforços enveredados para implantar algo que não foi
solicitado ou corretamente documentado pelo time do projeto.
Ao iniciarmos os estudos da criação de uma EAP, descrevemos inicialmente algumas
definições importantes – por exemplo, pacotes de trabalho, níveis de uma EAP e princípios da
qualidade de uma EAP – para então podermos demonstrar os principais tipos ou formatos de como
uma EAP pode ser confeccionada: gráfica, piramidal ou mapa mental; textual e tabular. Na
sequência, descrevemos os cuidados que precisam ser adotados para uma correta confecção de uma
EAP, como adotar a regra dos 100%, descrever o ciclo de vida do projeto no segundo nível e realizar
um correto trabalho de decomposição.
Ainda pudemos demonstrar que uma linha de base do escopo de um projeto, quando
corretamente dimensionada, é constituída da DE, uma EAP contendo os pacotes de trabalho e de
planejamento, assim como um dicionário da EAP. Utilizar corretamente uma linha de base do escopo
significa mitigar problemas em relação às entregas de um projeto e os seus impactos em relação às
demais áreas de conhecimento do projeto, bem como evitar uma prática conhecida como scope creep.

66
MÓDULO IV – VALIDAÇÃO E CONTROLE
DO ESCOPO

O Módulo IV do nosso material nos brindará com os únicos processos do escopo constantes
do grupo de processos de monitoramento e controle. Serão estudados os processos de “validar o
escopo” e “controlar o escopo”, bem como todas as entradas, técnicas e ferramentas, e saídas, para
a compreensão de um mecanismo formal de aceitação das entregas ou no caso de desconformidade
com as precisões dos requisitos, de avaliar uma solicitação de mudança, que tem a função de
coordenar o progresso do escopo do projeto e o escopo do produto, com poder de influenciar
diretamente as principais áreas de conhecimento de um projeto.

Processo “Validar o Escopo”: peculiaridades, entradas,

técnicas e ferramentas
Uma das provas de que o gerenciamento do escopo não anda sozinho em um projeto é o
processo “validar o escopo”. Esse processo demonstra de uma maneira sutil como o trabalho do
gerenciamento do escopo encontra-se intimamente ligado ao gerenciamento da qualidade e à área
de conhecimento de integração.
Existem duas situações ao analisarmos esse fluxo do processo “validar o escopo”, a primeira
ocorre quando se recebe a confirmação, por parte da área da qualidade, de que uma determinada
entrega foi verificada, e as precisões dos requisitos foram chanceladas. Quando isso ocorre, o fluxo
dos processos segue naturalmente para o encerramento do projeto, pois a área de escopo envia para
a área de integração, no seu último processo, a informação das entregas aceitas. Baseado nesse tipo
de informação, há a possibilidade de encerrar o projeto – à medida que todas as entregas conseguem
ser verificadas e, posteriormente, validadas – ou alguma fase intermediária do projeto.

67
 A segunda situação ocorre quando o controle da qualidade envia uma informação de entrega
verificada, mas com viés de não conformidade das precisões dos requisitos. É chegado então o
momento da tomada de decisão. É preciso avaliar quais são os objetivos estratégicos vinculados ao
projeto para se decidir pelo avanço ou pela solicitação de mudança. Uma solicitação de mudança
custa tempo e dinheiro ao time do projeto, apesar de ser um dos principais instrumentos de
aprendizado ao longo do ciclo de vida do projeto. Como se pode afirmar que um projeto sem
mudanças é algo utópico, ao menos em algum momento ocorrerá esse fluxo destinado a uma
solicitação de mudança. Algumas organizações utilizam o termo em inglês, change request.
A área de escopo então, em vez de validar a entrega, dispara um alerta de solicitação de
mudança para a área de integração. Essa solicitação será trabalhada por um dos processos mais
importantes dos 49 constantes do Guia PMBOK®, chamado “realizar o controle integrado de
mudanças”. Contudo, não há como se enganar, o foco do processo “validar o escopo” é o de aceitar
todas as entregas. Afinal de contas, caso isso ocorra, não haverá necessidade de passar ao processo
de “controlar o escopo” e novamente avaliar o rigor das precisões das entregas e nos cumprimentos
dos requisitos da qualidade, especificados para as mesmas.

Figura 20 – Processo 5.5: validar o escopo

Fonte: PMI (2017a).

Para que o processo “validar o escopo” ocorra, leva-se em consideração a entrada de grande
parte da documentação definida no momento do planejamento do escopo, a saber: o PGE, o plano
de gerenciamento dos requisitos e a linha de base do escopo, composta de EAP, com pacotes de
trabalho e pacotes de planejamento; dicionário da EAP e DE.
O PGE determina todas as regras para lidar com o assunto “escopo” ao longo do projeto, e
no momento do monitoramento e controle não pode ser diferente. Apenas para citar alguns
exemplos, devem existir informações nesse artefato, que determinam como as mudanças em relação
ao escopo serão gerenciadas e como as aceitações das entregas serão realizadas.

68
 Quanto ao plano de gerenciamento dos requisitos, a mesma coisa, pois determina todas as regras
para lidar com o assunto “requisitos” ao longo do projeto. Detalhes de priorização de requisitos, geração
de relatórios e critérios de aceitação, entre outros, são informações importantes nesse momento.
A documentação dos requisitos torna-se necessária para que haja comparação entre o status
quo e o que foi efetivamente realizado, para determinar se uma solicitação de mudança, quiçá uma
ação corretiva ou preventiva, precisará ser acionada. Há também a preocupação em receber
informação da matriz de rastreabilidade dos requisitos, pois contém informações valiosas de como
os requisitos deverão ser aceitos e validados.
Já a linha de base do escopo é requerida por se tratar da referência mor de tudo o que precisa
ser realizado ou entregue pelo time do projeto, no intuito de cumprir os objetivos do projeto. Ou
seja, se um determinado pacote de trabalho não estiver definido dentro da linha de base do escopo,
não há como passar pelo processo de controle da qualidade e, posteriormente, transformar-se em
entregas aceitas, como informação para a área de integração do projeto. O principal papel desse
processo, que é o de buscar todas as aceitações das entregas, não conseguiria ser executado.
É comum que o processo de controle de qualidade venha antes do processo de validação do
escopo, mas é importante ressaltar que não há dependência entre um processo e outro, podendo o
controle da qualidade ocorrer em paralelo com a validação do escopo, por exemplo. Alguns projetos
utilizam critérios de aceitação vinculados ao cumprimento de requisitos de qualidade, sendo
possível ganhar tempo em momentos importantes do projeto.
Além dos artefatos desenvolvidos pela própria área de escopo, ainda são requeridos como
entradas para o processo de “validar o escopo”: a) registro das lições aprendidas – uma maneira de
utilizar a gestão do conhecimento como forma de aumentar a eficiência e a eficácia da aceitação das
entregas; e b) relatórios da qualidade – mecanismo pelo qual as informações provenientes da área
de conhecimento da qualidade são recebidas para que então o produto, serviço ou resultado a ser
gerado, possa ser aceito.
Também existe a menção de receber dados de desempenho do trabalho, que podem incluir
graus de conformidade dos requisitos, riscos em caso de não conformidades ou, até mesmo, o
número de ciclos iterativos necessários ao um release de um produto.
Como ferramentas e técnicas, existem as menções acerca de inspeção e tomada de decisão.
Como inspeção, claramente há a preocupação com formalizações de medição, observação e
validação para chancelar se os requisitos e critérios de aceitação do produto, serviço ou resultado a
ser gerado foram cumpridos. Em determinadas áreas de atuação, o termo homologação também é
utilizado como uma técnica de inspeção. Já em relação às técnicas de tomada de decisão, os
exemplos mais indicados são, entre outros, análise de alternativas e votação.
Segundo o Guia PMBOK® (PMI, 2017a, p. 202), “a votação é usada para chegar a uma
conclusão quando a validação é realizada pela equipe do projeto e por outras partes interessadas”.

69
Processo “Validar o Escopo”: saídas
Quando um critério de aceitação é formalmente aprovado pela parte interessada competente,
significa dizer que há uma entrega aceita e pronta para ser remetida para o processo “encerrar o
projeto ou fase”. Essa é a saída que melhor caracteriza o processo “validar o escopo”. Contudo,
existe a possibilidade de emissão de novos dados a respeito do desempenho do trabalho,
independentemente se as entregas foram aceitas ou não. Essas documentações são documentadas e
transmitidas aos principais stakeholders. Assim como são documentados todos os registros em
relação à aceitação das entregas, aquilo que não recebe o aceite vira motivo de uma potencial
solicitação de mudança, que também vem a ser um processo de formalização e documentação chave
dentro do trabalho do escopo.
Isso abre, porém, uma nova possibilidade, pois visam a um processo de análise e
entendimento da situação para que haja a reavaliação do problema e a sua futura correção. Contudo,
conforme mencionado no subitem anterior, esse trabalho será direcionado ao processo “realizar o
controle integrado de mudanças”, pertencente à área de integração. Paralelamente a isso, todos os
documentos que, potencialmente, podem ter servido como entrada, tais como registro de lições
aprendidas, documentação dos requisitos e matriz de rastreabilidade dos requisitos, tendem a sofrer
atualizações, independentemente de a entrega ter sido aceita ou não. Tudo será documentado, e
todos esses artefatos, atualizados.
Um documento que pode auxiliar bastante no processo de “validar o escopo” é um formulário
de aceitação formal, que vem a ser uma lista de verificação que tanto possui o poder de auxiliar os
trabalhos oriundos da área de conhecimento da qualidade, quando o foco for verificar a exatidão da
entrega, como sequenciar essas informações e promover o trâmite integrado e natural para a área de
conhecimento do escopo, cujo foco é a verificar se a validação do requisito atende aos critérios de
aceitação acordados com o cliente. Um modelo desse formulário pode ser visualizado no quadro a seguir.

Quadro 14 – Formulário de aceitação formal

título do projeto data de elaboração

critério de critério de
ID requisito status comentários aprovação
aceitação validação

Fonte: adaptado de Snyder (2013).

70
 As quatro primeiras colunas são informações retiradas da documentação dos requisitos, o que
facilita em muito o sistema integrado de informações do projeto. Na sequência, o que se vê é uma
informação a respeito do status da entrega – pode ser simplesmente: aceito ou não aceito –, um
espaço para observações, por exemplo, informações do porquê de o requisito não ter sido aceito,
quando a solicitação de mudança foi realizada e que tipo de mudança espera-se desse processo. Por
fim, coleta-se a assinatura de quem foi a parte interessada responsável por aceitar a entrega.

Processo “Controlar o Escopo”: peculiaridades, entradas,

técnicas e ferramentas
Segundo o PMI (2017a, p. 203), “controlar o escopo” “é o processo de monitoramento do
progresso do escopo do projeto e do escopo do produto e gerenciamento das mudanças feitas na
linha de base do escopo. O principal benefício deste processo é que a linha de base do escopo é
mantida ao longo de todo o projeto”. Esse é um processo que só poderá ser acionado, na sequência
do processo “validar o escopo”, mas nada impede de ser executado ao longo de todo o projeto.
Conforme demonstrado na figura 20, as entradas para esse processo são o PGP, aqui
representado por PGE, plano de gerenciamento dos requisitos, plano de gerenciamento de
mudanças, plano de gerenciamento de configuração, linha de base do escopo e linha de base de
medição do desempenho.
O PGE define as normas para tratar o assunto “escopo” ao longo do projeto e documenta
como o escopo do projeto e o escopo do produto serão controlados. O plano de gerenciamento dos
requisitos também cumpre o papel de definir como o assunto “requisitos” deverá ser tratado ao
longo do projeto e descreve como os requisitos deverão ser aceitos e validados. O plano de
gerenciamento de mudanças define como ocorrerão os fluxos das mudanças de um projeto. O plano
de gerenciamento de configuração descreve quais funcionalidades dependem de controle formal de
mudança como será o fluxo para controle de mudanças dessas funcionalidades. A linha de base do
escopo possui toda a referência que será comparada para verificar se o requisito implantado será
aceito ou sofrerá uma solicitação de mudança. Por sua vez, a linha de base da medição do
desempenho também será utilizada como referência, utilizando análise de valor agregado para
determinar se haverá alguma necessidade de mudança.

71
 Figura 21 – Processo 5.6: controlar o escopo

Fonte: PMI (2017a).

Na sequência, há a menção de alguns documentos do projeto, por acaso, os mesmos descritos

no processo “validar o escopo”, e, não à toa, as razões serão essencialmente as mesmas. Utilizar o
registro de lições aprendidas no intuito de verificar se projetos similares ou fases anteriores do
mesmo projeto possuem informações que possam melhorar o gerenciamento do controle do escopo.
A documentação dos requisitos para avaliar se ocorreu qualquer tipo de desvio no escopo do projeto
ou no escopo do produto. Além disso, a matriz de rastreabilidade dos requisitos para avaliar a visão
macro, de ponta a ponta do projeto, em relação aos impactos que qualquer mudança ou desvio de
linha de base possa desferir contra os objetivos do projeto.
Os dados de desempenho de trabalho também são mencionados, afinal de contas, são relatórios
precisos acerca, por exemplo, da quantidade de solicitações de mudanças recebidas, variações de
indicadores, quantidade de entregas verificadas, validadas ou não. Por fim, há a menção dos ativos de
processos organizacionais, aqui representados por meio de políticas, procedimentos e diretrizes
organizacionais de controle, além de métodos, frameworks ou templates de monitoramento.
Como técnicas e ferramentas, menciona-se basicamente o processo de análise de dados por
meio de análises de variação e de tendências. As análises de variação buscam o foco da causa das
diferenças percebidas entre os planejamentos das linhas de base e o real executado, no sentido de
estar mais bem preparado para variações futuras e obter respostas a possíveis inconsistências de
medição de determinados indicadores. Já as análises de tendência continuam comparando o que foi
previsto em relação ao executado, mas possuem um maior foco em minimizar potenciais riscos por
meio de simulações de como o projeto potencialmente se comportará, utilizando sempre a
referência do momento atual para avaliar cenários futuros. Detalhes de suma importância no

72
trabalho de “controlar o escopo” incluem a determinação da causa e do percentual de variação em
relação aos parâmetros de base. Não podem faltar, contudo, decisões sobre tendências ou
necessidades de ações corretivas ou preventivas.
O processo “controlar o escopo” não atua de maneira isolada. Da mesma forma que o
planejamento do escopo exerce força em potenciais impactos nas demais áreas de conhecimento de um
projeto, o controle do escopo, necessariamente, precisa trabalhar com outras áreas de conhecimento e
os seus processos de controle. “O aumento sem controle do escopo do produto ou projeto sem ajustes
de tempo, custos e recursos é chamado de distorção de escopo” (PMI, 2017a, p. 204).

Processo “Controlar o Escopo”: saídas

As saídas do processo “controlar o escopo” baseiam-se, na sua maioria, em atualizar as
informações constantes nas informações que tenham sido utilizadas em uma possível aceitação de
entrega, mas que sofreram pedidos de ajustes, os quais podem ocorrer nas informações sobre o
desempenho do trabalho, nos documentos constantes do PGP, na documentação dos requisitos, na
matriz de rastreabilidade dos requisitos, no registro de lições aprendidas, que tenham sido objeto
de entrada no referido processo e que tenham sofrido influência por algum tipo de mudança nas
linhas de base do escopo do projeto, em resposta às possíveis mudanças solicitadas para um ajuste
do escopo. Além disso, a principal saída do processo “controlar o escopo” é, de fato, a solicitação
de mudança. Uma formalização que integrará o trabalho de controlar o escopo com o processo
formal de controle integrado de mudanças, proveniente da área de integração.

Retrospectiva do módulo
A Unidade IV fixou-se em apresentar todos os conceitos a respeito dos dois processos da área
de conhecimento do escopo, pertencentes ao grupo de processos de monitoramento e controle.
Avaliamos em primeiro lugar o processo “validar o escopo”, cujo foco principal vem a ser a busca
do aceite de todas as entregas, um trabalho realizado em conjunto com as áreas de conhecimento
da qualidade e de integração. Na sequência, verificamos o processo “controlar o escopo”, que visa
ao monitoramento do progresso do escopo do projeto e do escopo do produto, no intuito de
gerenciar todas as mudanças realizadas em qualquer documentação oriunda dos trabalhos de
planejamento do escopo.
Exploramos entradas, ferramentas e técnicas, e saídas desses dois processos, assim como
reforçamos a relação tênue do trabalho do time do projeto em relação aos assuntos escopo e qualidade.
Ao estudarmos estes dois últimos processos, fecha-se o ciclo do trabalho do gerenciamento
do escopo em um projeto. Essa área não ocupa momentos importantes apenas nos grupos de
processos do planejamento e de monitoramento e controle, mas possui um poder de influenciar

73
todo o restante do projeto. Quando um escopo é trabalhado de maneira correta, todo esse trabalho
se reflete no restante do projeto, e o contrário também é verdade.
Este último capítulo demonstra que errar faz parte do trabalho de um time do projeto. É
sempre bom ter em mente que os erros devem aparecer o mais rápido possível; afinal de contas,
quem erra rápido aprende rápido e conserta os seus erros, retomando as rédeas do projeto, também
de maneira rápida. Um escopo corretamente validado e controlado é um desafio estimulante, e
poucos profissionais se dão conta disso.
Com os ensinamentos desta última unidade, fica mais fácil compreender como aceitar
entregas ou então promover as suas revisões para buscar a perfeição do produto, serviço ou resultado
que estará sendo gerado.

74
BIBLIOGRAFIA
CAROLI, Paulo. Direto ao ponto: criando produtos de forma enxuta. São Paulo: Casa do Código, 2015.

______. O canvas MVP. Disponível em: <http://www.caroli.org/o-canvas-mvp>. Acesso em:

12 dez. 2018.

CLELAND, David I. Why project management? Business Horizons. USA, 1964.

CRUZ, F. Scrum e agile em projetos: guia completo. Rio de Janeiro: Brasport, 2015.

______. Estimativas. Disponível em: <http://www.fabiocruz.com.br/frameworkscrumold/sprint-

planning-sp1>. Acesso em: 10 jan. 2019.

DORAN, G. T. There’s a S.M.A.R.T. way to write management’s goals and

objectives. Management Review, n. 70, v. 11, p. 35-36, 1981.

DRUCKER, P. The practice of management. New York: Harper & Brothers, 1954.

GADDYS, Paul. The project manager. Harvard Business Review, USA, May/June, 1959.

JEFFERY, Ralf. Putting de “V” in MVP. InfoQ, 25 de fevereiro de 2018. Disponível em:
<https://www.infoq.com/presentations/mvp-lean-product>. Acesso em: 12 jan. 2019.

LOCKE, Edwin. Toward a theory of task motivation and incentives. New York: Harper & Row, 1968.

MASSARI, Vitor L. Agile scrum master no gerenciamento avançado de projetos. Rio de Janeiro:
Brasport, 2016.

______. Percepções sobre a 6a edição do PMBOK e o Agile Practice Guide, 2017. Disponível em:
<https://www.profissionaisti.com.br/2017/10/percepcoes-sobre-a-6a-edicao-do-pmbok-e-o-agile-
practice-guide>. Acesso em: 11 nov. 2018.

PROJECT MANAGEMENT INSTITUTE (PMI). Practice standard for work breakdown

structures. 2nd ed. PMI Inc. USA, 2006.

______. Requirements management: a practice guide. PMI Inc. USA, 2016.

75
______. A guide to the project management body of knowledge: PMBOK Guide. 6th ed. PMI Inc.
USA, 2017a.

______. Agile practice guide. PMI Inc. USA, 2017b.

______. The PMI guide to business analysis. PMI Inc. USA, 2017c.

______. Pulse of the profession 2018. Disponível em: <https://www.pmi.org/-

/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-
2018.pdf?sc_lang_temp=en>. Acesso em: 30 jan. 2019.

RESEARCH GATE. Disponível em: <https://www.researchgate.net/figure/Figura-3-Diagrama-

de-Contexto-Sistema-de-Analise-Espaciais-para-Planejamento-Urbano-PAE_fig16_321949922>.
Acesso em: 8 dez. 2018.

RIBEIRO, Richardson. Gerência de projetos em sistemas de informação. s/d. Disponível em:

<https://slideplayer.com.br/slide/11315661>. Acesso em: 12 jan. 2019.

SERPA, Silas. Project Management Knowledge Base (PMKB): restrições de projetos para reduzir
custos. Disponível em: <https://pmkb.com.br/artigos/restricoes-de-projeto-para-reduzir-custos>.
Acesso em: 3 dez. 2018.

SNYDER, Cynthia S. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Campus, 2013.

XAVIER, Carlos Magno S. Gerenciamento de projetos: como definir e controlar o escopo do projeto.
2. ed. São Paulo: Saraiva, 2009.

BIBLIOGRAFIA RECOMENDADA
PROJECT MANAGEMENT INSTITUTE (PMI). Practice standard for work breakdown
structures. 2nd ed. PMI Inc. USA, 2006.
Um dos padrões – standards – vigentes mais antigos do PMI continua atual para aquilo que
se propõe, ou seja, explicar o conceito e a importância estratégica na utilização de uma EAP
de alta qualidade. O livro é de um padrão simples e pode ser rapidamente utilizado,
demonstrando como é evidente descobrir os benefícios de utilização de uma EAP, não só em
situações organizacionais, mas também em relação a situações cotidianas. A obra fornece
elementos para o desenvolvimento preliminar de uma EAP, a sua integração dentro do
contexto geral do planejamento do escopo e a futura implementação da EAP como linha de
referência do escopo de um projeto.

76
PROJECT MANAGEMENT INSTITUTE (PMI). Requirements management: a practice guide.
PMI Inc. USA, 2016.
Com a visão de que organizações continuam experimentando problemas no gerenciamento
de projetos associados a baixos desempenhos em atividades relacionadas ao gerenciamento
dos requisitos, esse livro nasceu para trazer uma luz ao tema, fornecendo ferramentas e
desmistificando uma das principais etapas dos processos de gerenciamento do escopo. O livro
aborda o desenvolvimento, a elicitação e o gerenciamento dos requisitos em um nível
detalhado e prático, seja para implementação em projetos, programas ou portfólios,
preenchendo uma lacuna que perdurou durante muito tempo para profissionais de projetos.

PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of

knowledge: PMBOK Guide. 6th ed. PMI Inc. USA, 2017a.
A principal publicação do PMI continua sendo um recurso fundamental para o
gerenciamento eficaz de projetos em qualquer setor. O Guia PMBOK® compõe os padrões
globais da metodologia proposta pelo PMI, refletindo de forma contínua e precisa uma
profissão que permanece em constante evolução. A novidade desta última edição é que se
torna necessário avaliar diferentes abordagens para se trabalhar em um projeto, não mais
ficando um time preso a abordagens tradicionais. Exatamente por isso, essa publicação precisa
ser utilizada em sintonia, de maneira complementar, com o Agile Practice Guide. Juntas, as
duas publicações são uma ferramenta poderosa que permitirá definir qual deverá ser a melhor
abordagem para um determinado projeto.

PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. PMI Inc. USA, 2017b.
Trata-se da grande inovação recente do PMI, que reflete as últimas tendências de pesquisas
mercadológicas e impulsiona um trabalho de décadas a um novo nível, abrindo a visão de
trabalhar gerenciamento de projetos por meio de práticas ágeis, de maneira específica ou
mesclada, com abordagem híbrida. As orientações são complementares ao padrão global do
Guia PMBOK® e quando aplicadas em conjunto apresentam soluções importantes para
profissionais de projetos que trabalham em busca das melhores soluções para os seus
produtos, serviços ou resultados que estarão sendo desenvolvidos. É uma leitura
especialmente útil para membros de times de projetos acostumados a um ambiente mais
tradicional se adaptarem a um mindset ágil, em busca de entrega de percepção de valor e
verificação de resultados mais imediatos.

77
SNYDER, Cynthia S. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Campus, 2013.
Muitos profissionais do gerenciamento de projetos se perdem diante das complexidades de
documentação ou, por exemplo, de monitoramento, em determinadas situações vinculadas a
um projeto real. A autora nos brinda com uma bela seleção de templates que podem ser
otimizados em relação às verdadeiras necessidades de cada projeto. Porém, a grande valia
desse livro, que se encontra plenamente alinhado com as boas práticas preconizadas pelo Guia
PMBOK®, é mostrar modelos de documentos desde o início de um projeto até o seu
encerramento, passando por templates simples como o de uma ata de reunião – que serve,
entre outras coisas, para monitoramento e controle das comunicações de um projeto – até
um mais complexo, como um relatório de auditoria da qualidade.

78
PROFESSOR-AUTOR
Guilherme Hoffmann é doutorando em Business Administration pela École Supérieure de
Commerce de Rennes – França. Mestre em Marketing Internacional pela Universidad Nacional de
La Plata – Argentina. Especialista em Gerenciamento de Projetos e em Direito da Economia e da
Empresa, ambos pela Fundação Getulio Vargas. Graduado em Direito pela Universidade Católica
de Petrópolis. Negociador certificado pela Fundação Getulio Vargas e pelo programa Negotiation
and Leadership da Harvard Law School. Business Executive Program, pela Donghua University –
China. Certified ScrumMaster® (CSM) e Certified Scrum Product Owner (CSPO), ambos pela
Scrum Alliance. Agile Facilitator pela Knowledge21. Kanban certified pela Lean Kanban University.
HCMBOK 3G Practitioner e HCMP 3G Expert Professional, ambos pelo Human Change
Management Institute (HUCMI). Formado em Management 3.0 – Change and Innovation
Practices. Formado em Design Thinking pela Echos Design Thinking. Teampreneur workshop
certified pela Team Academy – Finlândia.
Agilista e facilitador com dezenas de projetos gerenciados, tanto em empresas privadas como
públicas, nos mais variados setores: navegação, óleo e gás, engenharia, serviços, tecnologia da
informação, educação, grandes eventos, etc. Consultor em Gerenciamento de Projetos e advogado.
Sócio-diretor da XVI Consultoria e Assessoria Empresarial Ltda. Conteudista e revisor técnico de
materiais em Gerenciamento de Projetos. Professor convidado da Fundação Getulio Vargas, do
Grupo IBMEC, da Escola Politécnica da Universidade Federal do Rio de Janeiro (UFRJ) e do
Instituto de Pós-Graduação (Ipog). Consultor convidado do Instituto de Desenvolvimento
Empresarial (Idemp).

79