Módulo 3 - Os Temas do PRINCE2

Prévia do material em texto

1
PRINCE2 - Outra maneira 
de gerenciar projetos na 
administração pública
Os Temas do PRINCE23
2
Conteudista:
Tiago Chaves Oliveira (conteudista, 2022); 
Diretoria de Desenvolvimento Profissional.
Enap Escola Nacional de Administração Pública
Enap, 2022
SAIS - Área 2-A -70610-900 - Brasília, DF
3
Sumário
Unidade 1: Os Temas e suas aplicações práticas ..................................................................4
1.1 Adaptando os temas ...................................................................................................................................... 5
1.2 Caso de Negócios ........................................................................................................................................... 6
1.3 Abordagem de Gerenciamento de Benefícios ...................................................................................... 9
1.4 Tema Organização ........................................................................................................................................10
1.5 Tema Qualidade .............................................................................................................................................14
1.6 Tema Planos ....................................................................................................................................................17
1.7 Risco ..................................................................................................................................................................29
1.8 Mudança ...........................................................................................................................................................33
1.9 Progresso.........................................................................................................................................................36
Referências .............................................................................................................................................................42
4
Os temas do PRINCE2 descrevem os aspectos do gerenciamento de projetos que devem ser tratados 
continuamente à medida que o projeto avança em seu ciclo de vida. Eles correspondem aos conhecimentos 
chamados de Áreas do Conhecimento do Guia PMBOK. 
Nesta unidade, você verá, em mais detalhes, a lógica por trás de cada um dos temas e suas principais características. 
Vale ressaltar que a grande força do PRINCE2 é a maneira pela qual os sete temas são inteiramente integrados. 
No PRINCE2, cada tema contém uma abordagem específica, estabelece um conjunto de papéis e 
responsabilidades, e indica documentos e/ou registros a serem elaborados e mantidos. Observe com 
atenção quais são os temas que constam no PRINCE2: 
Unidade 1: Os Temas e suas aplicações práticas
Objetivo de aprendizagem
Ao final desta unidade, você deverá ser capaz de aplicar os temas do PRINCE2 a partir de suas possibilidades 
práticas. Vamos começar!
Nesse módulo, que é composto por uma unidade, você identificará os temas que compõem o PRINCE2, incluindo 
as ferramentas e métodos sugeridos para a sua operacionalização. 
Os Temas do PRINCE2
M
Ó
D
U
LO
3
Temas do PRINCE2.
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
5
1.1 Adaptando os temas
Se não existe uma ordem cronológica específica para a aplicação dos temas, a equipe pode adaptar a 
forma de aplicação! Dependendo do contexto, pode-se, por exemplo, ser mais rígido e prescritivo, ou mais 
permissivo, dando maior liberdade à equipe do projeto. Questões como o risco, o tamanho, a natureza, 
o nível de controle necessário, as políticas e padrões corporativos e a complexidade do projeto podem 
influenciar na decisão sobre como implementar os temas.
Cada tema possui um conjunto de requisitos mínimos que devem ser cumpridos em todos os projetos. 
Portanto, todos os sete temas devem ser aplicados, sempre garantindo que os requisitos mínimos sejam 
atendidos em todos os projetos PRINCE2.
1 o porquê o tema é importante para a entrega bem-sucedida de um projeto;
2 a descrição dos principais conceitos necessários para entender os requisitos do PRINCE2 para o 
tema;
3 a relação dos requisitos do PRINCE2 para o tema, obrigatórias para os projetos PRINCE2;
4 a orientação sobre como aplicar o tema na prática em diferentes organizações, ambientes e 
abordagens de entrega; e
5 a indicação de técnicas que podem ser utilizadas para o tema.
Normalmente, o melhor é manter os processos e procedimentos o mais simples possível e garantir que a 
equipe de gerenciamento de projetos realmente saiba como usá-los. Quanto mais capacitada a equipe, mais 
leves os processos, procedimentos e controles podem ser. É melhor treinar as pessoas no uso de um processo 
ou procedimento do que continuar adicionando mais detalhes na esperança de que eles entendam melhor.
A seguir, serão detalhados os sete temas, contendo as seguintes informações:
Segundo o manual, não existe uma ordem cronológica 
específica para a aplicação dos temas. 
A adaptação permite criar procedimentos e controles adequados ao 
projeto e ao ambiente em que o projeto está, desde que os princípios 
do PRINCE2 sejam mantidos, os requisitos mínimos em cada tema 
sejam atendidos e a finalidade de cada tema não seja comprometida.
Os processos, procedimentos e controles por meio dos quais 
os temas são implementados podem se tornar excessivamente 
complexos e prescritivos. Isso geralmente cria uma carga 
desnecessária nos projetos e raramente fornece maior controle.
Relembre e tome nota: os temas do PRINCE2 são Caso de negócios; Organização; Qualidade; Planos; Risco; 
Mudança e Progresso. Agora, você verá cada um deles com detalhes.
6
Você já sabe que as organizações realizam projetos para fazer melhorias em um ou mais aspectos de seus 
negócios ou operações, certo? Essas melhorias mensuráveis são chamadas de benefícios.
Os projetos PRINCE2 entregam resultados na forma de produtos, e introdução desses produtos no negócio 
da organização gera resultados. Esses resultados permitem que a empresa perceba os benefícios que foram 
pensados no momento da construção da justificativa para o início do projeto.
O objetivo do tema Caso de Negócio (business case, em inglês) é estabelecer mecanismos para a avaliação 
do projeto, verificando se ele é, e continua sendo, oportuno, viável, bem como se os objetivos propostos 
continuam sendo alcançáveis. Em outras palavras, busca-se avaliar se o projeto continua conseguindo 
entregar os benefícios que são desejados. Essa avaliação visa apoiar a tomada de decisão sobre a 
continuidade do projeto. O tema é central para projetos PRINCE2, pois é o cerne do motivo pelo qual um 
projeto está sendo desenvolvido.
Portanto, no PRINCE2, todos os projetos devem ter uma justificativa de negócios documentada. Essa 
documentação, em geral, se dá em um Caso de Negócios.
Em outras palavras, é usado para documentar a justificativa de negócios para a realização de um projeto, 
com base nos custos estimados (de desenvolvimento, implementação e operações contínuas incrementais e 
custos de manutenção) em relação aos benefícios previstos a serem obtidos e compensados por quaisquer 
riscos associados. A documentação deve também delinear como e quando os benefícios esperados podem 
ser medidos. 
O esboço do Caso de Negócio é desenvolvido na etapa de pré-projeto e refinado na etapa inicial. Durante 
todo o projeto deve ser feita a aprovação e reafirmação do Caso de Negócio, que é usado para avaliar os 
impactos de problemas e riscos. Ele é revisado e atualizado no final de cada etapa de gerenciamento, bem 
como no final do projeto. 
Ele pode assumir vários formatos, como o de um documento, uma planilha ou slides de apresentação e 
informações inseridas em uma ferramenta de gerenciamento de projeto
Para garantir que o conteúdo seja de qualidade, deve seguir os seguintes critérios:
1.2 Caso de Negócios
Processo de geração de benefícios.
Fonte:CEPED/UFSC (2021). Adaptado de Axelos (2017)
• Os motivos do projeto devem ser consistentes em comparação com as estratégias da 
organização onde o projeto é realizado; 
• O Plano do Projeto deve estar alinhado com o Caso de Negócios; 
• Os benefícios são claramente identificados e justificados; 
• Deve estar claro como os benefícios serão obtidos; 
• O sucesso do projeto é claramente definido e descrito; 
7
• A opção de negócio mais selecionada é indicada, juntamente com os motivos para a seleção; 
• Deve descrever quando aquisições externas são necessárias e por quê; 
• Indica quando qualquer financiamento necessário ao projeto será obtido; 
• Os principais riscos enfrentados pelo projeto são explicitamente declarados, juntamente com as 
respostas propostas. 
SUMÁRIO EXECUTIVO: 
destaque aos pontos principais, que deve incluir os benefícios esperados; 
JUSTIFICATIVAS: 
define as razões para realizar o projeto e como o projeto permitirá a realização das estratégias e objetivos 
corporativos; 
OPÇÕES DE NEGÓCIOS: 
análise e recomendação fundamentada para as opções básicas de negócios de não fazer nada, fazer o 
mínimo ou fazer algo; 
BENEFÍCIOS ESPERADOS:
acontecem a partir dos resultados desejados a serem alcançados por meio do uso dos produtos do 
projeto. Os benefícios podem ser qualitativos e quantitativos. Quaisquer requisitos de realização de 
benefícios devem ser declarados. As tolerâncias devem ser definidas para cada benefício e para o 
benefício agregado, por exemplo, um aumento de 10 a 15 por cento nas vendas; 
DESVANTAGENS ESPERADAS:
o impacto de um ou mais resultados do projeto pode ser percebido como negativo por uma ou mais 
partes interessadas; 
CRONOGRAMA:
o período durante o qual o projeto será executado (retirados do plano do projeto); 
CUSTOS:
um resumo dos custos do projeto (retirados do plano do projeto); 
PRINCIPAIS RISCOS:
um resumo dos principais riscos associados ao projeto, junto com o impacto provável e os planos, caso 
ocorram. 
AVALIAÇÃO DE INVESTIMENTO:
comparação dos benefícios e desvantagens agregados com os custos do projeto (extraídos do plano do 
projeto) e as operações incrementais em andamento e os custos de manutenção; 
Que informações o Caso de Negócio deve conter? 
8
Principais papéis no Caso de negócios.
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
Em função do princípio de justificativa contínua do projeto, além da elaboração inicial, a justificativa deve ser 
revisada e atualizada regularmente em resposta a decisões e eventos que possam impactar a conveniência 
e viabilidade do projeto. 
Requisitos do PRINCE2 para o caso de negócios
Para seguir o PRINCE2, um projeto deve, no mínimo:
• criar e manter uma justificativa;
• revisar e atualizar a justificativa de negócios em resposta a decisões e eventos que possam 
impactar sua conveniência ou viabilidade;
• definir as ações para garantir que os resultados sejam obtidos e para confirmar que os benefícios 
previstos sejam alcançados; e
• definir e documentar as funções e responsabilidades relacionadas com o caso de negócio e com a 
gestão dos benefícios.
Os dois produtos seguintes devem ser gerados:
Caso de negócios
Indica os custos, benefícios, 
riscos e prazos que serão 
base para a análise de 
viabilidade.
Alternativamente, pode-se 
usar um plano de negócios, 
por exemplo.
Abordagem de 
gerenciamento de 
benefícios
Define as ações para 
garantir que os resultados 
do projeto sejam alcançados 
e para confirmar que os 
benefícios sejam realizados.
9
A seguir, você conhecerá o caminho a ser percorrido para a elaboração do Caso de Negócio e para a 
confirmação dos benefícios provenientes dos resultados do projeto.
O caminho de desenvolvimento do Caso de Negócio.
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
1.3 Abordagem de Gerenciamento de Benefícios 
Uma abordagem de gestão de benefícios define as ações que serão implementadas para garantir que os 
resultados do projeto sejam alcançados e para confirmar que os benefícios do projeto sejam realizados. 
Para garantir que o conteúdo seja de qualidade, deve-se seguir os seguintes critérios:
• Abranger todos os benefícios declarados no caso de negócios; 
• Ter benefícios mensuráveis e as correspondentes linhas de base registradas para permitir 
comparações sobre o alcance dos benefícios; 
• Considerar o tempo adequado para a medição dos benefícios; 
• Indicar as habilidades ou indivíduos que serão necessários para realizar as medições; e 
• Considerar o esforço e o custo para realizar as revisões de benefícios em comparação com o valor 
dos benefícios previstos.
 
Que informações a descrição da abordagem deve conter?
• O escopo, com indicação de quais benefícios devem ser gerenciados e medidos; 
• Os responsáveis pelos benefícios esperados; 
• As ações de gestão necessárias para garantir que os resultados do projeto sejam alcançados; 
• Como medir a realização dos benefícios esperados; 
• Quando a realização dos benefícios pode ser medidas; 
• Quais recursos são necessários para a mensuração; 
• Valores de linha de base a partir dos quais as melhorias serão calculadas; e 
• Como o desempenho do produto do projeto será revisado.
10
• Desenvolver o Caso de Negócios significa obter as informações corretas sobre as quais as decisões 
podem ser tomadas;
• Ao final da etapa inicial e das etapas subsequentes, cabe realizar uma verificação para decidir se 
o projeto (ainda) vale a pena;
• Manter o Caso de Negócio significa manter a justificativa do negócio atualizada com os custos e 
benefícios reais e com as previsões atuais de custos e benefícios;
• Confirmar os benefícios significa avaliar se os benefícios pretendidos foram (ou serão) realizados. A 
confirmação dos benefícios ocorrerá principalmente no pós-projeto, embora possam ser percebidos 
ainda durante a execução. Essa avaliação pode representar um dilema, porque, quando o projeto 
é encerrado, a equipe pode ser dissolvida, o que pode dificultar as atividades de medição. As 
análises de benefícios pós-projeto também irão observar o desempenho dos produtos do projeto 
em uso operacional e identificar se houve quaisquer efeitos colaterais (benéficos ou adversos) que 
podem fornecer lições úteis para outros projetos.
Destaca-se que o PRINCE2 não define quais técnicas devem ser usadas para demonstrar ou provar 
que um projeto é viável, e sim que a análise de viabilidade deve ser feita. A seleção da técnica pode ser 
influenciada pelo tipo de organização (por exemplo, regras de contabilidade do setor público) ou pelos 
próprios padrões da organização.
1.4 Tema Organização
O objetivo do tema Organização é definir e estabelecer a estrutura de responsabilidades e de accountability do 
projeto. Todo projeto precisa de direção, gestão, controle e comunicação eficazes, por isso, estabelecer e manter 
uma estrutura de equipe de gerenciamento e uma abordagem para comunicação é essencial para o sucesso.
Por esta razão, um dos princípios do PRINCE2 é que os projetos devem ter funções e responsabilidades 
definidas e acordadas dentro de uma estrutura organizacional que envolva os interesses das partes 
interessadas de negócios, usuários e fornecedores.
A equipe de gerenciamento de projeto
Negócio 
Os produtos do projeto devem atender a uma necessidade de negócio que justifique o investimento, e o 
projeto também deve fornecer uma boa relação custo-benefício. O ponto de vista do negócio, portanto, 
deve ser representado para garantir que esses dois pré-requisitos estejam presentes antes do início 
do projeto e continuem existindo durante todas as etapas. Em projetos PRINCE2, a alta administração 
representa os interesses de negócio no projeto.
O PRINCE2 identifica três categorias principais de interesses do projeto. 
Sobre o processo de desenvolvimento do Caso de Negócios, visualizado na imagem anterior, registra-se que:
11
A presença do usuário é necessária para especificar os resultados desejados e garantir que o projetoos entregue por meio do fornecedor. 
Em projetos PRINCE2, um usuário experiente deve representar os interesses dos usuários no projeto.
Fornecedor 
Alcançar os resultados do projeto exigirá recursos e certas habilidades. O ponto de vista do 
fornecedor deve representar aqueles que fornecerão as habilidades necessárias e produzirão o 
produto do projeto. 
O fornecedor precisa ter uma compreensão de todos os padrões relevantes com os quais o produto 
precisa estar em conformidade. 
Em projetos PRINCE2, um representante experiente do fornecedor deve representar os interesses 
dos fornecedores no projeto.
Embora seja possível identificar uma ampla gama de outros interesses no projeto – como os interesses do 
governo, de órgão regulador ou de sindicatos –, o negócio, o usuário e o fornecedor são os principais. Esses 
interesses são representados nos projetos por papéis específicos, de forma a garantir o atendimento de 
suas expectativas, conforme você acabou de ver. 
E as equipes de gerenciamento de projeto de sucesso? O que elas devem ter ou assegurar?
• Ter representantes de partes interessadas do negócio, do usuário e do fornecedor;
• Assegurar a governança apropriada, definindo claramente e revisando continuamente as 
responsabilidades em relação à direção, gestão e entrega do projeto; e 
• Ter uma abordagem efetiva para lidar com os fluxos de comunicação com as partes interessadas.
Usarão os resultados 
do projeto para obter 
os benefícios
Vão operar, manter ou 
apoiar os resultados 
do projeto
Serão impactados 
pelos resultados do 
projeto
Usuário 
Serão aqueles que usarão os resultados do projeto. O ponto de vista do usuário representa os indivíduos 
ou grupos aos quais alguns ou todos os itens a seguir se aplicam:
12
Hierarquia do projeto.
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
Os quatro níveis de gestão são:
A hierarquia do projeto
Os gestores em certo nível podem estar muito ocupados para se envolver cotidianamente com o projeto. 
No entanto, os projetos precisam de gestão diariamente para serem bem-sucedidos. Por este motivo, o 
PRINCE2 separa a direção, a gestão e a entrega dos resultados do projeto, levando em consideração o 
princípio de gerenciar por exceção.
Nesse sentido, a estrutura de gerenciamento dos projetos é dividida em quatro níveis, três dos quais 
representam a equipe de gerenciamento de projetos, e um quarto que fica fora do projeto. 
Gestão corporativa, do programa ou do cliente
Este nível fica acima da equipe de gerenciamento de projeto, mas será responsável por recursos que 
poderão ser utilizados pelo projeto, incluindo a identificação do gerente do projeto e a definição das 
tolerâncias dentro das quais o Conselho do projeto trabalhará. Esta informação deve, se possível, ser 
registrada no mandato do projeto.
Direção 
O Conselho é o grande responsável pelo sucesso do projeto. Cabe a ele a direção geral e gestão do 
projeto, dentro das restrições estabelecidas pela gestão corporativa. Suas responsabilidades são:
• Aprovar os principais planos;
• Autorizar desvios que excedam ou possam exceder as tolerâncias estabelecidas;
• Aprovar a conclusão de cada etapa e autorizar o início da próxima;
• Comunicar-se com outras partes interessadas.
13
Gestão
O gerente de projeto é responsável pelo gerenciamento diário do projeto dentro das restrições 
estabelecidas pelo Conselho do Projeto e por garantir que o os produtos necessários sejam produzidos 
de acordo com o tempo, custo, qualidade, escopo, benefícios e metas de desempenho de risco.
Entrega
Os membros da equipe são responsáveis por entregar os produtos do projeto com qualidade apropriada, 
tempestivamente e com um custo adequado. Dependendo do tamanho e complexidade do projeto, a 
autoridade e responsabilidade para planejar a criação de certos produtos e gerenciar uma equipe de 
especialistas para produzi-los pode ser delegada a um gerente de equipe.
• Definir sua estrutura organizacional e papéis, garantindo que todas as responsabilidades descritas 
nos papéis do PRINCE2 sejam cumpridas;
• Documentar as regras para a delegação de autoridade sobre mudança no projeto, se necessário; e
• Definir a abordagem para a comunicação e o engajamento com as partes interessadas.
Dois produtos devem ser gerados e mantidos:
Ambos os produtos devem ser criados durante a etapa inicial do projeto.
Documentação 
Inicial do Projeto 
(DIP)
Define a estrutura e os 
papéis da equipe de 
gerenciamento de projetos.
Abordagem de 
gerenciamento das 
comunicações
Descreve os meios e a 
frequência de comunicação 
para as partes interessadas.
As outras partes interessadas
Pode haver uma ampla gama de partes interessadas, internas ou externas à organização, que podem afetar 
ou ser afetadas pelo projeto. Elas podem:
• Apoiar o projeto;
• Ganhar ou perder como resultado das entregas do projeto;
• Ver o projeto como uma ameaça ou fortalecimento de posição; e
• Se tornar apoiadoras ou opositoras ativos do projeto e de seu progresso.
É importante analisar quem são essas partes interessadas e interagir com elas de forma adequada. O 
envolvimento efetivo com elas é a chave para o sucesso do projeto.
Requisitos do PRINCE2 para Organização
Para seguir o PRINCE2, um projeto deve, no mínimo:
14
1.5 Tema Qualidade
O objetivo do tema Qualidade é definir e implementar os meios pelos quais se verificará se os produtos 
entregues são adequados para os objetivos do projeto, se atendem às expectativas do negócio e se 
possibilitam o alcance dos benefícios desejados. 
O princípio de Foco no Produto é central para abordagem de qualidade do PRINCE2. 
Deixar de realizar as ações de gestão da qualidade pode levar a resultados de baixa qualidade e gastos excessivos. 
De forma a alinhar o vocabulário sobre o tema, o PRINCE2 usa terminologia derivada dos padrões ISO 
9000, mas é voltado especificamente para o trabalho em projetos.voc
Vocabulário da Qualidade
Qualidade é o grau em que um conjunto de características de um produto, serviço, processo, pessoa, 
organização ou recurso do sistema atende aos requisitos;
Gestão da qualidade corresponde às atividades coordenadas para dirigir e controlar uma organização 
no que diz respeito à qualidade;
Expectativas de qualidade do cliente é uma declaração sobre a qualidade esperada, capturada na 
descrição do produto do projeto;
Critérios de aceitação é uma lista priorizada de critérios a que o produto do projeto deve atender antes 
que o cliente o aceite;
Critérios de qualidade é uma descrição da especificação de qualidade a que o produto deve atender 
e das medidas de qualidade que serão aplicadas por aqueles que inspecionam o produto finalizado.
O PRINCE2 requer atividades sistemáticas para:
• Identificar os produtos do projeto até o nível em que o projeto pretende exercer controle;
• Registrar formalmente as expectativas de qualidade do cliente e os critérios de aceitação dos 
produtos do projeto;
• Descrever os produtos, incluindo os critérios de qualidade pelos quais eles serão avaliados, os 
métodos de qualidade a serem usados na concepção, desenvolvimento e aprovação deles, e as 
responsabilidades de qualidade dos envolvidos; e
• Implementar e rastrear os métodos de qualidade empregados em todo o projeto.
Saiba mais:
É importante que você se aprofunde mais sobre a Abordagem de Gerenciamento das 
Comunicações e a Documentação Inicial do Projeto (DIP) previstas no método. Por 
isso, leia com atenção o documento (disponível aqui).
https://articulateusercontent.com/rise/courses/9znMUdX9v1OMf7RazSNoCKzCpJMf_AEq/Xj8OO_PTXeB4oNPJ-Abordagem%2520de%2520Gerenciamento%2520das%2520Comunica%25C3%25A7%25C3%25B5es%2520e%2520Documenta%25C3%25A7%25C3%25A3o%2520Inicial%2520de%2520Projeto%2520(DIP).pdf
15
Planejamento e controle de qualidade
O planejamento da qualidade trata da definição dos produtos do projeto, com seus respectivos critérios de 
qualidade, métodos de qualidade (incluindo o esforço necessário para o controle de qualidade e aprovaçãodo produto) e as responsabilidades de qualidade dos envolvidos.
Se o planejamento falhar, as pessoas envolvidas no projeto podem ter visões conflitantes sobre o escopo 
da solução, o que constitui um resultado de sucesso, a abordagem a ser adotada, a extensão do trabalho 
necessário, quem deveria estar envolvido e quais deveriam ser seus papéis.
O controle de qualidade se concentra nas técnicas operacionais e atividades utilizadas pelos envolvidos no 
projeto para verificar se os produtos atendem aos critérios de qualidade e identificar formas de eliminar as 
causas de desempenho insatisfatório.
O controle de qualidade é obtido por meio da implementação, monitoramento e registro dos métodos de 
qualidade e responsabilidades definidas na abordagem de gestão da qualidade e nas descrições do produto 
(e subsequentemente acordados em pacotes de trabalho).
Planejamento e controle de qualidade.
Fonte: CEPED/UFSC (2021). Adaptado de Freepik
As expectativas de qualidade do cliente devem ser acordadas logo no início do processo de projeto. Elas 
são capturadas em discussões com o cliente e, posteriormente, refinadas para inclusão na descrição do 
produto do projeto.
16
Requisitos do PRINCE2 para Qualidade
Para seguir o PRINCE2, um projeto deve, no mínimo:
• Definir sua abordagem de gestão da qualidade que abranja, no mínimo:
• a abordagem do projeto para o controle de qualidade (assegurar que os produtos são 
entregues conforme a expectativa);
• a abordagem do projeto para a garantia da execução (assegurar de que o projeto está sendo 
conduzido corretamente); e
• como o gerenciamento da qualidade é comunicado ao longo do ciclo de vida do projeto.
• Definir os papéis e responsabilidades para a gestão da qualidade;
• Especificar critérios de qualidade explícitos para produtos em suas descrições;
• Detalhar as expectativas de qualidade do cliente e os critérios de aceitação priorizados para o 
projeto na descrição do produto; e
• Manter registros para fornecer evidências de que as atividades de qualidade planejadas foram realizadas.
Os dois produtos seguintes devem ser gerados e mantidos. 
A abordagem de gerenciamento da qualidade deve ser criada durante a etapa inicial do projeto.
O registro de qualidade é, efetivamente, um diário dos eventos de qualidade planejados e realizados. Ele é 
criado durante o início de um processo de projeto, à medida que os produtos e as medidas de controle de 
qualidade são definidos. 
Sobre as técnicas aplicáveis, o método recomenda o uso da Revisão de Qualidade, técnica que complementa 
o uso de descrições de produtos. Os objetivos de uma revisão de qualidade são:
• avaliar a conformidade de um produto em relação aos critérios de qualidade documentados na descrição;
• envolver as principais partes interessadas na verificação da qualidade do produto e na promoção 
de uma aceitação mais ampla do produto;
• fornecer a confirmação de que o produto está completo e pronto para aprovação; e
• estabelecer a linha de base do produto para controle de alterações futuras.
Abordagem de 
gerenciamento de 
qualidade 
Descreve como a qualidade 
será gerenciada no projeto.
Registro de qualidade 
Resume todas as atividades de 
gerenciamento de qualidade 
planejadas e realizadas, e 
fornece informações para os 
relatórios de monitoramento.
17
1.6 Tema Planos
O objetivo do tema Planos é facilitar a comunicação e o controle, definindo os meios de entrega dos produtos, 
indicando onde, como, por quem e estimando quando e quanto custará.
Os planos fornecem a espinha dorsal das informações de gerenciamento necessárias para qualquer projeto. 
Sem um plano, não é possível realizar o controle do projeto.
Projetos mal planejados causam frustração, desperdício e retrabalho. Portanto, é essencial alocar tempo 
suficiente para que o planejamento ocorra.
Plano é uma proposta detalhada para fazer ou alcançar 
alguma coisa. Especifica o quê, quando, como e por quem o 
objetivo será alcançado. 
No PRINCE2, existem apenas os seguintes tipos de plano: plano 
de projeto, plano de etapa, plano de equipe e plano de exceção.
Saiba mais:
É importante que você conheça um pouco mais sobre a Abordagem da Gestão da qualidade 
e o Registro de Qualidade já estudada. Leia com atenção o documento (disponível aqui). 
Um plano permite que a equipe do projeto entenda:
https://articulateusercontent.com/rise/courses/9znMUdX9v1OMf7RazSNoCKzCpJMf_AEq/JeESL1zFGNn7oAvK-Abordagem%2520de%2520Gest%25C3%25A3o%2520da%2520Qualidade%2520e%2520Registro%2520de%2520Qualidade.pdf
18
Um plano fornece uma linha de base pela qual o progresso pode ser medido. Os planos garantem alinhamento 
sobre o escopo a ser entregue e compromisso dos fornecedores a respeito dos recursos que são necessários.
Os recursos necessários para entregar um plano precisam ser 
comprometidos por aqueles que aprovam esse plano, para 
garantir que eles estejam disponíveis quando necessário.
Lidando com o horizonte de planejamento
O princípio da Gestão por Etapas do PRINCE2 indica que, geralmente, não é possível planejar todo o projeto 
desde o início. O planejamento se torna mais difícil e incerto à medida que o plano avança temporalmente 
no futuro. Haverá um período de tempo durante o qual será possível planejar com razoável precisão: esse 
período é chamado de "horizonte de planejamento". Raramente é possível planejar com algum grau de 
precisão além do horizonte de planejamento.
Muito esforço pode ser desperdiçado em tentativas de planejar além de um horizonte de planejamento 
razoável. Por exemplo, um plano detalhado para mostrar o que cada membro da equipe está fazendo nos 
próximos doze meses quase certamente ficará impreciso depois de apenas algumas semanas. Um plano 
de equipe detalhado para o curto prazo e um plano geral para o longo prazo é uma abordagem mais eficaz.
O PRINCE2 aborda a questão do horizonte de planejamento, exigindo que os planos detalhados de alto 
nível, sejam criados e mantidos no mesmo tempo, refletindo a relativa certeza e incerteza em ambos os 
lados do horizonte de planejamento. 
Requisitos do PRINCE2 para o tema do plano
Para seguir o PRINCE2, um projeto deve, no mínimo:
• Garantir que os planos possibilitem a realização do Caso de Negócios desejado;
• Tenha pelo menos duas etapas de gerenciamento, incluindo uma de iniciação. Quanto mais 
complexo e arriscado for o projeto, mais etapas serão necessárias;
• Produzir um plano de projeto para o projeto como um todo e um plano de etapa para cada etapa de gestão;
• Usar o planejamento baseado no produto para o plano do projeto, para os planos de etapas e para 
os planos de exceção. Pode ser usado opcionalmente para planos de equipe;
Plano de projeto
Para o projeto como um todo
Um plano de alto nível, com 
prazos indicativos, marcos, custos 
e requisitos de recursos com base 
em estimativas
Plano de etapa
Detalha a etapa atual
Alinhado com os cronogramas 
gerais do plano do projeto
Elaborado antes do início da 
etapa e não se estende além do 
horizonte de planejamento
19
• Produzir planos específicos para o gerenciamento de exceções;
• Definir as funções e responsabilidades para o planejamento; e
• Usar lições para informar o planejamento.
O PRINCE2 requer uma abordagem orientada ao produto para decompor a descrição do produto do projeto 
em uma estrutura analítica do produto, ou uma estrutura analítica do trabalho orientada ao produto. Em 
projetos que usam abordagens ágeis, a estrutura analítica do produto pode ser representada por epopeias 
ou histórias de usuários.
O PRINCE2 requer que quatro produtos sejam produzidos e mantidos. 
Os termos “estrutura analítica do produto” e “estrutura analítica do projeto’ podem ser confusos, pois as 
definições da terminologia variam de acordo com os diferentes órgãos profissionais de gerenciamento de 
projetos em todo o mundo. 
O PRINCE2 usa a terminologia da seguinte maneira:
Estrutura analítica do produto: é uma divisão hierárquica dos 
produtos a serem produzidos duranteum plano; no PRINCE2, uma 
estrutura de decomposição do produto contém apenas produtos.
Estrutura analítica do projeto: é uma divisão hierárquica de todo o 
trabalho que precisa ser concluído durante um plano; no PRINCE2, 
uma estrutura analítica do projeto contém apenas atividades.
Plano
Declara como e quando os objetivos 
devem ser alcançados, mostrando 
os principais produtos, atividades e 
recursos necessários para a entrega do 
escopo do plano
No PRINCE2, existem 4 tipos de plano: 
projeto, etapa, equipe e exceção
Descrição do produto do 
projeto
Uma descrição geral do resultado 
do projeto, incluindo as expectativas 
de qualidade do cliente, critérios de 
aceitação e métodos de aceitação para 
o projeto. Como tal, aplica-se apenas a 
um plano de projeto.
Descrição do produto
Uma descrição da finalidade, 
composição, derivação e critérios de 
qualidade de cada produto.
Estrutura analítica do 
produto
Uma hierarquia de todos os produtos a 
serem produzidos durante um plano
20
O Guia PMBOK®, em sua 7ª edição, define uma estrutura analítica do projeto como: 
“Uma decomposição hierárquica do escopo total do trabalho a ser realizado pela equipe do 
projeto para cumprir os objetivos do projeto e criar as entregas necessárias.” (PMI, 2021)
Os usuários do PRINCE2 com experiência no PMI podem achar útil substituir a frase "estrutura analítica do 
projeto orientada para o produto" quando virem a estrutura analítica do produto no manual do PRINCE2.
É importante ressaltar que ambos os usos da terminologia concordam que os gerentes de projeto 
precisam planejar dividindo os produtos ou resultados do projeto primeiro e, só então, decompor a 
atividade necessária para produzir os produtos.
O PRINCE2 recomenda, mas não exige, que um produto adicional seja 
criado e mantido: o Diagrama de Fluxo do Produto. Esse é um diagrama 
que mostra a sequência de produção e as interdependências dos 
produtos listados em uma estrutura analítica do produto.
Todos os planos têm a mesma estrutura e conteúdo fundamentais e o mesmo propósito. O que varia é o 
escopo e o nível de detalhe.
Embora uma sequência esteja implícita ao definir e analisar produtos, na prática, a estrutura analítica do 
produto, as descrições do produto e o diagrama de fluxo do produto são frequentemente criados em paralelo.
Sobre a criação dos planos, temos a seguinte sequência:
Relação entre os produtos 
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
21
Sobre os planos: 
Plano do projeto: é criado durante o processo de iniciação de um projeto e atualizado ao final de cada 
etapa. Ele resume as informações do projeto em alto nível, mostra os principais produtos, quando serão 
entregues e os custos. Um plano de projeto inicial é apresentado como parte do DIP. Esse é um importante 
documento de controle para a medição do progresso real em relação às expectativas.
Plano de etapa: detalha o conteúdo do plano de projeto no nível necessário para o controle diário pelo 
gerente de projeto. Durante o processo de inicialização, elabora-se o plano da etapa de iniciação, antes da 
elaboração do próprio plano do projeto. Todos os planos de etapa subsequentes são produzidos perto do 
final da etapa corrente, como preparação para a próxima. Essa abordagem permite que o plano de etapa seja 
produzido próximo ao momento em que os eventos planejados ocorrerão, o que ajudará o projeto a superar a 
questão do horizonte de planejamento e a incorporar o conhecimento adquirido nas etapas anteriores.
Uma descrição do produto é necessária para todos os produtos identificados em um plano de etapa. 
Ela é usada para:
- compreender a natureza detalhada, a finalidade, a função e a aparência do produto;
- definir quem usará o produto;
- identificar as fontes de informação ou de suprimento do produto;
- identificar o nível de qualidade exigido do produto;
- permitir a identificação das atividades necessárias para produzir, revisar e aprovar o produto; e 
- definir as pessoas ou habilidades necessárias para produzir, revisar e aprovar o produto. 
Plano de exceção: o PRINCE2 requer que planos de exceção sejam produzidos quando apropriado. Eles 
devem ser produzidos para mostrar as ações necessárias para recuperar ou evitar um desvio em relação 
às tolerâncias acordadas no plano do projeto ou em um plano de etapa. Se aprovado, o plano de exceção 
substitui o plano que está em execução e se torna o novo plano de linha de base.
Planos de equipe: os planos de equipe são opcionais e podem não precisar seguir a mesma composição de 
um plano de projeto ou plano de etapa.
Se utilizados, os planos de equipe podem incluir apenas um cronograma anexado ao(s) pacote(s) de trabalho 
atribuído(s) ao gerente da equipe. O plano deve cobrir não apenas as atividades para criar produtos, mas 
também as atividades para gerenciar a criação de produtos, incluindo atividades de garantia, gestão de 
qualidade, gestão de riscos, controle de mudanças, comunicação e quaisquer outros controles necessários.
Cada etapa do projeto pode compreender vários pacotes de trabalho. Um plano de equipe é produzido por 
um gerente de equipe para facilitar a execução de um ou mais pacotes de trabalho. Como são opcionais, 
a necessidade e quantidade dos planos de equipe serão determinados pelo tamanho e complexidade do 
projeto, bem como pelo número de recursos envolvidos.
Os pacotes de trabalho são conjuntos de informações relevantes para a criação de um ou mais produtos, e 
contêm uma descrição do trabalho, a(s) descrição(ões) do(s) produto(s), detalhes de quaisquer restrições à 
produção e a confirmação do acordo entre o gerente de projeto e a pessoa ou gerente de equipe que deve 
implementar o pacote de trabalho de que as ações podem ser executadas dentro das restrições.
Pode haver mais de uma equipe em um projeto, e cada equipe pode vir de organizações diferentes, 
seguindo diferentes métodos de gerenciamento de projeto que não necessariamente o PRINCE2. Em alguns 
22
contextos, na relação entre cliente e fornecedor, pode até ser inadequado para o gerente do projeto ver os 
detalhes do plano da equipe de um fornecedor. Nesses casos, devem ser fornecidas informações resumidas 
para permitir que gerente do projeto exerça o controle. A formalidade do planejamento da equipe pode 
variar de simplesmente anexar um cronograma ao pacote de trabalho a um plano totalmente formado em 
estilo semelhante a um plano de etapa.
A estruturação de um plano
Embora o uso de etapas de gerenciamento em um projeto PRINCE2 seja obrigatório, o número de etapas 
de gerenciamento é flexível e depende da escala, da duração e do risco do projeto. Um projeto simples pode 
precisar apenas de duas etapas, a primeira incluindo o início do projeto e a segunda para realizar o trabalho 
planejado e encerrar o projeto. Projetos maiores podem precisar de etapas de gerenciamento adicionais 
para permitir que a equipe tenha um nível ideal de planejamento e controle.
O PRINCE2 não define quanto tempo uma etapa de gerenciamento deve durar. As etapas de gestão devem 
ser mais curtas quando há maior risco, incerteza ou complexidade (por exemplo, no início dos projetos), e 
podem ser mais longas quando o risco for menor, normalmente nas etapas intermediárias. 
• Horizonte de planejamento em cada momento do projeto: o horizonte de planejamento pode variar 
dependendo da natureza do trabalho que está sendo realizado; e 
• Nível de risco: as etapas de gerenciamento de risco podem ser muito úteis como meio de trazer o 
controle do comitê de projeto para projetos arriscados. Quebras de etapa de gerenciamento podem 
ser inseridas em pontos-chave quando os riscos para o projeto podem ser revisados antes de grandes 
compromissos de dinheiro ou recursos, por exemplo.
 
É importante fazer a diferenciação entre as etapas de entrega e as etapas de gerenciamento: as etapas 
de entrega geralmente se sobrepõem, mas as etapas de gerenciamento, não. As etapas de entrega são 
tipificadas pelo uso de um conjunto particularde habilidades especializadas, enquanto as etapas de 
gerenciamento equivalem ao comprometimento de recursos e autoridade para utilizar esses recursos.
Uma forma de determinar as etapas de entrega é seguir as melhores práticas relacionadas com o tipo de 
produto que está sendo gerado. Por exemplo, a engenharia de software indica um conjunto de etapas para 
construir um software, a engenharia civil indica um conjunto e etapas para se construir um edifício etc.v
Saiba mais:
É importante que você conheça um pouco mais sobre o Tema Planos. Por isso, antes 
de prosseguir, faça uma pausa e leia, com atenção, o documento (disponível aqui). 
Exemplo de cronograma/etapas de gerenciamento e etapas de entrega
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
https://articulateusercontent.com/rise/courses/9znMUdX9v1OMf7RazSNoCKzCpJMf_AEq/yfm7hJEDJVotTCZv-Planos.pdf
23
Frequentemente, o limite das etapas de gerenciamento e de entregas coincidem, por exemplo, quando a 
decisão de gerenciamento é baseada na saída das atividades de entrega. No entanto, em outras ocasiões, 
os limites da etapa de gerenciamento e da etapa de entrega não coincidirão. 
Volte sua atenção para a figura anterior: ela demonstra um exemplo de um projeto fictício em que algumas das 
etapas de entrega correspondem às etapas de gerenciamento, mas, em outros casos, não há essa correspondência.
Abordagem recomendada para definir e analisar os produtos
O PRINCE2 recomenda, mas não obriga, a seguinte abordagem:
Abordagem recomendada para definir e analisar os produtos do projeto
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
A descrição do produto do projeto é criada no início do projeto e refinada no plano do projeto. Ela é 
usada na conclusão do projeto para verificar se o projeto entregou o que era esperado e que os critérios 
de aceitação foram atendidos. Todo esforço deve ser feito para tornar a descrição do produto do projeto 
o mais completa possível desde o início. 
O plano é dividido em seus principais produtos, que são então subdivididos até que um nível de detalhe 
apropriado para o plano seja alcançado. Um produto de nível inferior pode ser um componente de apenas um 
produto de nível superior. A hierarquia de produtos resultante é conhecida como estrutura analítica do produto. 
Conheça mais sobre a estrutura analítica do produto a seguir:
Estrutura Analítica do Produto
A Estrutura Analítica do Produto é o coração do gerenciamento de qualquer projeto. É a ação mais 
importante. É a capacidade de, a partir de um objetivo maior, entender quais são as partes que compõem o 
todo e o que deve ser feito para se chegar lá. 
Dependendo da lógica empregada na estruturação da ferramenta, essa fase pode receber um nome diferente. 
É importante notar que a Estrutura Analítica do Produto ou Product Breakdown Structure é bem semelhante à 
Estrutura Analítica do Projeto (EAP) ou Work Breakdown Structure (WBS) que é uma das principais ferramentas 
de controle de escopo do projeto segundo o PMBOK do PMI. 
A diferença é que a WBS detalha entregas a serem realizadas, com foco no trabalho, no esforço a ser 
despendido, e o PBS detalha os produtos que compõem o produto final a ser gerado.
24
Ao criar uma estrutura analítica do produto, considere o seguinte: 
• é comum envolver uma equipe de pessoas na criação de uma estrutura analítica do produto, talvez 
representando os diferentes interesses e vários conjuntos de habilidades envolvidos na saída do plano; 
• é comum identificar produtos realizando uma sessão de brainstorming estruturada para capturar cada 
produto conforme ele é identificado. Algumas formas de fazer esses brainstormings estruturados são 
usando notas adesivas ou um quadro branco. 
Quando uma equipe está criando uma estrutura analítica de produto, é provável que haja opiniões diferentes 
sobre como separar esses produtos. 
Por exemplo: se a saída do plano for um sistema de contas computadorizado, os usuários podem querer 
separar o sistema em contas a pagar, contas a receber, razão geral etc. Os fornecedores, no entanto, podem 
preferir telas, relatórios, bancos de dados etc. A equipe de gerenciamento de projetos deve chegar a um 
consenso sobre qual abordagem será usada na estrutura de divisão do produto (e, portanto, no plano). 
É útil identificar todos os produtos que devem ser criados por outros projetos, adquiridos ou contratados 
diretamente de um fornecedor; estes são produtos de origem externa. O gerente de projeto não é 
responsável pela criação de produtos de origem externa, pois eles serão fornecidos por terceiros fora da 
equipe do projeto. A equipe do projeto será, no entanto, responsável pelos produtos criados com produtos 
de origem externa. 
Por exemplo: o projeto pode exigir uma máquina de movimentação de terra que será contratada de um 
empreiteiro e será usada pela equipe do projeto para criar um muro de contenção em um canteiro de obras. 
Para produtos de origem externa, deve-se considerar a identificação de ameaças ao plano caso os produtos 
estejam atrasados ou não atendam às especificações exigidas.
Embora o gerente do projeto ou da equipe seja responsável pela criação do 
diagrama de fluxo do produto, é sensato envolver aqueles que irão desenvolver 
ou contribuir para os produtos contidos no plano.
25
Agora que você já viu como funciona a Estrutura Analítica do Produto, fica mais fácil entender que a 
descrição de um produto, portanto, é usada para antever a natureza detalhada, a finalidade, a função e a 
aparência de um produto. É assim que a necessidade do produto é identificada.
Ao criar uma descrição do produto, considere que as descrições devem ser escritas o mais rápido possível 
após a necessidade do produto ter sido identificada. Inicialmente, elas podem ser apenas “esqueletos”, com 
pouco mais do que o título e o identificador como informação. Elas serão refinadas e alterados à medida 
que o produto se torna mais bem compreendido e as etapas posteriores de planejamento são realizadas. 
Um diagrama de fluxo de produto pode ser útil para identificar e definir a sequência na qual os produtos 
do plano serão desenvolvidos e quaisquer dependências entre eles. O diagrama também ajuda a identificar 
dependências de quaisquer produtos fora do escopo do plano. 
Conheça mais sobre o diagrama de fluxo do produto a seguir:
Diagrama de Fluxo do Produto
O diagrama define a sequência em que os produtos previstos na Estrutura Analítica do Produto serão 
desenvolvidos. 
Além disso, ele mostra as dependências dos produtos que serão gerados durante o projeto. 
Para ilustrar o que é essa ferramenta, você pode se lembrar dos manuais de montagem de móveis, do 
estilo “Compre e Faça Você Mesmo”. Eles mostram as etapas que você deve seguir para conseguir montar o 
móvel. A mesma coisa ocorre quando compramos aqueles famosos blocos de montar da marca Lego. 
Quando você concluir a elaboração do diagrama estará pronto para detalhar as atividades necessárias para 
realizar as entregas previstas e para definir o cronograma do projeto. 
Para elaborar o diagrama considere os seguintes pontos: 
• o Gerente do Projeto deve garantir o envolvimento de outras pessoas que vão ajudar a entregar os 
produtos em vez de tentar fazer isso sozinho; 
• você pode efetuar a criação do diagrama de fluxo de produto na mesma reunião em que vão fazer a 
Estrutura Analítica de Produto, já que as pessoas com o conhecimento necessário estarão com você.
Quaisquer produtos que já existam ou que venham do trabalho fora do escopo do plano devem ser 
claramente identificados como produtos a serem adquiridos externamente ao projeto. 
Por exemplo: eles podem ser encerrados em uma forma diferente, como uma elipse.
26
Pode ser útil adicionar um ponto de partida no diagrama de fluxo do produto ao qual todos os pontos de 
entrada estão anexados. 
Sempre há uma saída em um diagrama de fluxo de produto, mas quando há muitas entradas, esse marcador 
de lugar evita que qualquer uma seja esquecida.O símbolo se torna o predecessor para todos os pontos de entrada e seria o único símbolo em um diagrama 
de fluxo de produto que não está na estrutura analítica do produto.
O diagrama de fluxo do produto pode ser derivado de um mapa de benefícios (ligando produtos, resultados 
e benefícios), garantindo assim que os produtos do projeto entregarão os produtos e resultados necessários 
para realizar os benefícios. 
Portanto, na prática, o diagrama define a sequência de entregas 
que deve ser percorrida ao longo projeto. Essa sequência será 
determinante para a definição do cronograma do projeto. 
Agora que você já conheceu o diagrama de fluxo de produto, pode voltar a pensar as estimativas do projeto. 
Estimativas
A decisão sobre quanto tempo e recursos são necessários para realizar uma parte do trabalho, seguindo 
padrões aceitáveis de desempenho, deve considerar o tipo de recurso necessário, ou seja, as habilidades 
que precisam ser aplicadas para realizar a entrega e a estimativa de esforço necessário para cada atividade 
por tipo de recurso.
Regras básicas para estimar
Para ajudar a garantir que uma estimativa seja precisa e realista, leve os 
seguintes fatores em consideração:
• Suponha que os recursos só serão produtivos por 80% do seu tempo;
• Os recursos que trabalham em vários projetos demoram mais para concluir as tarefas devido ao 
tempo perdido alternando entre elas;
• As pessoas costumam ser otimistas e frequentemente subestimam a duração das tarefas;
• Use as experiências de outras pessoas e as suas;
• Certifique-se de que a pessoa responsável pela criação do produto também seja responsável 
pela criação das estimativas de esforço;
• Sempre se prepare para a resolução de problemas, reuniões e outros eventos inesperados;
• Orce cada atividade individualmente em vez de tentar orçar o plano como um todo; e
• Comunique quaisquer suposições, exclusões ou restrições que você tenha considerado.
A estimativa não pode garantir a precisão, mas, quando aplicada, fornece uma visão sobre o custo geral e 
o tempo necessário para concluir o plano. 
Inevitavelmente, as estimativas mudarão à medida que mais coisas forem descobertas sobre o projeto. 
27
Para conhecer uma técnica de estimativa, veja abaixo:
Cronograma
Uma técnica muito utilizada para gerar estimativas é o cronograma. Abaixo você verá alguns detalhes 
importantes sobre esta ferramenta. Tenha em mente que elaborar um cronograma de qualidade pode fazer 
toda diferença em um projeto. 
O primeiro passo para que você elabore um cronograma de qualidade é que já tenha sido elaborada a 
Estrutura Analítica do Produto (EAP). 
A partir da EAP é gerado o Diagrama de Fluxo do Produto, com a sequência em que as entregas devem ser 
feitas e suas dependências.
A partir da EAP detalham-se as atividades que são necessárias para a elaboração de cada um dos produtos 
previstos. 
Os marcos do Projeto (ou milestones) referem-se a momentos fundamentais de um projeto que são 
almejados e normalmente estão associados ao final de etapas. Nas ferramentas de gerenciamento de 
projetos os marcos são atividades que possuem duração igual a zero. 
Em muitos projetos é comum que os marcos sejam de interesse do Conselho do projeto ou da alta 
administração, de forma a apoiá-los no controle do progresso.
Gráfico de Gantt
Sobre o gráfico de Gantt, é algo que sempre 
está presente no gerenciamento de projetos. 
Ele foi desenvolvido por Henry Laurence Gantt 
no início do século XX. Ele era um engenheiro 
mecânico e consultor de gestão e esses gráficos 
foram empregados em centenas de grandes 
construções e outros projetos desde então. 
Seu objetivo era que o gerente do projeto 
pudesse ver facilmente o andamento das 
tarefas e julgar se eles ainda estavam dentro 
do cronograma ou atrasados. 
No gráfico, as barras de tarefas são mostradas em linhas. O comprimento da barra mostra o tempo que se espera 
que a tarefa leve, ou seja, a linha de base do cronograma. A extremidade esquerda da barra mostra o início e a 
extremidade direita, o final.
Ao elaborar um cronograma de um projeto complexo é possível que um mesmo recurso, seja ele de pessoal 
ou um equipamento, sejam alocados em mais de uma atividade ao mesmo tempo. 
Para resolver esse problema surge o Nivelamento de Recursos. Trata-se de técnica que evita a 
superalocação dos recursos. 
Pelo método, recursos são retirados de atividades não críticas e alocados em atividades mais críticas para 
o momento do projeto. 
Com a mudança, o método normalmente aumenta o prazo do projeto. Sendo assim, análises de custos e 
prazos devem ser feitas antes do nivelamento e verificadas novamente após a aplicação do método. 
28
Muitos gerentes de projeto, erroneamente, fazem o nivelamento já na fase de execução, quando percebem 
que não possuem tantos recursos como planejado no cronograma. E após a aplicação do método, chegam 
à conclusão de que precisam renegociar o prazo com o cliente, pois os picos de superalocação foram 
pulverizados, estendendo o tempo necessário.
Um dos pontos mais críticos do processo de planejamento é a estimativa de tempo e esforço, principalmente 
quando se trata de algo que ainda é incerto ou que não se têm muita informação a respeito. 
As principais formas de estimativa são a Análoga, a Paramétrica e a de 3 Pontos. Veja como elas 
funcionam, a seguir:
Também conhecida por Estimativa Top-Down, utiliza-se dos custos ou tempo reais de projetos similares 
anteriores em tamanho, escopo e complexidade para a definição das estimativas do projeto atual. 
Baseia-se praticamente na experiência de quem já realizou um projeto semelhante, alinhando-se pela 
seleção de outros indicadores paramétricos, fatores de escala e curvas de capacidade. 
Sua principal vantagem em relação às demais é o fato de ser mais rápida, menos custosa e menos trabalhosa. 
Porém essa forma perde no quesito precisão. 
É o tipo de estimativa preferido quando não possuímos informações detalhadas sobre o projeto, com 
documentos incompletos, ou então quando a restrição principal é o tempo. 
Estimativa análoga Estimativa análoga
Estimativa Paramétrica 
A Estimativa Paramétrica baseia-se na relação estatística entre dados históricos (parâmetros) e outras 
variáveis para determinar estimativas para parâmetros da atividade, tais como custo, orçamento e duração. 
Tais modelos podem ser simples, como metros quadrados para a engenharia de software ou pontos de 
função para a engenharia de software. 
É um modelo simples e fácil de ser aplicado, além de passível de repetição. Esta técnica pode produzir altos 
níveis de precisão dependendo da sofisticação e dos dados básicos colocados no modelo. 
Estimativa de 3 Pontos 
Utilizada junto a outras técnicas como o Método do Caminho Crítico, o Program Evaluation and Review 
Technique, ou PERT como é mais conhecida, é uma técnica de estimativa mais assertiva em relação às demais 
para estimar esforço e duração das atividades. 
Para a aplicação da técnica o primeiro passo é a obtenção dos valores pelo especialista na realização das 
atividades, levando-se sempre em consideração: 
• Cenário Otimista consiste no cenário perfeito, onde tudo dará certo; 
• Cenário Pessimista representa o pior cenário, onde tudo dará errado; 
• Cenário Mais Provável é o cenário correspondente à normalidade, sem surpresas. 
Um peso maior deve ser aplicado à estimativa do Cenário Mais Provável, normalmente peso 4. Esse valor, por 
outro lado, deve sempre levar em consideração a realidade das atividades do projeto que está sendo estimado. 
29
1.7 Risco
O objetivo do tema de Risco é identificar, avaliar e controlar a incerteza e, como resultado, melhorar a 
capacidade de sucesso do projeto.
Todos os projetos encontram incertezas ao tentar 
alcançar seus objetivos. Essa incerteza pode 
surgir de eventos que ocorrem dentro ou fora da 
organização. Por exemplo, pode haver incerteza 
sobre a capacidade da organização de entregar 
o escopo do projeto dentro de certos prazos 
ou sobrea disponibilidade de recursos críticos. 
Também pode haver incerteza sobre o escopo final 
e a forma da legislação com a qual um projeto é 
necessário para garantir a conformidade. Os riscos, 
se ocorrerem, podem ter um impacto negativo ou 
positivo nos objetivos.Riscos
Fonte: Freepik
Vocabulário de riscos do PRINCE2
Risco é um evento incerto que, caso ocorra, terá efeito no cumprimento dos objetivos. Um risco é me-
dido por uma combinação da probabilidade de ocorrência de uma ameaça ou oportunidade percebida 
e a magnitude de seu impacto nos objetivos.
Gestão de riscos é a aplicação sistemática de princípios, abordagens e processos às tarefas de 
identificação e avaliação, planejamento e implementação de respostas a riscos e comunicação das 
atividades de gestão de riscos às partes interessadas.
Ameaça é um evento incerto que pode causar um impacto negativo nos objetivos.
Oportunidade é um evento incerto que pode causar um impacto positivo nos objetivos.
Exposição ao risco é a extensão do risco suportado pela organização em determinado momento.
Todos os projetos envolvem algum grau de risco e, por este motivo, é preciso gerenciá-los para possibilitar 
uma tomada de decisões eficaz e proativa.
Para que o gerenciamento de riscos seja eficaz: 
• os riscos que podem afetar os objetivos do projeto precisam ser identificados, capturados e descritos;
• cada risco precisa ser avaliado para entender as probabilidades, impacto e tempo (proximidade), 
para que possa ser priorizado; 
• a exposição geral ao risco deve ser mantida sob revisão, juntamente com o impacto do risco na 
justificativa geral do negócio;
• respostas a cada risco devem ser planejadas e atribuídas a pessoas para o devido tratamento; e
• respostas aos riscos precisam ser implementadas, monitoradas e controladas.
30
Ao longo do processo, as informações sobre os riscos devem ser comunicadas dentro do projeto e às 
partes interessadas.
O gerenciamento de riscos eficaz fornece a confiança de que o projeto é capaz de cumprir seus objetivos e 
de que a justificativa do negócio continua válida. Ele apoia a tomada de decisões, garantindo que a equipe 
do projeto entenda não apenas os riscos individuais, mas também a exposição geral ao risco que existe em 
um determinado momento.
Requisitos do PRINCE2 para o tema Risco
Para seguir o PRINCE2, um projeto deve, no mínimo:
• Definir a abordagem de gestão de risco, considerando, no mínimo:
• como os riscos são identificados e avaliados;
• como as respostas aos riscos são planejadas e implementadas;
• como a gestão de risco é comunicada ao longo do ciclo de vida do projeto;
• avaliação sobre o impacto dos riscos identificados sobre a justificativa de negócios do projeto; e
• a descrição dos papéis e responsabilidades para a gestão de riscos.
• Manter o registro dos riscos identificados e das decisões relativas à sua análise, gestão e revisão;
• Garantir que os riscos do projeto sejam identificados, avaliados, gerenciados e revisados durante 
todo o ciclo de vida do projeto; e
• Usar lições para apoiar a identificação e a gestão dos riscos.
O PRINCE2 requer que dois produtos sejam produzidos e mantidos.
Ambos os produtos devem ser criados durante o processo de iniciação do projeto. A abordagem de 
gerenciamento de risco deve ser revisada e, possivelmente, atualizada ao final de cada etapa de gerenciamento. 
Abordagem de 
gerenciamento de risco
Descreve como os riscos serão 
gerenciados no projeto. Inclui 
os processos, procedimentos, 
técnicas, padrões e 
responsabilidades a serem 
aplicados
Registro de riscos
Registro dos riscos 
identificados (ameaças e 
oportunidades) relacionados 
ao projeto, incluindo seu 
status e histórico
Saiba mais:
É importante que você conheça um pouco mais sobre o Tema Riscos. Por isso, antes de prosseguir, 
faça uma pausa e leia, com atenção, o documento que detalha os produtos (disponível aqui). 
https://articulateusercontent.com/rise/courses/9znMUdX9v1OMf7RazSNoCKzCpJMf_AEq/jQfIwVnV5XHaew1r-Abordagem%2520de%2520Gerenciamento%2520de%2520Riscos%2520e%2520Registro%2520de%2520Riscos.pdf
31
Ao olhar para a média das instituições públicas percebe-se uma grande lacuna. 
Os gerentes de projeto dessas organizações não podem ser responsabilizados por isso. Eles primeiro 
precisam seguir uma Abordagem de Gerenciamento de Risco, e o resto da organização também deve estar 
ciente da importância do Gerenciamento de Risco. 
Em termos práticos, para gerir projetos o mais importante é entender a estrutura do Registro de Riscos, 
como usá-lo para inserir informações de Risco e como rastrear os riscos durante o projeto. Esse registro pode 
ser formal ou não. É necessário que se saiba quais eventos podem comprometer o alcance dos objetivos do 
projeto e realizar ações para que estejam sob controle. 
É importante relembrar que o objetivo aqui é identificar, avaliar e controlar a incerteza durante um projeto 
e, como resultado, melhorar a sua capacidade de ser bem-sucedido. 
O gerenciamento de riscos não é feito apenas no início, mas deve ser uma atividade contínua durante toda a 
vida do projeto; é, portanto, uma das principais tarefas do Gerente de Projeto. O Executivo é o responsável 
pelo Risco em um projeto, e eles contam com o Gerente de Projeto para identificar, avaliar e controlar 
continuamente os riscos ao longo de todo o processo. 
O que é risco? 
Para o PRINCE2, risco é um conjunto de eventos que, caso ocorram, afetarão o cumprimento dos 
objetivos do projeto. 
O risco pode ser visto como positivo ou negativo. Outra maneira de dizer isso é que um risco pode 
ser visto como uma ameaça ou uma oportunidade. 
O Gerenciamento de Risco trata das etapas que você executa de uma forma sistemática que lhe 
permitirá identificar, avaliar e controlar o risco. Este Tema de Risco fornece uma abordagem para 
gerenciar o risco em um projeto. Existem três etapas para o Gerenciamento de Risco, que são identificação, 
avaliação e controle. 
• Identificação: como identificar e descrever o risco. 
• Avaliar o risco: probabilidade do risco e seu impacto nos objetivos. 
• Controle do risco: a melhor forma de responder a um risco. 
Veja a seguir uma síntese do que foi abordado neste tópico sobre riscos dentro de um projeto:
O PRINCE2 não prescreve uma abordagem particular ou detalhada para o gerenciamento de risco, e 
qualquer abordagem que atenda aos requisitos descritos pode ser considerada de acordo com o método.
32
O PRINCE2 adota o método MOR, utilizado no Reino Unido. A abordagem não difere muito do COSO e da 
ISO 31000. Ele é uma abordagem genérica para o risco e tem a seguinte abordagem: 
• Primeiro, entenda o contexto do projeto, o que significa entender o ambiente do projeto. 
• Envolva as partes interessadas, usuários, fornecedores e equipes para ajudar a identificar os riscos. 
• Estabeleça uma abordagem para o projeto e documente essa abordagem. 
• Forneça relatórios regulares sobre o risco. 
• Defina funções e responsabilidades de risco. 
Gerenciamento de risco no PRINCE2 
O procedimento de Gerenciamento de Risco é um conjunto de cinco etapas recomendadas pelo PRINCE2:
1 Identificar: identifique os riscos, tanto ameaças quanto oportunidades, que podem afetar o projeto. 
2 Avaliar: avalie os riscos em termos de sua probabilidade e impacto nos objetivos do projeto. 
3 Planejar: aqui, as etapas do seu plano são para preparar a resposta específica às ameaças (por 
exemplo, para ajudar a reduzir ou evitar a ameaça), ou também pode ser um plano para maximizar 
a oportunidade se o risco acontecer. 
4 Implementar: execute as respostas planejadas. 
5 Comunicar: continue se comunicando com as partes interessadas. Use relatórios de gerenciamento 
existentes que são criados durante o projeto (por exemplo, Relatório de Estágio Final). 
Em alguns projetos é necessário manter um orçamento de risco, ou seja, uma quantia de dinheiro que é 
separada para lidar com respostas específicas a ameaças ou oportunidades. Não pode serusado para mais 
nada. Determinadas respostas ao risco exigirão que certas ações que irão custar dinheiro sejam realizadas; 
isso será orçado no Orçamento de Risco. 
33
1.8 Mudança
O objetivo do tema de Mudança é identificar, avaliar e controlar quaisquer mudanças potenciais e aprovadas 
nas linhas de base do projeto.
Os projetos ocorrem em seu ambiente organizacional e em um contexto mais amplo, ambos mudando com 
o tempo. É raro que um projeto seja encerrado tendo entregue exatamente o que estava previsto quando 
foi iniciado. Analise a tirinha e reflita sobre isso:
Tirinha do projeto iniciado.
Fonte: CEPED/UFSC (2021)
Costuma-se dizer que a mudança é inevitável, e esse certamente é o caso de projetos longos e mais 
complexos. Isso significa que os projetos precisam de uma abordagem sistêmica para a identificação, 
avaliação e controle de questões que podem resultar em mudança. 
O controle de problemas e mudanças é uma atividade contínua, realizada ao longo da vida do projeto. 
Sem um processo contínuo e efetivo de controle de mudanças, um projeto deixará de responder às partes 
interessadas ou ficará fora de controle.
No PRINCE2, as mudanças são identificadas como “problemas’ (issues, em inglês). O termo cobre qualquer 
evento relevante que ocorra sem ter sido planejado e requeira ação de gestão. “Problemas” podem ser 
levantados a qualquer momento durante o projeto, por qualquer pessoa interessada nele ou em seu resultado.
34
Depois que um problema foi identificado e capturado, é necessário que haja um processo controlado para 
avaliar o problema e determinar a ação a ser tomada em resposta. A resposta a um problema pode ser mudar 
alguma dimensão do tempo, custo ou escopo do projeto. No entanto, é importante você compreender que a 
resposta apropriada para o problema pode, eventualmente, ser rejeitá-lo e não fazer nada. Existem apenas 
duas razões para implementar uma mudança: 
Motivos para realizar mudanças.
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
Cada mudança deve ser avaliada em relação ao seu impacto sobre uma linha de base (baseline) acordada. A 
linha de base corresponde aos níveis de referência contra os quais uma entidade é monitorada e controlada.
Um pré-requisito para o controle efetivo de problemas e mudanças é definir uma maneira de criar linhas de 
base para produtos e permitir mudanças controladas de forma apropriada. A complexidade disso depende 
do tamanho do projeto e do quão complexo isso pode ser.
No PRINCE2 as coisas que carecem de controle e precisam de linhas de base são chamadas de “itens de 
configuração”. As informações sobre seu estado e situação são mantidas em um “registro de item de configuração”. 
Portanto, um registro de item de configuração descreve a situação, a versão e a variação de um item de 
configuração e demais detalhes relacionados.
Requisitos do PRINCE2 para o tema Mudança
Para seguir o PRINCE2, um projeto deve, no mínimo:
• Definir sua abordagem de controle de mudanças, abrangendo:
• como os problemas são identificados e gerenciados;
• como avaliar se os problemas identificados podem ter um impacto material na justificativa de 
negócios do projeto; e
• os papéis e responsabilidades para o controle de mudança, incluindo uma autoridade de 
mudança definida.
• Definir como as linhas de base do produto são criadas, mantidas e controladas;
• Manter alguma forma de registro dos problemas identificados e das decisões relativas à sua 
análise, gestão e revisão;
• Garantir que os problemas do projeto sejam capturados, examinados, gerenciados e revisados 
durante todo o ciclo de vida do projeto; e
• Usar lições para informar a identificação e gestão de problemas.
O PRINCE2 requer que os seguintes produtos sejam produzidos e mantidos.
35
Os controles do projeto para problemas e mudanças serão definidos e estabelecidos durante o processo de 
início do projeto, então revisados e, se necessário, atualizados no final de cada estágio de gerenciamento, 
pelo gerenciamento de um processo de limite de etapa. 
Procedimento de controle de mudanças e problemas
Na ausência de qualquer outra abordagem, PRINCE2 recomenda o seguinte problema e procedimento de 
controle de mudança:
Na primeira etapa – “Capturar” –, o gerente de projeto faz uma avaliação inicial da gravidade e prioridade 
do problema. O objetivo é distinguir os problemas que podem ser gerenciados informalmente e aqueles que 
precisam ser gerenciados formalmente, para garantir que as decisões sejam tomadas em um nível apropriado. 
A próxima etapa, “Avaliar”, é analisar o impacto do problema. A análise será feita caso o esforço de análise 
valha a pena. Deve ser observado o impacto que o problema tem (ou terá) sobre as metas de desempenho 
do projeto, sobre os riscos, sobre a qualidade e sobre o escopo.
Depois de obter um entendimento completo do impacto do problema, a próxima etapa, “Propor”, é 
considerar opções disponíveis para responder a ele e propor um curso de ação a ser executado. Deve-se 
considerar o efeito que cada uma das opções terá no cronograma, no custo, na qualidade, no escopo, nos 
benefícios e nas metas de desempenho de risco do projeto. Deve haver um equilíbrio entre a vantagem a 
ser obtida com a implementação da opção e os impactos decorrentes.
O gerente de projeto pode ser capaz de resolver problemas sem a necessidade de escalá-los. Por exemplo, 
uma pequena alteração em um documento de design detalhado aprovado que não afete nenhum outro 
produto pode ser tratada pelo gerente de projeto (se permitido na abordagem de controle de mudança), 
desde que seja formalmente registrada. Outras questões podem precisar ser encaminhadas ao comitê do 
projeto (ou à sua autoridade de mudança delegada) para uma decisão.
A implementação da ação corretiva deve garantir que os produtos da linha de base sejam atualizados de 
maneira controlada e com as autorizações apropriadas. 
Registro de problemas
Captura e mantém 
informações sobre todos os 
problemas que estão sendo 
formalmente gerenciados
Abordagem de controle 
de mudanças
Identifica como e por quem 
os produtos do projeto serão 
controlados e protegidos
Capturar
Registrar o 
problema
Determinar 
o tipo e a 
severidade do 
problema
Avaliar 
Avaliar o imapacto 
nos objetivos do 
projeto/ caso de 
negócios
Checar 
severidade / 
prioridade
Propor
Identificar, 
Avaliar e 
Recomendar 
as opções 
possíveis
Decidir 
Escalar a 
decisão à alçada 
competente
Aprovar, rejeitar 
ou adiar a opção 
recomendada
Implementar
Realizar a ação 
corretiva
Atualizar 
registros e 
planos
36
1.9 Progresso
Você chegou até aqui, e agora o tema é Progresso! O objetivo deste tema é estabelecer mecanismos para 
monitorar e comparar as realizações reais do projeto com as planejadas, e fornecer previsões sobre o 
alcance dos objetivos e sobre a viabilidade do projeto e controlar possíveis desvios inaceitáveis.
O controle de progresso envolve a medição do progresso real em relação às metas de desempenho de 
tempo, custo, qualidade, escopo, benefícios e riscos.
O progresso é a medida do cumprimento dos objetivos de um plano. 
O controle do progresso é fundamental para garantir que o projeto permaneça viável em relação ao Caso 
de Negócio aprovado.
Essas informações são usadas para tomar decisões como aprovar uma etapa ou pacote de trabalho, escalar 
problemas e encerrar prematuramente o projeto. O progresso pode ser monitorado no pacote de trabalho, 
na etapa de gerenciamento e no nível do projeto.
Dos sete princípios do PRINCE2, o gerenciamento 
por exceção é particularmente importante para o 
tema de Progresso: uma exceção é uma situação 
em que pode ser previsto que haverá um desvio 
além dos níveis de tolerância acordados.
As tolerâncias são os desvios permissíveis acima 
e abaixo da meta de custo e tempo de um plano, 
sem escalar o desvio para o próximo nível de 
gerenciamento. Também podem haver níveis de 
tolerância para qualidade, escopo, benefícios e risco.
Progresso.
Fonte: FreepikRequisitos do PRINCE2 para gerenciar o progresso
O PRINCE2 não prescreve uma abordagem específica para gerenciar o progresso dos projetos. Qualquer 
abordagem que atenda aos requisitos descritos pode ser considerada de acordo como o método.
Para seguir o PRINCE2, um projeto deve, no mínimo:
• Definir, no DIP, a abordagem adotada para controlar o progresso;
• Ser gerenciado por etapas;
• Definir faixas de tolerâncias e de exceção;
• Rever a justificativa de negócios quando as exceções forem indicadas; e
• Aprender lições.
Saiba mais:
É importante que você conheça um pouco mais sobre o Tema Mudanças. Por isso, 
antes de prosseguir, faça uma pausa e leia, com atenção, o documento que detalha os 
produtos previstos (disponível aqui). 
https://articulateusercontent.com/rise/courses/9znMUdX9v1OMf7RazSNoCKzCpJMf_AEq/zJ9g-we3OrG5P_nh-Abordagem%2520de%2520Controle%2520de%2520Mudan%25C3%25A7as%2520e%2520Registro%2520de%2520Problemas.pdf
37
O controle do progresso é alcançado por meio:
• da delegação de autoridade de um nível de gestão para o nível abaixo dele;
• da divisão do projeto em etapas e da autorização das etapas, uma de cada vez;
• da revisão do progresso com base no tempo e em eventos; e
• da indicação de exceções.
Os controles do projeto devem ser documentados no DIP.
A frequência das ações de acompanhamento do projeto deve refletir o nível de controle necessário, e é 
provável que varie durante o projeto. Por exemplo, se a equipe for altamente experiente, relatórios menos 
frequentes podem ser apropriados, enquanto para uma equipe inexperiente o gerente de projeto pode 
desejar aumentar a frequência dos relatórios até que se tenha confiança suficiente na capacidade da equipe.
Tolerâncias
No PRINCE2, o projeto é gerenciado por exceção a respeito de seis tipos de tolerâncias. 
As tolerâncias devem ser definidas em diferentes alçadas de aprovação, desde a autoridade do gerente de 
equipes e do gerente do projeto, passando pelo conselho do projeto e pela alta administração da organização.
Tipos de controle
O PRINCE2 prevê dois tipos de controle de progresso ao longo da vida de um projeto:
• Controles orientados a eventos 
Acontecem quando ocorre um evento específico. Pode ser, por exemplo, a avaliação da etapa final, a 
conclusão do DIP ou a criação de um relatório de exceção. Também podem incluir eventos organizacionais 
que podem afetar o projeto, como o final do ano financeiro.
• Controles orientados ao tempo 
Eles ocorrem em intervalos periódicos predefinidos. Isso poderia ser, por exemplo, a produção de relatórios 
mensais de ponto de controle, mostrando o progresso de um pacote de trabalho.
Tempo
Quantidade de tempo 
sobre as datas de 
término planejadas
Custo
Quantidade de 
recursos sobre o 
orçamento planejado
Qualidade
Variações sobre 
os requisitos de 
qualidade dos 
produtos
Escopo
Variação permitida no 
escopo do projeto
Benefícios
Faixas de benefícios 
aceitáveis
Riscos
Limites sobre as 
ameaças acordadas
38
Segundo o manual, o monitoramento e a geração de relatórios 
requerem uma abordagem baseada no tempo, enquanto o controle 
(tomada de decisão) é uma atividade baseada em eventos.
Avaliação de progresso do projeto
O progresso do projeto pode apenas ser avaliado no nível de detalhes estabelecido para os planos. Por 
exemplo, se forem necessários relatórios semanais de ponto de controle, o plano de etapas terá que incluir 
o que deve ser alcançado semana a semana.
Como parte do controle de um estágio, o gerente de projeto revisará regularmente o andamento do trabalho 
por meio de relatórios de ponto de controle e manterá os registros e logs do projeto. O gerente de projeto 
usará essas informações para atualizar o plano de etapas com o progresso real alcançado.
O formato e a frequência dos relatórios de ponto de controle dependerão das necessidades do projeto e 
das partes interessadas.
Os seguintes produtos auxiliam na revisão do progresso do projeto:
Produtos de gerenciamento que auxiliam na análise de desempenho 
Fonte: CEPED/UFSC (2021). Adaptado de Axelos (2017)
Além disso, o método sugere a possibilidade de utilização de um registro diário como ferramenta para 
anotar atividades do cotidiano, questões informais e quaisquer outras notas ou observações que não são 
capturadas por outros registros. 
Outra ferramenta que pode ser útil é o registro de lições, usado para capturar e relatar lições aprendidas ao 
revisar o progresso. As lições podem incluir informações sobre gestão, processos, produtos, técnicas ou 
procedimentos que contribuíram para as realizações do projeto ou causaram problemas.
39
Veja a seguir: para aprender sobre ferramentas que podem ser utilizadas para o acompanhamento do 
progresso:
Curva S
Em geral, a intensidade dos esforços em um projeto aumenta até um pico, durante a etapa de entrega, e em 
seguida diminui, até o encerramento. 
Isso significa que o “consumo” de dinheiro e de recursos também chega a um pico e depois diminui. 
A curva S é elaborada a partir do acúmulo do uso de recursos (esforços de pessoas e dinheiro, em geral) ao 
longo do tempo, seguindo o cronograma do projeto. 
A representação gráfica desse acúmulo, tendo o tempo no eixo X e a Quantidade de recursos utilizados no 
eixo Y, geralmente tem a forma de um ‘S’ alongado horizontalmente. Daí o nome do gráfico ‘Curva S’. 
O uso real de um recurso ou despesa deve acompanhar a evolução do projeto. Dessa forma é possível 
realizar ações preventivas e corretivas caso a execução esteja próxima ou fora dos limites planejados. 
Em alguns projetos a execução se dá em velocidade inferior ao que foi planejado, o que leva a curva do 
executado para baixo da curva do planejado. Nesses casos, os gerentes de projeto chamam o gráfico de 
“Boca do jacaré”, em alusão à imagem que o gráfico começa a ilustrar pelo atraso no projeto. 
Burn Chart
Trata-se de uma técnica, bastante utilizada junto com o Scrum, para avaliar o progresso das entregas de um 
Sprint. Ele mostra a conclusão das histórias de usuário ao longo do tempo em comparação com o que ainda 
está pendente no backlog. A imagem lembra uma curva S, com a diferença que ele mostra o quanto já foi 
concluído dos itens que foram planejados. 
40
Curva S
A ferramenta foi desenvolvida pela Toyota no final dos anos 1940. Originalmente visava melhorar a 
eficiência da fabricação. O nome vem do sistema de cartões que rastreia a produção em uma fábrica, e 
desde então foi refinado e personalizado por muitos fabricantes diferentes. Agora esse sistema é utilizado 
na gestão de projetos, destacando-se na orientação do PRINCE2 Agile. 
O Kanban é um quadro composto por colunas com uma série de tarefas em cada uma. 
Quando uma tarefa é concluída em uma coluna por um membro da equipe, ela é puxada para a próxima 
coluna pela pessoa que completará a próxima tarefa. Por exemplo, quando uma tarefa é concluída na coluna 
de programação, ela será deslocada para a coluna de teste. 
É importante ressaltar que as pessoas “puxam” o trabalho de uma coluna para a sua. As tarefas não são 
“empurradas” de uma coluna para a outra, pois o trabalho pode se acumular para um ou alguns membros 
e criar um gargalo. Com esse método, as pessoas só aceitam um novo trabalho quando têm capacidade. O 
Kanban garante um fluxo de trabalho estável. 
Essas são regras básicas do modelo de gestão Lean, ou enxuto, elaborado também pela Toyota, e que é a 
base para todos os métodos e ferramentas ágeis. 
 Com o Kanban todo o trabalho da equipe fica exposto e altamente transparente. Com isso, os membros da 
equipe terão um melhor senso de controle sobre o projeto. 
O uso do Kanban, em geral, está atrelado a rodadas frequentes de feedback. Por exemplo, reuniões diárias 
de acompanhamento, em pé.
41
• Como definir os planos que indiquem as etapas e estratégias que serão seguidas na elaboração 
das entregas do projeto;
• Como gerir os riscos que podem causar algum impacto sobre os objetivos do projeto;
• Como gerir as possíveis