Gerenciamento de Projetos

Prévia do material em texto

Como citar este material: 
HOFFMANN, Guilherme. Gerenciamento do escopo e qualidade. Rio de Janeiro: FGV, 2024. 
 
Todos os direitos reservados. Textos, vídeos, sons, imagens, gráficos e demais componentes 
deste material são protegidos por direitos autorais e outros direitos de propriedade intelectual, de 
forma que é proibida a reprodução no todo ou em parte, sem a devida autorização. 
 
INTRODUÇÃO 
Em certo momento da minha vida profissional, deparei-me com 
um jovem engenheiro recém-formado que estava no primeiro emprego, 
na verdade, um estágio. Um dia, depois de muitos esforços em prol de 
um detalhe simples que demandou muitas horas de atenção por parte da 
equipe do projeto, escutei o rapaz questionar que a vida de um 
profissional de gerenciamento de projetos era muito inconstante e 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. Tamanha foi a minha surpresa quando 
esse mesmo indivíduo desejou que a vida profissional dele fosse mais 
estável. Aquilo martelou muito tempo na minha cabeça. Afinal de 
contas, quem possui uma vida estável no trabalho? Sem mencionar 
que uma vida estável pode consideravelmente levar à zona de conforto, 
ao sedentarismo, à desmotivação ou até mesmo à substituição de 
determinados cargos por máquinas. 
Se praticamente tudo o que a estabilidade traz é prejudicial, 
comecei a demonstrar para aquele estagiário exatamente o contrário, ou 
seja, o quão bom é um ambiente instável, pois o que importa é manter 
uma postura de busca por uma identidade cultural acerca da 
adaptabilidade à mudança e estar sempre disposto a abraçar desafios. O 
fato de viver em um ambiente em constante mudança pode ser 
extremamente gratificante, basta aprender a lidar com diferentes tipos de 
situações. Mais ainda, é possível que tenhamos de agradecer todos os dias 
pelo tipo de trabalho realizado, pois do contrário, muito provavelmente, 
já não seremos peças necessárias. 
Para auxiliar na questão da adaptabilidade, existe o gerenciamento 
de projetos que, por sua vez, não pode ser encarado nas organizações como 
um modismo, mas sim como algo que já deixou de ser tendência e passou 
a ser essencial para a saúde dos processos organizacionais. Trata-se de um 
tema que muito se explora há décadas, cujas benesses da correta aplicação 
dos conceitos muitas organizações públicas, privadas ou do terceiro setor 
apenas recentemente começaram a perceber. 
 
 
Sempre que o assunto é visto de maneira ordenada e integrada, muitas são as possibilidades de 
desenvolver melhores produtos e serviços, alinhando padrões internacionais de gestão com o 
fortalecimento de uma instituição, seja por demonstrar melhor cuidado com os processos ou por 
transparecer, por meio dos valores tangíveis e intangíveis, diferenciais competitivos. 
Exatamente por isso, muito se discute sobre como melhorar processos, estipular métricas, 
capacitar profissionais e otimizar entregas, entre outros detalhes que poderão trazer retornos 
rápidos, ou mesmo de longo prazo, para organizações que adotam tais práticas. O gerenciamento 
do escopo é somente a ponta desse iceberg, pois ele e os demais temas pertinentes ao projeto têm 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 são a base de toda e qualquer estrutura. De nada serviria o 
trabalho do escopo, se não estivesse corretamente alinhado com o da qualidade, por exemplo. São 
irmãos gêmeos separados no nascimento. Um depende, essencialmente, do outro. É por meio do 
gerenciamento da qualidade que se busca agregar valor àquilo que está sendo gerado pelo time do 
projeto e melhorar a percepção de satisfação das principais partes interessadas, assim como vincular 
o resultado do projeto com os objetivos traçados por diretrizes estratégicas organizacionais. 
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 
esses resultados, um escopo mal definido possui um enorme potencial para gerar problemas de 
comunicação. Em face dessa observação, surge uma questão sobre as respostas dos entrevistados: 
elas não estavam mais atentas às consequências dos problemas do que, talvez, às causas deles? Se 
essa 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. Curiosamente, a 
qualidade só é lembrada após menções de muitos outros tipos de problemas, como disputas por 
recursos, estimativas sem fundamento, riscos mal avaliados, atrasos de cronograma, entre outros. É 
verdade que nem toda organização possui algum tipo de mentalidade ou até mesmo um setor (quiçá 
profissionais específicos) voltados para processos de qualidade. Muitas acreditam que está tudo muito 
bem, obrigado e utilizam a máxima de que em time que está ganhando não se mexe. Exatamente por 
isso, é muito comum verem-se práticas de qualidade serem realizadas (quando realizadas) por 
profissionais que acumulam funções não originais de qualidade. 
A resposta para melhorar esses problemas – ou até solucioná-los, de uma vez por todas – está 
em uma correta atenção ao gerenciamento do escopo e da qualidade em projetos. Entretanto, esse 
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 ou falta de 
estrutura/cultura organizacional. 
 
 
 
Este material é um compêndio para que profissionais da área de gerenciamento de projetos 
percebam cada vez mais a importância do gerenciamento do escopo e da qualidade em projetos, assim 
como as correlações destes com o trabalho dos demais temas que permeiam o gerenciamento de projetos. 
Dessa forma, o objetivo geral desta disciplina é apresentar os conceitos de escopo e de 
qualidade, tratando algumas peculiaridades, ferramentas, dicas, modelos e práticas, entre tudo o 
que mais possa ser útil para a melhor compreensão desses dois importantes tópicos. Além disso, 
demonstrar como ambos, escopo e qualidade em projetos, portam-se, oferecendo um grau de 
compreensão que produza efeitos imediatos de utilização do assunto estudado em organizações, em 
capacitação/motivação de indivíduos e grupos de pessoas, que adotem ou visem a adotar o 
gerenciamento profissional de projetos. 
Por sua vez, os objetivos específicos são: 
 reconhecer os principais termos e as peculiaridades que envolvem o assunto escopo e 
qualidade em projetos; 
 identificar todas as etapas do escopo e da qualidade em projetos, segundo modernas 
práticas internacionais reconhecidas pelo mercado; 
 aplicar corretamente os processos do escopo e da qualidade ao longo de um projeto real, 
independentemente de porte ou segmento de mercado; 
 demonstrar uma visão holística, percebendo a importância dos trabalhos do escopo e da 
qualidade em relação às demais temáticas de um projeto e 
 elaborar, reconhecer e analisar, com visão crítica, os principais documentos relativos ao 
escopo e à qualidade em projetos. 
 
Visto isto, este material está organizado de tal forma que o módulo I, Introdução e conceitos 
fundamentais do escopo, apresenta o escopo como um dos assuntos mais nervais em um projeto, pois 
possui o dom de influenciar direta e indiretamente todo o trabalho da equipe do projeto. 
Exatamente por isso, é necessário conhecer os principais termos e peculiaridades demandados na 
conduçãode um bom trabalho de gerenciamento do escopo em projetos. O módulo se propõe a 
demonstrar, em um primeiro momento, como o termo escopo surgiu e amadureceu, passando 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 qualquer organização. Apresenta também todos os principais 
conceitos necessários à correta compreensão e à assimilação de um bom trabalho de gerenciamento 
do escopo em projetos. Na sequência, faz a conexão com os primeiros momentos do projeto, por 
meio do Termo de Abertura do Projeto, demonstrando como será o percurso a ser percorrido para 
o início dos trabalhos, visando aos esforços de um bom planejamento. 
 
 
 
Por sua vez, o módulo II, Introdução e conceitos fundamentais da qualidade, aborda a qualidade 
como um tema de suma importância em todos os setores e, para o gerenciamento profissional de 
projetos, não poderia ser diferente. O tema relaciona-se diretamente com todas as demais temáticas 
de um projeto e possui o poder de provocar potenciais impactos em muitos dos processos de tomada 
de decisão ao longo do ciclo de vida do projeto. Em função de melhorarmos a compreensão acerca 
do tema, serão apresentados os principais conceitos, iniciando por um breve relato histórico de 
como a sociedade moderna descobriu os benefícios da implementação da qualidade em produtos e 
serviços. Na sequência, trataremos de técnicas, métodos, ferramentas e outras opções, como rituais 
da qualidade, que possam ser rapidamente compreendidos – ou aperfeiçoados, caso o aluno já os 
conheça –, e implementados na prática com o mínimo de esforço, representando um benefício 
imediato de absorção dos ensinamentos do módulo, sempre com foco num trabalho cada vez 
melhor do gerenciamento da qualidade. 
Para começar a trabalhar o escopo, o módulo III, Planejamento do escopo: parte I, incorpora 
os conceitos primordiais de valor e o que isso representa para o desempenho dos trabalhos da equipe 
de um projeto. Em face dessa proposta, é importante que o time do escopo de um projeto domine 
esse conhecimento para que construa 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 a definição do escopo, mas, a partir do momento em 
que passa a existir essa definição, todo o trabalho da equipe do projeto passa a ter outro significado. 
O planejamento do escopo, independentemente da abordagem selecionada para executar o projeto, 
é primordial para o encadeamento do restante dos esforços. No módulo, serão identificadas as regras 
para se trabalhar com um bom planejamento do escopo assim como dos requisitos de um projeto, 
pois buscaremos compreender como funcionam os trabalhos de elicitação (coleta), análise, 
organização, documentação e suas respectivas importâncias para a saúde de um projeto. 
No módulo IV, Planejamento do escopo: parte II, com as regras do escopo já definidas, assim 
como as normas para o trabalho com os requisitos do projeto, o planejamento do escopo torna-se 
necessário em muitos níveis de atuação, desde os mais estratégicos até os com necessidade de ajustes 
mais prementes, como por exemplo intervalos diários. 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 que seja feita a entrega do produto, serviço ou resultado desejado ao cliente ou usuário final, a 
documentação do planejamento será complementada e atualizada com importantes informações 
sobre o escopo. A equipe do projeto passa a ter, então, conhecimento explícito e detalhado do 
escopo do projeto/produto, representado por uma linha de base do escopo. Faz-se mister definir 
como as entregas serão subdivididas em componentes gerenciáveis, os quais, pela sua vez, poderão 
ser melhor estimados, mensurados, monitorados e, caso necessitem, controlados. 
 
 
 
 
Todo bom trabalho começa com um planejamento bem feito. Com a qualidade não poderia ser 
diferente. No módulo V, Planejamento da qualidade, veremos como as informações provenientes do 
planejamento do escopo, mesmo que ainda incompleto, habilitam os primeiros trabalhos de 
planejamento da qualidade. É necessário reunir um conjunto de informações que guiam o trabalho da 
qualidade ao longo de todo o projeto, com o foco principal na definição de todos os parâmetros para 
acompanhar as condições (físicas, técnicas e estratégicas) do produto, serviço ou resultado que estará 
sendo gerado pela equipe do projeto, de maneira objetiva, ou seja, passível de verificação e controle. O 
planejamento da qualidade é fundamental para explicitar políticas, diretrizes, modelos e objetivos da 
qualidade, desenvolver métricas e estabelecer padrões. Planejar a qualidade é uma ação que, dependendo 
do tipo de abordagem destinada ao projeto, pode ser realizada em um único momento ou em momentos 
pré-estabelecidos. Veremos as melhores opções para cada tipo de abordagem. 
Em seguida, o módulo VI, Acompanhamento, validação dos requisitos, aceitação das entregas e 
controle do escopo, mostra como, a priori, o objetivo de um bom planejamento do escopo é 
conseguir que as entregas sejam todas aceitas no formato originalmente previsto. Esta é a meta 
máxima de toda a equipe do escopo: conseguir que todos os requisitos tenham as suas precisões 
confirmadas e as entregas possam ser realizadas tranquilamente. Trata-se de um trabalho realizado 
não somente pelas equipes do escopo mas também com valiosas contribuições dos times 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 constantes 
interferências de algumas 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 sempre alinhado com os objetivos 
estratégicos organizacionais e as necessidades do negócio. 
E, por fim, no módulo VII, Gerenciamento e controle da qualidade, veremos que gerenciar a 
qualidade é colocar em prática tudo o que foi discriminado pelo Plano de Gerenciamento da Qualidade, 
aumentando a probabilidade de cumprir os objetivos da qualidade, assim como mapear 
problemas/defeitos de desenvolvimento ou processos ineficazes, transmitindo o status da qualidade para 
as principais partes interessadas, sempre que necessário. Já o trabalho de controle da qualidade demanda 
monitorar e documentar os resultados dessa execução, avaliando o desempenho do trabalho da 
qualidade como um todo e garantindo que as entregas do projeto sejam plenas, próximas da perfeição 
(ou dentro de um limite de tolerância estabelecido desde o momento do planejamento da qualidade) e, 
efetivamente, atendam às necessidades/oportunidades que motivaram as razões do projeto. 
 
 
 
Para isso, serão descritas todas as etapas para um correto trabalho do gerenciamento do 
escopo e da qualidade em um projeto, assim como serão demonstrados modelos de artefatos 
(templates), técnicas, boas práticas, frameworks e ferramentas, que poderão auxiliar o trabalho de 
qualquer profissional na utópica busca pela perfeição, desenvolvendo competências, objetivando 
um trabalho de melhoria contínua de processos e a entrega de constante valor percebido por parte 
das principais partes interessadas do projeto, notadamente, patrocinadores e clientes/usuários 
finais. Por fim, lembre-se de que sempre é possível trabalhar uma gestão decorrente de um 
ambiente com muita instabilidade. 
Boa leitura!SUMÁRIO 
MÓDULO I – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DO ESCOPO ...................................... 11 
CONCEITO HISTÓRICO .................................................................................................................... 11 
ESCOPO E OS CICLOS DE VIDA DE UM PROJETO ......................................................................... 13 
CONCEITOS IMPORTANTES: VISÃO DO PRODUTO (OU DO SERVIÇO), FUNCIONALIDADES, 
CRITÉRIOS DE ACEITAÇÃO E CRITÉRIOS DE VALIDAÇÃO ............................................................. 18 
DIFERENÇA ENTRE ESCOPO DO PROJETO E ESCOPO DO PRODUTO ........................................ 24 
TERMO DE ABERTURA DO PROJETO E PROCESSOS DE GERENCIAMENTO DO ESCOPO ........ 26 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 29 
MÓDULO II – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DA QUALIDADE .............................. 31 
CONCEITO HISTÓRICO .................................................................................................................... 31 
QUALIDADE, PROCESSOS E A RELAÇÃO COM PRODUTIVIDADE, EFICIÊNCIA E EFICÁCIA ...... 33 
DEFEITOS, CUSTO DA NÃO QUALIDADE, DESPERDÍCIOS E A VISÃO DOS 3 MS ....................... 36 
CUSTO DA QUALIDADE (CDQ) ........................................................................................................ 42 
MELHORIA CONTÍNUA: PDCA, 5 WHYS E RETROSPECTIVAS ....................................................... 46 
O FLUXO DO GERENCIAMENTO DA QUALIDADE ......................................................................... 49 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 50 
MÓDULO III – PLANEJAMENTO DO ESCOPO: PARTE I ...................................................................... 52 
VALOR ................................................................................................................................................ 52 
REQUISITOS: CONCEITO E CLASSIFICAÇÕES ................................................................................ 55 
COLETA DOS REQUISITOS ............................................................................................................... 58 
ANÁLISE, ORGANIZAÇÃO E CLASSIFICAÇÃO DOS REQUISITOS .................................................. 61 
DOCUMENTAÇÃO DOS REQUISITOS ............................................................................................. 65 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 68 
MÓDULO IV – PLANEJAMENTO DO ESCOPO: PARTE II ..................................................................... 70 
PLANEJAMENTO DO ESCOPO EM VÁRIOS NÍVEIS ........................................................................ 70 
LINHA DE BASE DO ESCOPO ........................................................................................................... 73 
ESTRUTURA ANALÍTICA DO PROJETO – EAP ................................................................................. 76 
DICIONÁRIO DA EAP ........................................................................................................................ 82 
SCOPE CREEP ...................................................................................................................................... 84 
RETROSPECTIVA DO MÓDULO ....................................................................................................... 86 
MÓDULO V – PLANEJAMENTO DA QUALIDADE ................................................................................ 87 
OS TRÊS KS: KAIZEN, KAIKAKU E KAKUSHIN ................................................................................. 88 
PLANEJAMENTO DA QUALIDADE ................................................................................................... 94 
DOCUMENTOS VINCULADOS AO PLANEJAMENTO DA QUALIDADE ......................................... 98 
RETROSPECTIVA DO MÓDULO .................................................................................................... 101 
 
 
MÓDULO VI – ACOMPANHAMENTO, VALIDAÇÃO DOS REQUISITOS, ACEITAÇÃO DAS ENTREGAS 
E CONTROLE DO ESCOPO ................................................................................................................. 103 
ACOMPANHAMENTO DO ESCOPO E VALIDAÇÃO DOS REQUISITOS ..................................... 104 
ACEITAÇÃO DAS ENTREGAS ......................................................................................................... 108 
CONTROLE DO ESCOPO ............................................................................................................... 110 
RETROSPECTIVA DO MÓDULO .................................................................................................... 112 
MÓDULO VII – GERENCIAMENTO E CONTROLE DA QUALIDADE .................................................. 113 
GERENCIAMENTO DA QUALIDADE ............................................................................................. 114 
Processos integrados e de melhoria contínua ................................................................. 115 
Testes em todos os níveis .................................................................................................... 117 
Estudos/Análises de causa e efeito (ou causa-raiz) .......................................................... 117 
Inspeções ............................................................................................................................... 120 
Cultura customer centric ....................................................................................................... 123 
RELATÓRIO DE EXECUÇÃO DA QUALIDADE .............................................................................. 125 
CONTROLE DA QUALIDADE E RELATÓRIO DO DESEMPENHO DO TRABALHO .................... 127 
RETROSPECTIVA DO MÓDULO .................................................................................................... 132 
BIBLIOGRAFIA .................................................................................................................................... 134 
BIBLIOGRAFIA RECOMENDADA ................................................................................................... 138 
PROFESSOR-AUTOR ........................................................................................................................... 140 
GUILHERME HOFFMANN ............................................................................................................. 140 
Formação acadêmica ........................................................................................................... 140 
Experiências profissionais ................................................................................................... 140 
 
 
 
 
 
Neste módulo, são apresentados os principais conceitos para a compreensão do trabalho de 
gerenciamento do escopo de um projeto. É traçado um cenário histórico para determinar como a 
fixação na busca pela definição de objetivos demonstra-se algo importante para as organizações e os 
indivíduos, notadamente os que desempenham funções relacionadas ao gerenciamento de projetos. 
Na sequência, são demonstradas algumas visões acerca de abordagens de trabalho com o escopo, as 
quais podem servir a diferentes tipos e tamanhos de projetos. Dentre elas, são exibidas a visão do 
Project Management Institute (PMI) sobre os diferentes tipos de ciclos de vida e como a percepção 
do triângulo das restrições se adapta de acordo com a utilização de diferentes abordagens. Além 
disso, os principais conceitos e respectivas importâncias para a compreensão do gerenciamento do 
escopo são apresentados, tais como: visão do produto; funcionalidade; diferença entre critério de 
aceitação e critério de validação; e, a diferença entre escopo do produto e escopo do projeto.Por 
fim, são ilustradas as principais etapas envolvidas no gerenciamento do escopo e a sua conexão com 
o momento do nascimento de um projeto, assim como as possíveis direções para a sequência natural 
dos trabalhos que visam a um correto gerenciamento do escopo de um projeto. 
 
Conceito histórico 
Gerenciar projetos é uma arte, muitas vezes silenciosa, que existe há décadas. Desde que os 
indivíduos começaram a perceber a importância de um método para o melhor encadeamento das 
ações de trabalho nas suas respectivas organizações, mais se pôde 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 o pai da 
administração moderna demonstrava que nada se faz sem uma visão sistêmica de conjunto, de 
preferência, visando sempre a um mesmo objetivo. 
MÓDULO I – INTRODUÇÃO E CONCEITOS 
FUNDAMENTAIS DO ESCOPO 
 
12 
 
Com o mundo dos negócios em ebulição, após um momento histórico vivido pelo período 
de duas grandes guerras mundiais, a transformação se inicia exatamente por meio de um 
questionamento 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). 
A 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; estipulam-se 
objetivos e são traçadas formas de monitoramento; responsabilidades são delegadas; e, 
constantemente, comparam-se os resultados em relação ao planejamento que havia sido previamente 
estabelecido, no sentido de gerar um senso de aferição de resultados. Também há necessidade de 
delimitar objetivos de curto (operacionais), médio (táticos) e longo (estratégicos) prazos. 
Não à toa, aproveitando o êxito da definição de APO, o conceito de gerenciamento de 
projetos nasceu nos Estados Unidos ao final dos anos 1950, quando inicialmente era aplicado 
apenas a análises 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 na década de 80. Mesmo período em que George Doran (1981), 
aprimorando os trabalhos de Edwin Locke (1968), reconheceu que muitas organizações tentavam 
estipular metas/objetivos, mas muitas vezes estes eram estabelecidos de maneiras difusas. 
Objetivos não deveriam ser tratados como inarticulados – aqui, percebe-se uma pitada do 
conceito inicial de Drucker – em vez disso, deveriam ser tratados como mensuráveis, no intuito de 
alavancar o sucesso da organização. Então, uma 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 português, específico); M 
de mensurável; A de atingível; R de relevante; e T de tempo limite. Ao adotar que um objetivo 
precisaria possuir todas essas cinco propriedades em conjunto, e não apenas uma ou outra, Doran 
conseguiu reforçar o modelo APO e solidificar o conceito do estabelecimento de metas/objetivos 
em muitas organizações, suportado por meio de uma técnica simples, e que ainda possui uma 
aplicabilidade bastante atual. 
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 indivíduos 
pudessem reconhecer que o foco de um projeto nunca poderá ser negligenciado. Quanto mais se 
aprende e se compreende o objetivo a ser alcançado, maior é a chance de se conquistar o sucesso 
em uma empreitada. 
Junto a tudo isso, faz-se mister também destacar a evolução do movimento lean (gestão 
enxuta, em português), que vem a ser uma filosofia/metodologia centrada no cliente e utilizada para 
a melhoria contínua de qualquer processo por meio da eliminação de desperdícios em tudo o que 
se faz. Os dois principais pilares do lean são o melhoramento incremental contínuo e o respeito 
 
 
 13 
 
pelas pessoas. Os princípios básicos trabalham com foco na entrega efetiva de valor ao cliente; 
respeito e engajamento das pessoas; melhora no fluxo de valor por meio da eliminação de todos os 
tipos de desperdício; manutenção do fluxo de trabalho; e, a busca da perfeição. 
Para que uma empresa consiga atender a esses princípios, uma cultura organizacional é 
fundamental. Os líderes lean precisam influenciar diariamente os comportamentos dos indivíduos 
de uma organização para que a proliferação da adoção do mindset (modelo mental) seja eficaz. 
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. Continuaremos exatamente nesse caminho para nos aprofundarmos em nossos estudos. 
 
Escopo e os ciclos de vida de um projeto 
De acordo com o PMI (2017b), existem quatro tipos de ciclos de vida 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 processos sequenciais, nem sempre cartesianos. 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, de tempos em tempos, 
algum tipo de retorno por parte dos principais stakeholders engajados no projeto. Os 
feedbacks são recebidos pelo time do projeto sobre trabalhos ainda não finalizados, no 
intuito de que se melhore o produto, o serviço ou a condição a ser gerada e de que se 
consiga adaptá-los antes da 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 capacidade plena; 
 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 que se aprenda com a versão disponibilizada, para que ela seja 
analisada e melhorada. 
 
 
 
14 
 
Figura 1 – Continuidade dos ciclos de vida 
 
Fonte: adaptado de PMI (2017b). 
 
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, com riscos relativamente fáceis 
de serem gerenciados. 
No ciclo iterativo, há possibilidade de feedbacks sobre trabalhos parcialmente concluídos, 
visando à melhoria contínua e a modificações constantes, amenizando incertezasou erros naturais 
decorrentes de um planejamento incompleto ou incorreto, por exemplo. Já no ciclo de vida 
incremental, o foco encontra-se nas entregas potencialmente escalonáveis, com o cliente ou o usuário 
final tendo a possibilidade de aproveitamento imediato do produto, serviço ou condição, entregue 
em uma versão inacabada. Testes e ajustes são praticamente imediatos. 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, como transparência de processos, confiança 
e engajamento entre time do projeto e cliente, ou usuário final, adotando o foco de priorização das 
funcionalidades (veja o significado desse conceito no próximo capítulo) mais importantes, as quais 
geram mais valor às principais partes envolvidas. 
 
 
 15 
 
O grande argumento para a utilização desse tipo de ciclo de vida reside na questão estratégica, 
pois a visualização do return on investment (ROI) (retorno sobre o investimento, em português) será 
mais cedo do que em outros ciclos de vida, facilitando processos 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 do desenvolvimento de um produto, serviço ou 
condição, 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 da criação do que é hoje conhecido como abordagem híbrida. 
Uma abordagem híbrida é facilmente identificada por características de adaptabilidade, já 
que o time do projeto se vê diante da possibilidade de misturar e combinar quaisquer elementos de 
diferentes ciclos de vida que forem necessários para melhor atender necessidades, sejam as da equipe 
do projeto, as do cliente ou as da organização. 
Apenas para citar uma das muitas possibilidades em utilizar uma abordagem híbrida em 
um projeto, imagine como uma abordagem ágil pode auxiliar em uma entrega mais rápida, 
atendendo a requisitos inseridos em um ambiente de mudanças constantes. Agora, considere 
que, em uma abordagem preditiva, usualmente, você possui planos e estruturas claros e 
eficientes para auxiliar o gerenciamento do projeto. Ter o melhor de dois mundos na palma da 
sua mão poderá trazer vantagens competitivas e aumentar as chances de sucesso do projeto. 
Para muitos gestores, é uma maneira de manter a sua equipe cada vez mais motivada, 
desenvolvendo um entendimento mútuo, por meio de uma abordagem (muitas vezes) exclusiva, 
durante todo o trabalho ou em um momento específico do projeto. Além disso, detalhes 
vinculados ao escopo ficarão mais claros no momento do planejamento (por exemplo, refletidos 
nas estruturas analíticas do projeto – EAP), pois determinados pacotes de trabalho possuirão 
contornos de acordo com a abordagem selecionada, demonstrando diferentes níveis de 
adaptabilidade. Estudaremos esses conceitos um pouco mais à frente no nosso material, nos 
capítulos que tratarão do tema “planejamento do escopo”. 
Sem nos restringirmos a números de exemplos, pois, afinal de contas, não existem regras 
para combinação de abordagens de ciclos de vida de um projeto, mas apenas para ilustrar melhor 
o tópico, podemos apresentar algumas das utilizações de abordagens híbridas, por meio da 
próxima figura. 
 
 
 
16 
 
Figura 2 – Exemplos de abordagens híbridas 
 
 Fonte: adaptado de PMI (2017b). 
 
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 reside 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, mas com grau de adaptabilidade 
satisfatório para continuamente reconhecer onde e quando entregar valor, que precisa ser 
percebido pelo cliente ou usuário final. Esse é 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 um novo 
tipo de caneta esferográfica. Como principais solicitações, determinou as características quanto ao 
peso, ao tipo de material, às medidas, à cor etc. Porém, quando solicitou o produto, no primeiro 
momento, ele também possuía o desejo de que a caneta tivesse uma luz fraca intermitente que seria 
emitida no momento em que ela estivesse em utilização. 
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 de papel e, que a função secundária, ou com 
menor proposta de entrega de valor, seria a existência de uma espécie de luz intermitente. 
 
 
 17 
 
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 receber as principais características que a habilitam a 
desempenhar os objetivos (funções de negócio), não é difícil um cliente abdicar de determinadas 
condições por já verificar que a principal funcionalidade desejada para o produto está performando 
conforme o desejado. Portanto, é plenamente possível que, em determinado momento do projeto, 
esse cliente desista da ideia da luz intermitente 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 mas como variável ou estimado. 
A próxima figura demonstra que, com a utilização de parâmetros de fixação de escopo 
(triângulo da esquerda), 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. É comum, em determinados segmentos, escutar que o 
ideal para um projeto é entregar apenas o que 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 (triângulo da direita), 
o foco então passa a ser outro, e isso permite que, dessa vez, o escopo flutue, deixando as restrições 
para as áreas de custos e de cronograma. 
 
Figura 3 – Triângulo invertido das restrições 
 
Fonte: adaptado de SERPA (2016). 
 
É possível afirmar que 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 cliente ou usuário final, a tendência é que as 
principais partes interessadas fiquem satisfeitas. Já em uma proposta de 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, e o que tiver 
sido desenvolvido durante um timebox de dois meses será então o resultado final do projeto. 
 
18 
 
É 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 se demonstra voltado 
para a proposta de entrega de valor, comumente, escuta-se o termo escopo aberto. Independentemente 
da maneira como se denominam as diferentes abordagens em cada organização, o importante é sempre 
conseguir identificarcomo é tratado o assunto escopo dentro da estratégia de condução de cada projeto. 
Como pudemos perceber, ambas as possibilidades são boas e têm 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 no qual 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 execução dos processos inerentes 
à conduçã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 possua a força necessária para a 
produção do desempenho esperado. 
 
Conceitos importantes: visão do produto (ou do serviço), 
funcionalidades, critérios de aceitação e critérios de 
validação 
A grande beleza do gerenciamento profissional de projetos é não se prender a modelos 
específicos e permitir que organizações e equipes fiquem sempre à vontade para adaptarem o que 
for necessário para as próprias necessidades (ou necessidades do projeto em si), 
independentemente de porte ou de tipo. Atualmente, muito do que é tratado como métodos ou 
frameworks aplicáveis em diversos segmentos de mercado, como indústria, construção civil, saúde, 
grandes eventos, entre muitos outros, foi concebido nos trabalhos de engenharia de software. 
Afinal de contas, comumente, esse segmento lida com projetos de altíssimo grau de complexidade, 
processos pesados, apoiados pela integração de muitas ferramentas e técnicas específicas. É 
também verdade que, nem sempre, outros setores tiveram a necessidade de administrar os 
trabalhos por meio de um gerenciamento profissional de projetos (raras exceções, apenas para 
citar um exemplo do passado, alguns projetos militares). Com a natural popularização do 
gerenciamento de projetos, muito do que se vê hoje é derivado desses primeiros esforços da área 
de tecnologia da informação. No entanto, as versões adaptadas de métodos e frameworks estão, 
muitas delas, plenamente alinhadas aos novos segmentos, desvinculando-se daquela linguagem 
técnica de software que dominou e caracterizou o mercado durante muitos anos. 
 
 
 19 
 
A questão atual, no entanto, é apenas uma: um bom trabalho do gerenciamento do escopo 
inicia com um trabalho de qualidade no que tange à definição da visão do produto. Não há 
necessidade de se compreender perfeitamente o escopo do produto no início do projeto, mas aquilo 
que ele pretende ser (ou, de preferência, resolver), sendo que as técnicas para a geração da visão do 
produto permitem compreender melhor a razão de existir da necessidade ou da oportunidade que 
gerou a ideia do projeto em si. 
Cruz (2015, p. 68) propõe uma pergunta inicial de grande relevância para que a definição da 
visão do produto não se perca ao longo dos trabalhos da equipe do projeto e possa, ao mesmo tempo, 
preocupar-se com os viéses da qualidade: “Como podemos transformar a visão do produto em um 
produto real da melhor maneira possível?”. Aliadas a tal desafio, muitas técnicas associadas a métodos 
de design thinking, por exemplo, podem auxiliar o desenvolvimento da visão do produto. São cada vez 
mais frequentes, equipes debruçando-se em trabalhos de criação de personas, jornadas de usuário, mapas 
de empatia, técnicas de pitch, épicos e histórias de usuário (epics e user stories), storyboard, prototipagem 
e análise SWOT (para melhor compreender a estratégia do produto), dentre muitas infinidades 
possíveis. A intenção não é destrinchar todas elas, mas demonstrar a essência do que seria um correto 
trabalho de definição de visão do produto. 
Segundo o Chaos Report (STANDISH GROUP, 2018, on-line), relatório que realiza um 
trabalho de pesquisa consistente com o foco em taxas de sucesso/falha em projetos, define-se que 
uma visão do produto simples auxilia na entrega de um escopo, pela sua vez, também simples. Uma 
pergunta comumente realizada é “[...] com que frequência você [ usuário ] realmente utiliza [ um 
determinado recurso ] de [ um determinado produto ]?”. O resultado é simplesmente assustador, 
pois 50% dos entrevistados dizem quase nunca, 30% dizem pouco frequente e apenas 20% 
frequentemente. Ou seja, muito se gasta em termos de tempo e de esforços para a realização de 
determinados detalhes que dificilmente serão notados, quiçá utilizados, em diversos produtos. Na 
prática, tais informações poderiam ser utilizadas para evitar custos e melhorar a produtividade da 
equipe do projeto, pois quanto maiores forem os objetivos atrelados ao produto, maior será o grau 
de complexidade da sua realização, com possibilidade alta de incorrerem variáveis não antevistas, 
aumentando significativamente o número de potenciais riscos. 
 Para isso, vamos conhecer técnicas simples de definição de uma visão de produto (ou de 
serviço) que poderão ser adaptadas a qualquer projeto, como a técnica utilizada pelo modelo lean, 
desenvolvida por Moore (1999). 
 
 
 
20 
 
Figura 4 – Visão de produto lean 
Para [ cliente / usuário final ] 
que [ problema que precisa ser resolvido ]. 
 
O / A [ nome do produto/serviço ] 
é [ tipo ou categoria de produto/serviço ] 
que [ benefício-chave/razão para ser criado ] 
diferente de/da [ situação atual ], 
pois nosso produto/serviço terá [ diferenças-chaves ]. 
Fonte: adaptado de MOORE (1999). 
 
Um exemplo prático é o que aconteceu em uma empresa do setor de energia, que, por meio do 
recém-criado departamento de inovação, realizou uma pesquisa anônima com uma parcela 
significativa de funcionários e pode constatar que as chefias médias da organização tinham por hábito, 
por diferentes motivos (insegurança, cultura organizacional, falta de incentivo etc.), vetar 
sumariamente iniciativas oriundas de ideias de funcionários. Portanto, surgiu o conceito de uma caixa 
de sugestões, carinhosamente apelidada de caixa de ideias, anônima, a qual viria a ser posicionada em 
locais de passagem, considerados como estratégicos. A visão do produto ficou então assim: 
 
Figura 5 – Visão de produto do projeto Caixa de Ideias 
Para [ qualquer colaborador da empresa XPTO ] 
Que [ não consegue se fazer ouvir por sua chefia ]. 
 
A [ caixa de ideias ] 
é [ um depositário para sugestões anônimas ] 
que [ serão avaliadas pelos integrantes da área de inovação ] 
diferente da [ barreira criada por chefes muito ocupados ], 
pois nosso produto/serviço terá [ a possibilidade de implementação de boas ideias que 
servirão para uma melhor qualidade de trabalho a todos, ou ao menos para uma grande 
parcela de nossos colaboradores ]. 
Fonte: elaborada pelo autor. 
 
 
 
 21 
 
A caixa de ideias foi o primeiro projeto da nova área de inovação da empresa. Um setor que 
começou com uma pessoa (a famosa EUquipe) e, até a última vez que se teve conhecimento, já 
contava com um grupo de sete pessoas. O projeto da caixa de ideias foi um verdadeiro sucesso, 
apesar de ter sido algo que, inicialmente, gerou uma grande desconfiança. Isso era algo esperado, 
haja vista o tipo de cultura organizacional existente, a qual precisava sofrer algum tipo de 
provocação. A partir do momento em que as primeiras ideias começaram a surgir e a área de 
inovação começou a dar retorno sobre as iniciativas, o burburinho cresceu, propiciando muitas 
novas ideias. O curioso é que, na maioria das vezes, as sugestões requeriam implementações simples 
(projetos de reciclagem, dressing code para o período de verão, banheiros para visitantes com música 
ambiente etc.) e com alto impacto; em outras, requeriam apenas alguns ajustesde situações já 
existentes, como a extensão do horário de funcionamento da cantina. Ou seja, a caixa de ideias foi 
somente o projeto precursor de muitas outras boas ideias que auxiliaram a disseminar uma melhor 
qualidade do ambiente de trabalho, muitas gerando efeitos imediatos, com baixo custo (ou quase 
nenhum) de implementação e ainda promovendo mudanças positivas na cultura organizacional. 
Outra técnica que auxilia a caracterização de uma boa visão do produto, a qual permite um 
melhor grau de compreensão de futuras condições que o produto, o serviço ou o resultado a ser 
gerado precisará ter para que a solução possa ser implementada, está em uma das fases de 
desenvolvimento da visão do produto, demonstrada pela metodologia lean inception (CAROLLI, 
2015), sendo denominada É / NÃO É / FAZ / NÃO FAZ. De maneira colaborativa, de preferência 
após a equipe do projeto já possuir algum grau de compreensão acerca do que precisa ser realizado 
pelo projeto (aqui cabe um aparte, pois as duas técnicas – de Moore e de Carolli – trabalham muito 
bem quando complementadas, em que esforços somados auxiliam em uma melhor percepção do 
produto ou serviço), utiliza-se um quadro branco ou folha de papel para que a equipe possa 
responder às seguintes perguntas: 
 
Figura 6 – Técnica É / NÃO É / FAZ / NÃO FAZ 
O que o produto/serviço É? 
O que o produto/serviço NÃO É? 
O que o produto/serviço FAZ? 
O que o produto/serviço NÃO FAZ? 
Fonte: adaptado de CAROLLI (2015). 
 
Em termos práticos, vamos utilizar o mesmo exemplo do projeto caixa de ideias, para que 
sejam preenchidas as informações apresentadas por essa nova técnica. 
 
 
22 
 
Poderíamos dizer que a caixa de ideias é um artefato de madeira, fechada por meio de um 
cadeado, que pode ser pendurada por meio de ganchos em uma parede, com pequenas dimensões 
suficientes para comportar uma quantidade significativa de sugestões/ideias, semelhante a uma urna, 
na qual haverá um orifício para serem depositadas as sugestões/ideias, de preferência com uma caneta 
(ou algo do gênero) e pedaços de papel disponíveis em conjunto, para imediata utilização. Pode não 
ser o melhor formato possível para a implementação do produto em si, mas o que importa nessa 
técnica é permitir que outras pessoas compartilhem a visão de produto (aquilo que o produto precisa 
parecer, mesmo que seja apenas a sua primeira versão), para que haja um consenso naquilo que precisa 
ser realizado no sentido de o produto ganhar vida. Por sua vez, a caixa de ideias não é um depositório 
para reclamações, não é um depositório para lixo, não é uma brincadeira e não é uma atitude para 
constranger pessoas, pois trata-se de um movimento voluntário. A partir dessas novas definições que 
representam o seu não escopo, a caixa de ideias pode ser melhor compreendida. Ela precisará 
demonstrar, pela forma ou por meio de alguma(s) ferramenta(s) de comunicação/conscientização, o 
verdadeiro propósito, assim como os limites de utilização, evitando assim interpretações equivocadas 
sobre o conceito do produto. Ao avaliar seus objetivos, define-se que a caixa de ideias faz o 
recolhimento de sugestões/ideias de todos os colaboradores que desejarem compartilhar 
sugestões/ideias e que, por qualquer razão, sentiam-se constrangidos para fazê-lo. 
Além disso, o artefato permite que tais sugestões/ideias possam ser apresentadas de uma 
maneira simples, anônima e sem necessidade de justificativas grandiosas, facilitando a perpetuação 
de percepções de melhoria que, potencialmente, poderão ser realizadas em qualquer ambiente da 
empresa. A documentação das ideias recebidas ou as futuras análises e a divulgação (transparência) 
de resultados seriam detalhes da operação por trás da ideia do produto, cujo detalhamento não vem 
ao caso neste momento. No entanto, por já ter participado da implementação de dezenas de 
produtos/serviços por meio desse tipo de técnica de visão do produto, sugerimos que, durante o 
momento colaborativo de preenchimento dessas respostas, não se deva excluir nada e os registros 
de quaisquer insights, mesmo que não convenientes no momento, sejam realizados. Uma boa opção 
é registrar os trabalhos, por meio de uma gravação de áudio, por exemplo. São detalhes que poderão 
ser úteis no futuro. O que a caixa de ideias não faz poderia ser algo, como: não se responsabiliza 
pela implementação da ideia apresentada (há necessidade de uma avaliação posterior). Pronto! 
Mesmo tendo uma boa visualização do que poderia ter sido a visão do produto com a utilização do 
modelo lean, o trabalho da equipe foi complementado por meio dessa segunda técnica, e as chances 
de sucesso da idealização do futuro produto aumentaram consideravelmente, pois o grau de 
percepção acerca do que ele deverá ser também foi, consideravelmente, aumentado. 
Por fim, resta dizer que, por se tratar de um trabalho colaborativo, é importante que seja 
realizado em condições prazerosas, para que a equipe do projeto possa fazer fluir a criatividade e o 
pensamento crítico, não se privando de demonstrar qualquer viés que possa ser transformado em 
um insight ou, ao mesmo tempo, ser registrado como um potencial item/problema/impedimento a 
ser observado e, posteriormente, avaliado. Quanto mais tempo a equipe dispuser para descrever tais 
detalhes, mais rica será a visão do produto. 
 
 
 23 
 
Outro termo muito comum no momento de conduzir o trabalho do escopo ao longo de um 
projeto é funcionalidade. Uma funcionalidade é algo passível de execução, ou seja, algo definido 
como um comportamento ou até mesmo uma ação, delimitado por um período (caixa) de tempo 
– timebox –, presumindo que exista um momento de início para a sua execução e um momento de 
fim, claramente definidos. Em nosso ambiente virtual existem exemplos práticos de como definir 
uma funcionalidade e alinhá-la com o trabalho de gestão do escopo. 
As funcionalidades são determinadas junto com a definição do escopo do produto e do 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 de um substantivo. Você terá oportunidade de compreender 
melhor o conceito de funcionalidade, suas utilizações e a sua correlação com as users stories (histórias 
de usuário), em nosso ambiente virtual, notadamente, nos estudos da unidade 3, do módulo 1. 
É um trabalho que exige do time do projeto um grau de atenção redobrado, pois um início 
mal estruturado poderá ser desastroso quando o projeto evoluir e as implicações de um trabalho do 
escopo desestruturado começarem a influenciar os trabalhos das demais temáticas de um projeto, 
por exemplo, cronograma, recursos, qualidade etc. 
Naturalmente, como trabalharemos os assuntos do escopo e da qualidade ao longo da 
disciplina, cabe aqui um aparte para diferenciar dois conceitos que são comumente confundidos e 
que são também considerados de extrema importância para o sucesso do projeto: critério de 
validação e critério de aceitação. O primeiro trata de garantir que a condição ou a característica 
desejada seja efetivamente cumprida (um trabalho realizado pelo time de qualidade do projeto); 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, que, pela sua vez, é função do time de escopo 
do projeto. Aqui pode-se perceber a forte dependência em relação aos trabalhos do escopo e da 
qualidade, pois, enquanto um atesta a veracidade ou a precisão das funcionalidades, o outro recebe 
essas informações e promove, essencialmente, a entrega dessas funcionalidades. 
Em termos práticos, e de uma maneira bem simples, digamos que um determinado projeto 
seja construir uma ponte com 50 metros de comprimento, 2 metros de altura, além de dois pilares 
de sustentação. Como validar que a ponte, após pronta, possua realmente 50 metros de 
comprimento? Existem diversas maneiras de se fazer isso, desde processos simples e com baixíssimo 
graude exatidão, como técnicas de observação, ou processos mais complexos e com elevados graus 
de exatidão, como medições com instrumentos aferidores e de precisão. A questão não é fazer juízo 
de valor se o critério de validação é bom ou ruim, mas que exista um ou mais critérios, conforme 
as múltiplas variáveis vinculadas ao projeto permitirem. 
Logicamente, quanto mais preciso (s) e objetivo (s) for (em) o (s) critério (s), maiores as 
chances de garantir que o produto será 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. 
 
24 
 
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), em que ocorre a entrega final 
do produto, do serviço ou da condição gerados. 
 
Diferença entre escopo do projeto e escopo do produto 
Segundo o PMI (2017a), o termo escopo pode ser utilizado, no 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 (condição); 
 escopo do projeto – o trabalho realizado para entregar um produto, serviço ou resultado 
(condição) 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 
propriedades, no intuito de entregar uma versão final, de acordo com o que é esperado pelo cliente 
do projeto ou pelo usuário final, conforme definido (ou a ser definido) no momento da visão do 
produto. Já em relação ao escopo do projeto, depois de o time 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. De uma maneira bem resumida, mas que serve ao propósito de melhorar a compreensão 
desse tópico, observe a próxima figura. 
 
 
 
 
 25 
 
Figura 7 – Escopo do projeto versus escopo do produto 
 
Fonte: elaborada pelo autor. 
 
É nítido então que o trabalho maior, inerente aos esforços de gerenciamento do escopo do 
projeto e todas as suas complexidades, estará vinculado a uma visão macro, enquanto os esforços de 
trabalho vinculados ao escopo do produto serão específicos das características e das condições 
necessárias à idealização e à transformação em realidade do produto em si. Ambas as visões de gestão 
do escopo são complementares e caminham lado a lado durante a execução do projeto. 
Na prática, como perceber melhor essa diferença? Vamos utilizar como exemplo um projeto 
fictício de lançamento de 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 plataforma virtual a 
ser adotado, dentre outras características. Já o escopo do projeto seria definir como conseguir as 
licenças necessárias para registrar o curso em órgãos competentes, contratar mão de obra, alugar 
servidores de internet etc. Apenas para corroborar alguns ensinamentos da unidade anterior, 
algumas funcionalidades possíveis seriam: desenvolver conteúdo, estruturar trilha do curso e definir 
pré-requisitos para participação. 
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. 
 
 
26 
 
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 na metodologia 
proposta pelo PMI. Um escopo precisa ser extremamente bem definido e, mais ainda, bem 
controlado. Todo o restante do projeto depende disso. O gerenciamento do escopo possui o dom 
de potencialmente influenciar todos os demais temas pertinentes a um projeto, seja uma questão 
relacionada a budget ou a trabalhos que visam à manutenção e à melhoria da qualidade de processos 
organizacionais internos, por exemplo. 
Sendo assim, um correto 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 interessadas. 
No entanto, 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 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). 
 
Sugerido como primeiro documento do projeto, o TAP (ou qualquer outro documento que 
possa substituir essa função, por exemplo, um sumário executivo) representa o esforço inicial do 
time do projeto – o qual, provavelmente, ainda não estará plenamente definido – 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. Além disso, o documento deve 
chancelar 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. É altamente recomendado que o TAP também 
demonstre o grau de compromisso da organização com o trabalho que será desempenhado. 
 
 
 
 27 
 
Além disso, 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 uma implementação formal de um 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. Na maioria das vezes, o TAP vem recheado de anexos contendo valiosos 
documentos pré-projeto, como pesquisas de mercado ou estudos de viabilidade técnica. Dependendo 
do grau de importância e de investimento do projeto, entre outros fatores, é comum por exemplo, a 
realização de pré-projetos ou projetos-base para investigar melhor possíveis condições futuras. 
É 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. 
O PMI (2017a, p. 117) preconiza que “[...] ele documenta informaçõesde alto nível sobre o 
projeto e sobre o produto, serviço ou resultado que o projeto deve satisfazer” e, exatamente por 
causa 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; sendo uma importante fonte de informações 
para um futuro trabalho de especificação do escopo. 
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 responsável 
na elaboração desse artefato. 
 
 
 
28 
 
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, os 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 a um planejamento completo do projeto, 
permitindo a sua posterior execução, e é seguro afirmar que uma das etapas iniciais desse planejamento 
trata, exatamente, do planejamento do escopo, 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. 
A integração do escopo com os demais temas, provenientes de um bom trabalho de 
gerenciamento de projetos, é essencial, pois, a partir do momento em que as 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 demais 
processos serão realizados. Mesmo que não haja uma versão final do planejamento do escopo, essas 
informações já geram energia suficiente para que os requisitos possam começar a ser coletados, 
documentados, analisados e priorizados. É possível que haja a necessidade de a equipe do projeto 
confeccionar alguns 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). 
Uma visão mais detalhada a respeito do planejamento do escopo, de como se dá a 
especificação de um escopo, da execução dos trabalhos e de maneiras eficazes de monitoramento e 
controle serão fornecidas nas próximas unidades. 
 
 
 29 
 
Retrospectiva do módulo 
O módulo I iniciou a sua trajetória trazendo a evolução histórica do escopo. Desde as 
primeiras abordagens vinculadas a Peter Drucker e o conceito de Administração por Objetivos 
(APO), passando pela visão lean e a necessidade de evolução para uma melhor definição e 
mensuração de objetivos, até chegarmos à atualidade e à massiva importância destinada a esse 
conceito por meio das principais associações de gerenciamento de projetos do mundo. 
Foram demonstrados diferentes tipos de abordagens responsáveis por definir como o escopo 
será trabalhado ao longo de um projeto. Pudemos visualizar que o tratamento destinado ao escopo 
precisa ser determinado no momento de avaliar o tipo de ciclo de vida do projeto. 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, em 
que 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 constante entrega de valor. 
Na sequência, tratamos da visão do produto, condição fundamental para a equipe do projeto 
perceber como lidar com o que está por vir, ou seja, aquilo que precisa ser realizado/entregue para 
o seu cliente/usuário final. Também avaliamos os conceitos de funcionalidade, assim como a 
diferença entre critério de aceitação (vinculado aos trabalhos do time do escopo) e critério de 
validação (vinculado aos trabalhos do time da qualidade), termos extremamente importantes, os 
quais ainda 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. 
Por fim, adentramos em uma visão geral de como é esperado um trabalho por etapas do 
gerenciamento do escopo do projeto, em que primeiro foi verificado o que é essencial para que um 
projeto possa ser formalmente iniciado, os esforços de uma fase pré-projeto e um possível documento 
que dá origem ao projeto: o Termo de Abertura do Projeto (TAP). Não só foram ilustrados detalhes 
envolvidos para o nascimento de um projeto como também foi demonstrado o princípio dos trabalhos 
com as possíveis etapas do gerenciamento do escopo, em que a parceria com equipes da qualidade 
será fundamental para o sucesso do bom trabalho do escopo, ao longo do projeto. 
 
E para avaliar o seu nível de conhecimento até aqui, verifique se consegue responder, 
corretamente (e com suas próprias palavras), as seguintes perguntas: 
1. Consegue enumerar e explicar os diferentes ciclos de vida de um projeto? 
2. Qual a importância de definir corretamente a visão de um produto, serviço ou 
resultado desejado? 
3. Qual a diferença, na prática, entre escopo do projeto e escopo do produto? 
 
 
30 
 
 
 
 
 
Neste módulo, são apresentados os principais conceitos para a compreensão do trabalho de 
gerenciamento da qualidade em um projeto. A introdução se dá por um apurado histórico para 
determinar como o conceito de qualidade nasceu e evoluiu ao ponto de as organizações começarem 
a desenvolver enormes esforços em busca de um padrão de excelência da qualidade, com foco em 
agradar cada vez mais o seu cliente/usuário final. Logo a seguir, serão demonstradas as diferenças 
entre qualidade de negócio e qualidade técnica, assim como serão apresentados os principais conceitos 
para o trabalho da qualidade ao longo da disciplina, por exemplo: processos, produtividade, 
eficiência, eficácia, defeitos, custos da não qualidade e desperdícios (por meio da visão dos 3 Ms). 
Os conceitos de inspeção, tolerância, prevenção, avaliação e limites de controle também são 
apresentados, com o objetivo de conseguirmos avaliar melhor o que significa o custo da qualidade 
(contraponto às ideias da não qualidade) e a sua influência para muitos momentos de tomada de 
decisão ao longo do ciclo de vida do projeto. Por fim, trataremos de um dos assuntos mais 
destacados atualmente no trabalho de gerenciamento da qualidade: como implementar processos 
ou a cultura de melhoriacontínua, em equipes/organizações de projetos. Para isso, são 
demonstrados três métodos/ferramentas que poderão auxiliar nesse tipo de processo: método do 
ciclo PDCA, técnica dos 5 whys e rituais de retrospectivas. 
 
Conceito histórico 
O formato pelo qual muitas civilizações antigas realizavam atos de comércio era o escambo, 
ou seja, uma espécie de acordo em que havia uma relação direta de troca, em que cada uma das 
partes entregava um produto ou prestava um serviço, para receber algum tipo de compensação. 
A evolução natural desse modelo foi o surgimento do dinheiro, que visava à padronização em 
MÓDULO II – INTRODUÇÃO E CONCEITOS 
FUNDAMENTAIS DA QUALIDADE 
 
32 
 
uma unidade única (ou mais conhecida/confiável pela maioria das pessoas) como referência para 
uma espécie de pagamento, em vez da dependência de um processo de escambo por coisas 
distintas. No entanto, muito antes do surgimento do dinheiro, e com a evolução natural de 
materiais e técnicas na construção das primeiras ferramentas que tinham o objetivo de produzir 
alimentos (e a necessidade dos seus aprimoramentos contínuos), teve início o estímulo por uma 
valorização crescente dos componentes e da usabilidade desses artefatos – surgia então a essência 
do reconhecimento da qualidade. 
O aumento do comércio e a ampliação das tecnologias de manufatura geraram oportunidades 
para as bases da produção em série e, com ela, a necessidade do descarte de produtos defeituosos, 
especialmente nas indústrias naval e bélica, nas quais se iniciou o controle da qualidade baseado na 
inspeção do produto final (JURAN; GODFREY, 1999), um método bom para a época, mas 
demasiadamente caro e muito trabalhoso. O controle do trabalho por etapas, instituindo a distinção 
dos processos e das responsabilidades entre o que deveria ser produzido e o momento da produção, 
estabeleceu uma importante evolução e a base do esforço da tentativa de garantir um determinado 
padrão de qualidade (DEMING, 1990). Na sequência do período histórico ocasionado pela 
Revolução Industrial, que pela sua vez foi responsável por aumentar exponencialmente a capacidade 
de produção e, consequentemente, a dificuldade de controlar a qualidade dos produtos 
manufaturados, surgiu o conceito de inspeção por amostragem, oriundo do segmento da construção 
civil, cuja evolução apontou para a implementação de controles estatísticos de produção, 
fundamentais para o reconhecimento formal do aumento dos custos ocasionados pela falta de um 
padrão de qualidade. 
O reequilíbrio das atividades comerciais após o período das duas grandes guerras, na primeira 
metade do século XX, gerou as condições de ampliação da participação e da exigência crescentes 
dos consumidores, movimento que culminou, ao final da década de 1960, com a implementação 
da gerência da qualidade em muitas organizações, enfatizando a busca pela melhoria dos seus 
produtos por meio da compreensão acerca da opinião dos próprios consumidores/usuários finais. 
No entanto, um pouco antes disso, Philip Crosby já era um dos primeiros profissionais que 
associavam requisitos pré-estabelecidos, gerando um padrão objetivo de referência, a conceitos de 
qualidade. Crosby foi um dos responsáveis por migrar a visão da qualidade de algo simplesmente 
tido como bom para algo que pudesse ser tratado como investimento. Além disso, defendeu 
conceitos de defeito zero, padrões estipulados para gerar aumento de satisfação dos consumidores 
(atender necessidades), eliminação de retrabalho (conceito de fazer certo logo na primeira vez) e que 
qualidade devia ser responsabilidade da alta direção de uma organização e, pela sua vez, transmitida 
com bons exemplos. 
Já ao longo da década de 1970, a disciplinada e emergente economia japonesa aprimorou as 
práticas de gestão empresarial ocidentais e mudou o paradigma da sua linha de produção, que até 
então era conhecida por produtos baratos e pouco duráveis, integrando conceitos como manufatura 
lean, sistemas de produção just-in-time, heijunka (método de nivelamento de produção), entre 
 
 
 33 
 
outras importantes técnicas que ganhavam o mundo junto com um movimento conhecido como 
Total Quality Management (TQM) – Gestão para a Qualidade Total –, transformando a 
responsabilidade da qualidade não só de um departamento ou de um grupo de pessoas, mas de todo 
um complexo sistema de integração entre a postura de um ser humano e a sua capacidade de resolver 
problemas no local e no momento em que eles ocorrem. 
O desenvolvimento econômico alavancado pela acirrada disputa por consumidores cada vez 
mais exigentes estimulou os países a criarem diversas normas de padronização das suas atividades 
comerciais. Esse período marcou o nascimento dos standards – padrões de qualidade – que, em 
um primeiro momento, surgiram por meio da publicação da norma BS-5750, de origem inglesa, 
e logo a seguir, com a ISO (International Organization for Standardization), série 9000, vindo a 
se tornar uma organização internacional de normalização globalmente conhecida. 
Atualmente, não importa fazer o melhor produto com os melhores processos, se o resultado não 
vai ao encontro do ensejo do seu consumidor/usuário final, razão de ser de todos os processos 
organizacionais. Nesse sentido, organizações precisam estar plenamente sintonizadas com os seus 
principais stakeholders, focando na entrega de valor percebido ou na vivência de uma experiência 
diferenciada no que tange à jornada de um potencial usuário em relação ao consumo de um 
determinado produto ou serviço, e ainda, uma demanda cada vez mais crescente de sustentabilidade e 
propósito, ou seja, além do viés de lucro, demonstrar diferentes tipos de responsabilidades e 
preocupações, suportar causas e estarem constantemente presentes para os seus potenciais públicos-alvo. 
 
Qualidade, processos e a relação com produtividade, 
eficiência e eficácia 
Até aqui, temos associado, constantemente, o conceito de qualidade ao valor percebido 
proporcionado por uma entrega, vinculada ao trabalho da equipe de escopo de um projeto. Não à 
toa, RIES (2012, p. 98) menciona que “[...] se não sabemos quem é o cliente, não sabemos o que é 
qualidade”. No entanto, existem duas maneiras distintas de lidar com o conceito de qualidade ao 
longo de um projeto. É fato que quem deve determinar os objetivos de negócio de um determinado 
produto, serviço ou resultado esperado é o cliente (interno ou externo). Isso deixa muitos times de 
projeto em situações inusitadas, pois, por vezes, lidam em demasia com o cliente no início do 
projeto e pouco ao longo da jornada, ou às vezes simplesmente não definem os preceitos que 
deveriam estar atrelados à qualidade, desde o início dos trabalhos. Portanto, a qualidade de negócio 
deve sempre vir do cliente. Caso o cliente, por qualquer razão que seja, não puder ou não fizer isso, 
cabe ao time do projeto definir tais detalhes de alguma maneira e, minimamente, chancelar tais 
ideias com o cliente. Tal ação é fundamental para alinhar o atendimento de expectativas (um tema 
também muito visado no que tange à gestão dos stakeholders) com aquilo que vem sendo 
desenvolvido pela equipe do projeto. 
 
34 
 
Existe também a preocupação com a qualidade vinculada aos processos e ao modus operandi 
do time do projeto, conhecida pelo termo de qualidade técnica – fator que, por muitas vezes, difere 
produtos que poderiam ser considerados similares, mas que se distinguem por detalhes que são de 
exclusiva responsabilidade do time do projeto –, refletindo nos esforços para conduzir a execução 
do projeto, conforme critérios pré-estabelecidos. 
É exatamente no momento em que destrinchamos as diferenças entre qualidade de negócio e 
técnica, que se iniciam os questionamentos sobre as diferenças entre os termos produtividade, 
eficiência e eficácia. Apesar de muitos autores discutirem incessantemente sobre o tema, de uma 
maneira bem simples, poderemos definir os três termos por meio de reflexões vinculadas às 
perguntas descritasno quadro abaixo. 
 
Quadro 2 – Diferença entre produtividade, eficiência e eficácia 
conceito pergunta 
produtividade A equipe do projeto realiza muito trabalho, mas é o trabalho certo? 
eficiência 
O trabalho é realizado com facilidade (menos recursos, tempo, dinheiro 
etc.) mas sem perder o foco em obter o máximo de valor possível? 
eficácia 
A equipe faz o trabalho certo na hora certa. Esse processo/método 
consegue ser repetido, sistematicamente? 
Fonte: elaborado pelo autor. 
 
Imagine o seguinte caso fictício em que a equipe do projeto precisa entregar, por exemplo, 
quatro pacotes de trabalho (ou histórias de usuário), dentro de um determinado ciclo iterativo 
(sprint). Alinhar os esforços corretos de estimativa desses pacotes, com o fiel cumprimento das 
condições dos seus requisitos e validá-los antes do momento da entrega, faz esse trabalho ser 
altamente produtivo. De nada adiantaria entregar três pacotes de trabalho extremamente bem feitos 
se um ainda estivesse em atraso. Isso seria considerado ser eficiente, sem ser produtivo. Portanto, 
também vincular o que foi realizado/feito, apenas para citar alguns exemplos, a critérios como 
redução de esforços, eliminação de desperdícios, melhoria de níveis de satisfação de trabalho, tanto 
em razão de clima organizacional como também de superar as expectativas do cliente, pode servir 
de alavancagem para que um trabalho tido como produtivo (no caso do exemplo: o time ter 
entregado os quatro pacotes) possa também ser considerado eficiente. O básico da eficiência é fazer 
o que é correto, com menos. E, por fim, eficácia significa alinhar tais critérios com o perfeito senso 
de oportunidade (timing), levando ao fiel cumprimento de objetivos, de preferência permitindo que 
tais práticas possam ser repetidas gerando ganho de performance. Tratar corretamente o sentimento 
de eficácia significa dizer que a equipe do projeto produz resultados que correspondem às 
necessidades e aos desejos do ambiente externo. 
 
 
 35 
 
Alguns autores acreditam que produtividade não deve ser considerado o ato de medida final 
do potencial humano. Enquanto muitas técnicas e métodos de gestão profissional de projetos nos 
auxiliam a ser mais produtivos, muito provavelmente, também estão nos auxiliando a ser mais 
eficientes e eficazes. Apenas para citar um breve caso prático, o método Kanban trabalha com o 
conceito de Work in Progress (WIP), em português, algo como trabalho em andamento, que nada 
mais é do que uma prática para melhorar a produtividade ao limitar a capacidade de fluxo de 
trabalho de um determinado time em um determinado momento da execução do projeto, evitando 
que exista sobrecarga. Ou seja, uma maneira de gerenciar gargalos antes de estes se tornarem 
bloqueadores, permitindo que uma equipe desempenhe melhor, mantendo um ritmo de trabalho 
sustentável, sem exceder a sua capacidade. A técnica WIP, pela sua vez, também deixa o time do 
projeto mais eficiente, pois permite a concentração de trabalho naquilo que realmente interessa, 
com uma melhor velocidade de execução. Ou seja, gera impactos positivos na eficiência e melhora 
a produtividade da equipe. A sua repetição, se assimilada corretamente, possui plenas características 
para também deixar o trabalho mais eficaz, afinal de contas, poderá ser repetido com relativa 
redução de esforços. No entanto, se por acaso o time exceder o WIP por alguma razão, é um claro 
sinal de que os processos e as estimativas precisam ser revistos e, potencialmente, melhorados. 
Todos somos capazes de gerar momentos de produtividade, eficiência e eficácia, por exemplo, 
momentos específicos de trabalho com maior clareza, senso de propósito e autovalidação. Perceber, com 
oportunismo, como desenvolver esses momentos em trabalhos coletivos é o significado de conseguir 
tirar o melhor proveito de um determinado time de projeto, em um determinado período de tempo. 
Quando somos verdadeiramente produtivos, eficientes e eficazes, é mais provável que gostemos do que 
estamos fazendo e nos sintamos compelidos a fazê-lo melhor, criando um ciclo virtuoso. 
Os três conceitos aparecem refletidos nas boas práticas de qualidade, acima de tudo, quando 
idealizamos que, para lidarmos com o trabalho (execução) da qualidade, dependemos 
essencialmente de processos. Processos são um conjunto de atividades inter-relacionadas que 
necessitam de insumos (entradas ou inputs, em inglês) para gerar os produtos, os serviços ou os 
resultados esperados (saídas ou outputs, em inglês), com base na aplicação de técnicas ou ferramentas 
específicas. Se os processos de um projeto não forem de qualidade, o risco de gerar produtos de 
baixa qualidade é alto. Entretanto, nem sempre o oposto é verdadeiro – a geração de produtos de 
alta qualidade não é necessariamente uma indicação de que os processos mais adequados foram 
seguidos. Portanto, a qualidade do projeto é medida não apenas pelo grau de adesão aos métodos e 
processos mas também pelo grau de qualidade alcançado pelos resultados/benefícios gerados pelo 
projeto. Solte um punhado de moedas misturadas no chão e o resultado não será uma matriz 
alinhada em linhas por tipo ou tamanho. O resultado é um monte de moedas espalhadas 
aleatoriamente pelo chão. O mesmo acontece com a qualidade. Seja como for definido, a qualidade 
não é um evento que ocorre naturalmente. É o resultado de um trabalho árduo e deliberado que 
começa com o planejamento, inclui a consideração de elementos contribuintes, aplica processos e 
ferramentas disciplinadores e nunca termina. Obter qualidade na implementação do projeto não é 
uma questão de sorte ou coincidência; é uma questão de gestão. Boa gestão. 
 
36 
 
Defeitos, custo da não qualidade, desperdícios e a visão dos 
3 Ms 
Um consumidor pode exigir qualidade, organizações podem oferecer (ou prometer) 
qualidade, mas um time de projetos é quem deve planejar, executar e controlar essa qualidade, de 
preferência de maneira autogerenciável. Portanto, é natural que equipes de projeto sintam a 
necessidade da qualidade de uma maneira particularmente diferente. Defeitos podem ter 
impactos imediatos, mas talvez seja pior quando são de longo prazo, pois possuem o potencial de 
trazerem consequências devastadoras, não só para a equipe do projeto mas também para a 
organização responsável por ele. 
O maior problema reside no fato de que o assunto qualidade, em muitos casos (e posso falar 
por experiência própria, por tudo o que já vi nas dezenas de organizações pelas quais passei – mas, 
antes que me perguntem: sim, existem organizações com níveis excelentes de qualidade), ainda 
continua sendo gerido por meio de objetivos de qualidade imprecisos, não associados ao contexto 
organizacional ou minimamente adaptado a intangíveis, como a cultura organizacional. No 
entanto, existem muitos métodos de qualidade e de tomada de decisão baseados em estudos de 
causa-efeito, muitos deles adaptados das suas origens fabris. Nada contra adotar práticas de 
qualidade que funcionam em outras circunstâncias (aliás, muito pelo contrário, pois serei sempre 
um entusiasta de qualquer técnica ou processo que possa ser adaptado para o mundo do 
gerenciamento de projetos e gere resultados), mas a equipe do projeto precisa ter sempre em mente 
que existe uma necessidade latente de adaptar essas práticas às peculiaridades do projeto que está 
sendo desenvolvido. Talvez, exatamente por isso, ferramentas e técnicas de qualidade foram 
desenvolvidas e refinadas nas últimas (muitas) décadas e já não se trata mais de uma questão pura 
de arte, mas de ciência, munida de muita informação e suporte estatístico. 
O PMI (2017a) reforça que cada projeto é único e que a equipe precisará adaptar a forma 
como os processos de gestão da qualidade do projeto serão aplicados. Comumente, os itens a serem 
considerados para adaptação incluem: 
 conformidade com políticas e auditorias – o que já existe em relação a políticas e 
procedimentos de qualidade na organização detentorado projeto? Quais ferramentas, 
técnicas e templates de qualidade já são utilizados na organização? 
 padrões e conformidades com regulamentações – há algum padrão de qualidade 
específico que precisa ser aplicado? Há alguma restrição governamental, legal ou 
regulatória específica que precisa ser considerada? 
 melhoria contínua – existe o hábito ou procedimentos estipulados de melhoria contínua na 
organização detentora do projeto? Caso exista(m), como ocorrem os processos de melhoria 
contínua da qualidade? Todos são implementados? A equipe do projeto possui autonomia? 
 engajamento dos stakeholders – existe algum ambiente colaborativo ou procedimento 
específico para as principais partes interessadas (incluindo sponsors e fornecedores)? 
 
 
 37 
 
Retornando ao tópico defeito, enquanto o conceito da qualidade pode ser subjetivo, caso não 
seja corretamente definido, o defeito é algo nítido, pois denota imperfeição. Esta pode ser traduzida 
de diferentes formas, como produtos/serviços diferentes de especificações técnicas, 
desconformidades físicas, vícios, baixa capacidade de utilização etc. Quando se compra uma caneta 
esferográfica, por exemplo, é esperada uma determinada conduta do produto. Se a caneta for 
utilizada de acordo com as orientações corretas e não há qualquer tipo de variável externa que 
comprometa a sua utilização, é esperado que ela funcione com a quantidade ideal de tinta logo na 
primeira utilização sobre uma superfície de papel, por exemplo. Já uma caneta cuja carga tenha 
ressecado ou, ainda, que apresente como característica física alguma rachadura, dá sinais imediatos 
de defeito, passíveis de reclamação ou devolução. 
Para a qualidade, os defeitos são benéficos, pois podemos e devemos aprender com as falhas que 
nos rodeiam. Crosby, a contrario sensu, defendia uma visão completamente diferente, pois acreditava 
que a ausência de defeitos deveria ser o padrão de desempenho dos sistemas de gestão. Portanto, o 
segredo para não errar seria prevenir-se o máximo possível, antecipando potenciais defeitos e, sob 
qualquer custo, evitando-os. A qualidade deve ser gratuita, ou seja, traduzida por um conceito conhecido 
como custo da não qualidade, pois as implicâncias envolvidas em um possível não alcance da qualidade 
seriam muito maiores do que os custos de prevenção. Devemos respeitar as opiniões do renomado autor 
(e conhecido guru da qualidade), que para sistemas industriais refletia muitas necessidades da época, 
mas precisamos desenhar um meio-termo, principalmente no que tange à aplicabilidade desses conceitos 
perante o gerenciamento profissional de projetos (é o que veremos em breve). 
O vice-presidente do The Blu Fund, Bernardo Cavalcanti, afirmou que “o escopo da vida é 
o reconhecimento perceptível dos erros”, portanto, pelo viés positivo dos defeitos, a premissa maior 
é a de que, sempre que erramos rápido, temos o poder de retomar rapidamente uma melhor rota e 
evitar novos problemas, além da proposta de gerar aprendizado sobre o defeito... e, aí sim, tornar a 
evitá-lo. Muitos defeitos futuros de um produto ou serviço, ou seja, pós-entrega, podem ser evitados 
pelo fato de a equipe do projeto ter verificado um potencial erro ainda no momento da execução 
do projeto. Destarte, é muito importante que o time do projeto aprenda com os erros e discuta 
sobre os impactos e os potenciais cenários de uma determinada falha, visando a uma atmosfera de 
aprendizado contínuo, de preferência com viés de implementação de melhorias. Exatamente por 
isso, é necessário que tenhamos um controle explícito de erros/defeitos. Isso já me colocou em uma 
posição desconfortável, pois, certa vez, um membro de uma equipe de um projeto cujo produto 
final era um grande evento, questionou se não era desmoralizante ficar mensurando todos os 
defeitos daquela equipe e os expondo abertamente para todos. De pronto, respondi que, sob 
hipótese alguma, o monitoramento da métrica deveria servir para intimidar ou desmoralizar a 
equipe, mas que se de alguma forma aquele painel (algo próximo do que está representado na figura 
8) estivesse transmitindo uma ideia diferente da pretendida, era fato que precisaríamos conversar 
melhor a respeito do tema. Antes de tudo, convidei um amigo a realizar uma palestra para o grupo. 
Na época, ele era vice-presidente de uma organização que adotava a cultura do erro como fator 
 
38 
 
estratégico na condução dos projetos. Logo após a primeira parte da conversa, ele já havia 
conseguido transmitir a ideia de que tudo depende de como as pessoas interpretam a informação 
vinculada ao erro, podendo ela ser tratada de uma maneira saudável, gerando aprendizagem, hábito, 
respeito e oportunidades. A priori, ninguém erra de propósito. A questão é o que será feito em 
relação ao erro em si. Mostrar os erros de uma equipe, e lidar de maneira transparente em relação 
às consequências e respostas, gera um efeito motivador e tem o potencial de incentivá-la a evitar 
novas ocorrências. Isso é um alimento poderoso para a cultura da melhoria contínua e a vontade de 
adaptar práticas, processos ou detalhes que possam melhorar o padrão de trabalho de uma equipe. 
Massari (2016, p. 175) diz “[...] não dê visibilidade somente ao que precisa ser melhorado, dê 
visibilidade ao que funciona bem também”. Evitar defeitos significa fazer um bom uso do 
gerenciamento da qualidade dos projetos. No entanto, vale lembrar que os defeitos irão ocorrer, e 
quanto mais cedo eles ocorrerem, menor será o impacto desse erro nos processos de controle de 
mudanças do projeto, assim como melhor será a oportunidade de aprendizagem. 
 
Figura 8 – Gráfico de defeitos 
 
 Fonte: adaptado de MASSARI (2016). 
 
Aristóteles (apud AUDY, 2015, p. 9) afirmou que “nós somos aquilo que fazemos 
repetidamente. Excelência, então, não é um modo de agir, mas um hábito”. Salvo melhor juízo, 
qualidade não é uma opção. Em muitas ocasiões presenciei projetos reais em que se acreditava que, 
por alguma razão, o padrão ou o índice de qualidade havia sido modificado porque algum 
demandante passou a aceitar um nível menor de qualidade, muitas vezes influenciado diretamente 
por baixa disponibilidade de orçamento ou cronograma apertado. Mas, na maioria dos casos, o que 
dita a responsabilidade da qualidade de um produto, serviço ou resultado esperado é o timing. No 
caso de produtos e serviços, o time-to-market (tempo entre a análise de viabilidade de um 
produto/serviço e o seu lançamento no mercado). Bill Gates, então CEO da Microsoft, certa vez 
mencionou que, se ele tivesse de esperar para desenvolver o sistema operacional perfeito, nunca teria 
lançado o Windows 1.0, em 1985. 
 
 
 39 
 
Outro caso também muito interessante é o do lançamento da primeira versão do iPhone, em 
2007. Dizem que os engenheiros de software solicitaram ao então CEO da Apple, Steve Jobs, que 
dessem um prazo de três semanas para que algumas novas funcionalidades do então novo conceito de 
smartphone pudesse ir para as prateleiras das lojas mais bem equipado. Jobs, demasiadamente 
preocupado com o time-to-market, optou por lançar o produto do jeito que estava, e que ele 
considerava pronto e apto para o mercado. Podemos associar tal ação, fortemente, à famosa frase “O 
ótimo é inimigo do bom”, associada ao filósofo iluminista francês, Voltaire. O detalhe (reclamação 
mais clássica) que ficou de fora da primeira versão lançada foi a função de copiar e colar (copy and 
paste). No entanto, a decisão de lançamento com a sensação de timing perfeito permitiu a venda de 
mais de um milhão de unidades, somente no primeiro fim de semana do produto, 
independentemente das funcionalidades responsáveis pelo copiar e colar estarem disponíveis. O fato 
é que, mesmo sem determinadas funcionalidades (na época, de alguma maneira, consideradas como 
não essenciais), o produto foi um sucesso de vendas, refletido pelas expectativas consumadas dos 
usuários. A baixa qualidade gera defeitos, reclamações e tem o potencial de colocartodo um negócio 
em risco (a não ser, obviamente, que a estratégia de negócio esteja vinculada a um produto com baixa 
qualidade..., mas isso é outra história). Já o baixo preciosismo gera o engajamento de um público-alvo 
consumidor fiel, com direito a feedbacks e recomendações para a evolução do produto. Muitos dos 
consumidores que adquiriram a versão 1.0 do iPhone esperaram e adotaram também a versão 2.0. 
Em muitos casos, a questão não é de controle da qualidade e sim de controle de preciosismo. 
Por fim, os desperdícios são comuns em qualquer meio, e nos times de projetos não seria 
diferente. Geralmente, são as maiores causas de atrasos em cronogramas, estouro de budgets e 
referências para altos índices de insatisfação dos principais stakeholders. 
 
A eliminação dos desperdícios deve ser perseguida a todos os momentos. 
No entanto, em muitas situações, no início dos trabalhos é mais difícil 
detectar e perceber os desperdícios. Eles tendem a ficar muito mais claros 
e evidentes ao final das iterações (CRUZ, 2016, p. 396). 
 
Aprendemos, no módulo 1, que o movimento lean (gestão enxuta) visa eliminar desperdícios 
e implementar uma estratégia de aprimoração contínua de processos com o foco na experiência 
final do cliente (interno ou externo). Isso ocorre, pois a aplicabilidade do lean carrega 
implicitamente um enorme grau de comprometimento com uma gama de princípios e práticas que, 
por exemplo, não apenas fazem uma organização (ou o trabalho de uma equipe de projetos) “ser” 
lean mas também a faz “permanecer” lean. Os hábitos, rotinas e processos internos passam a 
expressar tais comportamentos e transformam-se na espinha dorsal que conduz estratégias de 
sucesso de longo prazo. Sendo assim, organizações lean são mais bem orientadas na valorização da 
percepção de entrega de valor aos seus clientes e desenvolvem produtos, serviços e resultados 
alinhados com altíssimos padrões da qualidade. A visão de melhoria contínua não é a única força 
 
40 
 
da qualidade do lean, mas, sem dúvida, é a que melhor expressa essa preocupação por avaliar 
problemas (básicos ou complexos) que possam ser alvos de programas/processos de aprimoramento 
contínuo, deixando um legado de eficácia na organização e nas pessoas. Um dos grandes legados 
deixados pelo movimento lean é a maneira como são tratados os desperdícios de uma linha de 
produção e, atualmente, tal conceito foi naturalmente adaptado para as estruturas organizacionais 
que desenvolvem projetos de todos os portes e tipos. Existem muitas formas de classificação de 
desperdícios, até mesmo algumas metodologias são baseadas em muitas dessas técnicas, no entanto, 
estudaremos um dos conceitos mais simples, pela genialidade como se conectam com o 
gerenciamento da qualidade: a visão dos 3 Ms. 
 
Quadro 3 – A visão de desperdício dos 3 Ms 
3 Ms significado, em português, do termo japonês 
mura irregularidades / inconsistências / erros 
muri sobrecarga 
muda desperdícios 
Fonte: adaptado de CRUZ (2016). 
 
A visão dos 3 Ms consiste em três classificações fundamentais de desperdício, cada uma delas 
abordando um determinado ponto de vista, as quais precisam ser perseguidas ao longo da execução 
de um projeto, visando a um ambiente produtivo, eficiente e eficaz. Cada um dos Ms é representado 
por uma palavra de origem japonesa, conforme já demonstrado no quadro anterior. 
Mura é a palavra japonesa para inconsistências, erros ou irregularidades. Como já tratamos do 
assunto defeito neste mesmo capítulo, entender a proposta do conceito mura será relativamente mais 
simples, basta ter em mente que não estaremos tratando de um erro final pós-projeto, com o 
produto ou o serviço já pronto para o mercado. Essas inconsistências são inerentes aos defeitos 
advindos dos processos do gerenciamento do projeto, ou seja, de um erro oriundo do processo de 
estimar a duração de uma tarefa, de validar uma entrega ou até mesmo de comunicar uma 
determinada informação, apenas para citar alguns exemplos. Elas tendem a gerar retrabalhos ou 
trabalhos não planejados, promovendo uma variação no ritmo da equipe. Comumente, são 
percebidas em momentos do dia em que ocorrem picos de atividades muito altos em detrimento 
de momentos relativamente mais tranquilos, em que a energia da equipe não foi distribuída 
igualmente. Ou seja, promovem ritmos irregulares no fluxo de trabalho. A solução para lidar com 
o mura é atacar a fonte do problema e eliminar por completo a origem do desperdício. Sempre que 
isso consegue ser realizado, impede-se que o mesmo defeito ocorra, eliminando um mal pela raiz. 
Então, por que a equipe do projeto gastou tempo desnecessário ao estimar as tarefas de um 
 
 
 41 
 
determinado pacote de trabalho ou história de usuário? Por que a demora e todo o sacrifício 
ocorrido no momento de validar determinada entrega? Entender as causas dessas questões é um 
processo fundamental para evitar que elas ocorram novamente e eventuais inconsistências possam 
ser corrigidas em processos internos que geram picos de trabalho desnecessários. 
Muri diz respeito à sobrecarga e pode ser aplicado a equipamentos, ferramentas ou pessoas. 
No caso de equipamentos, exigir que uma determinada máquina, por exemplo, opere acima do 
número de horas recomendadas ou ainda que não se respeite os períodos de descanso ou de 
manutenção. Em relação às ferramentas, quando um determinado template já não cobre mais a 
totalidade de uma situação por insuficiência de espaço ou por inabilidade dos utilizadores (imagine, 
por exemplo, um canvas em que o time do projeto sabe responder somente às perguntas sobre 
riscos). Já em relação às pessoas, talvez seja o ponto que mais influencia o dia a dia dos projetos, 
pois refere-se a desgastes físicos e morais, decorrentes de situações de estresses pontuais. Um 
exemplo é estimar mais entregas do que um time pode realizar em um determinado período de 
trabalho. O muri é muito comum em momentos-chave do projeto, como deadlines para 
importantes milestones ou no encerramento do projeto. É comum o time trabalhar além do 
necessário para entregar detalhes da melhor maneira possível. Quando se coloca uma equipe de 
projeto para trabalhar por longos períodos em uma situação de capacidade máxima, os ânimos 
tendem a acirrar e não sobra tempo para aprendizados ou melhorias. Como a capacidade já está no 
máximo, significa dizer que o time vive num constante caminho crítico e qualquer contratempo 
gerará perdas ou atrasos complicados, pois não há folga no sistema. 
Por fim, o muda representa tudo aquilo que não agrega valor ao cliente/usuário final do 
produto, serviço ou solução que está sendo gerado pelo time do projeto. Toda e qualquer atividade 
do time que possa ser reduzida (ou eliminada) e possa representar um maior ROI (return on 
investment) – basicamente, o esforço de realização ser menor do que o benefício gerado por uma 
determinada entrega –, ou seja, aumentar a vazão das entregas aliadas à proposta de entrega de valor 
percebido pelos principais stakeholders do projeto. Exemplos clássicos são aquelas funcionalidades 
que são requisitadas e não agregam valor ao produto ou serviço; as reuniões sem término em que se 
perde muito tempo com detalhes não importantes e não objetivos, ou ainda aquelas em que as 
pessoas saem com a clara sensação de que não serviram para muita coisa. Pelo fato de o mura ser 
mais comum ao ambiente de projetos, penso nesse conceito como algo mais abrangente e sempre 
cito um exemplo do que acontecia em uma empresa na qual trabalhei. O andar em que trabalhava 
tinha um sistema de baias, com diferentes equipes trabalhando juntas, separadas por pequenas 
muretas. Devíamos ser cerca de cinquenta pessoas e o nosso time do projeto, com seis pessoas, no 
meio de todo esse grupo. Erámos completamente integrados ao grupo e isso era uma coisa boa e 
ruim ao mesmo tempo, pois muitos muras eram gerados. O exemplo mais clássico era o dos 
aniversários. Invariavelmente ocorria o aniversário de alguém e,sempre por volta das 16 horas, 
parava-se tudo o que estava sendo produzido para que as pessoas se ausentassem por preciosos 
minutos para cantar parabéns e comer uma fatia de bolo, sendo que, por vezes, alguns doces e 
 
42 
 
refrigerantes estendiam ainda mais a jornada do aniversário. Nada contra esse tipo de atitude, pois 
ela constrói relacionamentos e contribui para elevar o moral da equipe, mas as festas eram frequentes 
e não era difícil acontecer em um dia importante, no qual muitos membros da equipe estavam 
bastante atarefados. No princípio, para evitar conflitos, começamos a dizer que estávamos ocupados 
e que depois daríamos os parabéns ao aniversariante. Funcionou uma ou duas vezes, mas quando 
as demais pessoas passaram a perceber que era uma desculpa cada vez mais frequente, passaram a 
nos tratar de forma diferente, como se nós não nos importássemos mais com os momentos de lazer 
do grupo. O problema é que esses momentos ocorriam em horário de expediente e passaram a ser 
um problema a ser discutido. Foi quando tive a ideia de conversar com uma das responsáveis pelos 
eventos de aniversário e expliquei a situação propondo que os aniversários fossem comemorados 
uma vez por mês, em um evento no qual cantaríamos os parabéns para todos os aniversariantes de 
um determinado mês, num único dia. Isso otimizaria nosso tempo e faria das comemorações 
momentos mais importantes. Nós não nos livramos completamente do problema (e não era o caso), 
mas reduzimos consideravelmente o número de ocorrências, passando a dar o devido valor aos 
momentos em que estávamos juntos. 
Uma maneira interessante de aplicar bons processos de gestão de desperdícios é combater os 
3 Ms juntos, defendendo um processo produtivo mais estável e um controle mais previsível de 
eventuais adaptações. Dificilmente esse controle será infalível, pois sobrecargas, irregularidades e 
desperdícios tendem a ocorrer em qualquer ambiente de trabalho. Por isso, destinar atenção especial 
a esse tema é um fator crítico de sucesso para qualquer equipe de projetos. 
 
Custo da qualidade (CDQ) 
Uma das primeiras perguntas que surgem quando um esforço de melhoria de qualidade é 
demandado é: Quanto isso nos custará? Independentemente de qual seja o modelo de gestão, sem 
dúvida alguma, trata-se de um questionamento válido. Durante muito tempo, a alta qualidade foi 
associada a altos custos de produção. No entanto, quando se melhora a qualidade dos processos de 
gerenciamento de um projeto, embora o novo processo possa representar um montante maior de 
investimento financeiro, a redução de defeitos e de problemas pós-produção pode gerar um retorno 
maior que uma mera análise nos custos financeiros. Identificar quais são os custos de uma 
determinada entrega de um projeto, a fim de quantificar de maneira específica todos os seus 
requisitos, visando à redução dos custos de implementação, sem se esquecer dos padrões de 
qualidade adotados no momento da definição das condições do produto, serviço ou desempenho 
que será gerado pela equipe do projeto (ou seja, antes da existência de alguma entrega), é uma boa 
prática, principalmente quando se busca uma relação entre os benefícios advindos dessa melhoria. 
Obviamente, as decisões inerentes a essa boa prática precisam estar associadas a questões como 
disponibilidade de recursos, índice de satisfação de stakeholders e cronograma, entre outras. Ocorre 
 
 
 43 
 
que, no mundo real, a qualidade gera custos, mesmo que eles sejam superados pelos benefícios. 
Portanto, é importante reconhecer que as fontes dos Custos da Qualidade (CDQ) são definidas por 
três fatores: falhas, prevenção e avaliação. 
O custo da qualidade incluirá todos os custos decorrentes do trabalho do gerenciamento do 
escopo do projeto, desde o momento em que os requisitos são colhidos, tratados, categorizados e 
priorizados, visando ao fiel cumprimento das suas condições após a execução, culminando com a 
validação da área da qualidade. Serão visados os cumprimentos dos requisitos em relação ao 
produto, ao serviço ou ao resultado que está sendo gerado pelo time do projeto, assim como o não 
cumprimento dos requisitos, por exemplo, custos com retrabalho. 
Para que o conceito de CDQ fique mais claro, o PMI (2017a) define alguns termos, como: 
 inspeção – método para manter erros/defeitos distantes do cliente/usuário final; 
 prevenção – mantém os processos isentos de erros/defeitos; 
 tolerância – determina uma margem de erro que possa enquadrar uma faixa específica 
para resultados aceitáveis e 
 limites de controle – define fronteiras que possam servir de referência para as possíveis 
variações comuns em processos tidos como estatisticamente estáveis ou desempenho 
de processos. 
 
As organizações optam a investir em prevenção de defeitos, devido aos 
benefícios ao longo da vida do produto. Como os projetos são temporários, 
decisões sobre o CDQ ao longo do ciclo de vida de um produto com 
frequência são a preocupação do gerenciamento de programas, do 
gerenciamento de portfólio, do EGP ou de operações (PMI, 2017a, p. 310). 
 
Ainda segundo o PMI (2017a), o custo da qualidade, sempre que associado com processos 
do gerenciamento de um projeto, desencadeará um ou mais dos custos demonstrados a seguir: 
 custos de prevenção – relacionados à antecipação de potenciais problemas vinculados à 
má qualidade em produtos, entregas ou serviços de um projeto específico; 
 custos de avaliação – relacionados a diagnosticar, mensurar, periciar e verificar produtos, 
entregas ou serviços de um projeto específico e 
 custos de falha (internos/externos) – relacionados à não conformidade de produtos, 
entregas ou serviços em relação à documentação de definição de pronto de um projeto 
específico, mas também podendo ser em relação às necessidades ou expectativas dos 
principais stakeholders vinculados ao projeto. 
 
 
 
44 
 
Figura 9 – Custos de conformidade x custos de desconformidade 
 
Fonte: PMI (2017a). 
 
Um CDQ propriamente avaliado precisa refletir a proporção dos gastos inerentes às situações 
de prevenção e de avaliação em relação àqueles que serão realizados na tentativa de evitar falhas. 
Sempre que um dos custos de um lado da balança começa a consumir esforços ou gastos em 
demasia, é possível que a razão financeira já não esteja equilibrada e o investimento em, por 
exemplo, custos de prevenção, já não justifique os elevados valores. Há sempre um momento em 
que um investimento deixa de ser eficaz em função da proporção entre gastos e benefícios. No 
entanto, em alguns casos, altos custos fazem parte do business, como investimentos altos em custos 
de prevenção para projetos de perfuração de petróleo em alto mar. Tudo isso precisa ser levado em 
consideração no momento do planejamento e da execução da qualidade de um projeto. Alguns 
exemplos podem ser verificados na figura anterior. 
Em linhas gerais, o mais perigoso é deixar que o cliente/usuário final descubra os defeitos 
inerentes ao desenvolvimento do produto, serviço ou resultado gerado pelo time do projeto. A não 
ser que seja um público-alvo específico que se envolva no processo de melhoria pós-lançamento, 
como é muito comum acontecer em setores de tecnologia e editorial, nos quais o próprio usuário 
pode descobrir o erro e informar ao fabricante, pois há uma cultura de certa tolerância com essa 
proposta. No entanto, o que mais se vê, sempre que existe tempo e investimento suficiente para 
isso, é a possibilidade de descobrir e corrigir os problemas antes que as entregas sejam aceitas pelo 
cliente. Uma variação dessa abordagem seria usar a garantia da qualidade para examinar e corrigir 
o processo em si e não apenas defeitos especiais. Outro tipo de abordagem, também muito comum 
em muitos setores ou tipos de projetos, pode ser exemplificada pela figura a seguir, que demonstra 
que os custos, quando aproximam-se das extremidades do gráfico de custo da qualidade (seja da 
 
 
 45 
 
busca pelo perfeccionismocom 100% de conformidades ou uma necessidade extrema de melhora 
com 0% de conformidades), fogem ao propósito por serem demasiadamente elevados. Então, uma 
boa prática é estabelecer um limite de controle da qualidade, excetuando-se as extremidades, 
permitindo que seja gerado, por exemplo, um padrão de 80% de conformidades. Dessa forma, 
existirão padrões de qualidade que serão estritos, rigorosos e estabelecidos com respostas binárias: 
sim ou não/go ou no go. Porém, também existirão os padrões que estipularão, por exemplo, uma 
lista com 50 conformidades e, no momento da verificação, será aceita uma identificação de 40 
conformidades mínimas como limite, ou seja, 80% em relação ao total, independentemente de 
quais sejam as ocorrências. 
 
Figura 10 – Custo da qualidade (CDQ) 
 
Fonte: adaptado de KIRKPATRICK (1970). 
 
Quando migramos para abordagens ágeis ou mais próximas de implementações híbridas, a 
qualidade é comumente incorporada no planejamento do projeto e reflete na execução dos ciclos 
iterativos, nos quais as equipes são responsáveis por avaliar e validar, mesmo que parcialmente, 
potenciais entregas já utilizáveis e escalonáveis, no encerramento de cada sprint. Ou seja, a gestão 
da qualidade e as medidas de monitoramento e controle constituem uma parte integral dos sprints, 
em vez de serem executadas somente ao final do projeto, como um pensamento tardio. Além da 
qualidade ser executada diversas vezes, em diversos níveis, há a possibilidade da construção de uma 
sólida base de conhecimento e aprendizado sobre a qualidade do produto, serviço ou desempenho 
que está sendo gerado pela equipe do projeto. Outra boa prática extremamente difundida é a 
geração de uma cultura interna constantemente voltada para a melhoria de processos e da qualidade, 
seja do produto final ou do ambiente de trabalho da equipe, por exemplo. 
 
46 
 
Melhoria contínua: PDCA, 5 whys e retrospectivas 
Uma das heranças mais significativas do movimento lean é o princípio fundamental de 
melhoria contínua. O amanhã precisa ser melhor que o hoje nem que seja em relação a minúsculos 
detalhes, sendo fundamental a percepção de evolução por parte da equipe do projeto e, de 
preferência, dos principais stakeholders. Apesar de o termo poder ser bastante abstrato – sempre 
devemos avaliar o contexto em que está sendo utilizado –, no que tange ao gerenciamento de 
projetos, significa buscar sempre por agregar mais valor para o cliente/usuário final daquilo que está 
sendo gerado pela equipe do projeto e, ao mesmo tempo, reduzir (quiçá eliminar) etapas que geram 
desperdícios (lembrar do conceito dos 3Ms), minimizando possíveis efeitos negativos. 
Muitas são as técnicas, ferramentas e rituais disponíveis para que se implementem ações de 
melhoria contínua. Trataremos neste material das três mais utilizadas/efetivas: aplicação do ciclo 
PDCA, análise de causa-raiz com utilização da técnica dos 5 whys e o ritual de retrospectiva. 
O ciclo PDCA, um acrônimo para Plan (Planejar), Do (Executar), Check (Checar ou 
Verificar) e Act (Agir ou Controlar), é um processo iterativo em quatro grandes etapas, que serve 
para implementar melhorias de processos. Historicamente, o modelo se baseou em um método 
científico de hipótese-experimentação-avaliação, que acabou por ter uma série de corruptelas, sendo 
ele próprio, o PDCA, a mais famosa de todas. 
O PDCA não é uma prática exclusiva do gerenciamento de projetos, muito pelo contrário. 
Ele nasceu da necessidade do aprimoramento de processos, inicialmente fundamental para muitas 
organizações, ganhando o mundo do gerenciamento de projetos depois. 
 
Figura 11 – Ciclo PDCA 
 
Fonte: adaptado de SITEWARE (2017). 
 
 
 47 
 
No momento do P, de plan/planejamento, cabe ao time do projeto identificar o problema 
que precisa ser resolvido/melhorado; selecionar as pessoas mais habilitadas para girar o ciclo PDCA; 
mapear o problema do início ao fim, vinculando potenciais causas e consequências; identificar os 
métodos de análise; e, definir os objetivos que precisam ser alcançados para aquela situação 
específica que será trabalhada. A dica é elaborar um plano de ação bem estruturado para facilitar o 
tratamento do problema. No D, de do/executar, o plano de ação toma forma e precisará ser 
implementado. É quando a equipe do projeto demonstra que possui as competências para fazer o 
planejamento funcionar e ganhar forma, engajando todos os stakeholders necessários para que isso 
ocorra. Todos os resultados são documentados e aguardarão a próxima etapa, que vem a ser o C, 
de check/verificar, responsável por avaliar o passo a passo de tudo o que foi realizado durante todo 
o ciclo de implementação do plano, analisando a documentação e checando resultados. Trabalhos 
de comparação entre o status quo e o momento pós atingimento dos objetivos propostos costumam 
fazer parte das boas práticas dessa etapa, pois conseguem auxiliar o processo de descrição dos 
problemas/defeitos que serão corrigidos no passo seguinte. Se os resultados mensurados nessa etapa 
não forem adequados, em alguns casos, sugere-se que a equipe do projeto retorne ao momento do 
planejamento. Em relação ao A, de act/agir, é o momento destinado a colocar em prática todas as 
possíveis ações corretivas vinculadas ao problema estudado. Também se destina a um momento de 
reflexão para distribuir o conhecimento adquirido pelo trabalho realizado e avaliar futuras 
investigações que demandem uma nova rodada do ciclo. 
 
A base para a abordagem científica da Toyota é perguntar “por que” cinco 
vezes sempre que encontramos um problema… Ao repetir “por que” cinco 
vezes, a natureza do problema, assim como sua solução, se torna clara 
(KANBANIZE, s. d., on-line). 
 
Outra técnica bastante utilizada é a dos 5 whys (os 5 porquês, em inglês), que proporciona a 
sondagem das diferentes camadas de um problema, levando o nível de compreensão de uma 
potencial solução até a sua causa primária (e também as intermediárias, se for o caso). Naturalmente, 
sempre que se investiga um problema, a tendência é descobrir como ele surgiu. É exatamente o que 
essa prática propõe, de uma maneira iterativa, aprofundando a análise do problema ao avaliar todas 
as possíveis causas até que se atinja a raiz do efeito negativo. Para chegar à conclusão que a causa é 
realmente a raiz do problema, basta continuar realizando a sondagem ao questionar os seguidos 
porquês. A técnica é denominada de 5 porquês, mas, na verdade, trata-se de um número arbitrário. 
É possível que se chegue a um grau complexo de entendimento do problema com apenas dois 
porquês. Em outros casos, talvez seja necessário questionar vinte porquês, dependendo do grau de 
complexidade da situação. O importante é nunca aceitar a primeira resposta como verdadeira e 
tentar explorar ao máximo a técnica até que se chegue à causa-raiz (definitiva) do problema. 
 
 
48 
 
Veja este exemplo adaptado do website kanbanize.com: 
 
Problema: A newsletter sobre as últimas atualizações de software não foi enviada no prazo correto. 
WHY 1 – Por que a newsletter não foi enviada a tempo? 
“Porque as atualizações não foram entregues até o prazo final.” 
 
WHY 2 – Por que as atualizações não foram entregues a tempo? 
“Porque os desenvolvedores ainda estavam trabalhando nos novos recursos.” 
 
WHY 3 – Por que os desenvolvedores ainda estavam trabalhando nos novos recursos? 
“Porque um dos novos desenvolvedores não conhecia os procedimentos.” 
 
WHY 4 – Por que o novo desenvolvedor não estava familiarizado com todos os procedimentos? 
“Porque ele não foi treinado adequadamente.” 
 
WHY 5 – Por que ele não foi treinado adequadamente? 
“Porque o CTO acredita que os novos funcionários não precisam de um treinamento 
extensivo e devem aprender enquanto trabalham.” 
 
Como resultado, o problema investigado, que parecia ter sido gerado por uma questão 
técnica, acabou por demonstrar um erro nos processos internos da empresa, algo completamente 
diferente do que parecia emuma primeira avaliação, mais superficial. A equipe negligenciou o fator 
humano e se prendeu, ao menos no primeiro momento, a critérios técnicos relacionados ao 
desenvolvimento do produto. Após a análise dos 5 whys, algumas possibilidades para resolver o 
problema e não repetir mais uma conduta de atraso no envio da newsletter poderão ser idealizadas 
e, potencialmente, compartilhadas com outros setores, se for o caso. Quanto aos processos internos, 
é bem provável que outras áreas da mesma organização adotem processos semelhantes e estejam 
aptas a incorrer em problemas semelhantes. 
 
Retrospectivas recorrentes verificam regularmente a eficácia dos processos 
de qualidade. Procuram a causa-raiz dos problemas e sugerem tentativas 
de novas abordagens para aprimorar a qualidade. Retrospectivas 
subsequentes avaliam quaisquer processos experimentais para determinar 
se estão funcionando e devem ser continuados ou receber novos ajustes, ou 
se devem ser abandonados (PMI, 2017a, p. 312). 
 
 
 
 
 49 
 
A reunião de retrospectiva, também conhecida como sprint retrospectiva, em alguns casos, é 
um dos rituais mais importantes de muitos dos métodos/metodologias ágeis, pois representa o 
momento de fechamento de um ciclo iterativo e a oportunidade de aprender (e replicar o 
aprendizado) o que foi realizado pela equipe durante um determinado período. A reunião tem o 
poder de concentrar propostas de melhoria contínua em relação a processos, pessoas, estruturas e o 
que mais se fizer necessário. Várias vezes ouvi equipes de projeto se referirem à retrospectiva como 
o momento da DR (“discussão da relação”) e, apesar da analogia com relacionamentos amorosos, 
faz sentido avaliá-la como uma excelente oportunidade para obter feedbacks individuais e coletivos, 
assim como demonstrar orgulho naquilo que está sendo realizado pelo time. Assim como se 
demonstra orgulho pelos detalhes bons (ou ótimos), é importante discutir os detalhes ou 
procedimentos que deram errado, evitando repetir os mesmos erros, detectando soluções para 
eliminar ou reduzir desperdícios. Não é um momento para reclamações e choradeiras. Não se deve 
nunca perder o foco da melhoria contínua. 
 
O fluxo do gerenciamento da qualidade 
O gerenciamento da qualidade do projeto se faz presente em todos os momentos do ciclo 
de vida de um projeto. Veremos que, ao trabalharmos o gerenciamento da qualidade como um 
sistema amplo, dificilmente não se respira qualidade, até mesmo antes da iniciativa da 
formalização oficial para um determinado projeto. É muito comum que organizações ou equipes 
de projeto orientadas para a qualidade se preocuparem em estabelecer padrões e definir 
critérios/atributos de qualidade antes de o projeto ser iniciado, muitas vezes refletidos nas 
necessidades do negócio ou em certificações de qualidade já existentes. Na verdade, em 
organizações com o drive da qualidade, as normas são tão poderosas que seria impossível não ter 
todos os procedimentos já estabelecidos de antemão, assim como no momento do seu 
encerramento, pois, sem um bom roteiro da qualidade, dificilmente concretizam-se resultados 
satisfatórios para a organização. Aqui, estamos tratando de uma série de fatores vinculados à 
qualidade, como níveis de satisfação das principais partes interessadas, ROI – return on 
investment, melhoria de processos internos e gestão do conhecimento, entre outros. 
O fluxo de trabalho da qualidade, quanto ao roteiro de execução, é bastante simples. A 
proposta básica é que a qualidade possa ser planejada (ou, em alguns casos, apenas confirmada, 
quando os standards já existirem), executada, verificada e, em casos de problemas, ajustada, com 
potenciais reflexos em atualizações do seu próprio planejamento. Veremos que muito do trabalho 
que decorre dessas quatro etapas está constantemente alinhado com outros temas do 
gerenciamento de projetos, como o trabalho de gerenciamento do escopo e dos requisitos, dos 
riscos, das comunicações e dos stakeholders, apenas para citar os mais próximos. No entanto, 
muitos outros temas, apesar de não estarem ligados diretamente ao fluxo da qualidade, serão 
eventuais fornecedores de informações e terão os seus trabalhos potencialmente refletidos pela 
 
50 
 
gestão da qualidade. Portanto, a partir do momento em que o planejamento da qualidade está 
pronto, ainda que parcialmente, já é possível afirmar que existe influência dessas informações nos 
demais trabalhos de planejamento do projeto. 
Após o trabalho de planejamento da qualidade, teremos todas as normas e regulamentações 
da qualidade confirmadas para o projeto, incluindo todas as métricas necessárias para a execução 
dos processos formais de validação das entregas, vinculadas ao trabalho do gerenciamento do 
escopo. Sempre que uma entrega puder ser verificada, esse trabalho será realizado pela gestão da 
qualidade, que estará estruturada por meio de uma série de técnicas e ferramentas da qualidade para 
que o roteiro de validação possa ser cumprido com o rigor estabelecido no momento do 
planejamento. Em linhas gerais, a partir do momento em que desconformidades não são 
encontradas e, consequentemente, a sequência de execução dos trabalhos é consumada conforme o 
planejamento do escopo, as informações serão documentadas e transmitidas às partes interessadas 
cabíveis, cumprindo o passo a passo das exigências para uma boa gestão da qualidade. 
Sempre que ocorrer algum tipo de verificação da qualidade e desconformidades (até mesmo 
novos defeitos fora de uma situação vinculada ao planejamento) entre a execução e o padrão 
estabelecido no momento do planejamento forem detectadas, as informações também precisarão 
ser documentadas e informadas, contendo os pareceres da qualidade necessários. Tais pareceres 
servirão como base para futuros processos de tomada de decisão no intuito de avaliar se a 
desconformidade será sanada no todo ou em parte, e como isso ocorrerá. Caso a equipe do projeto 
opte por não sanar a desconformidade encontrada, ela terá de justificar e documentar os porquês 
da decisão. Muitas vezes, por exemplo, essas decisões podem decorrer de uma necessidade de se 
cumprir um momento importante do cronograma; de estarem vinculadas à decisão de algum 
stakeholder importante para o projeto; ou, até mesmo dos custos elevados para a correção dos 
problemas, alguns nem mesmo previstos no momento do planejamento do projeto. Enfim, tudo é 
possível em relação ao que será realizado para o trabalho de gestão das desconformidades 
encontradas, cabendo à gestão da qualidade, no entanto, deixar tudo corretamente documentado. 
Isso é de suma importância para resguardar os responsáveis pelos processos de tomada de decisão 
da qualidade, visando a pavimentar o caminho a ser tomado pela equipe, assim como a refletir os 
impactos de cada possível alternativa. 
Uma visão detalhada do fluxo da qualidade de um projeto e uma sorte de técnicas/ferramentas 
comumente utilizadas nos trabalhos da qualidade serão tratadas nas próximas unidades. 
 
Retrospectiva do módulo 
Neste módulo, iniciamos o trabalho pelo conceito da qualidade e muitos dos termos 
necessários ao seu estudo e à sua compreensão, especificamente no que diz respeito à sua correta 
aplicação pelo gerenciamento profissional de projetos. Começamos, como não poderia deixar de 
ser, com um breve cenário histórico para credenciar o assunto qualidade, não só como importante, 
 
 
 51 
 
mas como primordial em um ambiente de gerenciamento de projetos. Entender as causas que 
levaram o tema qualidade a ser alçado de meios fabris para uma questão de suma importância dentro 
das organizações só reforça os cuidados que passaremos a ter para gerir corretamente os trabalhos 
da qualidade de um projeto. 
Estabelecemos a diferença entre a qualidade de negócio, vinculada aos objetivos daquilo que 
se pretende atingir com a entrega do produto final, serviço ou resultado esperado, e a qualidade 
técnica, responsável pelos atos da equipe especializada, queinfluencia diretamente a forma de 
conduzir os trabalhos de implementação das entregas do projeto. Tratamos de temas como 
produtividade, eficiência e eficácia e as suas reflexões em tudo o que pode ser credenciado como 
trabalho da qualidade, seja vinculado ao planejamento, à gestão ou à verificação e aos ajustes. 
Além disso, tratamos dos conceitos de defeitos (imperfeições), dos custos da não qualidade 
(todo esforço admitido em ações que visam a garantir que processos e produtos finais coincidam 
sempre com especificações pré-definidas), dos desperdícios (aquilo que pode ser melhorado ou 
eliminado, pois não gera valor para o trabalho da equipe do projeto) e dos desdobramentos em 
função da técnica dos 3 Ms (mura, muri e muda). Vimos que, segundo Crosby, a qualidade (como 
um todo) deveria ser mensurada pelo custo dessa não qualidade, tendo ciência de que a qualidade 
resulta exclusivamente da prevenção, mas também avaliamos o contraponto dessa proposta. 
Pudemos compreender melhor a relação entre os gastos realizados por ações de prevenção ou 
de avaliação dos gastos inerentes às falhas, tanto internas quanto externas, e como isso é revertido 
para o conceito de custo da qualidade (CDQ). Um time de projeto (em muitos casos também as 
organizações) precisa avaliar se os custos de um lado dessa proporção não estão elevados demais em 
relação aos benefícios que poderão ser gerados, pois podem ser julgados como impraticáveis diante 
do alto grau de investimento. 
Por fim, explicamos o conceito de melhoria contínua e a necessidade cada vez mais premente 
da sua utilização em processos de gerenciamento de projetos. Oportunamente, navegamos em três 
formas, dentre muitas outras possíveis, de implementação de melhoria contínua: o ciclo PDCA, os 
5 whys e o ritual de retrospectiva. Ainda verificamos como se dá o fluxo da qualidade no 
gerenciamento de projetos, objeto específico de um estudo mais detalhado à frente. 
 
Já pudemos perceber que uma verificação intermediária ao final de cada módulo pode 
auxiliar na fixação de conteúdos, portanto, para avaliar o seu nível de conhecimento até 
aqui, verifique se consegue responder, corretamente, as seguintes perguntas: 
1. Qual a diferença, na prática, entre qualidade de negócio e qualidade técnica? 
2. Consegue explicar com suas próprias palavras as diferenças entre produtividade, 
eficiência e eficácia? 
3. E os 3 tipos de desperdício (conhecidos como 3Ms)? 
4. O que é melhoria contínua? Qual a sua importância para a equipe do projeto, para 
o projeto em si e para a organização responsável pelo projeto? 
 
 
 
 
Neste módulo, iniciaremos os trabalhos de planejamento do gerenciamento do escopo em 
projetos. Para que isso seja possível, será demonstrado o conceito de valor e como esse intangível 
pode variar ao longo do tempo, ou, ainda, sofrer a influência de variáveis que fogem ao controle 
da equipe do projeto. Também é demonstrado o conceito de requisito, as suas possíveis 
classificações e tipos, além da correlação com o conceito de funcionalidade, assim como a 
necessidade de métricas e padrões para o acompanhamento e a verificação dos parâmetros do 
requisito. Um fluxo de trabalho de requisitos é demonstrado por meio do ciclo de coleta, análise, 
priorização e implementação, fazendo-se acontecer sempre que justificado pela equipe ou pela 
natureza do projeto. Vemos muitas das técnicas de elicitação de requisitos preconizadas pelo Guia 
PMBOK® e algumas ferramentas de priorização eficazes para auxílio na organização das 
informações, apresentando dois artefatos fundamentais: o documento de registro dos requisitos e 
a matriz de rastreabilidade dos requisitos. 
 
Valor 
Trabalhar o escopo de um projeto e alinhá-lo com valores fundamentais que determinarão o 
sucesso (ou não) de todo um esforço empregado em prol de um produto, serviço ou resultado a ser 
gerado não é um segredo guardado a sete chaves, mas, ainda assim, muitas equipes tropeçam em 
detalhes que podem fazer a diferença no momento de mensurar os resultados finais de um projeto. 
Muito se estuda e se ouve acerca do conceito de valor. Acelerando um pouco a discussão e 
traduzindo logo esse conceito para o mundo do gerenciamento de projetos, em linhas gerais, é aquilo 
que as principais partes interessadas valorizam em relação aos esforços de uma equipe visando à 
satisfação de diferentes expectativas com aquilo que será gerado. O curioso é que o tempo e muitas 
outras variáveis atuam perante essas partes interessadas, influenciando novos comportamentos, 
MÓDULO III – PLANEJAMENTO DO 
ESCOPO: PARTE I 
 
 
 53 
 
anseios e temores. Consequentemente, essas circunstâncias podem transmutar critérios que serviam 
como base para a construção de expectativas. Então, ainda que de maneira imperceptível para muitos 
dos envolvidos, altera-se uma possível visão desse valor. Por exemplo, o que seria o valor de um projeto 
para um patrocinador? Poderíamos dizer que um projeto entregue dentro de um budget pré-definido, 
que cumpriu o cronograma e entregou aquilo que foi documentado, com qualidade verificada, pode 
ser considerado, tipicamente, um projeto de sucesso. E se essa entrega não gerar os efeitos estratégicos 
pretendidos pela organização? Digamos que, em uma iniciativa estratégica para melhorar a gestão de 
clientes de um determinado setor de uma organização, parte do projeto seria implementar um sistema 
de CRM – Customer Relationship Management (Gestão de Relacionamento com o Cliente, em 
tradução livre), responsável por otimizar o armazenamento da informação e por relacionar atividades 
de um cliente com potenciais interações com a empresa. Seria muito simples dizer que um sistema de 
CRM implementado no prazo, cumprindo todos os requisitos com qualidade e dentro do orçamento, 
estaria de acordo com as expectativas do seu patrocinador (e, provavelmente, de muitas outras partes 
interessadas). Mas, e se, em vez de o novo CRM colaborar com as ações comerciais da empresa, o tiro 
sair pela culatra e os vendedores não se entenderem com a nova ferramenta, atrasando pedidos, 
duplicando informações e fazendo horas extras por causa do retrabalho? Seria muito simples dizer que 
o projeto deu certo, pois foi implementado como manda o figurino, mas a estratégia pós-projeto não 
funcionou corretamente. Será que esse patrocinador está satisfeito? Será que a culpa é do time 
comercial ou da equipe do projeto? Enfim, muitas são as variáveis que poderiam ter sido evitadas 
visando a um melhor aproveitamento do êxito desse projeto, em vez de simplesmente olhar pelo lado 
tático de entregar um produto, sem avaliar o fator humano envolvido. Possivelmente, muitas culpas 
seriam lançadas e, no final das contas, se nada fosse realizado para que se entenda o problema 
corretamente, diriam que o CRM é horrível e que o timing do projeto foi errado. E o tal valor 
percebido pelo patrocinador que estava satisfeitíssimo com um projeto perfeito? Para se resguardar de 
problemas como esses, é muito importante que a equipe do projeto consiga, desde o início, estabelecer 
critérios para a definição do que será considerado valor, em relação ao que está sendo gerado. Portanto, 
quando iniciamos os trabalhos de planejamento do escopo, definir valor é um sério fator crítico de 
sucesso, ainda assim, negligenciado por muitas equipes. Ao definir, por exemplo, aquilo que os 
clientes (internos/externos) ou usuários finais valorizam, automaticamente, a equipe do projeto estará 
apta para definir o que fazer e como fazer, além de priorizar entregas, definindo se deverá ou não 
realizar algum determinado detalhe. 
Todos nós possuímos olhos de clientes/usuários finais. Por muitas vezes, o que uma equipe 
de projetos necessita é um exercício de empatia. Colocar-se no lugar de quem vai receber o produto, 
serviço ou resultado a ser gerado pela equipe do projeto pode auxiliar na prevenção de muitos riscos. 
Além disso, humanizar a execução dos trabalhos é demonstrar que a equipe realmente se importa 
com aquiloque está sendo realizado, promovendo uma conexão profunda entre as duas pontas: 
aqueles que fazem/entregam e aqueles que utilizam/necessitam. 
 
 
54 
 
Cito um exemplo extremamente simples de entrega de valor em uma situação na qual um 
cliente/usuário final não esperava receber tal benefício. Era um dia agitado, com horários confusos 
e aquela sensação de correria. Finalmente, o avião decolou e o serviço de bordo teve início. Eu só 
queria um café e a comissária de bordo, gentilmente, perguntou se eu também não gostaria de um 
copo d’água. Isso foi uma gentileza na qual eu não estava pensando. Na sequência, ela ainda me 
perguntou se eu utilizaria açúcar ou adoçante (pergunta protocolar), mas eu respondi que não uso 
nenhum dos dois. As mãos dela estavam prontas para me entregar algo e eu percebi uma pitada de 
desapontamento quando dei a resposta rápida. No mesmo instante, eu pedi desculpas e solicitei 
que ela me entregasse o que havia preparado. Qual não foi a surpresa quando percebi o meu nome 
na embalagem do açúcar! Pode ser algo mínimo para muitos, mas, naquele momento estressante, 
ver um esforço na dedicação da comissária para tentar deixar o meu dia mais agradável foi algo 
muito prazeroso. Pode nem ter sido algo solicitado pela companhia aérea e ter sido uma ação 
idealizada pela profissional, mas o fato é que isso me levou a perguntar a ela, mais tarde, se havia 
sido uma ação proposital. Sim, ela me disse que como tinham tido tempo antes do embarque e 
estava de posse da lista de passageiros, apenas tentou combinar alguns dos nomes disponíveis nos 
pacotes de açúcar com os assentos ocupados, visando à prestação de um serviço mais customizado. 
 
Figura 12 – Entrega de valor ao cliente 
 
Fonte: acervo do autor. 
 
 
 
 
 55 
 
Em suma, valor é a importância que alguém (ou um conjunto de pessoas) dá a uma 
determinada coisa. Clientes/usuários finais são os responsáveis por definir o valor de um produto, 
serviço ou resultado a ser gerado pela equipe de um projeto. Quando isso não ocorre, cabe à própria 
equipe do projeto investigar informações acerca do que precisa ser realizado/entregue, de preferência 
com um algum tipo de auxílio desses importantes stakeholders, para que a percepção de valor possa 
ser fielmente representada por meio de padrões, condições e, muitas vezes, métricas, que servirão 
para a criação de uma linguagem comum entre todos. A maneira pela qual o valor de um produto, 
serviço ou resultado é representado passa pelo gerenciamento dos requisitos de um projeto. A partir 
do momento em que a equipe do projeto conhece os requisitos e interpreta corretamente as 
necessidades (do cliente/usuário final/organização) ou oportunidade detectada, consegue 
compreender detalhes que tinham potencial de se perder ao longo de trabalhos até mesmo bem 
gerenciados, mas, de alguma forma, ficava a sensação de ter deixado algo importante para trás. 
 
Requisitos: conceito e classificações 
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 com um trabalho de gerenciamento do escopo não sendo 
meramente realizado dentro da esfera do projeto mas 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, com o auxílio do gerente, precisará ajustar a maneira como 
as etapas do gerenciamento do escopo do projeto são conduzidas, 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 (visto no módulo I). 
O desafio de planejar o gerenciamento do escopo do projeto será realizado uma vez ou, então, 
em momentos definidos previamente, consumando diversos atos ao longo do projeto. Mas, em 
primeiro lugar, é importante salientar que requisito é “[...] uma condição ou capacidade que é 
necessária estar presente em um produto, serviço ou resultado, para satisfazer um contrato ou 
especificação formalmente imposta” (PMI, 2016, p. 2, tradução nossa). Essas especificações podem 
ser normas ou metas organizacionais estratégicas. É comum que os requisitos expressem 
necessidades, desejos, anseios ou expectativas explicitadas por partes interessadas específicas – 
clientes internos/externos, patrocinador, usuário final, organizações, 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. 
 
 
56 
 
Requisitos nascem de informações que estarão diretamente vinculadas ao sucesso ou ao 
fracasso do projeto, pois o gerenciamento é algo que demanda uma especial atenção por parte do 
time do projeto. São muitos os fatores críticos de sucesso que precisam ser observados no momento 
de lidar com o assunto requisito, sendo os principais: 
 engajamento organizacional – todo trabalho que envolve um viés estratégico demanda o 
comprometimento e o alinhamento da organização com as propostas de entrega de valor 
e os objetivos do projeto. O representante maior desse engajamento é o patrocinador do 
projeto, pois a 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 dos requisitos – um plano de 
gerenciamento dos requisitos corretamente elaborado e ativo, por meio do qual se possa 
não só idealizar 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 – Return on Investment (retorno sobre o investimento) do projeto e, 
em consequência, da organização capitaneadora do projeto; 
 engajamento das partes interessadas – as partes interessadas devem ser engajadas com a 
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 
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 dos requisitos o mais cedo possível, 
minimizando ou eliminando potenciais problemas e 
 integração com as atividades do gerenciamento do projeto – o gerenciamento dos 
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. 
 
Requisitos podem ser classificados de diferentes maneiras para auxiliar o processo de 
transparência de informações e prover um melhor contexto para o seu gerenciamento. De acordo 
como um determinado requisito é 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 informações das principais partes interessadas. 
Os requisitos classificam-se em: 
 requisitos de negócio – são a verdadeira justificativa do início de um projeto. Descrevem 
as necessidades ou ideias de alto nível estratégico organizacional, para que possa dar vazão 
a uma ideia, ser resolvido um problema ou atender a uma necessidade; 
 
 
 
 57 
 
 requisitos de partes interessadas – descrevem as necessidades de um determinado 
stakeholder ou de um grupo de stakeholders. Costumam revelar as expectativas desse(s) 
stakeholder(s) em relação ao que será gerado pelo projeto e são a base paraidentificar os 
requisitos de solução; 
 requisitos de solução – descrevem as funcionalidades e os recursos que o produto, serviço 
ou resultado a ser gerado precisa 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 e 
 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 a conversão de dados e as 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 a conformidade das funcionalidades estipuladas ao 
longo do planejamento com as que foram ou serão implantadas, assim como as métricas 
de qualidade, fundamentais para o momento de chancelar uma entrega; 
 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 e 
 requisitos do programa – descrevem as especificações e as saídas necessárias para entregar 
os benefícios propostos pelo gerenciamento do programa. 
 
Uma boa prática em gerenciamento de projetos é determinar, no planejamento do escopo, 
como os requisitos deverão ser coletados, analisados (verificando o impacto sobre a abordagem de 
desenvolvimento do produto ou do projeto), organizados e/ou classificados e, por fim, 
documentados. A maneira de documentar os requisitos pode variar, por exemplo, de uma planilha 
em Excel para um template mais elaborado, contendo macros, descrições e anexos detalhados, ou 
ainda por meio de softwares específicos. 
 
 
 
58 
 
Coleta dos requisitos 
O PMI (2017a, p. 174) define o ato 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”. 
A prática de coletar requisitos será realizada uma vez ou, então, em momentos definidos 
previamente, ao longo do projeto. Ainda segundo o PMI (2017a), muitas são as formas para que a 
equipe de projetos consiga coletar requisitos, sendo que dificilmente descreveremos todas as 
possibilidades, pois, para cada caso específico, pode existir uma maneira própria de descobrir 
importantes informações. Há a sugestão para a utilização de opinião especializada, com uma clara 
indicação de que as especialidades sejam voltadas para análise de negócio, obtenção e análise dos 
requisitos, documentação dos requisitos, requisitos em projetos similares, técnicas de diagramas, 
técnicas de facilitação e gerenciamento de conflitos. Contudo, há também a sugestão para a utilização 
de coleta de dados por meio de brainstorming, entrevistas, grupos de discussão, questionários, 
pesquisas e benchmarking. Não devemos, contudo, nos limitar à lista proferida pelo guia, pois pode 
ser de grande valia, por exemplo, alocar um quadro branco com uma caneta marcadora em uma copa 
ou local de refeições para permitir que os utilizadores desses ambientes 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 ficam protegidos por um relativo grau de anonimato e não existe 
qualquer nível de juízo de valor em relação às sugestões ou às ideias proferidas. 
Todas são consideradas abordagens metódicas. Na primeira, com a utilização de um 
facilitador ou um moderador, podem-se levantar ideias de maneira aleatória ou ordenada, em que 
um conjunto de técnicas é aplicado em 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 gerar um insight para outro indivíduo e protagonizar uma nova funcionalidade. 
Na realizaçã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, entre as muitas técnicas possíveis. 
Grupos de discussão, normalmente, protagonizam sessões estruturadas com times 
multidisciplinares com viés de identificação dos 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 maneiras de se apresentar um 
questionário ou de se realizar uma pesquisa podem afetar direta ou indiretamente os resultados, por 
 
 
 59 
 
exemplo, realizar uma pergunta ao vivo para uma pessoa ou solicitar resposta por meio de um e-
mail ou uma ligação telefônica. Cada um dos métodos está sujeito a inúmeras variáveis, em alguns 
casos, alheias aos olhos do profissional responsável pelo questionário. 
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, de acordo com a necessidade 
de informações. 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ções pode ser 
descoberta, basicamente, revisitando ou analisando documentações pré-existentes, mas, se for o 
caso, essas documentações poderão ser geradas por outras técnicas/ferramentas, e então, na 
sequência, analisadas por meio de técnicas de análises de documentos. 
Acrescido a essas técnicas, em determinados momentos, o time do projeto precisará tomar 
decisões que direcionarão o trabalho com os requisitos. Para isso, há a possibilidade de utilização 
de técnicas de votação – nas inúmeras formas – ou análises de decisão envolvendo critérios 
múltiplos. Neste último caso, 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 pela representação de dados via diagramas de afinidades, por meio dos 
quais se pode perceber o acúmulo de determinados dados no intuito de se 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. Outra finalidade é auxiliar a gerência 
do fluxo de informações de um determinado sistema, produto, serviço ou resultado a ser buscado. 
Segundo o PMI (2017a), podem ser utilizadas 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, 
indicada quando não se deseja que a opinião de um participante influencieas opiniões dos demais. 
O resultado deverá ser consensual. 
 
 
 
60 
 
Figura 13 – Exemplo de diagrama de contexto 
 
 Fonte: adaptado de RESEARCHGATE (2016). 
 
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 os momentos observados/conversados. Comumente 
utilizada para verificar como um indivíduo utiliza (ou deseja utilizar) um determinado produto ou 
serviço e quando determinados stakeholders têm dificuldade de expressão das necessidades em 
relação a um determinado produto ou serviço. Também existem as técnicas de facilitação, que 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 as técnicas de prototipagem. A primeira é uma 
ferramenta muito utilizada para modelar o escopo, tanto do projeto quanto do produto, por meio 
de referências visuais, conforme se pode visualizar na figura anterior. 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, implementar ajustes e reduzir futuros problemas com mudanças 
inadvertidas do escopo. 
 
 
 
 61 
 
Análise, organização e classificação dos requisitos 
Segundo o site Project Builder (2017, on-line), “[...] a análise de requisitos é uma verdadeira 
revolução no que diz respeito a dois importantes aspectos organizacionais da empresa: a 
produtividade na execução do projeto e a maneira como a equipe colabora e se organiza”. É um 
trabalho que, quando realizado com consistência, auxilia a equipe do projeto em todos os sentidos, 
tendo influência direta em fatores que, potencialmente, conduzem ao sucesso do projeto. 
Por tudo o que vimos até aqui, já temos a percepção de que as condições desejadas para a 
idealização de um produto, serviço ou resultado devem vir diretamente do cliente/usuário final e 
ser corretamente interpretadas pela equipe do projeto para gerar bons frutos. Para isso, visualizam-
se todas as informações recebidas, de uma maneira ordenada, avaliando cada necessidade para as 
suas implementações, descrevendo detalhes e estimando esforços, mesmo que de uma maneira ainda 
preliminar. É importante lembrar que, conforme a próxima figura, não existe necessariamente um 
único fluxo para lidar com os requisitos ao longo de um projeto. A partir do momento em que um 
determinado lote de requisitos é especificado e pode gerar outros tipos de trabalho para a equipe do 
projeto, por exemplo, estimativas de cronograma, há uma evolução natural para lidar com a análise, 
a priorização e a posterior execução desse lote. Mas é possível, por exemplo, que nasça um novo 
lote (ou onda) de requisitos, para uma maior necessidade de compreensão de determinados detalhes 
ou até mesmo, para novas ideias ou acréscimos ao escopo. Portanto, nada impede que, enquanto 
um lote estiver em uma fase mais avançada, outro esteja iniciando o ciclo de vida. Isso se repetirá 
quantas vezes forem necessárias para que a equipe do projeto consiga entregar o valor necessário 
para atender às expectativas do cliente/usuário final. 
 
Figura 14 – Ciclo do caminho dos requisitos 
 
Fonte: elaborada pelo autor. 
 
 
62 
 
Na primeira etapa, visualizada no quadrante superior direito, são realizados os atos de coleta 
e de documentação dos requisitos. Muitos são os formatos possíveis para que isso ocorra, conforme 
bem visualizamos anteriormente. No quadrante inferior direito, trata-se do fluxo natural dos 
trabalhos, quando os requisitos são avaliados, no sentido de saber quais serão efetivamente 
necessários para o projeto (pois colhe-se muita coisa que não chega a ser utilizada), podendo ganhar 
diferentes tratamentos, como pesos, ordens de grandeza ou níveis de importância, para depois serem 
organizados ou categorizados (muitas das formas possíveis de categorização foram descritas no início 
deste capítulo). É comum complementar algum tipo de informação pendente nesse momento, pois 
os requisitos, quando analisados, ganham níveis de detalhamento visando a uma futura 
implementação. Uma boa prática é determinar as métricas pelas quais os requisitos serão 
comparados no momento da verificação da qualidade. Isso significa estabelecer os padrões. Um caso 
curioso de análise e organização dos requisitos aconteceu quando a equipe do projeto responsável 
pela pesquisa histórica para o filme O resgate do soldado Ryan, do diretor Steven Spielberg, descobriu 
que a coleta realizada havia sido tão rica em quantidade de informações e nível de detalhes, que 
acabaram criando arquivos de material extra, para um futuro projeto. Tamanho foi o grau de 
empolgação da equipe, que esses requisitos foram responsáveis por originar uma minissérie chamada 
Band of Brothers, completamente amparada por esse material. O quadrante inferior esquerdo faz 
referência a trabalhos de priorização, com o potencial de criar um backlog (espécie de fila de 
funcionalidades prontas para serem criadas/implementadas). Existem muitas técnicas de priorização 
dos requisitos, desde as mais simples, como elencá-los por níveis (alto, médio e baixo) ou por 
números, por exemplo, mas o importante é caracterizar como serão demonstrados os requisitos 
inegociáveis, no intuito de traçar uma estratégia de priorização de entrega de valor. Por fim, o 
quadrante superior esquerdo faz menção a tudo aquilo que já foi priorizado (já planejado) e poderá 
ser executado, ou mesmo gerando a necessidade de coletar mais informações para que se avance 
com o desenvolvimento do produto, serviço ou resultado. Se isso ocorrer, potencialmente, um novo 
ciclo dos requisitos será gerado. 
Ainda como forma de priorização, existem técnicas simples que podem ser facilmente 
adotadas pelo time do projeto e poderão agregar muito valor ao trabalho do gerenciamento dos 
requisitos. Neste material, serão descritas apenas duas, das muitas possíveis: a matriz de importância 
versus urgência e a técnica conhecida como MoSCoW. 
 
 
 
 
 63 
 
Quadro 4 – Matriz importância versus urgência 
 urgentes não urgentes 
im
po
rt
an
te
s 
Acrescentam valor e resultados 
e são de resolução imediata. 
Não são de resolução imediata, 
mas acrescentam valor e 
resultados. 
nã
o 
im
po
rt
an
te
s 
São de resolução imediata, 
mas não acrescentam valor. 
Não acrescentam valor nem 
são de aplicação imediata. 
Fonte: elaborado pelo autor. 
 
A matriz de importância versus 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 avaliar os requisitos que serão 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 senso de urgência. 
Os requisitos que forem classificados com alta importância e alta urgência são aqueles que 
visivelmente acrescentam valor ou trazem resultados imediatos e requerem uma resolução também 
imediata. 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 de 
resolução rápida ou imediata, possivelmente acrescentam 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.Estes precisam ser mapeados, mas dificilmente serão implantados, dependendo 
de um processo estruturado de tomada de decisão. 
 
 
 
64 
 
Figura 15 – Técnica MoSCoW 
 
Fonte: adaptado de CRUZ (s.d.). 
 
Segundo o 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. 
 
Quadro 5 – Para melhor compreender a técnica MoSCoW 
must have 
(precisa ter) 
should have 
(deveria ter) 
could have 
(poderia ter) 
won’t have 
(não terá) 
1. Tudo que for 
não negociável. 
2. Produto mínimo 
viável. 
3. Incapaz de 
entregar o 
produto final 
sem isso. 
4. Não é legal sem 
isso. 
5. Não é seguro 
sem isso. 
6. Sem isso, o 
projeto não é 
viável. 
1. Importante, mas 
não é vital. 
2. Talvez seja 
doloroso deixar 
de fora, mas a 
solução ainda é 
viável sem isso. 
3. Se precisar de 
algum tipo de 
improviso ou 
“jeitinho”, 
desconfie. 
1. Desejável, mas 
não tão 
importante 
quanto deveria 
ser. 
2. Só fazer se 
sobrar tempo e 
orçamento, sem 
prejuízo de 
motivação de 
equipe ou 
ocorrência de 
gold plating. 
1. Não há tempo 
para isso de jeito 
nenhum. 
2. Fora do 
orçamento. 
3. Fora do escopo. 
4. Bacana se tiver, 
mas não causará 
nenhum 
impacto de valor 
ao projeto ou no 
produto final. 
Fonte: elaborado pelo autor. 
 
 
 65 
 
 A letra M significa must have ou, em português, algo como deve ter. Serão os requisitos 
tratados em primeiro nível (primários), aqueles imprescindíveis e que trazem uma relação de retorno 
alto. Por causa disso, são capazes de agregar valor ao produto, serviço ou resultado que está sendo 
gerado e, quando corretamente implantados, afetam 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 podem vir a ser importantes e, quando implantados 
corretamente, podem influenciar diretamente os níveis de qualidade, tornando operacional um 
determinado detalhe de um produto, por exemplo. É preciso uma avaliação estratégica de custo 
versus benefício ou de esforço versus valor gerado para determinar se será realizado ou não. 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 será gerado pelo time do projeto, não são tão imprescindíveis. 
Salvo melhor juízo, costumam ser implantados 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á. São 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. 
 
Documentação dos requisitos 
Muitas são as possibilidades para o momento de documentação dos requisitos. Eu mesmo já 
presenciei um projeto que foi completamente documentado por meio de fotografias. No entanto, 
dois artefatos que podem ditar grande parte do sucesso de um projeto são: um documento 
consistente para registro dos requisitos e uma matriz de rastreabilidade dos requisitos. 
Requisitos podem ser detalhados inicialmente em um formato e, gradativamente, alcançarem 
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/recursos, 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, métodos como 
axiomatic design (utilização de ferramentas matriciais que, dentre outras coisas, propõem-se a avaliar 
a transformação das necessidades do cliente/usuário final ao longo de um projeto) 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á se descrevam os 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 de qualidade, no futuro. 
 
 
 
66 
 
Quadro 6 – Template para documentação (registro) dos requisitos 
título do projeto data da versão 
ID requisito 
parte 
interessada 
categoria 
grau de 
priorização 
critério de 
validação 
critério de 
aceitaçã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 para implantar a solução que está sendo gerada. Definir, às vezes, o básico, mas 
seguir e manter atualizadas essas informações com grau de atenção suficiente é determinante para 
que os 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 prazos. 
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, inicia-se a 
descrição do requisito. Imagine, por exemplo, que o projeto seja um grande evento contendo 
apresentações musicais ao vivo. Um dos patrocinadores comerciais solicitou ao time do projeto um 
palco suficientemente alto para que a sua marca, quando apresentada na face frontal do palco, pudesse 
ser vista por toda a área do evento. Estamos, claramente, lidando com um requisito de parte 
interessada. Um dos requisitos de solução que poderia estar vinculado a esse desejo seria, por exemplo, 
o estabelecimento da altura mínima do palco em 30 metros. O requisito técnico (condições do palco) 
passa a corroborar então o requisito de negócio (funções 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, seja atualizada. 
Na sequência, podem-se categorizar os requisitos como temporários, de solução, de qualidade 
etc., conforme classificação mais bem recomendada. 
 
 
 
 67 
 
Em relação às prioridades, pode-se simplesmente elencá-las como alta, média ou baixa, ou 
utilizar qualquer ferramenta de priorização dos requisitos, adotando as respectivas 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 o 
preenchimento do documento, descreve-se o critério de validação, que descreverá como ter certeza 
de que o requisito alcançará a precisão vinculada à qualidade, no futuro; e o critério de aceitação, 
determinando como ficará caracterizado o aceite – ou formato de handover. 
No exemplo citado, como ter certeza de que o palco possui no mínimo trinta metros 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 alocada, será de fato vista por toda a área do evento? 
Aqui, temos diferentes técnicas de medições ou de inspeções que podem ser estipuladas para validar 
tal requisito. Pode-se utilizar até mesmo uma técnica de observação. Para efeitos de teste, pendura-
se algo do tamanho do logotipo da marca no lugar desejado e percorre-se toda a área do evento para 
avaliar se o material consegue ser visualizado conforme almejado. 
Atenção, a ideia aqui não é gerar juízode valor, aferindo se um determinado critério é 
bom ou ruim. Essa análise será realizada pelo time do projeto, com o auxílio do líder 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 se transformar em um problema significativo. Determinar ao 
menos um critério de validação para cada requisito é uma maneira de o time do projeto se 
resguardar objetivamente, e não subjetivamente. 
 
Quadro 7 – Template para a matriz de rastreabilidade dos requisitos 
título do projeto data da versão 
ID requisito prioridade categoria 
parte 
interessada 
objetivo 
entrega 
da EAP 
métrica 
critério de 
validação 
 
 
 
Fonte: adaptado de SNYDER (2013). 
 
Assim como uma boa documentação dos requisitos é importante, uma correta rastreabilidade dos 
vários atributos desses requisitos ao longo de todo o ciclo de vida do projeto também é um fator crítico 
de sucesso. 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 algo muito útil no momento da 
solicitação de mudanças e como instrumento de suporte para processos de tomada de decisão. 
 
68 
 
As informações inseridas no registro dos requisitos (quadro 6) servirão como base de 
informação para esse novo artefato. O template apresentado no quadro 7 é apenas um exemplo dos 
muitos estilos que uma matriz de rastreabilidade dos requisitos pode ter. O template sugerido é 
baseado nos objetivos do projeto, nas entregas da EAP, nas métricas e nos critérios de validação, 
mas é possível, por exemplo, gerar uma matriz entre requisitos funcionais e não funcionais, entre 
requisitos técnicos e de segurança ou ainda 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 apresentado é 
uma sugestão, ele poderá ser customizado conforme as 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 dos 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 começa-se a descrever que tipo de objetivo será 
cumprido ou está relacionado ao correspondente requisito. 
Um exemplo de objetivo seria total visibilidade da marca do patrocinador master, que poderia 
estar vinculado a um requisito de tamanho do palco, com características de trinta metros de altura. 
A coluna seguinte determina a qual item da Estrutura Analítica do Projeto (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 
elencadas? Utilizando ainda o exemplo do palco do evento, pode-se simplesmente dizer, por 
exemplo, técnica de inspeção com utilização de trena digital – para a medição da altura em metros. 
 
Retrospectiva do módulo 
O módulo III iniciou a sua trajetória demonstrando o que é valor e como esse conceito se 
correlaciona com o trabalho de gerenciamento do escopo do projeto. Vimos como o sentido de 
valor precisa, de alguma forma, ser definido visando à criação de um caminho que suporte o 
trabalho da equipe do projeto, para que as expectativas das principais partes interessadas possam ser 
atendidas da melhor maneira possível, culminando em benefícios tangíveis e intangíveis. Estes 
poderão ser apreciados também pela organização detentora do projeto. 
Na sequência, definimos o conceito e a importância de um requisito e foram citados os fatores 
críticos de sucesso para tratar o assunto em um ambiente de projeto, 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. 
 
 
 69 
 
Os diferentes tipos de requisitos também foram explorados, permitindo visualizar melhor 
como classificar um requisito em funcional ou não funcional, de negócio, de partes interessadas, de 
solução, de transição, de qualidade, do projeto ou do programa. 
Demonstramos a importância de a equipe do projeto trabalhar corretamente um fluxo enxuto 
de gerenciamento dos requisitos, em que um bom nível de atenção no momento inicial de entender 
às necessidades/expectativas do cliente/usuário final é fundamental para o desencadear de outras ações, 
como a sequência natural de análise, a categorização e a priorização desses requisitos. Somente depois, 
a equipe do projeto poderá implementá-las, devidamente orientadas à proposta de entrega de valor. 
Algumas sugestões de técnicas de priorização de requisitos, como a ferramenta da matriz 
importância versus urgência e a técnica MoSCoW foram apresentadas. Estas, sempre que a 
necessidade demandar, poderão ser customizadas, no intuito de melhor atender às características 
de um determinado projeto. 
Por fim, apresentamos dois dos principais artefatos para documentação e gestão dos 
requisitos: o registro dos requisitos e a matriz de rastreabilidade dos requisitos. O primeiro é 
responsável por ser a base de informações oficiais, constantemente atualizada acerca do tema, ao 
longo do projeto; a segunda, uma maneira de conectar as informações dos requisitos com os 
objetivos do projeto, as entregas da EAP, as métricas e os critérios de validação. Também 
percebermos que é possível, por exemplo, gerar matrizes específicas 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. 
 
Como de praxe, verifique se consegue responder, corretamente, as seguintes perguntas: 
1. Como se define o valor (não monetário) de um projeto? 
2. O que é um requisito? Qual a sua importância para o trabalho de gerenciamento 
do escopo de um projeto? 
3. Enumere e explique a maior quantidade de técnicas/ferramentas para coleta de 
requisitos que conseguir. 
4. Qual a importância de priorizar requisitos? 
 
 
 
 
 
Apresentaremos o conceito de planning onion, que demonstrará como o planejamento do 
escopo deve ser distribuído em vários níveis, combinando uma perfeita sensação de timing para 
atender aos objetivos estratégicos da organização, além das questões táticas e operacionais de uma 
equipe de projeto. Também será exposta a importância de se trabalhar uma linha de base do escopo, 
seja ela como for, mas acima de tudo, preocupada em definir todos os termos e regras necessários 
para uma visualização de planejamento do escopo ao longo do projeto. Trata-se de uma 
documentação que acompanhará o projeto por todo o seu ciclo de vida e influenciando os demais 
temas/equipes vinculados ao projeto, assim como no trabalho realizado do escopo, que será 
comparado, constantemente, com a base planejada. Alguns artefatos são demonstrados, como a 
declaração do escopo e a estrutura analítica do projeto e os seus componentes (pacotes de trabalho, 
pacotes de planejamento, contas de controle, dicionário, entre outros). No entanto, não limitam o 
trabalho de confecção de uma boa linha de base do escopo a tais documentos. Os principais 
tipos/formatos de uma estrutura analítica do projeto também são demonstrados, assim como o 
cuidado que uma equipe de projetos deverá ter com um fenômeno conhecido como scope creep. 
 
Planejamento do escopo em vários níveis 
O trabalho de gerenciamento dos requisitos é parte integrante do gerenciamentodo escopo 
e, a evolução natural desse trabalho, após um primeiro nível de esforço para a compreensão das 
expectativas das principais partes interessadas e o início da documentação dos requisitos, cabe voltar 
as atenções da equipe do projeto para a execução das tarefas ligadas aos pacotes de trabalho ou 
histórias de usuário (aquilo que precisa ser feito/entregue), gerando entregas aptas a serem 
verificadas e, posteriormente, validadas com o OK de um time da qualidade. 
MÓDULO IV – PLANEJAMENTO DO 
ESCOPO: PARTE II 
 
 
 71 
 
Não podemos abrir mão de um bom trabalho de planejamento do escopo, que culmina com a 
base de informações necessária à correta execução, conforme mencionado. É necessária uma definição, 
logo em um primeiro momento, visando o nível de detalhamento do trabalho. Trabalhos de 
planejamento podem ser exaustivos e produzir toneladas de informações que nunca serão utilizadas. 
Então, saber o momento certo de encerrar (ou reduzir) os esforços de planejamento são tão 
importantes quanto saber o momento de iniciar os trabalhos. Além disso, esse trabalho precisa ser 
compatível com o cronograma e com a quantidade/qualidade dos recursos disponíveis para o time do 
projeto, sendo que o nível de detalhamento precisa corresponder a esses insumos. O segredo para a 
busca dessa eficiência é distribuir o planejamento em diferentes níveis, lembrando sempre de utilizar 
tais insumos, de maneira ordenada, para produzir o melhor produto, serviço ou resultado possível. 
Segundo Cruz (2016, p. 257), um bom planejamento “[...] precisa ser quebrado em pedaços 
menores e ser realizado em diferentes níveis”. Uma técnica que adapta bem esse conceito é 
conhecida como Planning Onion (Planejamento Cebola ou Planejamento dos Anéis da Cebola), 
demonstrada na próxima figura. 
 
Figura 16 – Planning Onion 
 
 Fonte: adaptado de CRUZ (2016). 
 
Os níveis representam os momentos em que os planejamentos são realizados, cada um com 
durações e peculiaridades específicas, sendo que, quanto mais vinculado a uma camada externa da 
cebola, com menor grau de detalhamento o planejamento será. Não que o anel 1 não seja 
importante, muito pelo contrário, o planejamento do projeto é importantíssimo para todo o 
contexto restante, mas poderá sobreviver com informações relativamente superficiais, já que o 
determinante para o planejamento do projeto é a visão geral do escopo. No entanto, estamos 
lidando com um nível de planejamento voltado para temas estratégicos e cumprimento de objetivos 
organizacionais. Tópicos importantes para serem avaliados pela equipe no detalhamento do nível 
de planejamento do anel 1 são (sem estarem limitados a esta lista): riscos ligados a diferentes setores 
 
72 
 
da organização ou a outros projetos com algum grau de dependência; objetivos estratégicos 
organizacionais; macro informações, por exemplo, aprovação de orçamentos, cronogramas, 
relacionamento com o patrocinador etc.; membros e autonomia da equipe do projeto; e, registro e 
avaliação dos principais stakeholders. 
O anel 2 trata do planejamento inerente ao produto, serviço ou resultado que será gerado 
pela equipe do projeto, e é um elo natural entre as necessidades estratégicas organizacionais e as 
questões táticas, pois começa a se preocupar com o resultado final do projeto, mesmo que a equipe 
ainda não possua as características detalhadas vinculadas ao escopo do produto. São itens desejáveis 
de planejamento nesse momento: necessidades priorizadas do cliente/usuário final (das mais básicas 
às impreteríveis); expectativas das principais partes interessadas; condições especificadas do produto, 
serviço ou resultado a ser gerado; aquisições e contratos; estimativas de recursos; e, tipo de 
abordagem destinada ao projeto. 
Para o nível 3, podemos visualizar duas situações distintas, desde projetos com abordagem 
mais próxima da preditiva que determinam etapas para entregas-chave do projeto, até projetos com 
abordagem ágil que trabalham com entregas escalonáveis ou incrementos de produtos. De qualquer 
forma, é importante avaliar o que é necessário para o cumprimento dos requisitos mínimos 
necessários, priorizados, de preferência com viés de entrega de valor para as principais partes 
interessadas, nos momentos das entregas das etapas (vinculados a momentos-chave do projeto) ou 
dos incrementos (vinculados ao final de ciclos iterativos). São propostas para o planejamento nessa 
fase: classificações e priorizações de requisitos; restrições; padrões e métricas da qualidade; riscos 
remotos; e, ferramentas e técnicas de comunicação. 
Já no nível 4, trabalha-se o planejamento da iteração curta. Isso significa dizer que, 
dificilmente um projeto com abordagem preditiva chegará a esse nível de planejamento (muito 
menos o nível 5). Passamos a lidar com esse nível de planejamento apenas em abordagens iterativas, 
incrementais, ágeis ou híbridas, visando aos ciclos (sprints) que costumam servir como referência 
para a entrega de incrementos, potencialmente melhoráveis. Normalmente, não se condicionando 
a estes detalhes, visam a: planejar, avaliar e programar respostas a ciclos de feedbacks; detalhamento 
das atividades/tarefas; atualização/reorganização de prioridades; motivação de equipe; experiências, 
interações e comportamentos; problemas e questões decorrentes da execução das atividades; gestão 
de conflitos; e, experimentos e testes/validação de hipóteses. 
Por fim, de todos os níveis de planejamento, o nível 5 é aquele que será o mais curto (em 
termos de tempo decorrido), mas o que servirá para situações extremamente pontuais, com um 
caráter de inspeção e adaptação do trabalho, quase como uma sintonia fina para ajustes e orientações 
de curto prazo. São desejáveis: alinhamento de expectativas da equipe; colaboração multifuncional; 
impedimentos ou pequenas resolução de conflitos; e, realizações e previsões curtas. 
O Planning Onion, sob hipótese alguma, é responsável por um trade-off entre momentos de 
planejamento e execução. Isso não ocorre, pois a execução do projeto, inobstante do momento em 
que ele esteja, não é parada para que ocorram trabalhos de planejamento. Por isso que a proposta é 
ser cada vez mais superficial, de fora para dentro, sem perder tempo com discussões inócuas ou que 
 
 
 73 
 
estejam fora do alcance da equipe. Limitar os momentos de planejamento aos seus respectivos 
níveis, com os seus respectivos pesos, significa permitir o engajamento da equipe com o objetivo de 
realizar trabalhos de execução, independentemente de estarem também envolvidos em atividades 
de planejamento. O fato de não existir uma fórmula mágica para definir o quanto de planejamento 
um projeto deve ter, deixa os limites de tempo para cada nível de planejamento dos anéis de cebola, 
de livre escolha da equipe de projeto, seja administrando o cronograma (e o timing das informações) 
disponível(is) para o projeto ou respeitando rituais ágeis, por exemplo. 
Cabe uma última observação em relação ao método de planejamento Planning Onion, pois, 
apesar de o capítulo ser exclusivo sobre o tema escopo, em uma prática real da técnica, não devem 
ser omitidas as demais informações no que tange, por exemplo, a esforços de planejamento de 
comunicação ou de gerenciamento do engajamento das partes interessadas, entre muitos outros 
tópicos já listados. Como bem pôde ser percebido, tudo o que envolve o planejamento do escopo 
tem o potencial de influenciar outras temáticas do projeto e vice-versa. Ou seja, normalmente, 
decisões sobre o assunto escopo são possíveis provocadoras de muitos impactos em áreas como riscos 
e cronograma, entre outras, sendo que a visão do todo é fundamental para a compreensão dos 
diferentes níveis propostos pela técnica Planning Onion. 
 
Linha de base do escopo 
Materialização do planejamento do escopo, que também servirá como referência para tudo o 
que for efetivamente realizado no futuro do projeto, a linha de base do escopo é um compêndio de 
informações formada poruma série de documentos que refletem todas as necessidades de trabalho 
do escopo do projeto e do produto, para a equipe do projeto, assim como os principais stakeholders. 
Segundo o PMI (2017a), uma linha de base do escopo pode conter uma Declaração do 
Escopo do Projeto (DE), com descrições do escopo do projeto e do produto, entre outros detalhes; 
uma Estrutura Analítica do Projeto (EAP), uma decomposição hierárquica daquilo que precisa ser 
realizado; o dicionário da EAP, especificações detalhadas que complementam cada item da EAP; 
pacotes de trabalho (último nível da EAP), que são parte de contas de controle, por sua vez, 
responsáveis por integrar escopo, cronograma e custos; e, pacotes de planejamento, o nível acima 
dos pacotes de trabalho e abaixo das contas de controle, sem descrição de atividades vinculadas ao 
cronograma. Todas essas referências serão exploradas ao longo deste módulo. 
O principal benefício ao definir o escopo do projeto é descrever os limites do produto, serviço 
ou resultado e os respectivos critérios para aceitação. É exatamente o que propõe qualquer artefato 
nos moldes de uma DE, que, 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 documentos 
mais importantes do planejamento geral do projeto, em face de trazer informações cruciais acerca 
do entendimento comum do escopo do projeto, bem como das partes interessadas, pode utilizar 
para a sua confecção informações trazidas no TAP e na documentação dos requisitos, por exemplo. 
 
74 
 
O TAP continuará cumprindo a função preliminar de repositório de informações nesse 
momento de definições do projeto. 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 pode 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 os 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 dos requisitos vem a ser constante, em 
intervalos regulares, durante todo o ciclo de vida do projeto. 
Por isso, a declaração do escopo sofrerá influência constante da coleta dos 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 é seguidamente 
descrito com mais detalhes, conforme novas informações a respeito do projeto são trazidas a bordo. 
Por fim, obviamente, o time do projeto não pode se esquecer 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. 
Em suma, uma especificação do escopo do projeto, que pode ser idealizada por meio de uma 
DE, é um artefato que trará a descrição do escopo do projeto bem como 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 propiciam 
resguardar o time do projeto no gerenciamento de algumas das principais partes interessadas. 
Para ilustrar melhor a questão das exclusões no escopo, existem termos que são comuns a 
determinados segmentos ou profissões e que podem ser interpretados de diferentes maneiras, 
por diferentes pessoas. Em um recente caso real de um projeto, uma empresa, indo avaliar a 
entrega da construção de um galpão, e os seus funcionários foram dotados de uma lista de 
 
 
 75 
 
verificação – checklist – para avaliarem o encerramento da obra, ou seja, o produto final do 
projeto. 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. Então, o responsável pela obra correu às especificações que tinha em 
mãos e apontou para o termo infraestrutura básica. Sim, eles eram responsáveis por entregar a 
obra do galpão com a infraestrutura básica pronta. No entanto, na sua maneira de ver o mundo, 
o termo infraestrutura básica dizia a respeito de piso, pilares, cobertura, canteiro de obra etc., 
mas nunca sistemas hidráulicos e afins. 
O curioso é que depois de presenciar essa situação, comumente, pergunto a engenheiros civis e 
outros profissionais que vivenciam diferentes cenários de obras, o que pode ser considerado como 
infraestrutura básica típica de uma obra. Não há qualquer tipo de surpresa em verificar que, nos seus 
entendimentos, a resposta é sempre bem variada e não há um senso comum, apenas em situações em 
que exista algum tipo de documentação na qual esse grau de detalhe esteja expressamente 
discriminado. Ou seja, é possível que uma equipe de projeto não esteja preparada para diferentes 
interpretações acerca de um mesmo requisito. Para isso, a saída é sempre determinar as exclusões ao 
escopo, que, no exemplo, poderiam estar explicitamente descritas como os sistemas hidráulicos e o 
que mais não julgassem características do termo infraestrutura básica de uma obra daquele nível. 
Como não bastasse, ainda existe o problema de que muitos bons profissionais confundem, 
no dia a dia do projeto, a exclusão do escopo com a restrição de escopo. Cuidado, pois elas são 
completamente distintas! Quando alguém disser que está proibido para o time do projeto 
trabalhar após um determinado horário, por qualquer que seja o motivo, isso deverá ser tratado 
como uma restrição e não como uma 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 
itens, frutos dessa análise, estarão contidos na linha de base do escopo ou se serão considerados 
externos aos limites do projeto. 
A versão mais simples e eficaz de uma declaração do escopo passa a ser, então, segundo o 
próprio PMI (2017a) a define, conforme o template demonstrado para especificação do escopo do 
projeto, proposto na próxima figura. Além do trabalho avaliado para efetivar as ações de entrega do 
produto, serviço ou resultado a ser gerado pelo projeto, é natural que ocorra uma descrição do 
escopo do produto, pois detalhes inerentesàs suas características precisarão ser retratados. É uma 
consequência da utilização da documentação dos requisitos na elaboração da DE. 
 
 
 
76 
 
Figura 17 – Template de declaração do escopo 
 
Fonte: elaborada pelo autor. 
 
Em relação ao conceito de entrega, o Guia PMBOK® (2017a, p. 744) diz que se define 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 têm 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. 
 
Estrutura Analítica do Projeto – EAP 
A Estrutura Analítica do Projeto (EAP) é o artefato que define o trabalho que será necessário 
para que os objetivos do projeto possam ser cumpridos, assim como a base de referência 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, além de instrumento de 
comunicação entre as principais partes interessadas. 
Por isso, as estimativas de trabalho do escopo de um projeto são melhor percebidas quando 
gerenciadas de uma maneira visual e decomposta, demonstrando uma estrutura única de elementos 
encadeados, que posteriormente farão a comunicação com as demais temáticas do projeto, como 
cronograma, qualidade, custos, aquisições etc. 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. 
 
 
 77 
 
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 e de toda a 
documentação dos requisitos, como também auxiliará em um melhor trabalho de estimativa 
dos esforços do planejamento do projeto como um todo. Isso ocorrerá quando as informações 
começarem a ser integradas com os demais temas, por exemplo, com as informações a respeito 
dos custos e da qualidade. 
A EAP é um instrumento que possui a tarefa de orientar todo o planejamento do projeto, 
desde a elaboração da sua primeira versão. Exatamente por isso, mudanças na linha de base de 
escopo tendem a infligir impactos nos trabalhos de muitas outras áreas de um projeto. Sempre que 
houver qualquer tipo de mudança na EAP, há a chance de refletir potenciais impactos na qualidade 
ou em recursos, por exemplo. 
Um correto trabalho de decomposição é de suma importância, pois é muito mais fácil, por 
exemplo, estimar os custos da reforma de um cômodo de uma casa do que de uma casa inteira. 
Sendo assim, 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, como membros de outros setores da organização ou subcontratados. 
A intenção da apostila não é demonstrar como se elabora uma EAP (esse aprendizado é 
exclusivo de nosso ambiente virtual, com apoio fundamental dos vídeos da unidade). No entanto, 
verificaremos características e detalhes essenciais para a compreensão dessa importante ferramenta. 
Na próxima figura, por exemplo, é 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 
precisa 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 planejamento e o seu 
futuro gerenciamento. Em suma, o número de níveis deve ser apropriado ao gerenciamento 
efetivo do projeto em questão. 
 
 
 
78 
 
Figura 18 – Níveis de uma EAP 
 
Fonte: elaborado pelo autor. 
 
Segundo o PMI (2017a), 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 é 
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. 
Dificilmente uma EAP não passará por um trabalho de revisão ao longo do projeto, não só 
por causa das 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 idealização. 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 é 
considerado, por muitos, uma boa prática. 
Na verdade, uma EAP pode ser confeccionada de muitas maneiras e com diferentes tipos de 
abordagens, que no final acabarão representando a mesma coisa, mas em formatos diferentes. O PMI 
(2006) cita, por exemplo, a possibilidade de utilização de modelos gráficos, textuais ou tabulares. 
Um exemplo de modelo gráfico, que é um dos mais conhecidos no mercado, seria o modelo 
piramidal ou em blocos, representado por figuras em formato de retângulos 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. 
 
 
 79 
 
Figura 19 – 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 apresentado na próxima figura. Com um formato de fácil utilização 
(com bons aplicativos/softwares gratuitos para auxiliar), pode ser uma excelente proposta de trabalho 
colaborativo para o 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 20 – Exemplo de EAP gráfica em mapa mental
 
Fonte: RIBEIRO (s. d.). 
 
80 
 
Em relação ao modelo textual, poderíamos utilizar a EAP da figura anterior e transformá-la 
no seguinte formato: 
Figura 21 – 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 
Fonte: elaborada pelo autor. 
 
Por fim, o mesmo exemplo, se confeccionado em um modelo tabular ou no formato de uma 
planilha (de Excel, por exemplo), estaria representado como no quadro a seguir: 
 
 
 
 
 81 
 
Quadro 8 – Exemplo de EAP tabular (ou planilha) 
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 
Fonte: elaborado pelo autor. 
 
82 
 
Além disso, como os trabalhos de gerenciamento do escopo têm uma ligação muito próxima 
com os trabalhos de gerenciamento 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, futuramente, garantir os critérios de aceitação, quando 
necessários, estamos tratando do trabalho da equipe do escopo. Porém, a equipe da qualidade será 
responsável pelos critérios de validação, ou seja, dizer que as entregas foram validadas ou, ainda, 
que os requisitos documentados desde o momento de coletar os requisitos alcançaram a precisão 
desejada por meio do atingimento das suas métricas. Somente depois que a área da qualidade definir 
que uma entrega foi validada é que a área de escopo poderá, formalmente, 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 o 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 tenha sido realizado um bom trabalho de elicitação de requisitos, no intuito de 
refletir em uma EAP a importância destes. Quando o trabalho descrito na EAP for de fato 
implantado, devem existir condições de mensurar, avaliar, testar e controlar uma entrega, para que 
se reflita 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. 
 
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). 
 
 
 
 83 
 
O dicionário da EAP é um documento complementar à EAP. Esta, 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. No entanto, o dicionário deverá descrever 
todos os detalhes inerentes a cada item da EAP. Para cada item, haverá uma potencial descrição 
para uma declaração de trabalho resumida ou, ainda, uma definição do escopo daquele 
componente, entre muitas outras informações possíveis. 
 
Quadro 9 – Exemplo de um trecho de um dicionário da EAP preenchido 
código item da EAP descrição critério(s) de validação 
nível de 
esforço 
1.2.1.4.3 
treinamento 
da equipe 
 Treinamento presencial 
para toda a equipe do 
projeto sobre plano de 
emergência contra 
incêndios a fim de cumprir 
norma interna nº 023/2019. 
O instrutor será o GP. 
 Não há necessidade de 
roupas específicas. 
 Realização na sede da 
empresa, sala 808, das 8h 
às 18h, com intervalo de 
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 do intervalo 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.). 
 Cobrir todos os 
procedimentos da 
metodologia proposta 
pela norma interna 
nº 023/2019. 
 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 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. 
9 horas 
Fonte: elaborado pelo autor. 
 
84 
 
Enquanto a confecção de uma EAP visa ao mapeamento, de maneira gráfica, dos 
componentes de um escopo do produto, no dicionário da EAP, o objetivo é descrever 
detalhadamente expectativas, estabelecer critérios de medição (até mesmo indicadores) e definir 
responsabilidades. Por vezes, associam-se detalhes, como estimativas de custos, recursos ou 
esforços/duração. Portanto, quando for o caso e de acordo com o grau de complexidade das 
informações do projeto, deve ser definida, 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/término –, estimativas de recursos, custos, número 
identificador associado ao item da EAP, informações contratuais, requisitos da qualidade, critérios 
de aceitação, referências técnicas, premissas e restrições, entre muitas outras informações possíveis. 
O dicionário da EAP funciona realmente como um dicionário, pois a intenção é que cada 
verbete referencie um pacote de planejamento ou de trabalho (algumas versões mais enxutas 
trabalham apenas com pacotes de trabalho), promovendo um melhor grau de compreensão para 
todas as principais partes interessadas naquilo que será desenvolvido pela equipe do projeto. 
 
Scope creep 
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, seria 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, 
desencadeando uma série de efeitosnão previstos sobre as demais temáticas do projeto, como por 
exemplo, recursos, cronograma e custos. A boa notícia é que o percentual de projetos que sofrem 
com o scope creep vêm decaindo ao longo dos anos, no entanto, o percentual de 34% de projetos 
atingidos por esse fenômeno ainda se revela como um dos grandes desafios dos times de 
gerenciamento do escopo em projetos (PMI, 2021). 
Dentre muitas ações que podem reduzir a probabilidade de ocorrências de um possível scope 
creep, gerenciar de perto as exclusões ao escopo do projeto – ou seja, o não escopo do projeto – é 
uma prática cada vez mais utilizada por times de projetos. 
Entre muitos problemas que podem, potencialmente, desencadear o fenômeno do scope creep 
em um projeto, os principais são: 
 má definição do escopo ou um escopo em desalinho com a realidade, ou mesmo 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 (por exemplo, falta de 
patrocínio) e 
 projeto com cronograma muito extenso. 
 
 
 
 85 
 
Figura 22 – Scope creep 
 
Fonte: elaborada pelo autor. 
 
Trabalhar em entregas não aprovadas de um projeto pode levar uma equipe a dedicar esforços 
a alterações não autorizadas com potencialidade de não agregar valor ao cliente ou usuário final do 
produto, serviço ou resultado que será 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 essas ações. 
 
86 
 
Retrospectiva do módulo 
O módulo IV demonstrou como desenvolver e integrar um planejamento do escopo do 
projeto com o trabalho realizado pela equipe do projeto em função do gerenciamento dos 
requisitos. Foi apresentado o modelo de planejamento dos anéis de cebola, demonstrando uma 
profundidade de planejamento em até cinco níveis, sendo que alguns tipos de projeto chegam, 
no máximo a três. O planejamento tem uma visão macro (e pelo ponto de vista da equipe do 
projeto, mais superficial) e alinha-se de acordo com as necessidades do produto, serviço ou 
resultado que está sendo desenvolvido, assim como a escolha da abordagem utilizada pelo time 
do projeto/organização, sendo que, quanto mais interna é a camada da cebola, maior é o nível de 
detalhes a serem trabalhados no escopo. 
Na sequência, tratamos do conceito de linha de base, notadamente vinculado ao escopo do 
projeto, permitindo um grau de planejamento completo para que as referências possam ser 
acompanhadas, discutidas, avaliadas e adaptadas, sempre que a necessidade dos trabalhos assim 
demandar. Uma linha de base do escopo é, tradicionalmente, constituída de uma especificação do 
escopo do projeto (e do produto) – aqui, descrevemos e apresentamos como sugestão o template de 
uma Declaração do Escopo – de uma EAP e os seus componentes, que norteiam os trabalhos 
naquilo que precisa ser entregue/realizado pela equipe do projeto, objetivando as aceitações das 
entregas do projeto perante as principais partes interessadas. 
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 demonstrar os principais tipos de confecção de uma EAP. 
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 de um dicionário da EAP (cuja confecção também foi demonstrada). 
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, tendo, por fim, as suas mazelas expostas. 
 
Uma vez mais, hora de verificar o aprendizado. Responda, corretamente, as seguintes 
perguntas: 
1. Como é composta uma linha de base do escopo? Qual a sua importância para o 
projeto? 
2. Para que serve uma EAP? 
3. Qual a diferença entre pacote de planejamento e pacote de trabalho? Por que os 
pacotes de trabalho são importantes? 
4. Há limite para o número de níveis de uma EAP? 
 
 
 
 
O módulo V nos fornece todas as informações necessárias para um correto trabalho de 
planejamento da qualidade de um projeto. Em um momento em que o time do projeto ainda vive 
muitas incertezas, o plano de gerenciamento da qualidade surge como uma espécie de guia para os 
futuros trabalhos de execução do projeto. Esse planejamento visa a servir de referência para que a 
atividade da qualidade do projeto seja aderente às políticas e aos padrões da qualidade da 
organização detentora do projeto, assim como, em muitos casos, também aderente às solicitações 
dos responsáveis pelo pedido do produto, serviço ou resultado a ser gerado. 
Antes de tudo, conheceremos três conceitos fundamentais para os trabalhos da qualidade, 
derivados do modelo Toyota de gestão: Kaizen, Kaikaku e Kakushin. O primeiro visa à melhoria 
contínua, o segundo visa à mudança e o terceiro visa à quebra de paradigmas. Todos são 
amparados por sólidas filosofias e modelos mentais com potencial para sustentar verdadeiras 
transformações em estruturas organizacionais, com impactos significativos em intangíveis, por 
exemplo, a cultura organizacional. Trataremos também da identificação do trabalho da 
qualidade com os métodos ágeis (ou híbridos), haja vista o constante processo de verificação e 
validação ao final de cada ciclo iterativo, facilitando a aproximação do processo de gestão do 
conhecimento e da cultura de aprendizagem com o estudo das falhas cometidas. Verificaremos, 
também, algumas das principais técnicas e ferramentas preconizadas pela metodologia proposta 
pelo PMI (2017a), culminando com alguns dos principais artefatos da qualidade vinculados ao 
momento do planejamento, que são essencialmente o plano de gerenciamento da qualidade 
(PGQ) e as informações sobre as métricas da qualidade. 
 
MÓDULO V – PLANEJAMENTO DA 
QUALIDADE 
 
88 
 
Os três Ks: Kaizen, Kaikaku e Kakushin 
Kaizen, em tradução literal, significa mudança (Kai) e para melhor (Zen). Em muitas 
adaptações sofridas por esse conceito-filosofia, é possível verificar a sua aplicação atual algo como 
um tipo de melhoria gradual ou aperfeiçoamento constante. Traduzido pela expressão fazer o hoje 
melhor do que o ontem, muitos são os ambientes de negócio que adaptam os seus valores e as suas 
práticas organizacionais para a implementação de um way of life (ou estilo de vida – às vezes um 
modus operandi) que encoraja mudanças incrementais e contínuas, iniciando por aspectos 
profissionais, mas que podem produzir profundas influências no ambiente pessoal, social e 
familiar. Eu mesmo costumava cobrar muito de times de projetos que pensassem com o propósito 
da melhoria contínua. Fazíamos treinamentos, trabalhávamos a comunicação, incentivávamos 
ideias, mas a impressão era que sempre que a pressão por melhoria contínua arrefecia, os esforços 
da equipe também minguavam e o status quo retornava. Era algo que, enquanto nos esforçávamos 
para enxergar e praticar, conseguia produzir efeitos sustentáveis e situações extremamente 
agradáveis. No entanto, para a minha surpresa, naturalmente, isso desaparecia com o tempo, 
mesmo com a aplicação de práticas tidas como sucesso que agradavam a todos. Aquilo me 
intrigava profundamente, pois, como não perpetuar comportamentos bons deuma maneira 
natural? Será que o ser humano precisa ser lembrado constantemente para fazer coisas melhores? 
Então, reparei que não adiantava acreditar que eu praticava a melhoria contínua no trabalho, se, 
na minha vida pessoal/familiar, isso não se refletia da mesma forma. Para ser algo natural, é 
necessário que a melhoria contínua faça parte de você, como uma filosofia. E talvez eu tenha 
aprendido isso de uma forma muito dura, pois, quando meus filhos nasceram – sou pai de gêmeos 
–, os dois ficaram por um longo período na UTI neonatal. Um deles, durante um período de 
sessenta dias, passou por três cirurgias (a primeira logo nos primeiros dias de vida e em condições 
bem desfavoráveis). Logo após a primeira cirurgia, quando ele estava se recuperando em um 
estado de coma induzido (adormecido, segundo a gentil equipe técnica do hospital) e ainda não 
havia sequer tido a chance de segurá-lo no colo, eu estava completamente imbuído de fazer tudo 
dar certo e respeitar procedimentos hospitalares, mas, ao mesmo tempo, sentia uma necessidade 
imensa de ter um dia melhor do que o anterior. A partir do momento que pude compreender 
melhor a situação e evidenciar os ganhos de um longo processo de recuperação, sempre que eu 
chegava ao hospital para visitá-lo, perguntava qual era a evolução do quadro clínico (eu buscava 
qualquer coisa que pudesse evidenciar avanços e trazer boas notícias) e, em relação ao meu 
relacionamento com ele, perguntava o que eu podia fazer. Certo dia, a enfermeira-chefe me disse 
que eu poderia me sentar ao lado da incubadora e conversar com ele, pois ele reconheceria a 
minha voz e isso o acalmaria. No dia seguinte, quando ela me disse para fazer isso novamente, eu 
comentei que sim, mas queria fazer algo mais... afinal de contas, isso foi o que eu fiz ontem, hoje 
eu queria fazer algo especial, diferente, sempre visando a um processo de melhoria contínua. Não 
preciso nem dizer que esse longo período me marcou profundamente, não só como ser humano, 
 
 
 89 
 
mas como profissional, pois hoje eu enxergo processos de melhoria contínua de uma maneira 
completamente diferente. Apenas finalizando, meu filho, hoje, é uma criança saudável e dono de 
uma energia infindável, como toda criança deve ser. 
Para que exista uma melhoria contínua em todas as áreas de uma organização, a filosofia de 
trabalho do Kaizen deve ser implementada desde pequenos detalhes até grandes avanços, para o bem 
de todos que são influenciados por processos e resultados daquele sistema. Mas, basicamente, 
podemos dividir o Kaizen em manutenção e melhoramento. O primeiro, define regras que auxiliam a 
manter níveis de performance estratégicos, estipulados pela alta direção, e por padrões de execução de 
processos ou operações. Já o segundo significa um esforço para a melhoria de padrões/processos 
existentes ou incentivo à inovação, para abandonar padrões/processos obsoletos. Em times de 
projetos, estamos diante de um fator crítico de sucesso, pois melhorias contínuas reforçam o 
compromisso das pessoas com uma estratégia abrangente para todo o negócio, revelando uma melhor 
disposição para influenciar o clima organizacional e deixar o trabalho da equipe muito mais agradável. 
 
Figura 23 – Os três Ks 
 
Fonte: QUALITYWAY WORDPRESS (s. d.). 
 
Equipes da qualidade (e de lean thinking) trabalham o conceito de Kaizen essencialmente como 
a ideia de melhoria contínua e, em muitos casos, até como um princípio de trabalho, com o propósito 
de influenciar pessoas no sentido de incutir o modelo mental desejado para a realização de melhorias 
sem grandes esforços, afinal de contas, a partir do momento que algo passa a ser tão natural para 
alguém, estranho seria deixar de fazê-lo. Uma mentalidade Kaizen bem trabalhada é incremental e 
viabiliza processos consistentemente melhores, perpetuando um ciclo virtuoso, indispensável ao 
modus operandi de qualquer time de projeto, independentemente do tipo de segmento. 
 
90 
 
Muitos são os métodos de implementação do Kaizen e de busca de um padrão de adequação 
contínuo ao conceito, desde observar como melhorar ações em relação aos 3Ms (mura, muda, muri 
– vistos no módulo II), que por si sós resolverão problemas como subutilização (ou sobreutilização) 
de recursos, esperas desnecessárias, defeitos/falhas e trabalhos extras, entre muitos outros possíveis 
fatores, como também demonstrar insatisfação com zonas de conforto ou processos que são 
realizados sempre da mesma forma, repetidas vezes. Certa vez, perguntei ao integrante de uma 
equipe o porquê de ele entregar um relatório em determinado formato. Eu tinha plena consciência 
que a resposta seria dolorosa (de fato foi): “Porque sempre fazemos isso desse jeito”. Inconformado 
com tal comodismo, foi exatamente nesse dia que surgiu o roteiro apresentado na próxima figura, 
sugerindo que primeiro haja a seleção de um processo, como escrever o relatório XPTO. Estude 
como esse relatório foi realizado ao longo de um determinado período de tempo, reconheça as suas 
nuances e as suas dependências, para então documentá-las. Converse com todos que, de alguma 
forma, contribuam para que o processo seja executado. Depois, de preferência, de maneira 
colaborativa, apresente o problema para o grupo: “Temos um relatório ineficiente que é realizado 
sempre da mesma maneira”. Questões que precisam ser respondidas: 
a) As informações provenientes desse relatório são necessárias/essenciais? 
b) Se são necessárias, o documento pode ser substituído por algum método mais eficaz? 
c) Se não puder ser substituído, como reduzir o tempo de confecção, envolver menos 
recursos ou melhorá-lo, deixando o resultado mais atraente? 
 
Pronto! O time passa a ter um processo novo apto a ser testado e com a possibilidade de 
receber feedbacks das principais partes interessadas. Funcionou? Reflita sobre as causas e continue 
dessa forma. Não funcionou? Reflita e tente resolver o problema com uma abordagem alternativa. 
Registre os resultados para gerar uma base de gestão do conhecimento da sua equipe, que 
potencialmente poderá ser transmitida a outros setores da organização ou a outros times que 
enfrentam problemas semelhantes. Depois de certificar-se de que o processo novo está melhor que 
o antigo, comece a provocá-lo novamente, repetindo o roteiro Kaizen visando sempre à qualificação 
de pessoas e à imposição/manutenção de uma cultura de melhoria contínua. 
 
 
 
 
 91 
 
Figura 24 – Kaizen na teoria 
 
 
Fonte: elaborada pelo autor. 
 
Um exemplo simples de Kaizen (que também demonstra uma outra técnica de qualidade 
conhecida como poka-yoke, funcionando como um dispositivo visual ou mecânico à prova de 
erros) em serviços pode ser visualizado na próxima figura. Em lojas de aeroportos é comum a 
frequência de muitas pessoas, no entanto, caracterizadas em três tipos: a) pessoas em trânsito, sem 
intenção de compras; b) pessoas com intenção de compras, mas práticas ou sem tempo a perder; 
e c) pessoas com intenção de compras, que podem, eventualmente, precisar de algum tipo de 
assistência dos vendedores. A empresa que administra as lojas de duty free (que vendem produtos 
sem a incidência de determinados impostos) em um determinado aeroporto, criou um sistema 
visual, à prova de falhas, que veio a corrigir um problema clássico de má alocação da força de 
vendas para auxílio nas compras dos clientes. Eram comuns reclamações de ausência de 
vendedores, ou ainda, de atenções demasiadas a frequentadores que gostariam de privacidade no 
momento das compras. Após mapearem os processos de vendas e, visando a evitar esforços 
desnecessários dos vendedores, a empresa implementou um sistema de cores nas suas cestas de 
compras, com um roteiro explicativo e simples logo na entrada da loja. A cesta na cor vermelha 
atende ao consumidor que pode necessitar de algum tipo de ajuda. Ela fica na entrada da loja, 
com os dizeres: “Eu gostaria de ser atendido/assistido”. A cesta preta serve aos consumidores 
práticos, que já sabemo que desejam ou não dispõem de tanto tempo assim, e querem pegar os 
seus produtos, pagar e seguir viagem. Ela é acompanhada dos dizeres: “Eu gostaria de comprar 
 
92 
 
por conta própria”. Quem não utilizar qualquer tipo de cesta será considerado apenas um 
passageiro em trânsito e, portanto, sem a intenção de adquirir produtos. A partir do momento 
em que o código de cores das cestas foi implementado, todos os vendedores da loja possuem um 
código de conduta para otimizar esforços e oferecer atenção apenas ao cliente portador da cesta 
vermelha, a não ser que ela seja solicitada de outra maneira explícita. 
 
Figura 25 – Kaizen na prática 
 
Fonte: acervo do autor. 
 
Quando estamos diante de desafios que impliquem a aplicação de ferramentas ou de métodos 
(5S, por exemplo) para disciplinar pessoas a terem uma melhor consciência de utilização de um 
determinado recurso ou aproveitar melhor a eficiência de um processo, a saída é implementar o 
Kaizen. No entanto, quando desenvolvemos novas tecnologias ou materiais novos para substituir 
uma ação ou adaptar um processo, com viés de transformação, ou seja, não simplesmente 
melhorando aquilo que se tinha, mas revolucionando e transformando por completo o modelo 
anterior para uma nova maneira de desenvolver algo, estamos então diante de Kaikaku, que em 
tradução literal, significa mudança (Kai) e radical ou revolucionária (Kaku). Reduzir o tempo de 
uma reunião de controle diária com a equipe do projeto por desenvolver uma nova técnica de 
facilitação com o grupo é aplicar o Kaizen, mas realizar o mesmo propósito dessa reunião de uma 
maneira diferente, impactando em mudança de cultura e de hábitos de trabalho que influenciam 
em grande escala, é aplicar o Kaikaku. Tive a oportunidade de presenciar esse tipo de modelo mental 
em equipes autogerenciáveis e é algo realmente surpreendente. 
 
 
 93 
 
É normal que a aplicação do Kaizen evolua e, em um determinado momento, chegue a um 
ponto de estagnação. Ou seja, pequenas mudanças evolutivas deixam de ser significativas e o esforço 
da equipe em implementar essas melhorias já não justifica mais o trabalho em prol de tentar 
melhorar esse grau de eficiência, seja por meio do alcance de objetivos ou de necessidades 
estratégicas. Sempre que o Kaizen chega em um limite no qual já não consegue mais ser eficaz, a 
saída natural é rever as regras do jogo e inovar, provocando uma revolução conhecida como Kaikaku. 
Quem acompanha corridas de automobilismo há alguns anos ou conhece o histórico da 
modalidade, poderá lembrar que, na década de 1980, um pit stop (parada) de fórmula 1 para a troca 
de pneus demorava, em média, algo como 20 segundos. Mais algumas décadas antes disso, chegava a 
durar mais de 1 minuto. No entanto, em novembro de 2013, a equipe Red Bull Racing foi a primeira 
a conseguir quebrar a barreira dos 2 segundos, realizando a troca de pneus do carro pilotado por Mark 
Webber, durante uma corrida nos Estados Unidos, contando um intervalo de 1,923 segundos. Não 
foi só o processo da troca de pneus que evoluiu (Kaizen), mas outros detalhes (Kaikaku) como tipos 
de materiais que permitiram a utilização de um único pino para prender uma roda (em vez de quatro), 
tecnologia de ferramentas, número de pessoas envolvidas (três para cada roda), regras da modalidade 
desportiva, entre outros detalhes que permitiram uma mudança completamente diferente da forma 
como as equipes conheciam e desenvolviam tal processo no passado. São movimentos que, 
normalmente, geram forte intensidade de energia e aprendizado com elevado impacto de resultados, 
propiciando a utilização de novas técnicas, conhecimentos e recursos. 
E quando tudo parece estar às mil maravilhas, afinal de contas, quebram-se barreiras tático-
operacionais e equipes acabam passando por mudanças extraordinárias, ainda é possível um novo 
nível de mudança, conhecido como Kakushin. Kaku já sabemos que significa radical ou revolucionário, 
que agora junta-se a Shin que significa novo(a). Sendo assim, a palavra Kakushin remete a inovação, 
renovação, ou ainda a uma inovação radical, para sermos mais atentos ao espírito da mensagem 
vinculada ao termo. O conceito de Kakushin é transformar organizações ou setores de organizações, 
ou ainda, dependendo do grau de maturidade delas, a maneira de trabalhar de algumas equipes de 
projetos, movendo-se de um status atual para um status futuro desejado. A revolução provocada pelo 
Kakushin envolve uma gestão integrada de mudanças que modifique significativamente o modelo de 
negócio (por exemplo, de cost driven – voltado para custos – para value driven – voltado para a entrega 
de valor), normalmente influenciado por intangíveis (aprendizados, novos modelos mentais, culturas, 
valores etc.) que propiciarão a transformação organizacional/cultural, revelando novas atitudes e 
comportamentos. Um exemplo clássico e muito atual tem sido a transformação de organizações que 
adotam modelos clássicos de gerenciamento de projetos para modelos lean/ágeis (ou híbridos), 
revolucionando completamente a maneira de agir das pessoas, com adoção de novos princípios e 
valores, que tendem a influenciar todo o sistema de fluxo de produtos, serviços ou resultados 
desenvolvidos pelas equipes de projeto e os seus principais stakeholders. 
 
 
 
94 
 
Quadro 10 – Comparações entre os 3Ks 
Critério KAIZEN KAIKAKU KAKUSHIN 
Conteúdo 
realizar pequenas 
melhorias 
incrementais 
gerar grandes 
mudanças técnicas 
ampla reformulação 
e transformação 
Ator principal times multifuncionais especialistas técnicos diretores e gerentes 
Foco principal 
eliminar desperdícios 
nos processos 
aplicar novas 
tecnologias, técnicas, 
materiais 
introduzir uma 
inovação radical 
Justificativa melhoria contínua 
introduzir saltos de 
produtividade 
romper um cenário 
de mercado 
Fonte: elaborado pelo autor. 
 
Os três Ks são conceitos que podem atuar conjunta ou separadamente, pois, mesmo que 
estejamos tratando de um conceito vinculado a uma espécie de inovação radical (Kakushin), em 
momento algum subentende-se que seja necessário abandonar os dois conceitos que precederam à 
transformação, vinculados ao Kaizen e ao Kaikaku. A vantagem do Kaizen é a sua autonomia, pois a 
partir do momento em que se desenha uma cultura (na equipe ou na organização) de esforços em 
prol da melhoria contínua, a adaptação e a aplicabilidade para a implementação do Kaizen é 
instantânea e produz efeitos imediatos – como times de projetos que apresentam um determinado 
problema em uma reunião de retrospectiva e, de pronto, avaliam a situação e discutem uma solução 
para aderir a um novo formato de processo ou para enxergar determinados detalhes. O Kaikaku 
normalmente já é tema de projetos específicos, em que a necessidade ou a oportunidade passa a ser 
materializada em observância aos objetivos de negócio e de estratégia, envolvendo muitos stakeholders 
que podem ser afetados pela solução. Já o Kakushin são necessidades reais, muitas vezes de 
subsistência, como a aceleração digital provocada pelo cenário pós-Covid19 em muitas organizações, 
ou de oportunidades/estratégias de inovação, como o lançamento de um novo produto ou serviço, 
por exemplo, a inovação do conceito de hospedagem proposto pelo surgimento do Airbnb. 
 
Planejamento da qualidade 
Assim como todo trabalho de planejamento, o da qualidade não poderia ser diferente e 
demonstrará todas as regras para que o assunto qualidade seja gerenciado e verificado ao longo do 
projeto, sem permitir que o assunto gere dúvidas para os principais interessados. É necessário que se 
desenvolva um documento base que será tratado como a principal referência no assunto, denominado 
Plano de Gerenciamento da Qualidade (PGQ), o qual, entre outras missões, deverá definir os padrões 
 
 
 95 
 
desejados da qualidade, as métricas para a validação das principais entregas vinculadas ao escopo do 
produto e do projeto, as condutas para a melhoria contínua de processose de detalhes que influenciam 
os principais stakeholders do projeto, assim como a designação de técnicas, rituais e ferramentas que 
auxiliarão na verificação da qualidade ao longo de todo o ciclo de vida do projeto. 
No início dos trabalhos de desenvolvimento de um PGQ, é desejável que a visão do produto, 
serviço ou resultado a ser gerado já esteja determinada pela equipe do projeto. A necessidade de 
existir uma visão geral do escopo (mesmo que ligeiramente detalhada) serve para suportar as 
premissas de qualidade que advirão das expectativas levantadas com o cliente/usuário final. Segundo 
Pitchler (2011, p. 26) “[...] ser capaz de antever como um novo produto ou a sua próxima versão 
deve se parecer e se comportar é essencial para chegar lá. Esta antevisão resulta em um esboço do 
produto futuro”. A visão do produto deve comunicar tal essência de uma maneira que facilite o 
processo de criatividade da equipe. Estamos tratando da razão de ser do produto, serviço ou 
resultado a ser gerado, portanto, quanto mais se conhecer sobre a proposta de execução nesse 
momento, melhor será para sustentar os detalhes do planejamento da qualidade. 
Para que o planejamento da qualidade tome forma, toda e qualquer informação do projeto 
será bem-vinda. Contudo, nem sempre o grupo trabalhará com informações muito sólidas nesse 
momento protagonizado pela equipe do projeto (ou equipe da qualidade) e, portanto, todas as 
fontes primárias de informações, por exemplo, o termo de abertura do projeto ou as documentações 
do escopo, serão tratadas como boas referências de informação, contanto que estejam atualizadas e 
sejam confiáveis, pois podem concentrar não só detalhes pré-projeto mas também os demais 
conhecimentos oficiais do projeto até o presente momento. Um plano geral para o gerenciamento 
do projeto provavelmente ainda não está completamente terminado, mas independentemente do 
que esteja pronto ou não, informações oriundas do trabalho da equipe com o levantamento, a 
análise e a classificação dos requisitos, por exemplo, são fundamentais para que as métricas da 
qualidade possam ser corretamente descritas. Não obstante, é importante que se avaliem também 
todas as especificações constantes da linha de base do escopo, pois minúcias do escopo do produto 
projetados na EAP (ou qualquer outra técnica destinada para descrever o escopo do produto), o seu 
dicionário e os pormenores de documentos de especificação do escopo serão de suma importância 
para que a necessidade da qualidade possa ser bem caracterizada, afinal de contas, todas as entregas 
e os processos que tenham como objetivo uma revisão de qualidade estarão (ou deveriam estar) 
elencados nesse compêndio de informações. Utilizar os critérios de aceitação definidos na linha de 
base do escopo para definir muitos critérios de validação pode aumentar consideravelmente o custo 
da qualidade do projeto. No entanto, o cumprimento de todos os critérios de validação significa 
dizer que as principais partes interessadas ficarão satisfeitas com o bom andamento dos trabalhos 
da qualidade. Exatamente por isso, um plano de engajamento das partes interessadas, caso exista, 
pode representar uma excelente fonte de informações sobre como as necessidades e as expectativas 
dos stakeholders precisam ser saciadas. Um plano de gerenciamento dos riscos também se demonstra 
uma peça importante, pois análises detalhadas dos riscos e avaliações dos impactos nos demais 
planejamentos do projeto, como cronograma, custos, recursos, devem ser consideradas. 
 
96 
 
São muitas as ferramentas e as técnicas possíveis para que esse planejamento tome forma. É 
comum ao Guia PMBOK® (PMI, 2017a) sempre discriminar uma série de opções para que os 
processos da qualidade tenham êxito, mas é sempre importante lembrar que as técnicas e 
ferramentas nunca estão limitadas àquelas demonstradas pela metodologia, ou seja, não há porque 
prender-se à seleção aqui apresentada, podendo existir muitas outras maneiras de transformar as 
informações recebidas como inputs em futuros entregáveis do projeto. 
A primeira técnica é opinião especializada, cuja aplicação já estudamos junto ao planejamento 
do escopo. Nesse caso, refere-se a qualquer tipo de conhecimento da qualidade disseminado para a 
equipe do projeto, como medições, garantias, controles, melhorias ou sistemas de qualidade. Na 
sequência, temos a técnica de coleta de dados, aqui aberta em benchmarking (comparações práticas de 
padrões da qualidade ou melhores práticas, tanto de projetos internos como externos à organização 
executora); brainstorming (técnica utilizada para gerar momentos de ideação e criatividade, sem 
restrições, tanto com a equipe do projeto como com especialistas em determinados assuntos, mesmo 
que externos); e, a técnica de entrevistas (forma pela qual as principias partes interessadas podem vir a 
contribuir fornecendo informações sobre as necessidades e as expectativas da qualidade para o projeto 
e para o produto). Duas técnicas de análise de dados também são mencionadas: análise de custo-
benefício e análise de custo da qualidade (CDQ). A primeira trata de uma ferramenta clássica de análise 
financeira que impulsiona muitas tomadas de decisão por parte da equipe do projeto, pois permite 
avaliar os pontos fortes e fracos, fornecer alternativas e direcionar o grupo em prol do melhor 
benefício. Essencialmente, direciona o time na avaliação de quais atividades da qualidade são eficazes 
em relação aos seus custos, levando-se em consideração fatores como menos retrabalho, aumento de 
lucratividade, aumento de satisfação das partes interessadas, maior produtividade e custos reduzidos, 
entre outros. A segunda trata especificamente de outros custos, aqueles vinculados ao CDQ, já 
mencionados no módulo II: custos de prevenção, custos de avaliação e custos de falhas, sejam internas 
ou externas. Apesar de não ser algo tão simples de se determinar, geralmente, os dois primeiros 
(prevenção e avaliação), quando equilibrados, podem gerar redução do último (falhas). Existe também 
a sugestão de utilização de técnicas de tomadas de decisão, excetuando-se tudo o que já foi 
demonstrado até aqui (que sempre será, de alguma maneira, incentivo para processos de tomada de 
decisão), havendo uma maior carga de atenção para as análises de decisões envolvendo critérios 
múltiplos. O PMI (2017a, p. 319) registra que “[...] ferramentas para análise de decisão envolvendo 
critérios múltiplos (por exemplo, matriz de priorização) podem ser usadas para identificar as principais 
questões e alternativas adequadas a serem priorizadas como um conjunto de decisões para 
implementação”. Assim, fórmulas matemáticas são utilizadas para estabelecer alternativas ponderadas 
e, futuramente, priorizadas. Um exemplo clássico de utilização dessa ferramenta em relação à 
qualidade é a priorização de métricas da qualidade. 
Fluxogramas (mapas de processos ou gráficos de procedimentos) são considerados uma das 
sete ferramentas básicas da qualidade. Eles são uma representação gráfica, por meio de símbolos, 
que podem significar desde a natureza da ação até o fluxo de desenvolvimento de processos 
específicos. São simples e, ao mesmo tempo, ferramentas complexas, pois bons fluxogramas 
 
 
 97 
 
demandam conhecimento real sobre o processo estudado ao explorar todas as possibilidades, 
destrinchar ramificações de processos, demonstrar dependências de entradas e saídas, iluminar 
pontos de decisão/atenção, atividades, gargalos, ordens e sequências paralelas, entre muitos outros 
detalhes que permitam uma avaliação completa para que se entenda como estimar o custo da 
qualidade. Acima de tudo, descrevem (como pode ser verificado no exemplo proposto na próxima 
figura) as decisões que devem ser tomadas, permitindo que se visualize o percurso que trará o melhor 
resultado quando avaliadas todas as hipóteses possíveis vinculadas ao processo. 
 
Figura 26 – Exemplo de fluxograma para a implementação de um CEP – 
Controle Estatísticode Processos 
 
Fonte: ADAMY et al. (2017). 
 
98 
 
Ainda tratando de possíveis técnicas e ferramentas, é factível a utilização de representações de 
dados. Muitas são as técnicas que poderiam estar aqui discriminadas, mas nos limitaremos às 
seguintes: modelos lógicos de dados (representações visuais dos dados de uma organização, traduzidos 
em linguagem específica, que auxiliam na identificação de problemas na integridade dos dados ou 
em situações vinculadas à qualidade); diagramas matriciais (demonstram correlações entre diferentes 
fatores, causas e objetivos, que possam eventualmente existir em uma matriz, fornecendo uma 
triangulação de informações que alinham a percepção das métricas da qualidade); e, mapeamento 
mental (método visual de apresentação de informações que preconiza a cooperação do time do 
projeto ou de partes interessadas, especialmente selecionadas para auxiliar na análise e na 
necessidade dos requisitos da qualidade, assim como restrições, dependências e correlações). Por 
fim, não podemos deixar de mencionar técnicas de testes e inspeções, visando à instituição das 
verificações para possíveis validações (ou não) dos requisitos e técnicas de reuniões, que incluirão 
quaisquer recursos (materiais, estruturais ou humanos) que possam ter responsabilidades ou graus 
de dependência em atividades vinculadas ao planejamento da qualidade do projeto. 
 
Documentos vinculados ao planejamento da qualidade 
Para que o planejamento aqui mencionado produza uma sólida base de referência para os 
trabalhos da qualidade ao longo do projeto, é recomendado que uma linha de base da qualidade 
seja documentada, minimamente representada por um PGQ e uma documentação de métricas da 
qualidade. Automaticamente, essa documentação, tão logo esteja concluída, terá o potencial de 
atualizar muitas informações para a equipe do projeto e os seus principais stakeholders, e muitas 
delas deverão ser transmitidas para as demais áreas de trabalho, permitindo que muitas 
documentações complementares possam ser atualizadas. 
O PGQ, um dos componentes mais importantes do planejamento de um projeto, além de 
descrever todas as políticas, diretrizes, normas e procedimentos que serão instituídos para a 
obtenção de todas as metas destinadas à qualidade do produto, serviço ou resultado que está sendo 
gerado pelo time do projeto, também visa a descrever as atividades e a prever os recursos destinados 
ao alcance do sucesso da qualidade para o projeto. Segundo o PMI (2017a), o PGQ deve conter, 
não se restringindo a esta lista, as seguintes informações: 
 
 
 
 
 99 
 
Quadro 11 – Plano de gerenciamento da qualidade 
O plano de gerenciamento da qualidade pode incluir, entre outros, os seguintes 
componentes: 
 padrões da qualidade que serão usados pelo projeto; 
 objetivos da qualidade do projeto; 
 papéis e responsabilidades da qualidade; 
 entregas do projeto e processos sujeitos a revisão da qualidade; 
 atividades de controle da qualidade e gerenciamento da qualidade planejadas 
para o projeto; 
 ferramentas da qualidade que serão usadas pelos projetos; 
 procedimentos importantes relevantes para o projeto, como lidar com não 
conformidades, procedimentos para ações corretivas e procedimentos para melhoria 
contínua. 
Fonte: PMI (2017a). 
 
A fim de tornar fiáveis as muitas entregas vinculadas ao projeto, a determinação de padrões 
da qualidade é o primeiro item de importância em um PGQ. Somente por meio dos padrões da 
qualidade é que se pode buscar um alto grau de satisfação do cliente/usuário final do produto, 
serviço ou resultado a ser gerado pela equipe do projeto, pois são essas definições que permitem 
perceber a exatidão do que se está buscando, assim como auxiliam no processo de estipulação dos 
indicadores para mensurar parâmetros. Em termos práticos, digamos que uma determinada 
empresa deseja contratar uma consultoria especializada para realizar um trabalho de assessment 
(diagnóstico) da estrutura de tecnologia da informação dela, para confirmar se está corretamente 
dimensionada para as suas necessidades. Antes de realizar a contratação, é adequado que sejam 
definidos padrões de qualidade para a empresa que realizará o serviço de consultoria, por exemplo, 
exigir certificados de excelência proferidos por entidades respeitadas ou reconhecidas 
internacionalmente, experiência mínima comprovada em serviços semelhantes com empresas do 
porte da contratante, atestados de capacidade técnica, quadro de profissionais com determinadas 
formações e capacitações ou expertises, entre outros quesitos que possam ser considerados como 
imprescindíveis. Os demais itens de um PGQ são praticamente autoexplicativos e dependem das 
muitas informações vinculadas ao projeto para que a customização desses detalhes traduza o melhor 
possível a definição de ferramentas, processos, políticas, objetivos, papéis, responsabilidades, 
procedimentos, controles e tudo o mais que for importante para que se defina o que será 
determinante para a implementação do plano de gerenciamento da qualidade. Alguns projetos 
tendem a incluir também planos de melhorias de processos no PGQ. No entanto, isso costuma ser 
algo percebido em culturas organizacionais com alto nível de maturidade em gerenciamento de 
projetos ou, ainda, alto grau de exigência por parâmetros da qualidade. 
 
100 
 
Vejamos dois detalhes importantes sobre o PGQ: o primeiro deles é que revisões do plano de 
gerenciamento da qualidade são tratadas como boas práticas, pois permitem que o time do projeto 
avalie constantemente os benefícios trazidos pelo fiel cumprimento do plano em relação aos custos 
do projeto (verifique o que já estudamos sobre o custo da qualidade). Tomadas de decisão 
provenientes desse tipo de análise precisam ser fundamentadas em uma sólida base de informações, 
de preferência com o foco permanente em entrega de valor percebido pelo cliente/usuário final. O 
segundo diz respeito a organizações que já possuem determinadas certificações da qualidade ou 
rigores de práticas da qualidade estabelecidas por lei, que deixam padrões da qualidade acima de 
qualquer plano de gerenciamento da qualidade escrito por qualquer time de projeto. Nesse caso, o 
PGQ passa a assumir as condições de alto grau dessas certificações ou práticas, apenas auxiliando 
na disseminação dessas informações aos principais stakeholders do projeto. 
Quanto às métricas da qualidade, são especificações que descrevem os atributos de um 
produto (serviço ou resultado) ou, até mesmo, do projeto em si. É um artefato de extrema 
importância, pois essas informações serão a base para o trabalho da equipe no momento de controlar 
a qualidade. Podem incluir percentuais de tarefas concluídas em um determinado período de 
tempo, índices de falhas e pontuações para índices de satisfação, entre muitas outras propostas de 
utilização. Conforme descrito na próxima figura, podemos observar um extrato de um caso prático 
da implementação de um Serviço de Atendimento ao Cliente (SAC). 
 
Figura 27 – Métricas da qualidade 
PROJETO: Implementação de um SAC – Serviço de Atendimento ao Cliente. 
ATRIBUTO: Atendimento do SAC. 
REQUISITO: Rapidez no atendimento telefônico. 
INDICADOR: % de chamadas respondidas até o segundo toque. 
META: Responder 95% das chamadas até o segundo toque. 
PADRÃO: Determinar % das chamadas até o segundo toque durante o período de testes, nas 
primeiras 48 horas. 
Requisito de 
Qualidade 
Indicador Meta Técnica de medição Frequência Responsável 
Rapidez no 
atendimento 
telefônico do 
SAC 
ICR* = % de 
chamadas 
atendidas 
até o 2º 
toque / % de 
chamadas 
totais 
atendidas 
ICR > 
ou = 
0,95 
Contar, 
manualmente, 
número de chamadas 
totais atendidas e 
número de chamadas 
atendidas até o 2º 
toque 
Única 
(primeiras 48 
horas do 
período de 
testes) 
Auditor de 
qualidade 
(*) ICR = Índice de Chamadas Recebidas 
Fonte: adaptado de ESCRITÓRIO DE PROJETOS (2017). 
 
 
 101 
 
Um artefato de métricasda qualidade dispõe sobre todas as informações necessárias para 
responsabilizar, verificar e comunicar um grau de medição atrelado a um determinado 
requisito/atributo da qualidade de um produto, serviço ou resultado a ser desempenhado pelo 
projeto. Salienta-se que o erro mais comum a ser evitado é a atribuição de indicadores, sem vincular 
a sua medição a uma possível meta (de preferência, mais de uma). Nada adiantaria, por exemplo, 
mensurar o ICR, se não existisse o propósito (ou a necessidade) de atingir um objetivo com 95% 
de sucesso. Toda métrica precisa ser representada por algum tipo de medida, sendo esta traduzida 
por um número ou proporção (valor real). Se for o caso, devem-se definir limites de controle (ou 
de tolerância – conforme estudamos no módulo II), podendo considerar uma variação aceitável 
(margem de erro ou de sensibilidade) para aumentar o nível de abrangência do resultado. Uma coisa 
é dizer “Amanhã estarei em casa às 18 horas”; outra é dizer “Amanhã estarei em casa às 18 horas, 
podendo variar cerca de 10 minutos para menos ou para mais”. O nível de abrangência passará a 
ser consideravelmente maior, pelo fato de ampliar em 20 minutos a margem de tolerância. Ou seja, 
a probabilidade de acerto será bem maior. No entanto, a precisão da métrica pode ser questionada 
por ser considerada muito tolerante. O fato é que, ao longo do projeto, muitos ajustes e tomadas 
de decisão serão realizados com base no grau de informações existentes nesse documento. Quanto 
melhor especificadas forem as informações constantes da métrica da qualidade, maior a chance de 
obter um alto índice de satisfação das principais partes interessadas e de alinhar a entrega de valor 
percebido ao cliente/usuário final. 
Com o planejamento da qualidade completo e exibindo as primeiras versões de importantes 
artefatos, o projeto começa a tomar um novo rumo. Muitas das informações necessárias para que a 
equipe do projeto possa iniciar os trabalhos (caso ainda não tenha iniciado) estão disponíveis, 
permitindo que a dinâmica da equipe do projeto passe a ser relativamente diferente, pois os esforços 
destinados ao planejamento começam gradativamente a ser reduzidos e a se concentrar mais nos 
trabalhos de execução e, em alguns casos, de monitoramento e controle. 
 
Retrospectiva do módulo 
O módulo V apresentou um breve resumo de como os três Ks do modelo de gestão Toyota 
podem influenciar os trabalhos da qualidade de um projeto. Descobrimos que muito pode ser feito 
no intuito de provocar modelos mentais de melhoria contínua afetando diretamente intangíveis 
organizacionais e provocando profundas mudanças no modus operandi das equipes de projetos. 
Vimos que o Kaizen se relaciona diretamente com o fazer desta vez melhor que da vez anterior, 
notadamente por meio de uma boa gestão dos 3 Ms (mura, muda e muri), encorajando mudanças 
incrementais e contínuas. Já o Kaikaku denota uma mudança mais radical, uma mudança de rumo 
mesmo. Sempre que o Kaizen chega a um determinado limite é o momento de experimentar algo 
novo, e isso ocorre por meio da exploração de novas tecnologias ou de novas expertises. Por fim, o 
 
102 
 
conceito de Kakushin significa algo totalmente revolucionário, em que o modelo de negócio pode 
ser questionado e até mesmo o propósito de trabalho poderá sofrer influências, pois a aplicação de 
inovação surge para quebrar paradigmas e redefinir padrões. 
Além disso, vimos a influência dos principais artefatos do planejamento da qualidade no ciclo 
de vida de um projeto, compreendendo como é a sequência dos trabalhos desencadeada após o 
início do planejamento do escopo, que consequentemente disseminará informações preciosas para 
os demais temas do projeto. A qualidade é uma sequência lógica, pois o trabalho de levantamento 
dos requisitos, a especificação e a confecção de uma linha de base do escopo, leva a equipe do projeto 
a novos desafios. É preciso determinar como aquilo que ficou detalhado no momento do temos de 
fazer isso será efetivamente validado, evitando atritos com muitas das principais partes interessadas 
do projeto. Para que esse trabalho possa ser realizado, verificamos a necessidade da confecção de 
um plano de gerenciamento da qualidade e a importância das métricas da qualidade para o futuro 
da execução e do controle da qualidade ao longo do projeto. Como resultado, identificamos os 
templates de um plano de gerenciamento da qualidade e de uma documentação de métricas da 
qualidade, detalhando componentes e algumas peculiaridades. 
 
Pronto para mais uma etapa de verificação de conhecimento? Então, responda, 
corretamente, as seguintes perguntas: 
1. Qual a importância dos 3Ks para uma organização? E, no nível de um projeto, como 
podemos perceber sua aplicação? 
2. Enumere e explique a maior quantidade de técnicas/ferramentas comumente 
utilizadas para o planejamento da qualidade em um projeto. 
3. Qual a importância de métricas da qualidade em um projeto? 
 
 
 
 
 
 
O módulo VI trata do momento pós-planejamento do gerenciamento do escopo, que é 
quando ocorrem situações importantíssimas, que auxiliam a caracterizar o avanço do projeto e a 
necessidade de ajustes, ou seja, processos ligados ao gerenciamento de mudanças do projeto. Com o 
trabalho de desenvolvimento da equipe do projeto sendo realizado, o time responsável pelo escopo 
volta os olhos para as entregas. Todas (ou ao menos as mais importantes) as que são vinculadas à 
linha de base do escopo serão (ou deverão ser), em algum momento, verificadas quanto à precisão 
dos requisitos definidos na documentação do projeto. Entregas verificadas e chanceladas pela equipe 
da qualidade são documentadas e encaminhadas para aceite sempre que necessário (nem todas as 
entregas precisam estar vinculadas a critérios de aceitação). O aceite se dá de maneira formal ou 
informal, mas sempre documentado conforme as necessidades do projeto e das principais partes 
interessadas. Sempre que uma entrega for verificada e encontrar qualquer grau de desconformidade, 
um momento de tomada de decisão precisa ser estabelecido. Se o ‘realizado’ encontra-se diferente 
do ‘previsto’, esforços precisam ser realizados para avaliar a situação de acordo com o momento 
vivido pela equipe do projeto no sentido de compreender o problema, verificar causas e impactos 
de possíveis ajustes, estabelecer solicitações para correções e processos de melhoria, além de registrar 
todo o trâmite das ações para estimular a gestão do conhecimento organizacional. Tais esforços não 
só são vinculados ao gerenciamento do escopo e da qualidade, mas fielmente ligados ao 
gerenciamento das mudanças dos projetos. Por fim, não custa lembrar, escopo bom é escopo 
verificado, chancelado, aceito (transmitido/entregue) e documentado. 
MÓDULO VI – ACOMPANHAMENTO, 
VALIDAÇÃO DOS REQUISITOS, ACEITAÇÃO 
DAS ENTREGAS E CONTROLE DO ESCOPO 
 
104 
 
Acompanhamento do escopo e validação dos requisitos 
Uma das provas de que o gerenciamento do escopo não acontece sozinho em um projeto é o 
(tenso) momento de validação. É impossível presenciar um momento mais oportuno para a 
demonstração de como o trabalho do gerenciamento do escopo está intimamente ligado ao 
gerenciamento da qualidade, além de depender de uma série de fatores que poderão levar a um 
fluxo de controle integrado de mudanças. 
Existem duas situações ao analisarmos um fluxo de validação do escopo: a primeira ocorre 
quando se recebe a confirmação, por parte da área ou do time da qualidade, de que uma determinada 
entrega foi verificada e as precisões dos seus requisitos foram chanceladas. Quando isso ocorre, o fluxo 
dos processos segue naturalmente para o encerramento do projeto, pois a área ou o time do escopo 
concebe e documenta as informações necessárias para chancelar a aceitação dessas entregas. Baseado 
nesse fluxo de validações das entregas, há a possibilidade de encerrar o projeto – à medida que todas 
as entregas conseguem ser verificadas e, posteriormente, validadas– ou alguma fase intermediária (ou 
uma etapa importante vinculada a algum milestone) do projeto. A segunda situação ocorre quando a 
equipe 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 justificado ou por 
uma solicitação de mudança (algumas organizações optam por manter a utilização do termo em inglês, 
change request). 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 e algo muito 
comum. Afinal, como todo processo de mudança, será necessário avaliar o impacto dessa solicitação 
em uma série de eventos/artefatos do projeto, como mapas de riscos e planos de comunicações, entre 
muitos outros. Como é possível afirmar que um projeto sem mudanças é algo utópico, ao menos em 
algum momento é esperado que ocorra esse fluxo destinado a uma solicitação de mudança, acionando 
o controle integrado de mudanças do projeto, normalmente vinculado a fluxos pré-definidos por um 
plano de gerenciamento de mudanças. 
O time responsável pelo escopo então, em vez de validar a entrega, dispara um alerta de 
solicitação de mudança que, naturalmente, será avaliado por um comitê de mudanças. Contudo, 
não há como se enganar, o objetivo maior do momento de validação do escopo é o de buscar e, 
consequentemente, realizar a aceitação de todas as entregas. Afinal de contas, estando tudo a 
contento, não haverá necessidade de qualquer tipo de controle do escopo, que no futuro poderá 
gerar um novo fluxo de avaliação visando ao rigor das precisões das entregas e dos cumprimentos 
dos requisitos do produto e do projeto (devidamente atualizados e especificados). 
 
 
 
 105 
 
Uma boa ferramenta para acompanhamento dos escopos validados ou enviados para controle 
é um quadro visual que possa ser atualizado constantemente, de preferência ao final dos ciclos 
iterativos de entrega ou vinculado a um cronograma de marcos. Isso não só servirá de documentação 
para o fluxo de entregas validadas ou enviadas para controle mas também poderá servir como ponto 
de discussão e apoio para o aprendizado com erros e ajustes para a melhoria contínua. 
 
Figura 28 – Painel visual para acompanhamento de entregas 
 
 Fonte: elaborada pelo autor. 
 
A vantagem de um painel visual de acompanhamento de entregas é que a equipe do 
projeto estará sempre lidando com o fluxo de entregas (estará lá, para todos visualizarem) e 
lembrando, constantemente, daquilo que tem algum tipo de pendência. É uma técnica visual 
simples de ser atualizada e que envolve a colaboração de todos, ou seja, ao mesmo tempo deixa 
toda a equipe ciente de pormenores sobre qualquer espécie de entrega, podendo atuar para que 
o fluxo esteja sempre retificado e o mais próximo da eficiência desejada para a conclusão dos 
trabalhos de um determinado período. 
Outra técnica/ferramenta que também poderá ser utilizada é a própria EAP, pois, a partir do 
momento em que ela existe, o acompanhamento das entregas (seja manual, seja por meio de 
sistemas de informações/softwares de gestão) poderá ser facilmente visualizado. O importante é 
apenas definir a necessidade de informação e, muitas vezes, a questão da acessibilidade. Talvez nem 
todos os stakeholders tenham necessidade de visualizar todas as informações e, por vezes, algumas 
legendas ou imagens deverão ser decifradas (decodificadas) por meio de outros formatos. 
 
 
 
106 
 
Figura 29 – EAP como acompanhamento de entregas 
 
Fonte: adaptado de XAVIER (2009). 
 
A necessidade do projeto sempre definirá o nível de informação necessário sobre o 
rastreamento das entregas. Muitos são as técnicas e os artefatos que auxiliarão a equipe do projeto, 
como matrizes de rastreabilidade dos requisitos. No entanto, os sistemas de informação em projetos 
e ferramentas de compartilhamento têm se mostrado verdadeiros aliados, e muitos protocolos 
acabam surgindo por causa de padrões determinados pelos próprios softwares de gestão. Poderíamos 
tratar de uma série destes, mas como isso não é o propósito de nosso estudo (ainda), veremos apenas 
o extrato de um dos mais conhecidos no mercado, conforme apresentado na figura a seguir. 
 
Figura 30 – Padronizações em acompanhamento de entregas 
 
Fonte: elaborada pelo autor. 
 
Uma padronização de utilização de cores é muito comum para avaliar o avanço de um pacote 
de trabalho ou de uma entrega específica em uma conta de controle. Os três retângulos acima 
representam a entrega de um mesmo pacote de trabalho, sempre associados a informações 
financeiras, de uma EAP fictícia, porém cada um representando uma situação diferente em relação 
 
 
 107 
 
à entrega, ou seja, cada um com uma peculiaridade vinculada ao seu acompanhamento. O da 
esquerda, na cor azul, ilustra um trabalho integralmente realizado (o percentual de 100% é 
demonstrado, sendo que as duas linhas que cortam diagonalmente o retângulo reforçam 
visualmente a ideia), e dentro das expectativas financeiras, pois, ao compararmos o previsto em 
relação ao realizado, há sobra de recursos financeiros. O retângulo central demonstra um trabalho 
parcialmente realizado (50% concluído em termos de entregas daquilo que precisa ser realizado e 
por isso o reforço visual de apenas uma linha cortando a imagem diagonalmente), mas ainda dentro 
das expectativas financeiras, pois o valor gasto até o presente momento ainda está abaixo quando 
proporcionalmente comparado aos 50% realizados do escopo. Mesmo que projetado no futuro, 
esse valor continuaria dentro das estimativas iniciais dos recursos financeiros daquele pacote de 
trabalho. No entanto, cabe aqui um aparte, pois nem sempre essa correlação será verdadeira, pois é 
possível uma entrega consumir muitos recursos financeiros no início dos trabalhos e encontrar o 
seu valor estimado apenas ao final. Se, nesse mesmo exemplo, os recursos financeiros tivessem sido 
consumidos em 80%, mas o escopo tivesse avançado apenas 50%, ainda assim seria possível alcançar 
o planejado ao final dos 100% (dos recursos financeiros e do escopo). É sempre importante avaliar 
as informações disponíveis em conjunto com outros dados que possam auxiliar na avaliação da 
situação e de futuras tomadas de decisão da equipe do projeto. O último retângulo, na cor vermelha, 
demonstra que a entrega foi integralmente realizada (100% e duas linhas cortando a imagem), mas 
que os recursos financeiros extrapolaram as estimativas iniciais. Caberá à equipe do projeto justificar 
os gastos extras e avaliar o impacto disso no futuro do projeto, para decidir o que precisará ser 
realizado no sentido de ajustar o planejamento inicial à realidade de execução do projeto. 
A documentação dos requisitos assim como a linha de base do escopo são as principais 
referências para que possa existir uma comparação entre o status quo e o que foi efetivamente 
realizado, visando a determinar se uma solicitação de mudança, ou 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 ela contém informações valiosas sobre como os requisitos 
deverão ser aceitos e validados. Relatórios de lições aprendidas ou outros documentos que permitam 
difusão da gestão do conhecimento do projeto, assim como relatórios da qualidade, também 
poderão servir de grande valia para o auxílio na validação do escopo, pois aumentarão as chances 
de eficiência e de eficácia no momento da aceitação das entregas. 
Se um determinado pacote de trabalho não estiver corretamente definido na linha de base do 
escopo, não há como passar pelo processo de verificação da qualidade e, posteriormente, 
transformar-se em entregas aceitas (momento em que a informação deveria seguir adiante e ser 
transmitidapara viabilizar o encerramento – ou parte – dos trabalhos). Sem a verificação da 
qualidade, o principal papel do momento de validação do escopo, que é o de buscar futuramente 
todas as aceitações das entregas, não conseguiria ser executado. 
 
 
108 
 
É comum que o processo de verificação da qualidade ocorra 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. Em alguns 
casos, projetos utilizam critérios de aceitação vinculados ao cumprimento de alguns requisitos da 
qualidade, sendo possível ganhar tempo em momentos importantes do projeto. 
 
Aceitação das entregas 
Quando um critério de aceitação é formalmente recebido pela parte interessada competente, 
significa dizer que há uma entrega aceita. A priori, uma entrega aceita é o que melhor caracteriza o 
momento de validação do escopo, pois trata-se do seu objetivo máximo conseguir todas as aceitações 
do projeto. Contudo, existe a possibilidade de emissão de novos dados a respeito do desempenho 
do trabalho, independentemente de as entregas serem aceitas ou não. Essas informações tendem a 
ser documentadas e transmitidas aos principais stakeholders, assim como são documentadas todas as 
peculiaridades em relação à aceitação das entregas. Aquilo que não recebe um aceite formal 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 visa a um processo de análise e entendimento da situação para que possa ocorrer 
uma reavaliação do(a) problema/questão e a sua futura correção/resolução. Contudo, esse trabalho 
será direcionado ao momento de controlar o escopo, acionando processos de mudanças também 
preconizados no planejamento do projeto. 
Um documento que pode auxiliar bastante no processo de aceitação de entregas é um 
formulário de aceitação formal, que tanto vem a ser uma lista de verificação que pode auxiliar os 
trabalhos oriundos da equipe da qualidade, quando o foco for verificar a exatidão da entrega ou a 
precisão dos requisitos vinculados a ela, como sequenciar essas informações e promover o trâmite 
integrado e natural para a equipe que lida com o gerenciamento do escopo, cujo foco é verificar se 
a validação dos requisitos atende aos critérios de aceitação acordados com o cliente/usuário final. 
Um modelo desse formulário pode ser visualizado no quadro a seguir. 
 
Quadro 12 – Formulário de aceitação formal 
título do projeto data de elaboração 
ID requisito 
critério de 
validação 
critério de 
aceitação 
status comentários aprovação 
 
 
 
Fonte: adaptado de SNYDER (2013). 
 
 
 109 
 
As quatro primeiras colunas são informações retiradas da documentação dos requisitos, o 
que facilita 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, ou 
ainda parcialmente aceito –, além de um espaço para observações, por exemplo: informações 
detalhadas 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 se espera desse processo. Por fim, coleta-se a confirmação de 
quem foi a parte interessada responsável por aceitar respectiva entrega. É importante frisar que, 
apesar de estarmos lidando com modelos de documentos em papel ou planilhas eletrônicas – que 
podem ser facilmente adaptados para sistemas de informações digitais, promovendo um melhor 
grau de mobilidade – existem alternativas mais modernas, disponíveis no mercado, que facilitam 
aceites virtuais entre outras alternativas. 
Para consolidarmos o entendimento sobre aceitação de entregas e validação de requisitos, 
vamos retomar o exemplo prático que foi dado no capítulo IV, quando estudamos como deve ser 
descrito um pacote de trabalho no dicionário da EAP (quadro 9). 
Aquele exemplo de pacote de trabalho, chamado “treinamento da equipe”, encontra-se 
vinculado a uma entrega importante do projeto e está detalhado de tal maneira a não existirem 
dúvidas acerca da sua execução (conforme os tópicos na coluna “descrição”). É possível verificar 
que estão listados todos os requisitos necessários para que o pacote de trabalho possa ser gerado 
da maneira que foi idealizado. Outra função desse artefato é promover a integração desse pacote 
de trabalho com outros com os quais ele possua ligação e, potencialmente, possam interferir 
diretamente ou indiretamente no seu planejamento e execução, por exemplo, os pacotes de 
trabalho de “coffee break” e “material didático”. Por fim, os critérios de validação permitem que 
a equipe do projeto entenda qual é o passo a passo para que aquele pacote de trabalho possa 
ganhar o status de “realizado”, após um processo de verificação. Lembrando que a maneira como 
o setor de qualidade fará as checagens está determinada nas métricas da qualidade, dentro do 
plano de gerenciamento da qualidade do projeto. Tão logo os critérios possam ser verificados e 
validados, o time do escopo do projeto poderá formalizar a aceitação do pacote de trabalho, caso 
haja necessidade. Todas as demais informações, por exemplo, nível de esforço, códigos e, por 
vezes, até questões de responsabilidade, servem para integrar a área de escopo com outros setores, 
como área financeira, de cronograma, de riscos, etc. Eventuais problemas que fujam às diretrizes 
estipuladas nesse documento do projeto, precisariam passar por processos de verificação e 
controle, por vezes, incitando solicitações formais de mudança. 
 
 
 
110 
 
Controle do escopo 
Segundo o PMI (2017a, p. 203), controlar o escopo é o momento “[...] 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”. Trata-se de uma situação que só poderá ser acionada na 
sequência de tentar validar um escopo e a equipe não obter êxito. 
Caso o planejamento do projeto não tenha estipulado um plano integrado de mudanças 
(como ocorrerão os fluxos das mudanças de um projeto), segundo Louzada (2017), algumas 
diretrizes são recomendadas para desenvolver um bom processo para gerenciar mudanças 
vinculadas ao escopo, como: 
 definir critérios para avaliar as propostas de mudanças (iniciadas por uma change request – 
solicitação de mudanças); 
 manter a comunicação com as demais equipes/setores organizacionais para verificar como 
será gerenciado o controle integrado da mudança; 
 avaliar o impacto da mudança no objetivo de negócio (normalmente, viabilizado por 
documentações de viabilização do projeto, como um plano de negócios ou estudos de 
mercado/viabilidade); 
 definir de quem serão as responsabilidades pelas mudanças; definir como elas serão 
priorizadas e documentadas e 
 atualizar as avaliações de riscos e os seus potenciais novos impactos. 
 
Para que todas as análises do escopo – do projeto ou do produto – possam ocorrer da melhor 
maneira possível, a linha de base do escopo precisa estar disponível, pois não só é a documentação 
responsável por conter todas as referências que serão comparadas para verificar o(s) requisito(s) 
afetados por uma solicitação de mudança, como também qualquer inovação que requeira uma 
reavaliação geral daquilo que foi elicitado. 
Os cuidados com as informações para um possível controle do escopo são muito semelhantes a 
um processo de verificação do escopo para efeitos de aceitação, pois a base de documentação que 
servirá de referência para a análise será praticamente a mesma. Muitos documentos do projeto, como 
o registro de lições aprendidas (no intuito de verificar se projetos similares ou fases anteriores do 
mesmo projeto contêm informaçõesque possam melhorar o gerenciamento do controle do escopo) e 
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. Dados sobre o desempenho de trabalho 
também são bem-vindos, afinal, são relatórios precisos acerca, por exemplo, da quantidade de 
solicitações de mudanças recebidas, das variações dos indicadores, da quantidade de entregas 
 
 
 111 
 
verificadas, validadas ou não. Por fim, a equipe do projeto também não deve deixar de verificar alguns 
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. 
Controlar o escopo nunca será algo isolado. Da mesma forma que o planejamento do escopo 
exerce força em potenciais impactos nas demais áreas ou setores vinculados a um projeto, o controle 
do escopo, necessariamente, precisa trabalhar com outros temas e os seus respectivos processos de 
controle, por exemplo, a necessidade de aumentar o número de rodas de um determinado veículo 
é um trabalho que precisaria estar alinhado com departamentos/fluxos de aquisições, avaliações 
conjuntas com equipes de riscos e fatores técnicos da qualidade, somente para mencionar alguns. 
Como o próprio PMI (2017a, p. 204) salienta: “[...] o aumento sem controle do escopo do produto 
ou projeto sem ajustes de tempo, custos e recursos é chamado de distorção de escopo”. 
 
Figura 31 – Controle do escopo 
 
Fonte: adaptada de GUIMARÃES (s. d.). 
 
Em suma, toda equipe do projeto sabe de antemão que passará por momentos que requerem 
ações corretivas/adaptativas com influências no escopo do produto, serviço ou resultado que está 
sendo gerado pelo projeto. O trabalho de gerenciamento do escopo será responsável por não deixar 
que esses momentos se perpetuem de maneira descontrolada, no sentido de evitar o fenômeno de 
scope creep. As variações (mudanças) solicitadas precisarão ser avaliadas em conjunto com toda a 
documentação e o conhecimento necessários, para que possam fluir pelos processos pré-
determinados de um controle integrado de mudanças. 
Para efeitos de análises de variação, representadas por referências e métricas que acompanham 
importantes pontos de qualquer projeto, é possível que mudanças do escopo impactem métricas 
operacionais, por exemplo, o percentual de cumprimento de um cronograma, ou métricas de 
desempenho, como um índice de satisfação do patrocinador do projeto (este último, mensurado 
após o término do projeto ou de alguma fase importante). 
 
112 
 
Retrospectiva do módulo 
O módulo VI fixou-se em apresentar todos os conceitos a respeito do momento pós-
planejamento do gerenciamento do escopo, notadamente em relação a ações de verificação (com fito 
de validação) e, caso necessário, controle (por disseminação de solicitações de mudança que acionarão 
o controle integrado de mudanças do projeto). Avaliamos, em primeiro lugar, como se acompanha o 
trabalho de verificação das entregas e, posteriormente, como se realiza a validação dessas entregas. O 
foco principal desse momento é a busca do aceite de todas as entregas, um trabalho realizado em 
conjunto com equipes multifuncionais que respondem pelos trabalhos da qualidade e da gestão de 
mudança, concomitantemente, com o trabalho de gestão do conhecimento. 
Listamos os principais problemas/fatores que costumam estar relacionados ao escopo e têm 
grande potencial de gerar revisões com chance de mudanças e exploramos algumas 
técnicas/ferramentas com baixo grau de complexidade e alto grau de engajamento, como painéis 
visuais para acompanhamento de solicitações de mudança e entregas em conformidade, além de 
peculiaridades da já conhecida EAP, analisando um pouco mais de perto os pacotes de trabalho e 
as suas propriedades. Se um determinado pacote de trabalho não estiver corretamente definido 
dentro da linha de base do escopo, torna-se muito difícil (quase impossível) passar pelo processo de 
verificação da qualidade e, posteriormente, transformar-se em entregas aceitas. Vimos que, um olhar 
detalhado, com atenção às entregas do escopo e os seus critérios de aceitação/validação é chave 
crítica para o sucesso do projeto. 
Pudemos avaliar um template simples, porém eficaz, para um formulário de aceitação formal 
que vincula critérios de aceitação e de validação, não deixando brechas para surpresas. 
Apesar de ajustes e ações corretivas serem recorrentes em projetos, sempre que é requisitada 
uma solicitação de mudança oriunda do escopo, tem-se a certeza de que essa mudança precisará ser 
avaliada em conjunto com toda a documentação e o conhecimento necessários, para que possa fluir 
pelos processos pré-determinados de um controle integrado de mudanças. 
Ao estudarmos esses últimos detalhes, fecha-se o ciclo do trabalho do gerenciamento do 
escopo em um projeto. Quando um escopo é trabalhado de maneira correta, todo esse trabalho se 
reflete no restante do projeto, sendo o contrário também verdade. 
Com os ensinamentos deste módulo, torna-se mais fácil compreender como aceitar as entregas 
ou promover as suas revisões, para buscar a perfeição do produto, serviço ou resultado que será gerado. 
 
Vamos lá... hora de responder, corretamente, as seguintes perguntas: 
1. Qual a diferença entre uma entrega validada e uma entrega aceita? 
2. Como a documentação e a rastreabilidade dos requisitos pode influenciar no 
acompanhamento do escopo de um projeto? 
3. Como se dá o aceite de uma entrega? Tente exemplificar com um caso prático. 
 
 
 
 
 
O módulo VII nos mostra como é tênue a linha que separa o gerenciamento e o controle da 
qualidade em um projeto. Muito do que se faz em prol da execução da qualidade evidencia possíveis 
trabalhos de controle que depois remetem a novos esforços de execução, ou seja, é um ciclo virtuoso 
que tende a explorar muitas boas práticas, técnicas e ferramentas para que tudo possa ser realizado 
da melhor maneira possível. As dezenas de práticas adotadas pela qualidade são extensas e muitas 
vezes adaptadas de outros meios, por exemplo, os de produção industrial. Por um lado, isso permite 
que times de projetos disponham de um leque de opções para encaminhar assuntos da qualidade e 
resolver possíveis problemas. Por ora, torna-se humanamente impossível falar de todos sem ser, de 
alguma forma, injusto com um determinado método ou framework. A seleção que acompanha este 
capítulo foi criteriosamente selecionada para poder atender às necessidades de estudo e ao roteiro 
de aprendizado desenvolvido pelo nosso material. Alguns itens, contudo, terão um maior peso em 
nosso ambiente virtual, por meio de estudos de casos e alguns outros exemplos práticos, facilitando 
o intercâmbio dos métodos de aprendizagem que este curso proporciona. Além disso, é importante 
frisar que executar a qualidade serve como referência para processos de melhoria contínua, pois 
também auxilia na distribuição de informações geradas durante o processo de controle da qualidade. 
Quanto a este, a equipe do projeto deve, antes de tudo, monitorar resultados e avaliar o grau de 
precisão dos requisitos. De posse das constatações derivadas do monitoramento, caso sejam 
encontradas desconformidades (falhas internas e externas), as causas dos resultados insatisfatórios 
deverão ser mapeadas e as ações corretivas determinadas, evitando novas ocorrências. Para isso, 
presenciaremos uma série de ferramentas, técnicas e práticas que poderão ser facilmente adaptadas 
para qualquer tipo ou porte de projeto. 
 
MÓDULO VII – GERENCIAMENTO E 
CONTROLE DA QUALIDADE 
 
114 
 
Gerenciamento da qualidade 
Gerenciar a qualidade significa executar na íntegra aquilo que foi preconizadopelo plano de 
gerenciamento da qualidade. Uma vez que o PGQ ganha vida, cabe ao time do projeto responder 
por padrões, procedimentos, abordagens e tudo o mais que estiver determinado pelos artefatos 
constantes desse compêndio da qualidade, que, além do PGQ, como bem recomendamos ao longo 
do módulo V, também demonstra-se adequado confeccionar uma documentação de métricas da 
qualidade, no intuito de facilitar os trabalhos de validação dos requisitos. Exatamente por isso, o 
PMI (2017a, p. 307) determina que gerenciar a qualidade significa “[...] traduzir o plano de 
gerenciamento da qualidade em atividades da qualidade executáveis que incorporam as políticas da 
qualidade da organização do projeto”. 
 No entanto, vale recordar que mesmo com todos os requisitos da qualidade devidamente 
mapeados e documentados, é possível que muitos aspectos vinculados à qualidade sofram 
influências das múltiplas variáveis que assolam o dia a dia de trabalho de qualquer equipe de 
projetos. Por isso, é correto afirmar que o trabalho da qualidade, mais que qualquer outro tema, 
deve se prender àquilo que se encontra definido pelo plano de gerenciamento da qualidade, 
documento que precisa ser constantemente revisado e atualizado para fazer frente a possíveis 
desafios e necessidades de mudanças. De nada adiantará um excelente trabalho da qualidade por 
parte da equipe do projeto, se, em qualquer momento, o cliente/usuário final decidir que um 
determinado aspecto já não faz mais sentido ou não agrega valor ao produto, serviço ou resultado 
que vem sendo gerado. Para Juran (2009, p. 99), o objetivo de um produto é “[...] satisfazer o 
cliente com a qualidade certa. Nem mais nem menos”. Ou seja, a necessidade de um trabalho 
próximo aos desejos, receios e expectativas do cliente/usuário final é uma condição que, cada vez 
mais, reverte-se em modernas boas práticas, evidenciando-se como um fator crítico de sucesso para 
o desempenho da qualidade de um projeto. 
Algumas práticas comuns a muitos projetos poderão ser destacadas como essenciais para o 
gerenciamento da qualidade. Iremos conhecê-las agora. 
 
 
 
 
 115 
 
Processos integrados e de melhoria contínua 
Servem para aprimorar o gerenciamento da qualidade do projeto e também a qualidade do 
produto, serviço ou resultado final, pois frequentemente incorporam os erros (aprendizados) e 
acertos da qualidade perante o conjunto do trabalho como um todo. Em um menor espaço de 
tempo, é possível verificar se o produto inteiro ainda se porta como esperado. Beneficia não só o 
resultado final do projeto como também propicia um mergulho em muitas questões que podem 
auxiliar para melhorar o nível de maturidade da equipe (numa visão coletiva), assim como a 
evolução profissional dos indivíduos. Talvez por serem bem eficazes e demonstrarem valor logo 
nas primeiras vezes de aplicação, muitas são as práticas e ferramentas associadas ao tema (como 
as que já exploramos no módulo II: ciclo PDCA, 5 whys e reuniões de retrospectiva; ou no módulo 
V: os 3Ks). No entanto, demonstraremos algumas outras técnicas/ferramentas a seguir. 
Reuniões ou sprints de manutenção – reuniões de manutenção são, significativamente, 
diferentes de reuniões de retrospectiva. A priori, são estimuladas em momentos específicos do 
projeto, quando a capacidade da equipe está sobrecarregada e, portanto, realizada em momentos 
extraordinários. Elevados índices de sobrecarga podem estar associados a altos índices de correções 
ou ajustes, pois desviam os esforços de trabalho da equipe para cumprir funções que não agregam 
valor ao produto, visto que estão associadas a retrabalhos ou defeitos. Podem ser sinais de falhas no 
planejamento, na execução, no gerenciamento ou na priorização dos requisitos, entre muitas outras. 
Com o viés de servir de instrumento da qualidade para a equipe do projeto, essas reuniões 
conseguem equalizar os esforços da equipe, solucionando problemas e determinando novas 
diretrizes de trabalho. Quando o problema é grande demais, uma variação dessa técnica é criar um 
ciclo iterativo (sprint) de manutenção, freando-se o trabalho de desenvolvimento do produto ou 
serviço, e o foco passa a ser a correção de problemas, quase como um mutirão para abrir caminhos 
para que o time possa novamente trabalhar sem estar infestado de ocorrências. 
Reuniões de refinamento ou grooming – um tipo de reunião diferente, preferencialmente 
quando há necessidade de atualização de planejamento fazendo parte, normalmente, do 
cronograma do projeto. Os objetivos são, entre outras possíveis ações: reavaliar estimativas que 
possam estar defasadas em decorrência de informações atualizadas ou de qualquer outra variável 
imposta ao projeto; eliminar requisitos que não se fazem mais relevantes; repriorizar requisitos cuja 
classificação possa já não fazer mais sentido para a execução dos trabalhos; criar novas 
funcionalidades que tenham passado despercebidas no momento do planejamento; e, decompor 
funcionalidades ou pacotes de trabalho que pareciam suficientes e ganharam um nível maior de 
esforço, por qualquer que seja a razão. 
 
 
116 
 
Figura 32 – Ficha de controle de processo 
 
Fonte: CALDAS; SALGADO (2017). 
 
 
 117 
 
Fichas de controle – uma ferramenta que funciona para capturar informações e atestar uma 
atividade ou momento-chave do projeto enquanto ele acontece. Comumente utilizada em 
operações, quando a responsabilidade de algo passa de mão em mão, a técnica foi adaptada para o 
dia a dia das equipes de projetos. Trata-se de uma forma padrão, por meio de uma folha ou 
formulário eletrônico, em que o novo responsável possa registrar o status atual de um produto ou 
de uma determinada situação (processo). Talvez a situação de utilização mais conhecida de nosso 
cotidiano sejam as fichas de controle utilizadas por firmas de seguro ou de locação de carros, 
membros da polícia e serviços de manutenção (reboque), por exemplo, quando precisam transmitir 
a posse de um determinado veículo, após um acidente. As fichas são preenchidas por terceiros, para 
informar o estado atual do veículo, e podem relatar avarias, itens defeituosos e causalidades, entre 
muitas outras questões. Equipes de projetos, entre muitos outros formatos, podem utilizar uma 
ficha de controle para o registro de defeitos no produto (ou em componentes) que está sendo 
desenvolvido. Em um determinado momento, a equipe pode sentar e avaliar detalhes acerca desse 
histórico de defeitos para tentar resolvê-los ou preveni-los de uma outra forma, evitando que se 
repitam, promovendo uma cultura de melhoria contínua. 
 
Testes em todos os níveis 
Efetuam-se testes unitários para componentes singulares (itens isolados, condições únicas etc.) 
e testes em nível coletivo (de sistema) para obter informações mais complexas. Sempre que possível, 
visualizar a necessidade de testes de integração e de testes automatizados, propiciando um dinamismo 
maior de validação das entregas. Utilização de testes preliminares que revelem falhas simples, porém 
capazes de gerar ocorrências graves no futuro, como encontrar uma funcionalidade com falha que 
inviabilize a validação futura de uma versão de um MVP (também conhecido como smoke testing). 
 
 Estudos/Análises de causa e efeito (ou causa-raiz) 
São abordagens práticas, fáceis e colaborativas com foco no entendimento de um 
determinado problema, para solucioná-lo. Na maioria das vezes, aparecem combinadas com 
ferramentas de tomadas de decisão. Costumam produzir grandes benefícios, não só para o nível da 
equipe do projeto, como também para níveis estratégicos/direção. São muitas as ferramentas com 
o viés de definição de um problema, identificação das possíveis causas e proposição de solução: 
Diagrama de Ishikawa ou diagrama espinha de peixe – a aparência gráfica do diagrama 
desenvolvido por Kaoru Ishikawa, como uma espinha de peixe, deixou a sua alcunha tão famosa 
quanto o nome do seu criador. O diagrama foi gerado para associar um efeito (problema ou defeito)às suas possíveis causas, no entanto, sob diversos pontos de vista. Por ser uma ferramenta 
colaborativa, serve como meio de compartilhar entendimentos e gerar futuras discussões para que 
se evidencie uma possível solução ao efeito registrado como uma consequência de uma ou muitas 
origens. O modelo original se baseia em seis categorias de influência sobre um resultado: medida 
 
118 
 
(medição), método, mão de obra, máquina, meio ambiente e material. Para cada causa com origem 
em uma dessas influências demonstra-se como se desenvolve a conexão entre causa e efeito para, 
posteriormente, discutir uma solução para uma ou mais causas. 
 
 Figura 33 – Diagrama de Ishikawa 
 
Fonte: BORGES (2014). 
 
Diagrama de Pareto – desenvolvido por Juran, o diagrama de Pareto utiliza o mesmo padrão 
de semelhança encontrado por Vilfredo Pareto, quando demonstrou uma relação de causa e efeito 
numa proporção de 80/20 nas suas pesquisas econômicas do século XIX. Juran sugeriu que o 
princípio de Pareto sustenta que (aproximadamente) 80% dos efeitos vêm de 20% das causas. Por 
um viés de resolução de problemas, consequentemente, pode-se pressupor que, ao tratar 20% das 
causas, 80% dos problemas desaparecerão. O gráfico demonstra não somente as porcentagens de 
cada análise, mas também as cumulativas, definindo, como na próxima figura, que os cinco 
primeiros produtos (da esquerda para a direita) representam cerca de 80% de concentração dos 
problemas, sendo esses os prioritários para ações de correção e prevenção. 
 
 
 
 
 119 
 
Figura 34 – Diagrama de Pareto 
 
Fonte: BORGES (2014). 
 
Árvore do problema (problem tree) – a representação baseada na estrutura física de uma 
árvore permite que o problema seja alocado ao centro (representando o caule) para que o time do 
projeto possa então conjecturar sobre possíveis causas que determinaram (ou determinarão, no caso 
da prevenção de um possível problema – muito comum no trabalho de levantamento de riscos) o 
problema, assim como eventuais efeitos/consequências, caso o problema efetivamente ocorra. 
Trata-se de uma análise situacional que gera grande empatia pelo problema e alto grau de 
colaboração da equipe, pois avalia uma espécie de anatomia de causa e efeito, semelhante a modelos 
de mapas mentais. É uma técnica facilmente adaptável, podendo, por exemplo, o problema ser 
separado em partes gerenciáveis e definíveis, auxiliando a focar nos objetivos que priorizem uma 
solução (mais imediata ou mais barata, apenas para citar uma opção). 
 
 
 
120 
 
Figura 35 – Árvore do problema 
 
Fonte: elaborado pelo autor. 
 
Inspeções 
A partir de normas e documentos, constituir responsabilidades para examinar 
minuciosamente um determinado produto, componente, processo e experiência de serviço, entre 
outras possibilidades, visando à garantia de que o resultado da aferição esteja alinhado com o 
previsto. Pode ser realizada por meio de amostragens ou de maneira mais específica. Veremos, a 
seguir, algumas das técnicas/ferramentas de inspeção. 
Lista ou folha de verificação (checklist ou checksheet) – segundo o PMI (2017a, p. 751), é “[...] 
uma ferramenta estruturada para verificar se um conjunto de etapas exigidas foi executado”. Pela sua 
simplicidade, é outra ferramenta considerada como uma das sete básicas da qualidade e serve como 
uma representação gráfica para a coleta de informações pré-estruturadas, visando à uniformização dos 
processos de monitoramento. Alguns modelos mais conhecidos são padronizados por organizações, 
por associações profissionais ou por provedores de serviços comerciais. 
 
 
 121 
 
Figura 36 – Lista de verificação 
Lista de verificação 
Problema: 
Estágio de verificação: Data: 
Produto: Seção: 
Total inspecionado: Inspetor: 
Lote: Turno: 
Tipo de defeito Contagem Subtotal 
Arranhão 
Trinca 
Revestimento inadequado 
Mancha 
Acabamento inadequado 
Outros 
TOTAL 
Total rejeitado 
Fonte: COUTINHO (s. d.). 
 
Medições de controle da qualidade – técnica de documentação dos resultados das atividades 
definidas para o controle da qualidade, exatamente como estipuladas no plano de gerenciamento 
da qualidade, visando a uma correta definição do produto (ou parte), do serviço ou do resultado a 
ser gerado. Costumam ser documentos extremamente técnicos e informativos, com alto grau de 
responsabilidade pelas informações transmitidas. 
 
 
 
122 
 
Figura 37 – Medições de controle da qualidade 
 
Fonte: COLUMBUS MCKINNON (2012). 
 
 
 
 
 123 
 
Cultura customer centric 
Colocar o cliente/usuário final no centro da estratégia de desenvolvimento das soluções 
geradas pela equipe de um projeto é demonstrar propósito de entrega de valor percebido, em cada 
etapa do produto, serviço ou resultado apresentado. Técnicas e ferramentas customer centric 
costumam ser estimuladas por organizações que adotam um tipo diferenciado de cultura 
organizacional comumente com um nível de relacionamento muito próximo aos seus 
clientes/usuários finais. Equipes com esse tipo de modelo mental costumam trabalhar antecipando 
as necessidades dos clientes, por meio de processos empáticos, muitos ciclos de feedbacks e processos 
de interação facilitados. São muitas as possibilidades de práticas voltadas a esse tipo de abordagem, 
mas demonstraremos apenas algumas a seguir. 
Mapa de empatia – são muitas as versões e as possibilidades trazidas por uma ferramenta tão 
poderosa, pois o mapa de empatia, como o próprio nome diz, faz a equipe do projeto se colocar no 
lugar do cliente e passar a pensar e se portar, como o cliente/usuário final, antevendo e avaliando 
necessidades/expectativas que possam determinar requisitos da qualidade de um determinado 
produto, serviço ou resultado. Também pode ser utilizada como ferramenta para gerir e 
compreender melhor importantes stakeholders. 
 
Figura 38 – Mapa de empatia 
 
Fonte: PEREIRA (2017). 
 
 
124 
 
Personas – técnica que cria personagens semifictícios baseados em experiências de consumo 
ou de utilização de serviços ao caracterizar avatares que correspondem ao perfil de um cliente ideal, 
ou seja, permite compreender melhor quem é o seu potencial cliente e do que ele precisa. O objetivo 
principal dessa técnica é basear ações comerciais, como as de mídias digitais, para permitir um maior 
grau de conexão da marca/produto/serviço com o cliente/usuário final ideal. Quanto à qualidade, 
antecipa a equipe do projeto a definir premissas e requisitos indispensáveis da qualidade. 
Comumente é complementada com uma técnica conhecida como jornada do usuário, que permite 
avaliar um estilo de vida de uma determinada persona e auxiliar a identificar os momentos em que 
tal personagem se conecta com a marca/produto/serviço e quais desses momentos são mais propícios 
para interações com o indivíduo, visando à melhoria da experiência de usuário. 
 
Figura 39 – Personas 
 
Fonte: NARAYAN (2016). 
 
O universo de atuação do gerenciamento da qualidade é vasto e quase infinito, tamanhas são 
as possibilidades de utilização de ferramentas, práticas e frameworks que podem auxiliar os trabalhos 
de uma equipe de projetos. Apesar de não termos visto muitas delas, vale uma rápida menção a 
algumas que também possuem utilizações consolidadas no mercado, como auditorias (avaliação 
independente que visa a confirmar se as muitas atividades do projeto estão efetivamente cumprindo 
normas, políticas, processos e procedimentos da qualidade da organização detentora do projeto), 
design for X (significa, em um dado momento do projeto, direcionar o trabalho de design de um 
determinado produto – ou parte – para algum tipo de customização ou aspecto específico do design, 
como usabilidade, segurança, ergonomia, qualidade e confiabilidade, entremuitos outros possíveis); 
 
 
 125 
 
técnicas para resolução de problemas (visam a descobrir soluções para potenciais desafios ou algum 
tipo de questão específica, podendo incluir técnicas de observação, de criatividade – design thinking, 
design service ou design sprint, por exemplo – métodos quantitativos/lógicos e ferramentas A3, entre 
muitos outros possíveis); e, métodos para a melhoria da qualidade, como representações gráficas 
(diagramas de dispersão e outros tipos de representação de dados), SIPOC – Supplier-Input-Process-
Output-Customer, BPM – Business Processes Management, seis sigma, Casa da Qualidade e ToC – 
Theory of Constraints (teoria das restrições). 
Já presenciei muitas maneiras de se adaptar grande parte das técnicas e das ferramentas 
demonstradas neste capítulo. Vou tentar traduzir a minha preocupação por meio de um exemplo 
prático. Certa vez, vi uma equipe de projeto utilizar uma variação de um diagrama de espinha de 
peixe (fizeram as mesmas representações que transformariam a imagem final). No entanto, talvez por 
desconhecimento da técnica completa, ou por algum aprendizado equivocado, não aplicaram 
corretamente as técnicas destinadas à solução que foi gerada por Kaoru Ishikawa. O diagrama original 
foi desenvolvido no segmento da produção industrial e servia para a avaliação de potenciais causas 
vinculadas a métodos, materiais, mão de obra, máquinas, medidas e meio ambiente (os famosos 6Ms, 
conforme vimos anteriormente). Eu percebi que, no momento da aplicação da ferramenta, os 
membros da equipe faziam perguntas indiscriminadas e apenas alocavam as respostas como potenciais 
grupos de problemas (categorizados em clusters), mas não necessariamente avaliando em relação aos 
6Ms, como preconiza a aplicação da técnica. A verdade é que, independentemente de aplicarem a 
técnica da maneira incorreta, o exercício de análise que foi realizado pela equipe gerou uma série de 
insights importantes e conseguiu o efeito desejado, que era o de encontrar relações de causa e efeito 
acerca dos problemas discutidos. No final, a técnica adaptada serviu ao propósito do time e beneficiou 
o desenvolvimento do projeto. A questão então é, sem dúvida alguma, que é importante conhecer 
técnicas, ferramentas e as suas corretas utilizações, mas não devemos nos privar de adaptá-las, caso 
isso faça sentido para o trabalho de execução da qualidade que vem sendo desenvolvido pelo grupo. 
Devemos ter cuidado apenas com invenções fora de propósito que façam o time do projeto perder 
tempo e investir esforços apenas naquilo que realmente possa trazer benefícios. Além disso, devemos 
abrir a cabeça para inúmeras possibilidades de ferramentas e técnicas que existem no mercado, pois a 
lista é vasta e as propostas de utilização podem surtir efeitos interessantíssimos, não só no resultado 
final do projeto mas também no moral da equipe. 
 
Relatório de execução da qualidade 
O trabalho da qualidade demonstra a sua força a partir do momento em que a execução da 
qualidade ganha vida. É por meio dos muitos relatórios de qualidade (ou de auditoria de 
qualidade), muitas vezes contendo informações traduzidas por gráficos, tabelas e avaliações 
qualitativas/quantitativas, que as informações da qualidade são oficialmente compartilhadas com 
todas as principais partes interessadas, servindo de referência para muitos outros processos que 
 
126 
 
necessitam ser complementados por meio desse tipo de informação. Em suma, a gama de 
informações proveniente de um relatório de qualidade auxilia na adoção de ações corretivas/ 
preventivas e na busca plena por atingir o maior nível de satisfação possível das principais partes 
interessadas. Segundo o PMI (2017a, p. 332), os relatórios de qualidade 
 
[...] podem incluir todos os problemas de gerenciamento da qualidade 
encaminhados pela equipe; recomendações para melhorias em processo, 
projeto e produto; recomendações de ações corretivas (incluir retrabalho, 
reparo de defeitos/bugs, inspeção de 100% e mais); e o resumo das 
conclusões do processo de controle da qualidade. 
 
Um template pode ser apreciado a seguir. 
 
Figura 40 – Relatório da qualidade 
Título do projeto: _________________________ Data de elaboração: ______________ 
Auditor do projeto: _______________________ Data da auditoria: _______________ 
1. Área auditada 
 
 
2. Boas práticas a compartilhar 
 
 
3. Oportunidades para melhorias 
 
 
4. Relatório de defeitos 
ID Descrição Ação Responsável Data de entrega 
 
 
 
5. Comentários 
 
 
Fonte: adaptado de SNYDER (2013). 
 
Qualquer aspecto do projeto ou do produto é passível de ser auditado, sendo que é 
importante frisar que todo e qualquer trabalho de auditoria precisa ser adaptado para melhor 
atender às necessidades do projeto e da organização. 
 
 
 127 
 
No modelo disponibilizado, iniciamos o relatório de qualidade (item 1) com um informe 
sobre a área ou o que está sendo auditado. De acordo com Snyder (2013, p. 152): 
 
As áreas comuns para auditoria incluem: processos de projeto, documentos 
do projeto, requisitos do produto, documentos do produto, implementação 
das mudanças aprovadas, implementação da ação corretiva ou preventiva, 
correção do defeito ou da deficiência, conformidade com as políticas e 
procedimentos organizacionais, e conformidade com o plano de qualidade. 
 
Para otimizar o trabalho de gestão do conhecimento e de aprimoramento da qualidade 
visando aos esforços de melhoria contínua, o item 2 existe para que o responsável pelo relatório 
possa descrever todas as práticas advindas do recém-trabalho de auditoria e que devam ser 
compartilhadas, seja entre setores da mesma organização, seja entre diferentes times de projeto, seja 
até mesmo entre diferentes organizações. Há quem goste de categorizar esse tipo de informação 
diretamente no relatório. O item 3 deve descrever todas as áreas que tiveram algum tipo de 
identificação de melhoria, assim como processos e estrutura, entre muitas outras informações que 
possam representar um futuro com melhor aproveitamento de recursos ou de esforços, por exemplo, 
medições específicas que precisam ser alcançadas. No item 4, temos o exemplo de um relatório 
dentro do próprio relatório, em que todos os defeitos encontrados por ocasião da auditoria de 
qualidade precisam ser catalogados, categorizados e descritos, assim como quais seriam as potenciais 
ações corretivas sugeridas para solucionar cada um dos problemas, incluindo responsáveis e datas 
limite. Por fim, no item 5, deve-se desenvolver qualquer tipo de comentário extra que possa ser útil 
para o público-alvo desse documento. Indicações de documentos, como normas, pareceres técnicos 
ou standards (padrões) são algumas das possíveis referências. 
Documentos de teste e avaliação também costumam ser responsáveis por muitos relatórios, 
pois avaliam o cumprimento dos objetivos da qualidade. Normalmente, são gerados com base em 
modelos existentes na própria organização, adaptados às necessidades do mercado e do setor. 
 
Controle da qualidade e relatório do desempenho do 
trabalho 
Se, eventualmente, existir a necessidade de algum tipo de ajuste durante as investidas da 
equipe do projeto no gerenciamento da qualidade, a saída cabível é acionar o controle integrado de 
mudanças do projeto, por meio de artefatos conhecidos como solicitações de mudança (change 
request). Antes de tudo, porém, devemos olhar de uma maneira mais cuidadosa e perceber que para 
que algo possa ser controlado deve também passar por algum tipo de verificação, pois somente 
aquilo que se monitora é passível de controle. Então, a abrangência do conceito desse último 
momento destinado ao trabalho da qualidade é ligeiramente maior do que se pode supor. Trata-se 
 
128 
 
de uma extensão natural do gerenciamento da qualidade, pois demonstra a necessidade de 
monitoramento e documentação de todos os resultados dos processos derivados da execução da 
qualidade. Além disso, os registrosprecisam ser avaliados para assegurar que o realizado vai ao 
encontro do planejado. Caso esteja, significa dizer que a qualidade do projeto está sendo cumprida 
e as entregas estão atendendo aos padrões da qualidade, de preferência, mapeados com os 
clientes/usuários finais do produto, serviço, ou resultado que está sendo gerado pela equipe do 
projeto. Com o OK da qualidade, o time responsável pelo escopo poderá prosseguir com os 
trabalhos vinculados aos critérios de aceitação das entregas. No entanto, sempre que algo estiver em 
desalinho com aquilo que deveria ter sido realizado ou, por exemplo, diferente da maneira como 
um determinado estágio do produto deveria se portar, deve ser acionado o controle integrado de 
mudanças, previsto por um plano de gerenciamento de mudanças do projeto. 
Certamente, o rigor dispensado ao trabalho de controle da qualidade dependerá de uma série 
de fatores, como estilos de gestão, restrições de budgets e setores para o qual o projeto será 
desenvolvido, entre outros. Alguns setores naturalmente possuem controles de qualidade mais 
rigorosos. Não dá para desenvolver um novo medicamento, por exemplo, sem que muitos rigores 
da indústria farmacêutica sejam correspondidos à risca. 
Então, para que possamos entender melhor como funciona o momento de controle da 
qualidade, devemos antes avaliar que tipo de documentação a equipe do projeto terá em mãos para 
desempenhar tal papel. Primeiramente, o plano de gerenciamento do projeto fornece informações 
sobre o planejamento da qualidade, por meio do PGQ. É a maneira de possuirmos todas as 
diretrizes e procedimentos da qualidade disponíveis para potenciais trabalhos de verificação. Na 
sequência, potencialmente, devemos prestar atenção a alguns documentos do projeto, como o 
registro das lições aprendidas (um dos documentos responsáveis por disseminar a gestão do 
conhecimento, desde os primórdios do projeto, podendo trazer valiosas informações de fases 
anteriores no intuito de aprimorar o trabalho do controle da qualidade); as métricas da qualidade 
(documento necessário para que a verificação de conformidades possa ser realizada, pois serve para 
descrever todos os padrões/atributos da qualidade desejados ao projeto e ao produto, serviço ou 
resultado a ser gerado); e, a documentação de testes e de avaliações (documentos que auxiliam no 
trabalho de mensuração dos objetivos da qualidade). Também chama atenção o fato de avaliarmos 
dados de desempenho do trabalho, pois demonstram informações acuradas acerca do status do 
produto, medições para desempenho técnico, assim como a correlação de informações da qualidade 
e a sua influência para o desempenho do cronograma e dos custos, apenas para citar alguns dos 
principais aspectos. Fatores ambientais da empresa comumente são apreciados, como a 
possibilidade de utilização de sistemas de informações gerenciais (alguns específicos para a 
qualidade), as regulamentações de órgãos governamentais, as normas e os padrões específicos para 
uma determinada área de atuação. Por fim, restam os ativos de processos organizacionais, que 
podem fornecer importantes informações acerca de padrões, certificações e políticas da qualidade, 
templates da qualidade já existentes, políticas de comunicação de defeitos, procedimentos para a 
emissão e a circulação de informações e de relatórios, entre muitos outros. 
 
 
 129 
 
Como entrega, o PMI (2017a, p. 337) define “[...] qualquer produto, resultado ou 
capacidade singular e verificável para realizar um serviço cuja execução é exigida para concluir um 
processo, uma fase ou um projeto”. Simplesmente tudo aquilo que está pronto para a validação (ou 
ser inspecionado), contanto que esteja determinado pelo plano do projeto para que isso ocorra. Ou 
seja, potencialmente, tudo o que puder ser verificado, comparando-se o previsto com o realizado, 
assim como todos os critérios de aceitação e de validação vinculados às entregas especificadas na 
linha de base do escopo. É o ponto inicial da verificação, possuir algo para ser verificado. Essas 
demandas chegam por meio de entregas mas também podem chegar por meio de solicitações de 
mudanças aprovadas pelo comitê de mudanças do projeto. Solicitações de mudanças aprovadas que 
chegam para o controle da qualidade são comumente vinculadas a reparos de defeitos e a revisão 
dos métodos de trabalho, por exemplo, a necessidade de introduzir alguma ferramenta para o 
controle da qualidade até então não discriminada pelo PGQ. Além disso, não é difícil surgirem 
solicitações que são implementadas de maneira parcialmente correta ou, até mesmo, de maneira 
errada, gerando novos registros de defeitos/falhas (e, potencialmente, futuras novas solicitações de 
mudanças que ainda precisarão ser avaliadas pelo comitê de mudanças). 
Nem sempre um projeto executa as tarefas de maneira perfeita e sempre que há a chance de 
se avaliar uma situação de desconformidade, potencialmente, uma grande onda de dados é gerada 
motivando ações e responsabilidades, que tendem a recolocar o trabalho da equipe do projeto em 
um novo rumo (de preferência, o rumo correto). Portanto, independentemente de boas ou más 
notícias, o papel fundamental desse processo é o de conscientizar a equipe sobre os resultados, 
motivando-a para alcançar os objetivos elencados no plano de gerenciamento da qualidade, fornecer 
feedback (o mais rápido possível) para a busca da garantia da qualidade (composta por análise de 
dados, localização de defeitos, propostas de melhoria contínua e atualizações no PGQ) e prover 
subsídios para que todas as ações corretivas possam ser realizadas, evitando-se novas ocorrências. 
Exatamente por isso, há necessidade de documentar informações sobre o desempenho do 
trabalho. Esses registros costumam ser documentos extensos, confeccionados com as referências 
apontadas nos dados sobre o desempenho do trabalho, comumente materializados como relatórios 
de status da qualidade ou de desempenho do trabalho (ou do projeto). Um exemplo de template 
pode ser visualizado a seguir. 
 
 
130 
 
Quadro 13 – Relatório de desempenho do trabalho 
Título do projeto: _________________________ Data de elaboração: ______________ 
Gerente do projeto: _______________________ Patrocinador: ___________________ 
1. Realizações para o período do relatório 
1. 
2. 
3. 
2. Realizações planejadas, mas não 
concluídas no período do relatório 
1. 
2. 
3. 
3. Causa-raiz / justificativas para o item 2 
4. Impacto sobre marcos futuros ou data 
de entrega do projeto 
 
5. Ações corretivas ou preventivas 
planejadas para o item 4 
 
6. Recursos financeiros consumidos no 
período do relatório 
 
7. Causa-raiz / justificativas para o item 6 
8. Impacto sobre o orçamento geral ou 
recursos financeiros de contingência 
 
9. Ações corretivas ou preventivas para o 
item 8 
 
10. Realizações previstas para o próximo 
período ou próximo relatório 
1. 
2. 
3. 
11. Custos previstos para o item 10 
12. Novos riscos identificados 
13. Questões 
14. Observações finais / comentários 
Fonte: adaptado de SNYDER (2013). 
 
No item 1, devemos informar todos os pacotes de trabalho ou demais realizações/tarefas 
importantes que foram concluídas no período destinado ao relatório. No item 2 é a mesma coisa, 
mas dessa vez, devemos informar aquilo que havia sido planejado e que, por alguma razão, não 
foi concluído, no mesmo período. Na sequência (item 3), devemos informar todas as 
justificativas, variações ou causas-raiz referentes às informações do item anterior. O número 4 
 
 
 131 
 
também é referente ao item 2, pois ainda é sobre aquilo que não foi realizado (mas deveria ter 
sido). Deve-se demonstrar qualquer tipo de impacto em relação ao cronograma do projeto, 
fazendo menção de potenciais problemas no caminho crítico e variações de indicadores de tempo. 
O item 5 trata de possíveis ações necessárias para compensar as variações que foram influenciadas 
pelo item 2 ou, ainda, em uma visão de futuro,já avaliar ações para evitar variações futuras do 
cronograma. Os itens 6 a 9 são uma análise muito semelhante do que foi realizado em relação ao 
cronograma, mas dessa vez demonstrando as informações financeiras. Deve-se avaliar os custos 
do período; informar as variações, assim como as suas justificativas (por exemplo, as diferenças 
entre variações de custos de mão de obra versus variações nos custos dos materiais); definir os 
impactos no orçamento geral ou informar se os recursos de contingência deverão ser acionados; 
e, por fim, informar as ações necessárias para a recuperação das variações dos custos já incorridos 
ou as visões de planejamento, no intuito de evitar variações futuras no orçamento. Nos itens 10 
e 11, devemos definir todos os pacotes de trabalho ou realizações/tarefas que serão conduzidos 
até o período limite vinculado ao próximo relatório, incluindo os recursos financeiros necessários. 
No item 12, devemos avaliar os riscos potenciais que possam advir das informações já descritas 
no relatório. Essas informações serão remetidas como base de atualização do registro dos riscos 
do projeto. No item 13, devemos registrar potenciais questões que possam advir das informações 
já descritas no relatório. Essas informações serão remetidas como base de atualização do registro 
das questões do projeto. Por fim, o item 14 é um campo aberto para registrar quaisquer 
comentários ou observações finais, ou até menções a anexos ou informações externas que tenham 
um grau de relevância para o conteúdo apresentado pelo relatório. 
O controle da qualidade ocorre ao longo de todo o projeto, pois a todo instante existem 
entregas (resultados oriundos de outros processos) que necessitam ter os seus padrões e as suas 
especificações avaliados, ou seja, se os critérios de aceitação e de validação definidos pela equipe do 
projeto, com base nas interações com o patrocinador do projeto ou os seus clientes/usuários finais, 
foram corretamente atendidos. É comum, em abordagens ágeis ou híbridas, que toda a equipe 
participe do propósito de controlar a qualidade. Já nos projetos com uma abordagem mais preditiva, 
costumam-se determinar momentos específicos, normalmente, próximos do final de uma fase ou 
do próprio projeto, além de demandarem profissionais específicos para o trabalho. 
Um bom trabalho da equipe do projeto vinculado ao controle da qualidade gera uma série 
de informações, muitas delas com o poder de influenciar processos importantes de tomadas de 
decisão de apoio a medidas técnicas ou estratégicas. Pode-se dizer que, no caso de um trabalho 
perfeito, o grande objetivo desse momento seria o de confirmar esse status de conformidade, 
permitindo corroborar a ideia de que tudo está conforme planejado e que todas as métricas foram 
confirmadas, estando de acordo com os padrões e as especificações da qualidade definidos no 
momento do planejamento. 
 
 
132 
 
Retrospectiva do módulo 
A unidade VII encerrou os trabalhos da qualidade apresentando como eles são conduzidos na 
prática. Gerenciar a qualidade talvez seja um dos desafios mais estimulantes de um projeto, pois 
muitas variáveis assolam o seu fiel cumprimento. O alinhamento perfeito dos trabalhos da qualidade 
com o que ocorre em face do desenvolvimento do produto, serviço ou resultado que está sendo gerado 
pela equipe do projeto visa ao alinhamento total com os demais temas trabalhados pela equipe, por 
exemplo, o gerenciamento dos custos, dos recursos e dos riscos, entre muitos outros. 
Tivemos a oportunidade de avaliar uma série de práticas adaptadas à qualidade que poderão 
ser utilizadas pela equipe de projeto, cada uma delas dependendo dos objetivos estratégicos 
estabelecidos para o cumprimento dos resultados e dos benefícios vinculados ao projeto. Entre essas 
muitas práticas, demonstramos que processos integrados e de melhoria contínua devem receber 
atenção constante, seja por meio das reuniões de manutenção (desejável sempre que o nível de 
sobrecarga começa a atrapalhar o desempenho do time), seja pelas reuniões de refinamento 
(importantes para reavaliações de prioridades e sintonias finas de planejamento), seja por meio de 
fichas/folhas de controle. Também pudemos visualizar a importância de testes em todos os níveis 
de desenvolvimento do produto, serviço ou resultado que está sendo gerado, assim como a 
necessidade de estudos/análises de causa e efeito (ou causa-raiz). Estes últimos, referenciados por 
uma série de ferramentas interessantes, que, na maioria das vezes, produz grandes momentos de 
colaboração, desempenhando um papel sobrecomum no status de motivação das equipes. 
Ferramentas como o diagrama de Ishikawa, o diagrama de Pareto e a árvore do problema são simples 
de serem utilizados e têm o potencial de produzir excelentes ideias, que se transformam em ações 
no intuito de solucionar problemas, dos mais simples aos mais complexos. 
Inspeções também demonstram ser uma técnica que, quando bem trabalhadas, produzem 
efeitos interessantes, principalmente, por permitirem uma avaliação relativamente rápida e a 
chance de uma avaliação parcial, por meio de amostragens de grandes quantidades. Foram 
demonstradas as técnicas de listas de verificação e de medições de controle da qualidade. Para 
finalizar, vimos o poder da qualidade em projetos ou organizações que desenvolvem trabalhos 
com o modelo mental centrado no cliente/usuário final e percebemos que a qualidade é 
desenvolvida até mesmo de maneira preventiva, tentando conhecer o cliente/usuário final por 
todos os pontos de vista, gerando níveis de interação elevados e um cliente/usuário final 
fidelizado. Por fim, ainda demonstramos dois templates úteis para a qualidade: o de relatórios de 
execução da qualidade e o do relatório de desempenho dos trabalhos. 
Uma correta aplicação da qualidade passa pela fase de planejamento e segue um curso natural 
de aderência aos padrões e métricas da qualidade estabelecidos, culminando com a avaliação final 
do cumprimento das condições técnicas, assim como de objetivos de negócio para os quais o 
produto, serviço ou resultado estão sendo gerados. A busca pelo êxito no trabalho da qualidade visa 
à execução de tudo aquilo que foi planejado no plano de gerenciamento da qualidade, com a 
posterior obtenção de todos os padrões estipulados pelas métricas da qualidade. 
 
 
 133 
 
Ao estudarmos esses últimos tópicos, encerra-se mais uma fase de aprendizado, pois não somente 
é possível visualizar, compreender e praticar toda a abrangência da qualidade destinada a um projeto, 
independentemente do setor, tipo ou porte, assim como integrar o assunto da qualidade com qualquer 
outra temática do projeto. Percebemos que qualidade não é só uma maneira de avaliar o sucesso do 
trabalho da equipe do projeto e os níveis de satisfação das principais partes interessadas mas também 
serve para aperfeiçoar competências, gerando um maior grau de maturidade para as organizações. 
A qualidade pode (e deve) ser mensurada constantemente em relação aos processos do 
gerenciamento profissional de projetos, gerando impacto direto na redução de esforços, na sobrecarga e 
no nível de defeitos; e também em relação à qualidade técnica do produto, serviço ou resultado que está 
sendo gerado pela equipe do projeto, visando a melhorar, cada vez mais, os índices de entrega de valor 
percebido e de satisfação do cliente/usuário final, além do patrocinador do projeto. 
 
Encerramos a apostila e não podemos perder o hábito de verificar o aprendizado. Sendo 
assim, responda as perguntas referentes a essa unidade: 
1. Quais as maneiras possíveis para gerenciar a qualidade de um projeto? 
2. Qual a diferença de processos ou ferramentas/técnicas de melhoria contínua e 
estudos de causa-efeito? Como podem ser utilizados em conjunto? 
3. Por que ferramentas/técnicas customers centric auxiliam na geração de valor e/ou 
entregas com maior percepção de valor 
 
 
 
134 
 
BIBLIOGRAFIA 
ADAMY, A. P. do A. et al. O uso de controleestatístico de processo como forma de garantia 
de qualidade para o cliente: aplicação em uma indústria metalmecânica. Revista Espacios, n. 03, 
v. 38, p. 6, 2017. 
 
ANDRADE, L. Como fazer PDCA passo a passo?. 2017. Disponível em: 
https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/. Acesso em: 10 jan. 2024. 
 
AUDY, J. Scrum 360: um guia completo e prático de agilidade. São Paulo: Casa do Código, 2015. 
 
BECK, K. et al. Manifesto ágil para o desenvolvimento de softwares. 2001. Disponível em: 
http://www.manifestoagil.com.br. Acesso em: 10 jan. 2024. 
 
BENSON, J.; BARRY, T. D. Personal Kanban. Mapping work. Navigating life. Modus 
Cooperandi Press, 2011. 
 
BORGES, L. O que é o famoso diagrama de Pareto (80/20) – passo a passo. 2014. Disponível em: 
https://blog.luz.vc/o-que-e/diagrama-de-pareto-8020-passo-a-passo/. Acesso em: 10 jan. 2024. 
 
CALDAS, L.; SALGADO, S. M. Gestão da qualidade aplicada ao processo de projeto de avaliação 
do ciclo de vida (ACV) para edificações. In: SIMPÓSIO BRASILEIRO DE QUALIDADE DO 
PROJETO NO AMBIENTE CONSTRUÍDO. 2017. João Pessoa. Anais... Porto Alegre: 
ANTAC. p. 1-12. Disponível em: https://www.researchgate.net/publication/321058197_ 
GESTAO_DA_QUALIDADE_APLICADA_AO_PROCESSO_DE_PROJETO_DE_AVALIA
CAO_DO_CICLO_DE_VIDA_ACV_PARA_EDIFICACOES. Acesso em: 10 jan. 2024. 
 
CAROLI, P. Direto ao ponto: criando produtos de forma enxuta. São Paulo: Casa do Código, 2015. 
 
CAROLI, P. O canvas MVP. 2018. Disponível em: http://www.caroli.org/o-canvas-mvp. Acesso 
em: 10 jan. 2024. 
 
COLUMBUS McKINNON CORPORATION. Site oficial. 2012. Disponível em: 
http://www.cmdobrasil.com.br/gn_manilhas.html. Acesso em: 10 jan. 2024. 
 
COUTINHO, T. Folha de verificação: saiba tudo sobre essa ferramenta da qualidade!. [s. d.]. 
Disponível em: https://www.voitto.com.br/blog/artigo/folha-de-verificacao. Acesso em: 10 jan. 2024. 
https://www.siteware.com.br/metodologias/como-fazer-pdca-passo-a-passo/
http://www.manifestoagil.com.br/
https://blog.luz.vc/o-que-e/diagrama-de-pareto-8020-passo-a-passo/
https://www.researchgate.net/publication/321058197_GESTAO_DA_QUALIDADE_APLICADA_AO_PROCESSO_DE_PROJETO_DE_AVALIACAO_DO_CICLO_DE_VIDA_ACV_PARA_EDIFICACOES
https://www.researchgate.net/publication/321058197_GESTAO_DA_QUALIDADE_APLICADA_AO_PROCESSO_DE_PROJETO_DE_AVALIACAO_DO_CICLO_DE_VIDA_ACV_PARA_EDIFICACOES
https://www.researchgate.net/publication/321058197_GESTAO_DA_QUALIDADE_APLICADA_AO_PROCESSO_DE_PROJETO_DE_AVALIACAO_DO_CICLO_DE_VIDA_ACV_PARA_EDIFICACOES
http://www.caroli.org/o-canvas-mvp
http://www.cmdobrasil.com.br/gn_manilhas.html
https://www.voitto.com.br/blog/artigo/folha-de-verificacao
 
 
 135 
 
CLELAND, D. I. Why project management? Business Horizons. USA, 1964. 
 
CRUZ, F. Scrum e agile em projetos: guia completo. Rio de Janeiro: Brasport, 2015. 
 
CRUZ, F. PMO Ágil. Escritório ágil de gerenciamento de projetos. Rio de Janeiro: Brasport, 2016. 
 
CRUZ, F. Estimativas. [s. d.]. Disponível em: http://www.fabiocruz.com.br/frameworkscrumold/ 
sprint-planning-sp1. Acesso em: 10 jan. 2024. 
 
DEMING, W. E. Qualidade: a revolução da administração. São Paulo: Saraiva, 1990. 
 
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. 
 
ESCRITÓRIO DE PROJETOS. Métricas da qualidade. 2020. Disponível em: 
https://escritoriodeprojetos.com.br/metricas-da-qualidade. Acesso em: 10 jan. 2024. 
 
GADDYS, P. The project manager. Harvard Business Review. USA, May/June, 1959. 
 
GUIMARÃES, C. Escopo do projeto: 7 dicas para você ter sucesso nessa etapa. 2019. Disponível 
em: https://www.voitto.com.br/blog/artigo/escopo-do-projeto. Acesso em: 10 jan. 2024. 
 
JEFFERY, R. Putting de “V” in MVP. InfoQ. 2018. Disponível em: 
https://www.infoq.com/presentations/mvp-lean-product. Acesso em: 10 jan. 2024. 
 
JURAN, J. M. A qualidade desde o projeto. Os novos passos para o planejamento em produtos e serviços. 
São Paulo: Cengage Learning, 2009. 
 
JURAN, J. M.; GODFREY, A. B. (eds.). Juran’s Quality Handbook, 5. ed. New York: McGraw-
Hill Education, 1999. 
 
KANBANIZE. 5 Porquês: a melhor ferramenta para a análise de causa raiz. [s. d.]. Disponível 
em: https://kanbanize.com/pt/gestao-lean/melhoria/5-porques-ferramenta-de-analise. Acesso 
em: 10 jan. 2024. 
 
http://www.fabiocruz.com.br/frameworkscrumold/sprint-planning-sp1
http://www.fabiocruz.com.br/frameworkscrumold/sprint-planning-sp1
https://escritoriodeprojetos.com.br/metricas-da-qualidade
https://www.voitto.com.br/blog/artigo/escopo-do-projeto
https://www.infoq.com/presentations/mvp-lean-product
https://kanbanize.com/pt/gestao-lean/melhoria/5-porques-ferramenta-de-analise
 
136 
 
KURTZ, C. F.; SNOWDEN, D. J. The new dynamics of strategy: Sense-making in a complex 
and complicated world. IBM Systems Journal, v. 42, n. 3, p. 462-483, 2003. 
 
LOCKE, E. Toward a theory of task motivation and incentives. New York: Harper & Row, 1968. 
 
LOUZADA, P. É possível controlar o escopo do seu projeto?. 2017. Disponível em: 
https://www.fm2s.com.br/gestao-escopo-projeto/. Acesso em: 10 jan. 2024. 
 
MASSARI, V. L. Gerenciamento ágil de projetos. Rio de Janeiro: Brasport, 2014. 
 
MASSARI, V. L. Agile scrum master no gerenciamento avançado de projetos. Rio de Janeiro: 
Brasport, 2016. 
 
MASSARI, V. L. Percepções sobre a 6ª 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: 10 jan. 2024. 
 
MENEZES, L. C. de M. et al. Gerenciamento de escopo em projetos. 3. ed. Rio de Janeiro: FGV, 2014. 
 
MOORE, A. G. Crossing the Chasm: marketing and selling high-tech products to mainstream 
customers. USA: Harper Business Essentials, 1999. 
 
NARAYAN, A. Growth hacking 101: growth metrics, lean analytics & growth culture. 2016. 
Disponível em: https://www.slideshare.net/anirudhnarayan/growth-hacking-101-growth-metrics-
lean-analytics-growth-culture. Acesso em: 10 jan. 2024. 
 
PEREIRA, D. Mapa de empatia. 2017. Disponível em: 
https://analistamodelosdenegocios.com.br/mapa-de-empatia-o-que-e/. Acesso em: 10 jan. 2024. 
 
PICHLER, R. Gestão de produtos com Scrum. Implementando métodos ágeis na criação e 
desenvolvimento de produtos. Rio de Janeiro: Elsevier, 2011. 
 
PROJECT BUILDER. 4 segredos para especificar requisites de forma ágil. 2017. Disponível em: 
https://www.projectbuilder.com.br/blog/4-segredos-para-especificar-analise-de-requisitos/. Acesso 
em: 10 jan. 2024. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Practice standard for work breakdown 
structures. 2. ed. USA: PMI Inc., 2006. 
http://alumni.media.mit.edu/%7Ebrooks/storybiz/kurtz.pdf
http://alumni.media.mit.edu/%7Ebrooks/storybiz/kurtz.pdf
https://www.fm2s.com.br/gestao-escopo-projeto/
https://www.profissionaisti.com.br/2017/10/percepcoes-sobre-a-6a-edicao-do-pmbok-e-o-agile-practice-guide
https://www.profissionaisti.com.br/2017/10/percepcoes-sobre-a-6a-edicao-do-pmbok-e-o-agile-practice-guide
https://www.slideshare.net/anirudhnarayan/growth-hacking-101-growth-metrics-lean-analytics-growth-culture
https://www.slideshare.net/anirudhnarayan/growth-hacking-101-growth-metrics-lean-analytics-growth-culture
https://analistamodelosdenegocios.com.br/mapa-de-empatia-o-que-e/
https://www.projectbuilder.com.br/blog/4-segredos-para-especificar-analise-de-requisitos/
 
 
 137 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Requirements management: a practice guide. 
USA: PMI Inc., 2016. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of 
knowledge: PMBOK Guide. 6. ed. USA: PMI Inc., 2017a. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. USA: PMI Inc., 2017b. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). The PMI guide to business analysis. USA: PMI 
Inc., 2017c. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). 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: 10 jan. 2024. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of 
knowledge: PMBOK Guide. 7th ed. Newton Square, PA: PMI Inc., 2021. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Pulse of the profession. 2021. Disponível em: 
https://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2021. Acesso em: 
10 jan. 2024. 
 
RIES, E. A startup enxuta. Como os empreendedores atuais utilizam a inovação contínua para criar 
empresas extremamente bem-sucedidas. São Paulo: LeYa, 2012. 
 
RESEARCH GATE. Disponível em: https://www.researchgate.net/figure/Figura-3-Diagrama-de-
Contexto-Sistema-de-Analise-Espaciais-para-Planejamento-Urbano-SPAE_fig16_321949922. 
Acesso em: 10 jan. 2024. 
 
RIBEIRO, R. Gerência de projetos em sistemas de informação. [s. d.]. Disponível em: 
https://slideplayer.com.br/slide/11315661. Acesso em: 10 jan. 2024. 
 
ROCHA, A. V. et al. Gerenciamento da qualidade em projetos. Rio de Janeiro: FGV, 2014. 
 
ROSE, K. H. Project quality management. Why, what and how. J. Boca Raton: Ross Publishing, 2005. 
 
https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc_lang_temp=en
https://www.pmi.org/-/media/pmi/documents/public/pdf/learning/thought-leadership/pulse/pulse-of-the-profession-2018.pdf?sc_lang_temp=en
https://www.pmi.org/learning/thought-leadership/pulse/pulse-of-the-profession-2021
https://www.researchgate.net/figure/Figura-3-Diagrama-de-Contexto-Sistema-de-Analise-Espaciais-para-Planejamento-Urbano-SPAE_fig16_321949922
https://www.researchgate.net/figure/Figura-3-Diagrama-de-Contexto-Sistema-de-Analise-Espaciais-para-Planejamento-Urbano-SPAE_fig16_321949922
https://slideplayer.com.br/slide/11315661
 
138 
 
SERPA, S. Project Management Knowledge Base (PMKB): restrições de projetos para reduzir 
custos. 2017. Disponível em: https://pmkb.com.br/artigos/restricoes-de-projeto-para-reduzir-
custos. Acesso em: 10 jan. 2024. 
 
SNYDER, C. S. Guia de templates para gerenciamento de projetos. Rio de Janeiro: Campus, 2013. 
 
STANDISH GROUP. The chaos report: beyond infinity. 2020. Disponível em: 
https://standishgroup.myshopify.com. Acesso em: 10 jan. 2024. 
 
SUAREZ, G. A. 3Ks no lean: kaizen, kaikaku e kakushin. [s. d.]. Disponível em: 
https://qualityway.wordpress.com/2019/02/17/3ks-no-lean-kaizen-kaikaku-e-kakushin-por-
gregorio-suarez/. Acesso em: 10 jan. 2024. 
 
XAVIER, C. M. 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. 2. ed. USA: PMI Inc., 2006. 
Um dos padrões (standards) vigentes mais antigos do PMI continua atual para aquilo a 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 é um roteiro simples e pode ser facilmente utilizado, demonstrando 
os benefícios da 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 no contexto geral do planejamento do escopo e a sua futura 
implementação como linha de referência do escopo de um projeto. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Requirements management: a practice guide. 
USA: PMI Inc., 2016. 
Com a referência de que organizações continuam experimentando problemas no 
gerenciamento de projetos associados a baixos desempenhos em atividades relacionadas ao 
gerenciamento dos requisitos, esse livro traz uma luz ao tema, fornecendo ferramentas e 
desmistificando uma das principais etapas dos processos de gerenciamento do escopo, assim 
como a sua ligação com os processos do gerenciamento da qualidade. O livro aborda o 
desenvolvimento, a elicitação e o gerenciamento dos requisitos em um nível detalhado e 
prático, seja para a implementação em projetos, programas ou portfólios, preenchendo uma 
lacuna que perdurou durante muito tempo na área de projetos. 
https://pmkb.com.br/artigos/restricoes-de-projeto-para-reduzir-custos
https://pmkb.com.br/artigos/restricoes-de-projeto-para-reduzir-custos
https://standishgroup.myshopify.com/
https://qualityway.wordpress.com/2019/02/17/3ks-no-lean-kaizen-kaikaku-e-kakushin-por-gregorio-suarez/
https://qualityway.wordpress.com/2019/02/17/3ks-no-lean-kaizen-kaikaku-e-kakushin-por-gregorio-suarez/
 
 
 139 
 
PROJECT MANAGEMENT INSTITUTE (PMI). A guide to the project management body of 
knowledge: PMBOK Guide. 6. ed. USA: PMI Inc., 2017. 
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 dessa ú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 a ser adotada para um determinado projeto. 
 
PROJECT MANAGEMENT INSTITUTE (PMI). Agile practice guide. USA: PMI Inc., 2017. 
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 abordagens híbridas. 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 serão 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. 
 
SNYDER, C. 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 está 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. 
 
 
140 
 
PROFESSOR-AUTOR 
Guilherme Hoffmann 
Formação acadêmica 
 Mestre em Marketing Internacional pela Universidad 
Nacional de La Plata – Argentina. 
 Formado no Business Executive Program pela 
Donghua University – China. 
 MBA em Gerenciamento de Projetos pela Fundação 
Getulio Vargas. 
 UX Designer pela Glasgow Caledonian University – 
Reino Unido. 
 Agile Coach com diversas certificações: SDS Sprint 
Master, CSM, CSPO, Management 3.0, Kanban, Design Thinking, HCMP, HCMBOK 
3G Practitioner. 
 
Experiências profissionais 
 Consultor sênior, com mais de 20 anos de experiência nas áreas de gerenciamento de 
projetos, métodos ágeis, gestão de mudanças e transformação organizacional. 
 Professor convidado da Fundação Getulio Vargas. 
 Revisor oficial da Scrum Alliance.https://www.instagram.com/fgv.educacaoexecutiva/
https://www.linkedin.com/school/fgv-educacaoexecutiva/
	INTRODUÇÃO
	SUMÁRIO
	MÓDULO I – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DO ESCOPO
	Conceito histórico
	Escopo e os ciclos de vida de um projeto
	Conceitos importantes: visão do produto (ou do serviço), funcionalidades, critérios de aceitação e critérios de validação
	Diferença entre escopo do projeto e escopo do produto
	Termo de abertura do projeto e processos de gerenciamento do escopo
	Retrospectiva do módulo
	MÓDULO II – INTRODUÇÃO E CONCEITOS FUNDAMENTAIS DA QUALIDADE
	Conceito histórico
	Qualidade, processos e a relação com produtividade, eficiência e eficácia
	Defeitos, custo da não qualidade, desperdícios e a visão dos 3 Ms
	Custo da qualidade (CDQ)
	Melhoria contínua: PDCA, 5 whys e retrospectivas
	O fluxo do gerenciamento da qualidade
	Retrospectiva do módulo
	MÓDULO III – PLANEJAMENTO DO ESCOPO: PARTE I
	Valor
	Requisitos: conceito e classificações
	Coleta dos requisitos
	Análise, organização e classificação dos requisitos
	Documentação dos requisitos
	Retrospectiva do módulo
	MÓDULO IV – PLANEJAMENTO DO ESCOPO: PARTE II
	Planejamento do escopo em vários níveis
	Linha de base do escopo
	Estrutura Analítica do Projeto – EAP
	Dicionário da EAP
	Scope creep
	Retrospectiva do módulo
	MÓDULO V – PLANEJAMENTO DA QUALIDADE
	Os três Ks: Kaizen, Kaikaku e Kakushin
	Planejamento da qualidade
	Documentos vinculados ao planejamento da qualidade
	Retrospectiva do módulo
	MÓDULO VI – ACOMPANHAMENTO, VALIDAÇÃO DOS REQUISITOS, ACEITAÇÃO DAS ENTREGAS E CONTROLE DO ESCOPO
	Acompanhamento do escopo e validação dos requisitos
	Aceitação das entregas
	Controle do escopo
	Retrospectiva do módulo
	MÓDULO VII – GERENCIAMENTO E CONTROLE DA QUALIDADE
	Gerenciamento da qualidade
	Processos integrados e de melhoria contínua
	Testes em todos os níveis
	Estudos/Análises de causa e efeito (ou causa-raiz)
	Inspeções
	Cultura customer centric
	Relatório de execução da qualidade
	Controle da qualidade e relatório do desempenho do trabalho
	Retrospectiva do módulo
	BIBLIOGRAFIA
	Bibliografia recomendada
	PROFESSOR-AUTOR
	Guilherme Hoffmann
	Formação acadêmica
	Experiências profissionais