EBOOK Gerência de Projetos

Prévia do material em texto

GERÊNCIA DE PROJETOS
Priscila Nesello, André Steiner
SUMÁRIO
Esta é uma obra coletiva organizada por iniciativa e direção do CENTRO SU-
PERIOR DE TECNOLOGIA TECBRASIL LTDA – Faculdades Ftec que, na for-
ma do art. 5º, VIII, h, da Lei nº 9.610/98, a publica sob sua marca e detém os 
direitos de exploração comercial e todos os demais previstos em contrato. É 
proibida a reprodução parcial ou integral sem autorização expressa e escrita.
CENTRO UNIVERSITÁRIO UNIFTEC
Rua Gustavo Ramos Sehbe n.º 107. Caxias do Sul/ RS 
REITOR
Claudino José Meneguzzi Júnior
PRÓ-REITORA ACADÊMICA
Débora Frizzo
PRÓ-REITOR ADMINISTRATIVO
Altair Ruzzarin
DIRETOR DE ENSINO A DISTÂNCIA (EAD) 
Rafael Giovanella
Desenvolvido pela equipe de Criações para o Ensino a Distância (CREAD)
Coordenadora e Designer Instrucional 
Sabrina Maciel
Diagramação, Ilustração e Alteração de Imagem
Igor Zattera, Julia Oliveira, Thaís Munhoz 
Revisora
Thais Piccoli Dalzochio
INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS 4
OS PROJETOS E O GERENCIAMENTO DE PROJETOS 5
A SELEÇÃO DE PROJETOS E O PORTFÓLIO DE PROJETOS 7
OS PROJETOS E AS OPERAÇÕES 9
A ESTRUTURA ORGANIZACIONAL 11
O CICLO DE VIDA DO PROJETO 14
OS PAPÉIS EM GERENCIAMENTO DE PROJETOS 15
ÁREAS DE CONHECIMENTO DE INTEGRAÇÃO E PRINCIPAIS 22
GRUPOS DE PROCESSOS EM GERENCIAMENTO DE PROJETOS 23
GERENCIAMENTO DA INTEGRAÇÃO 26
GERENCIAMENTO DO ESCOPO 29
GERENCIAMENTO DO TEMPO 33
GERENCIAMENTO DO CUSTO 39
GERENCIAMENTO DA QUALIDADE 41
ÁREAS DE CONHECIMENTO DE SUPORTE 46
GERENCIAMENTO DOS RECURSOS HUMANOS 48
GERENCIAMENTO DAS COMUNICAÇÕES 51
GERENCIAMENTO DOS RISCOS 54
GERENCIAMENTO DAS AQUISIÇÕES 58
GERENCIAMENTO DAS PARTES INTERESSADAS 63
MÉTODOS ÁGEIS DE GERENCIAMENTO DE PROJETOS 68
MANIFESTO ÁGIL 69
O SCRUM 70
ELEMENTOS QUE PODEM SER ADICIONADOS AO FRAMEWORK 77
O PROJECT MODEL CANVAS 79
O PROPÓSITO E A LÓGICA DO PMC 80
OS COMPONENTES E AS ETAPAS DE CONSTRUÇÃO DO PMC 82
3GERÊNCIA DE PROJETOS
APRESENTAÇÃO
O gerenciamento de projetos consiste na aplicação de conhecimento, habilidades, ferramentas e 
técnicas às atividades do projeto, a fim de atender seus requisitos. Cada vez mais as organizações es-
tão buscando diferentes tipos de metodologias para desenvolver seus projetos. Modelos tradicionais, 
ágeis, híbridos, diferentes tipos de abordagens e ferramentas são assuntos que estão em pauta, pois 
precisamos saber usar da maneira correta os recursos da empresa. E isso se faz por meio de um bom 
gerenciamento de projetos!
O nosso material está estruturado da seguinte forma: primeiramente, faremos um alinhamento 
entre os conceitos de base em gerenciamento de projetos. Nessa unidade, vamos diferenciar projetos 
de programas e portfólios, conhecer os diferentes tipos de estruturas organizacionais, os papéis em 
gerenciamento de projetos e o ciclo de vida dos projetos. Esses conceitos são muito importantes para 
que haja um melhor entendimento sobre outros conceitos que virão na sequência.
Nossa segunda unidade fala do método tradicional de gerenciamento de projetos, com base no 
PMBOK GUIDE® 2017. Nessa unidade, vamos conhecer os diferentes grupos de processos que temos 
em gerenciamento de projetos e as 10 áreas de conhecimento que compõe o gerenciamento de pro-
jetos tradicional. Essa unidade também é uma base importante, pois a maioria das abordagens que 
surgiram depois vêm do método tradicional. Ele é amplamente utilizado em todos os segmentos e ge-
ralmente é aplicado em contextos simples – nos quais se tem clareza de qual será o produto, serviço 
ou resultado a ser entregue pelo projeto.
Na sequência, falaremos sobre os métodos ágeis. Esses métodos têm sua 
origem no desenvolvimento de software, mas podem também ser utilizados em 
projetos de qualquer natureza. São indicados para projetos de contextos comple-
xos, nos quais não se tem clareza de qual será a entrega do projeto ou o caminho 
que o time terá que percorrer para atingir seu objetivo. Para tanto, vamos apre-
sentar o Scrum e o Project Model Canvas, abordagens muito interessantes para 
serem utilizadas em projetos inovadores, de menor duração.
Por fim, na nossa quarta etapa, veremos um pouco do uso de softwares na 
gestão de projetos. Para isso, demonstraremos o uso do Microsoft Project, um 
software muito completo e que nos ajuda muito a fazer gestão de projetos, prin-
cipalmente quando temos muitas situações de etapas, prazos, recursos e restri-
ções com as quais nos preocuparmos.
O material desta apostila proporcionará a você uma visão completa do ge-
renciamento de projetos, desde as abordagens tradicionais até o que existe de 
mais moderno na disciplina. Lembre que qualquer abordagem ou método pode 
ser utilizada em qualquer tipo de projeto. Como saber o que utilizar? Primeiro 
você deverá ter uma ideia do todo, depois identificar para o seu projeto o que será 
mais importante e aplicar com propriedade! Boa sorte e bons estudos!
4
INTRODUÇÃO AO 
GERENCIAMENTO DE 
PROJETOS
Entendendo as bases da disciplina.
5GERÊNCIA DE PROJETOS
 SUMÁRIO
A unidade de introdução ao gerenciamento de projetos apresentará os conceitos dessa área que 
desafia as organizações e os profissionais na aplicação de boas práticas para a condução de um projeto. 
As iniciativas de projetos podem ser categorizadas desde melhorias pontuais até complexos esforços 
que têm seus impactos dentro e fora da organização.
Nossos objetivos serão compreender a aplicação do conhecimento, habilidades, ferramentas e 
técnicas para promover o desempenho do projeto; examinar as relações, os projetos e as operações, a 
estrutura organizacional e o ciclo de vida do projeto; e desenvolver a visão crítica da importância dos 
papéis em gerenciamento de projetos. Vamos ao conteúdo!
OS PROJETOS E O GERENCIAMENTO DE PROJETOS
O gerenciamento de projetos tem sido cada vez mais utilizado nas organizações como forma de 
gerar resultados de qualidade, considerando aspectos de prazos, custos e satisfação das partes interes-
sadas, no contexto do projeto. Com a disseminação do tema, cada vez mais os executivos têm adotado o 
gerenciamento de projetos para a condução das iniciativas estratégicas organizacionais. Então vamos 
iniciar esta aula com uma reflexão: você já participou de algum projeto? Certamente sim.
Um projeto, por essência, não é um conceito novo. Projetos sempre existiram, o que talvez tenha 
se modificado ao longo do tempo foi a forma como gerenciá-lo. Pense em sua infância, em como funcio-
nava o seu planejamento de estudos com o objetivo de passar de ano na escola, ou como era organizada 
a viagem de final de ano, a festa de casamento, a preparação para aquele cargo tão almejado na organi-
zação. Todos esses são exemplos de projetos!
Por definição, projeto é um esforço temporário empreendido para criar um 
produto, serviço ou resultado exclusivo. Já o gerenciamento de projetos é a aplica-
ção de conhecimento, habilidades, ferramentas e técnicas às atividades do projeto, 
a fim de atender seus objetivos.
O corpo de conhecimento em gerenciamento 
de projetos, proposto pelo Project Management 
Institute (PMI), é chamado PMBOK® GUIDE.
Nesse guia estão contidos os 47 processos que apoiam o gerenciamento de 
projetos ao longo de todo o seu ciclo de vida. A tarefa de gerenciar um projeto 
passa por equilibrar restrições conflitantes, que variam de acordo com carac-
terísticas e circunstâncias específicas de cada projeto. Exemplos de restrições 
são o escopo, os prazos, os custos, entre outros.
Uma das principais associações mundiais sem 
fins lucrativos em gerenciamento de projetos é o 
Project Management Institute (PMI).
O PMI foi estabelecido em 1969 na Filadélfia, Pensilvânia – EUA, e, segun-
do dados do próprio PMI, possui pessoal certificado em quase todos os países do 
mundo. O trabalho do PMI consiste na divulgação do gerenciamento de projetos 
com base em padrões mundialmente reconhecidos, na pesquisa em gerencia-
crisd
Realce
crisd
Realce
crisdRealce
crisd
Realce
6GERÊNCIA DE PROJETOS
 SUMÁRIO
mento de projetos e na criação de oportunidades de desenvolvimento para profissionais da 
área. Entre as principais certificações oferecidas pelo PMI está a de Project Management 
Professional (PMP). Essa certificação é reconhecida mundialmente e atesta que o profissio-
nal tem formação, experiência e competência para conduzir e dirigir projetos.
Como o PMBOK® GUIDE trata das boas práticas para se gerenciar um projeto, a utiliza-
ção dos processos propostos em maior ou menor grau será uma escolha do gerente de projetos 
e da organização. Essa é a principal diferença entre um guia de boas práticas e uma norma. No 
caso de uma norma, a organização é obrigada a adotar todos os requisitos solicitados. Já as 
boas práticas serão adotadas de acordo com o que representar a melhor opção para o projeto.
7GERÊNCIA DE PROJETOS
 SUMÁRIO
Por fim, um projeto será considerado bem-sucedido se atender ou exceder 
as expectativas das partes interessadas, mediante aprovação formal. Todas as in-
formações relevantes ao projeto são registradas durante seu ciclo de vida. Isso 
irá compor um repositório de lições aprendidas, que será utilizado pela organiza-
ção para projetos futuros, tornando-se um importante ativo organizacional.
A SELEÇÃO DE PROJETOS E O PORTFÓLIO DE PROJETOS
Os projetos surgem nas organizações por motivos que podem ser catego-
rizados na capitalização de oportunidades, na minimização do impacto de ame-
aças, na resposta às mudanças de mercado e no reforço do foco em atividades 
operacionais críticas, entre outros. Em conjunto com o processo de planejamento 
estratégico, no que se refere aos projetos, são geradas iniciativas estratégicas, 
que serão selecionadas e darão origem aos programas ou projetos estratégicos e 
de processos que, por sua vez, irão compor o portfólio de projetos da organização.
Nesse contexto, um programa consiste num conjunto de projetos gerencia-
dos de modo coordenado, para que seja possível obter benefícios não disponíveis 
se esses mesmos projetos fossem gerenciados individualmente. São exemplos de 
programas a implementação de um programa de qualidade em uma organização 
ou o estabelecimento de um programa educacional para uma cidade ou estado. Já 
um portfólio consiste no conjunto de projetos ou programas e outros trabalhos 
agrupados para facilitar o gerenciamento.
Os programas ou projetos selecionados para compor o portfólio devem representar as inicia-
tivas que melhor contribuirão para o alcance das metas estratégicas da organização. Para isso, 
devem passar por uma etapa de avaliação sob a perspectiva da estratégia organizacional, seguindo 
para a priorização de acordo com critérios específicos e o balanceamento, no qual serão analisados 
sob a perspectiva das restrições organizacionais – limitações de recursos. Por fim, alguns projetos 
podem ficar com status de adiados ou cancelados, e poderão ser reavaliados em outros ciclos. Outros 
projetos seguirão para a implementação, compondo o portfólio da organização.
crisd
Realce
8GERÊNCIA DE PROJETOS
 SUMÁRIO
Os métodos de seleção de projetos podem ser enquadrados em duas categorias: mo-
delos matemáticos e modelos de decisão. Os modelos matemáticos utilizam fórmulas ma-
temáticas e algoritmos complexos para subsidiar a tomada de decisão para seleção de um 
projeto. Os modelos de decisão empregam formas de análise e abordagens comparativas no 
processo decisório. São exemplos de modelos de decisão: a análise de custo-benefício, mo-
delos de pontuação e técnicas de análise de fluxo de caixa.
O portfólio de projetos poderá ser composto de programas e projetos de diversas ca-
tegorias, como empreendimentos estratégicos, produto-mercado, operacional e expansão 
de capital. Essas iniciativas, embora independentes, estão ligadas ao planejamento estraté-
gico da organização. O planejamento fornecerá os recursos e o apoio para o desenvolvimen-
to sustentável do portfólio. Com isso, o planejamento estratégico de uma organização será 
o principal norteador dos investimentos em projetos.
Ferramentas utilizadas na seleção e avaliação de projetos
Tempo de retorno (payback period)
É o número de períodos de tempo até o ponto em 
que as receitas acumuladas excedem os custos 
acumulados e o projeto “deu lucro”. O projeto 
que tem o payback mais curto deu lucro mais 
rapidamente.
Valor presente 
Avalia o valor do produto em relação ao que 
será gasto e os retornos em relação a uma 
taxa, trazendo-os para o momento presente, 
objetivando que ele demonstre que é rentável.
Retorno do investimento Taxa de retorno em um período de tempo.
Retorno de vendas
Equivale aos lucros líquidos antes dos impostos, 
como uma percentagem das vendas líquidas.
Retorno em equidade
Quantia recebida no investimento em ações 
comuns em uma companhia.
Elaborado pelo autor com base em HELDMAN (2009).
9GERÊNCIA DE PROJETOS
 SUMÁRIO
O gerenciamento do portfólio tem por função tratar da gestão dos pro-
gramas, projetos, outros trabalhos e, eventualmente, outros portfólios. Ele 
geralmente pode ser executado por um gerente sênior ou uma função dentro da 
estrutura organizacional. O gerenciamento do portfólio tem sob sua responsa-
bilidade o monitoramento dos projetos ativos quanto ao seu alinhamento aos 
objetivos, o equilíbrio entre o portfólio e os demais investimentos da empresa e 
a garantia do uso eficiente de recursos.
OS PROJETOS E AS OPERAÇÕES
Conforme mencionado anteriormente, um projeto é caracterizado por ser 
temporário e exclusivo. Temporário significa dizer que o projeto possui início e 
término definidos, possui ciclo de vida e termina quando os objetivos forem atin-
gidos, ou não. Exclusivo significa dizer que o produto ou serviço a serem desen-
volvidos no projeto são de alguma forma diferentes de todos os outros. São exem-
plos de projetos: a construção de uma garagem, a pesquisa de um novo produto, 
a implantação de uma nova tecnologia, a realização de uma viagem, a publicação 
de um livro, o desenvolvimento de um sistema de gestão, entre outros.
Em contraponto, as operações são esforços contínuos que geram saídas 
repetitivas, com recursos designados para realizar basicamente o mesmo con-
junto de tarefas, de acordo com padrões institucionalizados no ciclo de vida do 
produto. As operações envolvem o trabalho contínuo da rotina da organização. 
10GERÊNCIA DE PROJETOS
 SUMÁRIO
Dessa forma, os objetivos de um projeto estarão relacionados com o atingimento 
das metas e sua conclusão, e as operações estarão envolvidas em manter a organiza-
ção funcionando. Na prática, um ciclo natural de acontecimentos seria o desenvolvi-
mento de algo até ser entregue e aprovado (projeto); a partir de então, isso vira rotina 
para a organização (operação), que pode ser melhorada a qualquer momento. Essa 
melhoria pode ser feita por processos mais simples ou, quando requerida em função 
de sua complexidade e impacto na organização, através de um novo projeto. Dessa 
forma, dizemos que o projeto está ligado a situações únicas ou grandes melhorias, e 
a gestão de operações está ligada ao dia a dia e manutenção da rotina da organização.
Um conceito que acompanha os aspectos 
temporários e únicos de um projeto é o da 
elaboração progressiva.
A elaboração progressiva ocorre quando maiores níveis de detalhes de um pro-
duto ou serviço de um projeto surgem de forma iterativa durante o seu desenvolvi-
mento. Esse conceito é importante, pois nem sempre todos os requisitos acerca do 
projeto são conhecidos nas etapas iniciais.
Os projetos e as operações podem estar se cruzando em muitos momentos como, 
por exemplo, em cada fase de encerramento, no desenvolvimento de novos produtos, na 
melhoria das operações e até o fim do ciclo de vida de um produto. Com isso, projetos e 
operações formam um contínuo no qual não é possível identificar quem é causa ou efeito.
Dica: em função dos impactos da transiçãodos projetos 
para as operações, é interessante envolver as pessoas das 
unidades de negócio para que participem no projeto. Essa 
é uma estratégia para que seja estimulada a confiança e 
comprometimento das partes interessadas.
11GERÊNCIA DE PROJETOS
 SUMÁRIO
Muitas vezes, a identificação de um projeto na organização não é um 
processo simples. Por exemplo, imagine que se tenha uma demanda para 
a alteração de uma funcionalidade do sistema de gestão da organização, 
criação de uma nova coleção de roupas para a próxima estação ou a aber-
tura de uma filial em outro estado. Nesse momento, a primeira pergunta 
que vem à mente é: “Isso é um projeto?”.
A importância de se identificar a existência de um projeto ou operação 
contínua é justamente poder dar o tratamento adequado para a iniciativa. 
Assim, se a demanda for enquadrada como um projeto, deverá ser condu-
zido o processo de seleção de projetos, descrito anteriormente. Se for en-
quadrada como uma operação contínua, deverão ser seguidas as políticas 
da organização no que tange ao gerenciamento de processos de negócio.
A ESTRUTURA ORGANIZACIONAL
A estrutrura organizacional é um fator ambiental relacionado ao 
estilo e cultura próprios de cada organização. A estrutura afetará a forma 
de condução dos projetos na organização, o tratamento e disponibilização 
de recursos e o nível de autonomia do gerente de projetos.
De acordo com sua estrutura, as organizações podem ser divididas 
em projetizadas, matriciais e funcionais. 
12GERÊNCIA DE PROJETOS
 SUMÁRIO
• As organizações projetizadas são aquelas orientadas para a execução de projetos. Nes-
sas estruturas, equipes já estão formadas e prontas para o desenvolvimento dos projetos. 
Um exemplo de estrutura projetizada são organizações cujo produto seja sempre algo 
novo (construção, por exemplo), nas quais uma equipe que tem pessoal/recursos ligados a 
todas as atividades é destinada a um projeto; quando ele acaba, esse pessoal/recursos é des-
tinado a outro projeto. Usualmente, se são grandes organizações, existe pessoal/recursos 
trabalhando de forma paralela em cada projeto da empresa.
Elaborado pelo autor.
E
la
b
o
ra
d
o
 p
e
lo
 a
u
to
r.
Um exemplo de estrutura projetizada são organizações cujo produto seja sempre algo 
novo (construção, por exemplo), nas quais uma equipe que tem pessoal/recursos ligados a 
todas as atividades é destinada a um projeto; quando ele acaba, esse pessoal/recursos é des-
tinado a outro projeto. Usualmente, se são grandes organizações, existe pessoal/recursos 
trabalhando de forma paralela em cada projeto da empresa.
• As estruturas funcionais são estruturas orientadas às operações contínuas. Eventu-
almente, essas organizações também desenvolvem projetos e, quando isto acontece, 
profissionais são remanejados de áreas funcionais para o cumprimento das tarefas 
definidas para o projeto.
13GERÊNCIA DE PROJETOS
 SUMÁRIO
Um exemplo de estrutura funcional é uma empresa que tenha um departa-
mento de projetos e que esse, de acordo com a necessidade de projetos específicos, 
se utilize de pessoal/recursos de cada departamento de forma temporária; quando 
o projeto se encerra, esse pessoal/recursos volta à atividade normal em seus de-
partamentos. Esse é o caso típico de empresas menores que se utilizam, por exem-
plo, de uma pessoa específica para auxiliar nos projetos de cada departamento.
• As estruturas matriciais possuem uma variação que vai desde a matriz for-
te, passando pela matriz balanceada até a fraca. Se a estrutura estiver mais 
próxima de uma projetizada, então será matriz forte. Se a estrutura estiver 
mais próxima de uma funcional, então será matriz fraca. A matriz balancea-
da ficaria como uma posição intermediária na classificação.
Um exemplo de estrutura matricial é uma empresa que tem diversos tipos de produtos diferen-
tes, cada qual com sua especificidade e, para isso, tem dentro de cada departamento pessoal/recursos 
dedicados a esses produtos, que se ligam aos seus pares em outros departamentos para trabalhar. 
Nesse sentido, haveria uma estrutura de desenvolvimento de projetos dedicada a cada uma dessas 
linhas de produtos. Esse é o caso típico de grandes organizações com linhas amplas de atuação. 
Uma organização projetizada, apesar de estar orientada aos 
projetos, também possui operações contínuas.
Da mesma forma, uma organização funcional, apesar de orientada às operações contínuas, 
também possui projetos. A diferença entre uma estrutura e outra está na intensidade dessas rela-
ções. A influência das diferentes estruturas organizacionais no desenvolvimento de projetos pode 
ser mais facilmente entendida se observada a atuação do gerente de projetos. O gerente de projetos 
é a pessoa que liderará a equipe e será responsável por alcançar os objetivos do projeto. Esse papel é 
diferente de um gerente funcional, pois tem o foco no desenvolvimento do projeto, enquanto o outro 
tem o foco nas operações contínuas. 
No entanto, se esse gerente de projetos estiver liderando uma equipe em uma estrutura fun-
cional, geralmente a sua autoridade será menor, bem como a disponibilidade de recursos, o con-
trole do orçamento, o nível de suas atribuições e o número de integrantes da equipe. Se o gerente de 
projetos estiver liderando uma equipe em uma estrutura projetizada, maior será sua autoridade, 
disponibilidade de recursos, controle do orçamento, atribuições e equipe - o contrário da estrutura 
funcional. Entre um extremo e outro, as estruturas matriciais equilibrarão essas variáveis de acor-
do com a proximidade dos extremos de uma estrutura funcional ou projetizada.E
la
b
o
ra
d
o
 p
e
lo
 a
u
to
r.
14GERÊNCIA DE PROJETOS
 SUMÁRIO
Essas relações contribuem ou dificultam o andamento do projeto, 
pois em uma estrutura projetizada geralmente as equipes são fixas, e isso 
faz com que os membros já se conheçam e tenham afinidades. Com isso, o 
trabalho do projeto já inicia com um bom nível de desempenho. Ao contrá-
rio, em estruturas funcionais, as equipes são formadas especialmente para 
um projeto. Muitas vezes os membros ainda não se conhecem e, por isso, 
no início do projeto o desempenho é baixo.
O CICLO DE VIDA DO PROJETO
O ciclo de vida do projeto é constituído de fases pelas quais um projeto passa, do início ao término. 
Essas fases são determinadas pelo nível de gerenciamento e controle requerido pelas organizações, pelo 
tipo de projeto e pela área de aplicação do produto ou serviço que está sendo desenvolvido. Independente-
mente da complexidade do projeto, as seguintes fases podem ser propostas para um ciclo de vida genérico: 
início do projeto, organização e preparação, execução do trabalho do projeto e encerramento do projeto.
Na fase inicial do desenvolvimento de um projeto, geralmente haverá maior incidência de riscos e 
menor alocação de recursos financeiros. Isso ocorre em função de que nessa fase o escopo total do projeto 
ainda pode ser desconhecido, e a equipe estará mais focada em se aprofundar nesse conhecimento e plane-
jar o projeto. À medida que o projeto avança, o escopo se torna mais bem conhecido e as tarefas começam 
a ser realizadas pela equipe. Com isso, os riscos vão diminuindo e as alocações de recursos financeiros vão 
sendo executados. Por fim, os produtos ou serviços demandados do projeto são entregues e aceitos pelas 
partes interessadas, e a equipe se desfaz. Nesse ponto, os custos do projeto caem rapidamente.
As relações entre as fases do ciclo de vida podem se apresentar de duas maneiras diferentes durante 
o desenvolvimento do projeto. A primeira é uma relação sequencial, na qual uma fase só iniciará depois 
que a fase anterior terminar; a segunda é uma relação sobreposta, em que uma fase tem início antes do 
término da anterior. As fases sobrepostas podem aumentar o risco e resultar em retrabalho se as informa-
ções não forem bem entendidas antes do início do trabalho, na fase subsequente.Também podem requerer 
recursos adicionais, para executar de forma paralela o trabalho do projeto. Em contrapartida, a utilização 
da relação sobreposta pode gerar ganhos em termos do tempo de execução do projeto.
crisd
Realce
crisd
Realce
15GERÊNCIA DE PROJETOS
 SUMÁRIO
As técnicas de compressão de cronograma visam a reduzir o cronograma 
do projeto (data de entrega) sem mudar o escopo.
Elas são a compressão entre custos e cronograma e o parale-
lismo de atividades. Em projetos com mais de uma fase, pode ha-
ver diferentes aplicações das relações entre fases individuais. Os 
ciclos de vida de projetos ainda podem ser definidos como: ciclos 
de vida previstos, ciclos de vida iterativos e incrementais ou ciclos 
de vida adaptativos.
Nos ciclos de vida previstos, geralmente todo o escopo do pro-
jeto já é de conhecimento das partes interessadas antes do seu iní-
cio. Nesses casos, o projeto será desenvolvido de acordo com um 
ciclo de vida de produto já conhecido. Nos ciclos de vida iterativos e 
incrementais, o escopo ainda não é totalmente conhecido, por isso 
é necessário dar início ao projeto para que a compreensão da equipe 
aumente acerca dos produtos ou serviços que serão desenvolvidos 
no projeto. Já os ciclos de vida adaptativos estão direcionados à mu-
dança ou à aplicação de métodos ágeis.
OS PAPÉIS EM GERENCIAMENTO DE PROJETOS
Os principais papéis dos envolvidos em projetos nas organiza-
ções são: o escritório de projetos (Project Management Office – PMO), 
o patrocinador (Sponsor), o gerente de projetos (Project Manager) e 
as partes interessadas (Stakeholders).
16GERÊNCIA DE PROJETOS
 SUMÁRIO
• O Escritório de projetos é uma estrutura organizacional que padroniza os processos de 
governança relacionados a projetos e facilita o compartilhamento de recursos, metodo-
logias, ferramentas e técnicas. Ele é uma fonte por meio da qual o gerenciamento irá per-
mear todas as partes da organização. Fundamentalmente, ele é necessário para apoiar, 
influenciar e direcionar esforços. Sua atuação vai desde o provimento de serviços ope-
racionais, passando pelos táticos e chegando aos serviços estratégicos. Normalmente, o 
escritório de projetos é um tipo de papel que é facilmente identificado em grandes cor-
porações, nas quais existe um grupo de pessoas que se reúne e define as situações ligadas 
a projetos, tais como prover metodologias, acompanhar projetos fornecendo suporte, 
capacitar colaboradores, fornecer indicadores, garantir o alinhamento estratégico, re-
comendar a inclusão ou cancelamento de projetos etc. Em empresas menores, esses atri-
butos todos acabam sendo ligados diretamente ao gerente de projetos ou função análoga.
• O patrocinador é a ponte existente entre a organização e os projetos em andamento na 
empresa. Ele fornecerá os recursos e o suporte necessário para o desenvolvimento do 
projeto. O patrocinador também irá encaminhar as questões que estiverem além da res-
ponsabilidade do gerente de projetos aos níveis hierárquicos superiores. Suas funções 
vão desde o início até o fim do projeto, como assegurar que as estratégias e planos es-
tejam estabelecidos e controlados, fornecer apoio para mobilização da equipe, fornecer 
apoio político ao projeto, garantir que o projeto permanecerá alinhado ao plano estra-
tégico, monitorar a transição do projeto para operação, estimular o rápido encerramen-
to do projeto etc. Em projetos como as startups, esse é o papel conhecido como “anjo”, 
tendo a função de efetivamente garantir recursos para a execução do projeto.
crisd
Realce
17GERÊNCIA DE PROJETOS
 SUMÁRIO
• O gerente de projetos é o elo entre a estratégia da organização e a equipe definida que irá fazer parte do projeto. Os 
gerentes são responsáveis pelo atendimento das necessidades de tarefas, da equipe e de necessidades individuais de 
seus membros. Muitas vezes o gerente de projetos ainda terá que se reportar ou trabalhar de maneira colaborativa 
com o gerente funcional, gerente de programas ou portfólios e outras funções como analistas de negócios e espe-
cialistas de outras áreas. Para isso, ele necessita de um conjunto de habilidades muito peculiar. 
18GERÊNCIA DE PROJETOS
 SUMÁRIO
Primeiramente, ele deve ter a compreensão da aplicação do conhe-
cimento, ferramentas e técnicas reconhecidas como boas práticas em ge-
renciamento de projetos. Mas apenas isso não é o suficiente; ele ainda deve 
promover o desempenho adequado no projeto. Essa habilidade refere-se a 
ser capaz de fazer ou realizar o trabalho do projeto de maneira a atender 
aos interesses e expectativas das partes interessadas, por meio do conhe-
cimento em gerenciamento de projetos. 
Ele também deve ter habilidades pessoais que se referem ao seu com-
portamento na execução do projeto ou atividade relacionada. A efetividade 
pessoal abrange atitudes, características de personalidade e liderança. 
Algo bastante importante é compreender que o papel comumente 
chamado de “gerente de projetos” é uma questão de nomenclatura, já que 
nem sempre essa pessoa tem realmente status de gerência em uma orga-
nização, mas trata-se da definição da pessoa que gerencia projetos. É uma 
grande diferença; portanto, se esse cargo for atribuído a um supervisor, 
analista, coordenador, diretor etc., não importa: ele terá a função de ge-
rente de projetos, e não o cargo de gerente de projetos.
De acordo com PMI, 90% do tempo do 
gerente de projetos é consumido adquirindo e 
comunicando informação.
19GERÊNCIA DE PROJETOS
 SUMÁRIO
a. As partes interessadas incluem todos os membros da equipe, assim como todas as entida-
des interessadas dentro ou fora da organização. As partes interessadas podem ter diferentes 
níveis de interesse no projeto. A seguir, podemos visualizar suas diferentes características.
• Campeões de projetos: são aquelas partes que se envolvem desde o início no desenvolvimen-
to do projeto e tem interesse real no seu sucesso. Alguns exemplos são os investidores, os pa-
trocinadores de projetos e os clientes.
• Participantes do projeto: é o grupo que realiza o trabalho do projeto. Seu papel está relaciona-
do ao projeto em si. Alguns participantes são o gerente de projetos, a equipe e os fornecedores.
• Externos: essas partes são passíveis de se envolver no projeto se tudo não ocorrer de acordo 
com seus interesses. Elas são afetadas pelo projeto à medida que ele se desenvolve ou no seu 
término. São exemplos ambientalistas, líderes comunitários e mídia.
Elaborado pelo autor
20GERÊNCIA DE PROJETOS
 SUMÁRIO
Também é importante salientarmos a diferença entre projetos e opera-
ções. Como vimos, um projeto é caracterizado por ser temporário e exclusivo. 
Já as operações são esforços contínuos que geram saídas repetitivas. 
Vimos que a estrutura organizacional é um fator ambiental relacionado 
ao estilo e cultura próprios de cada organização. As organizações podem ser 
divididas em projetizadas, matriciais e funcionais. As organizações projeti-
zadas são aquelas orientadas para a execução de projetos. As estruturas fun-
cionais são estruturas orientadas às operações contínuas.
Os projetos são constituídos de fases, do seu início ao término. As 
relações entre as fases do ciclo de vida podem se apresentar de duas ma-
neiras diferentes durante o desenvolvimento do projeto. A primeira é uma 
relação sequencial, na qual uma fase só iniciará depois que a fase anterior 
terminar. A segunda é uma relação sobreposta, em que uma fase tem início 
antes do término da anterior.
Por fim, temos os principais papéis dos envolvidos em projetos nas 
organizações: o escritório de projetos (Project Management Office – PMO), 
o patrocinador (sponsor), o gerente de projetos (project manager) e as par-
tes interessadas (stakeholders). 
É importante determinar categorias ou grupos de partes interessadas para melhor gerenciá-las. Es-
sas partes podem representar aliados ou opositores ao projeto, com diferentes níveis de interessee poder. 
Esse processo é conduzido para que se possa dar maior importância para as partes que realmente têm re-
levância para o projeto e planejar as estratégias para o seu tratamento.
O gerenciamento das partes interessadas é uma das áreas de conhecimento de gerenciamento de 
projetos. Ela consiste na identificação das partes interessadas, no planejamento do gerenciamento dessas 
partes, no gerenciamento do seu engajamento e no controle do seu engajamento.
RESUMO DA UNIDADE
Nesta unidade, estivemos alinhando alguns conceitos que são a base da disciplina de gerencia-
mento de projetos. Um projeto é definido como sendo um esforço temporário empreendido para criar 
um produto, serviço ou resultado exclusivo. O gerenciamento de projetos é a aplicação de conheci-
mento, habilidades, ferramentas e técnicas às atividades do projeto, para que este possa atender aos 
objetivos para os quais foi criado.
O Project Management Institute (PMI) é uma instituição internacional sem fins lucrativos que asso-
cia profissionais de gestão de projetos. O corpo de conhecimento em gerenciamento de projetos proposto 
pelo PMI é chamado PMBOK® GUIDE. Nesse guia, estão contidos os 47 processos que apoiam o gerencia-
mento de projetos ao longo de todo o seu ciclo de vida.
crisd
Realce
crisd
Realce
21GERÊNCIA DE PROJETOS
EXERCÍCIOS SUMÁRIO
Questões para reflexão que são importantes para o entendimento 
desta unidade.
1. Diferencie projeto de operação.
2. Quais são os tipos de organizações quanto à sua relação com projetos?
3. Quais são os principais papéis relacionados a projetos e suas funções?
4. O que é a função de gerente de projetos? Qual sua importância?
5. Você, no seu âmbito profissional ou pessoal, entende como se encai-
xam os conceitos de projeto? Tem alguma experiência, mesmo que 
não estruturada, com isso? 
22
ÁREAS DE 
CONHECIMENTO 
DE INTEGRAÇÃO E 
PRINCIPAIS
O que são áreas de conhecimento? Como funcionam as principais?
23GERÊNCIA DE PROJETOS
 SUMÁRIO
Os processos descritos no PMBOK® GUIDE estão agrupados em cinco categorias: pro-
cessos de iniciação, planejamento, execução, monitoramento e controle e encerramento. Es-
ses processos pertencem a dez áreas de conhecimento distintas. Uma área de conhecimento 
representa um conjunto completo de conceitos, termos e atividades de um campo profissio-
nal. As áreas de conhecimento são: gerenciamento da integração do projeto, do escopo, do 
tempo, da qualidade, dos recursos humanos, das comunicações, dos riscos, das aquisições e 
das partes interessadas do projeto. Vamos conhecer um pouco melhor essas áreas de conhe-
cimento e compreender a contribuição de cada uma delas para o sucesso dos nossos projetos!
GRUPOS DE PROCESSOS EM GERENCIAMENTO DE PROJETOS
Para iniciarmos o entendimento sobre os grupos de processos do gerenciamento de 
projetos, primeiramente precisamos entender o que é um processo.
De acordo com o guia PMBOK®, um processo é um 
conjunto de ações e atividades inter-relacionadas que são 
executadas para criar um produto, serviço ou resultado 
pré-especificado.
Em gerenciamento de projetos, cada processo é caracterizado por suas entradas, fer-
ramentas, técnicas e saídas resultantes. Esses processos que compõe o conjunto de práticas 
para o gerenciamento de projetos podem ser divididos em duas categorias: os processos de 
gerenciamento de projetos e os processos orientados ao produto.
Os processos de gerenciamento de projetos são os 47 que estudaremos nesta unidade. 
Os processos orientados a produtos são específicos de cada tipo de projeto que será desen-
volvido, seu ciclo de vida, área e fase do ciclo de vida do produto. Por exemplo, gerar protó-
tipo pode ser um dos processos orientados a produto em um projeto de desenvolvimento de 
um novo componente para o setor automotivo. 
Uma visão de todos os grupos de processos de gerenciamento de projetos e suas áreas de 
conhecimento pode ser obtida de forma integrada no mapa de processos de gerenciamento:
24GERÊNCIA DE PROJETOS
 SUMÁRIO
Planejamento
5.1 Planejar
Gerenciamento
do Escopo
4.2 Desenvolver Plano de 
Gerenciamento do Projeto
6.1 Planejar
Gerenciamento
de Tempo
7.1 Planejar
Gerenciamento
de Custo
11.1 Planejar
Gerenciamento
de Riscos
12.1 Planejar
Gerenciamento
das Aquisições
13.2 Planejar
Gerenciamento
das Partes
Interessadas
11.2 Identificar 
Riscos
8.1 Planejar
Gerenciamento
da Qualidade
9.1 Planejar
Gerenciamento
dos Recursos
Humanos
10.1 Planejar
Gerenciamento
dos Recursos
Humanos
Execução
4.3 Orientar e Gerenciar a 
Execução do Projeto
12.2 Conduzir 
Aquisições
13.3 Gerenciar
Partes Interessadas
8.2 Realizar
Garantia da 
Qualidade
9.2 Mobilizar
Equipe do Projeto
9.3 Desenvolver
Equipe do Projeto
9.4 Gerenciar
Equipe do Projeto
10.2 Gerenciar 
Comunicação
7.2 Estimar
Custos
7.3 Criar
Orçamento
11.3 Realizar 
Análise
Qualitativa 
dos Riscos
6.3 Sequenciar 
Atividades
6.5 Estimar 
Durações das 
Atividades
6.6 Desenvolver 
Cronograma
5.2 Coletar 
Requisitos
5.3 Definir 
Escopo 5.4 Criar EAP
11.4 Realizar 
Análise
Quantitativa 
dos Riscos
11.5 Planejar 
Respostas aos 
Riscos
6.4 Estimar 
Recursos das 
Atividades
6.2 Definir 
Atividades
Iniciação
4.1 Desenvolver
Termo de Abertura
do Projeto
13.1 Identificar
Partes Interessadas
4.6 Encerrar o 
Projeto ou Fase
12.4 Encerrar o 
AquisiçõesEncerramento
Monitoramento e Controle
6.7 Controlar 
Cronograma
4.4 Monitorar e Controlar 
o Trabalho Projeto
4.5 Realizar Controle 
Integrado de Mudanças
12.3 Administrar 
Aquisições
13.4 Monitorar o 
Gerenciamento das
Partes Interessadas
8.3 Realizar
Controle da 
Qualidade
10.3 Controlar 
Comunicação
7.4 Controlar
Custos
5.5 Validar
Escopo
5.6 Controlar
Escopo
11.6 Monitorar e 
Controlar Riscos
Fonte: Adaptado de Portal MundoPMP
PROCESSOS DE GERENCIAMENTO
COR 
(NÚMERO)
ÁREA DE 
CONHECIMENTO
Cinza (4): 
Gerenciamento da 
integração
Vermelho (5): 
Gerenciamento do 
escopo
Bege (6): 
Gerenciamento do 
tempo
Rosa (7): 
Gerenciamento do 
custo
Laranja (8): 
Gerenciamento da 
qualidade
Amarelo (9): 
Gerenciamento de 
recursos humanos
Roxo (10): 
Gerenciamento das 
comunicações
Azul (11): 
Gerenciamento dos 
riscos
Verde (12): 
Gerenciamento das 
aquisições
Verde escuro 
(13): 
Gerenciamento das 
partes interessadas
25GERÊNCIA DE PROJETOS
 SUMÁRIO
Importante: embora nosso foco seja nos processos de 
gerenciamento de projetos, devemos também estar atentos aos 
processos que estão relacionados a produtos.
Os processos de gerenciamento de projetos são aplicados globalmente, nos variados setores econômicos 
e indústrias. Por isso consideramos o PMBOK® um guia de boas práticas. Isso significa que existe um acordo 
de que a aplicação desses processos em um determinado projeto pode aumentar suas chances de sucesso.
Em relação à aplicação desses processos aos projetos, o gerente de projetos, em colaboração com 
a sua equipe, deve decidir quais processos serão selecionados e como serão aplicados ao projeto. Nesse 
caso, o cuidado está relacionado a não burocratizar excessivamente o projeto, e sim utilizar esses proces-
sos para melhorar o seu desenvolvimento. A seguir, estão listados os cinco grupos de processos.
• Processos de iniciação: compreende os processos executados para definir um novo projeto ou fase de 
um projeto existente. Nesta etapa, é obtida a autorização formal para iniciar o projeto! Após obtê-la, é 
preciso começar a planejá-lo. 
• Processos de planejamento: contém os processos necessários para definir o escopo do projeto, refi-
nar os objetivos e definir a linha de ação necessária para alcançar os objetivos para os quais o projeto 
foi criado. Mas como trabalhar com a questão das mudanças nesse contexto? Sempre que mudanças 
significativas ocorrerem ao longo do ciclo de vida do projeto, é necessário revisitar um ou mais pro-
cessos de planejamento e possivelmente alguns dos processos de iniciação. Esse é o planejamento por 
elaboraçãoprogressiva, já mencionado na unidade anterior.
O planejamento é a etapa mais longa do 
gerenciamento de projetos tradicional, 
fundamentado pelo PMBOK®.
• Processos de execução: envolve coordenar pessoas e recursos, geren-
ciar as expectativas das partes interessadas, integrar e executar as ati-
vidades do projeto em conformidade com o planejamento, realizado 
na etapa anterior. Os resultados que forem sendo gerados no grupo de 
processos de execução podem requerer atualizações no planejamento 
e mudanças nas linhas de base do projeto.
Importante: a linha de base é como uma 
fotografia retirada no momento da aprovação 
do que foi planejado, como se esse momento 
fosse “congelado”. Depois que isso for feito, a 
linha de base é então monitorada, verificada e 
controlada no ciclo de vida do projeto.
• Processos de monitoramento e controle: acontece ao longo de todo o 
ciclo de vida do projeto. Esses processos são realizados para acompa-
nhar, analisar e controlar o progresso e desempenho do projeto e iden-
tificar as áreas nas quais serão necessárias mudanças de planejamento.
26GERÊNCIA DE PROJETOS
 SUMÁRIO
• Processos de encerramento: têm por objetivo finalizar todas as atividades de todos os grupos 
de processos, encerrando formalmente o projeto ou fase. Esse grupo de processos também pode 
formalizar o encerramento prematuro do projeto.
Infelizmente, nem sempre os projetos obtêm êxito e isso tem vários motivos. Entre os di-
ferentes tipos de término de projeto, podemos citar absorção, esgotamento, integração e extinção.
• A absorção ocorre quando os projetos se transformam em operações continuadas. Este é um 
exemplo de término de projeto com êxito! 
• O esgotamento ocorre quando os recursos são cortados do projeto e deixam de ser fornecidos. 
Quando isso ocorre, o projeto vai enfraquecendo antes de finalizar todos os requisitos e fica 
como algo inacabado. Possíveis causas para esse tipo de encerramento são o surgimento de ou-
tros projetos, a interrupção do pedido de fornecimento pelo cliente, a redução do orçamento ou 
a extinção de um recurso importante do projeto e da própria organização.
• A integração ocorre quando os recursos são distribuídos para outros projetos ou áreas funcio-
nais. Neste caso, o projeto termina por falta de recursos.
• A extinção ocorre quando o projeto foi concluído e aceito pelas partes interessadas. Neste caso, 
as metas são alcançadas e o projeto é encerrado. Este tipo de encerramento também é positivo.
Conforme vimos anteriormente, o conjunto de processos compõe o gerenciamento de proje-
tos, e segundo o PMBOK® é formado por dez áreas de conhecimento. Vamos ver em seguida quais 
são essas áreas, seus objetivos e os processos que as compõem.
Mas, antes disso, é importante categorizarmos essas áreas de conhecimen-
to como principais, de suporte e integração. Neste primeiro momento, vamos 
nos ater às duas primeiras. 
GERENCIAMENTO DA INTEGRAÇÃO
A área de conhecimento de integração tem a função de conectar as demais. 
É como em uma empresa: temos algumas áreas que estão diretamente relacio-
nadas ao produto ou serviço que está sendo produzido e outras dão suporte para 
que essas áreas principais possam trabalhar melhor. A integração acaba ocor-
rendo de maneira intrínseca nos processos e pode ser percebida sob a forma dos 
sistemas de gestão integrados.
27GERÊNCIA DE PROJETOS
 SUMÁRIO
Inclui os processos e atividades para identificar, definir, combinar, unificar e coorde-
nar os vários processos e atividades dentro dos grupos de processos de gerenciamento de 
projetos. Os processos de gerenciamento da integração de projetos são os litados a seguir.
• Desenvolver o termo de abertura do projeto: processo de desenvolver um documento 
que formalmente autoriza a existência de um projeto e dá ao gerente a autoridade ne-
cessária para aplicar recursos organizacionais às respectivas atividades.
• Desenvolver o plano de gerenciamento do projeto: processo de definir, preparar e 
coordenar todos os planos subsidiários e integrá-los a um plano de gerenciamento de 
projeto abrangente.
• Orientar e gerenciar o trabalho do projeto: processo de liderar e realizar o trabalho 
definido no plano de gerenciamento do projeto e implementação das mudanças apro-
vadas para atingir seus objetivos.
• Monitorar e controlar o trabalho do projeto: processo de acompanhar, revisar e re-
gistrar o progresso do projeto para atender aos objetivos de desempenho definidos no 
seu plano de gerenciamento.
• Realizar o controle integrado de mudanças: processo de revisar todas as solicitações 
de mudança, aprovar e gerenciar as mudanças nas entregas, nos ativos de processos 
organizacionais, nos documentos e no plano de gerenciamento do projeto, comuni-
cando a decisão sobre eles.
• Encerrar o projeto ou fase: processo de finalização de todas as atividades de todos 
os grupos de processos de gerenciamento do projeto para encerrá-lo - ou uma de 
suas fases - formalmente.
É no gerenciamento da integração que os principais 
documentos do projeto são gerados. Eles são o Termo de 
Abertura (TA) e o Plano de Gerenciamento do Projeto.
O TA autorizará formalmente o início do projeto. Ele deve ser emitido por alguém 
externo ao projeto (um patrocinador, um escritório de projetos ou um comitê diretivo de 
portfólio) em um nível adequado para financiá-lo. É recomendado que o gerente de projetos 
participe do seu desenvolvimento. O TA fornecerá autoridade ao gerente de projetos para 
usar os recursos da organização nas atividades do projeto. Ele pode adotar o formato de um 
memorando, carta ou até mesmo ser enviado por e-mail: é um anúncio importante, mas não 
necessariamente complexo. O TA deve ser enviado a todos que possam estar associados ao 
projeto, atingindo ampla audiência.
No TA também deverá constar a descrição do objetivo do projeto e o que deve ser feito, 
com base no exemplo a seguir.
Objetivo ruim: construir uma casa (todos podem pensar em uma casa diferente).
Objetivo melhorado: construir uma casa na cidade de Porto Alegre com acabamento pa-
drão, com uma área aproximada de construção de 300 m², no prazo máximo de 24 meses, com o 
custo total estimado de R$ 800.000,00 conforme acordado com minha família.
28GERÊNCIA DE PROJETOS
 SUMÁRIO
O Plano de Gerenciamento do Projeto é o principal documento gerado pelo gru-
po de processos de planejamento. Ele contemplará todos os demais planos auxiliares: 
de mudanças, de configuração, de escopo, dos requisitos, do cronograma, dos custos, 
da qualidade, dos recursos humanos, das comunicações, dos riscos, das aquisições, das 
partes interessadas e de melhoria no processo. Ao final dos processos de planejamen-
to, será gravada a linha de base do projeto, e esse será (pelo menos deve ser) o ponto 
inicial para todas as verificações do projeto a partir de então; portanto, indicadores, 
métricas, comparativos, tudo deveria se basear nesse momento.
Com o Plano de Gerenciamento do Projeto concluído, 
o trabalho do projeto começará a ser executado.
A partir do momento em que o planejamento base citado estiver pronto, junto com 
a concretização das entregas planejadas, deverão ser definidas informações sobre o de-
sempenho do trabalho e solicitações de mudança. Isso significa definir métricas, pon-
tos de análise e medição, indicadores etc., para justamente verificar o quanto estamos 
seguindo o nosso planejamento, quanto precisou eventualmente ser modificado e ou-
tros detalhes mais. Para isso, usamos algo conhecido como Sistemas de Informação 
de Gerenciamento de Projetos (SIGP em português). Eles são utilizados para fornecer 
informações sobre o desempenho do trabalho do projeto, como situação das entregas, 
progresso do cronograma, custos incorridos e outros. Os SIGPs são softwares para agen-
damentos, sistemas de gerenciamento de configuração ou interfaces web para outros 
sistemas que tratam e facilitam o controle sobre diversos pontos dos projetos.
Doinício ao término do projeto, o monitoramento e controle do trabalho será execu-
tado. Esse processo tratará do acompanhamento, revisão e ajuste do progresso do projeto para 
atender aos objetivos de desempenho definidos no Plano de Gerenciamento do Projeto.
Durante o desenvolvimento do projeto, mudanças 
ocorrerão. O processo de controle integrado de mudanças 
garantirá que somente as mudanças aprovadas sejam 
implementadas.
Nesse processo de gestão, será feita a revisão, análise e aprovação das solicitações de 
mudança, situações que geralmente acabam por acontecer durante a execução de um projeto. 
Isso não é exatamente desejável, deveríamos partir do pressuposto de que, se fizemos um bom 
planejamento, deveríamos segui-lo do início ao fim do projeto e tudo estaria correto. No en-
tanto, é bem normal acontecerem mudanças no projeto, modificações nas situações que foram 
planejadas, ajustes de rumo, enfim... uma série de acontecimentos eventualmente acaba por 
modificar o projeto e, portanto, seu planejamento. 
O gerenciamento de configuração é o procedimento que fornecerá orientações técnicas 
e administrativas para identificar e documentar as características funcionais e físicas do pro-
duto ou componente, controlar mudanças feitas nas características, registrar e relatar cada 
mudança e o andamento de sua implementação e dar suporte à auditoria dos produtos ou com-
ponentes para verificar a conformidade com os requisitos. Esse documento ganha uma impor-
tância maior quanto mais complexo for o produto que está sendo gerado pelo projeto; sendo 
29GERÊNCIA DE PROJETOS
 SUMÁRIO
assim, precisamos ter um controle sobre as eventuais modificações que ele for sofrendo ao 
longo do andamento do projeto, para conseguirmos comparar o produto final com aquele 
que foi inicialmente previsto e, por consequência, aprovado.
Tão importante quanto realizar a correta abertura do projeto é realizar o seu encerramen-
to. Cada fase deve ser apropriadamente encerrada, garantindo que informações importantes e 
úteis não sejam perdidas. O processo de encerramento assegurará que o trabalho do projeto 
está completo e alcançou seus objetivos. Quando isso ocorrer, os produtos, serviços ou resul-
tados gerados serão transferidos para a próxima fase do projeto ou para a produção/operação. 
Também será auditado o sucesso ou fracasso do projeto, serão reunidas as lições aprendidas e 
arquivadas para uso futuro. As lições aprendidas de projetos anteriores representam um im-
portante ativo de processos organizacionais, que será utilizado em futuros projetos.
GERENCIAMENTO DO ESCOPO
O gerenciamento do escopo inclui os processos necessários para assegurar que o pro-
jeto inclui todo o trabalho necessário, e apenas o necessário, para terminá-lo com sucesso. 
Os processos de gerenciamento do escopo do projeto são os listados a seguir.
• Planejar o gerenciamento do escopo: processo de criar um plano de gerenciamento do 
escopo do projeto que documenta como ele será definido, validado e controlado.
• Coletar os requisitos: processo de determinar, documentar e gerenciar as necessidades 
e requisitos das partes interessadas a fim de atender aos objetivos do projeto.
• Definir o escopo: processo de desenvolvimento de uma descrição detalhada do projeto 
e do produto.
• Criar a estrutura analítica do projeto (EAP): processo de subdivisão das entregas e do 
trabalho do projeto em componentes menores e mais facilmente gerenciáveis.
• Validar o escopo: processo de formalização da aceitação das entregas concluídas do 
projeto.
• Controlar o escopo: processo de monitoramento do progresso do escopo do projeto e do 
escopo do produto e gerenciamento das mudanças feitas em sua linha de base.
30GERÊNCIA DE PROJETOS
 SUMÁRIO
O gerenciamento do escopo contemplará o escopo do produto e o escopo do projeto pro-
priamente dito. Vamos entender que escopo, na concepção da palavra, é um alvo ou um ponto 
que se mira; sendo assim, o projeto tem mirado atingir um produto (uma entrega, um objeti-
vo) e também que isso tudo ocorra dentro de um tempo correto, utilizando recursos corretos, 
passando pelas etapas e fases corretas e assim por diante.
Então, podemos entender que o escopo do produto se refere às características e funções que 
descrevem um produto, serviço ou resultado. O escopo do projeto é o trabalho que precisa ser reali-
zado para entregar um produto, serviço ou resultado com as características e funções especificadas.
Nesse contexto, o primeiro processo apresentado é o de coletar requisitos, que se divi-
dirão em requisitos do produto e requisitos do projeto. Os requisitos do produto podem ser 
técnicos, de segurança, de desempenho e outros, todos relacionados àquele objeto, serviço ou 
produto que se deseja entregar ao final. Os requisitos do projeto são os requisitos de negócios, 
de gerenciamento do projeto, de entrega e outros, relacionados ao gerenciamento desse pro-
cesso como um todo.
As principais técnicas para se coletar requisitos são:
• grupo nominal - basicamente, um grupo definido opinará sobre os requisitos de produto 
e projeto, usualmente fazendo um brainstorming e buscando um consenso ao seu final para 
obter as definições que serão seguidas dali em diante;
• job shadowing - observação do usuário ou grupo de usuários que utilizará o produto 
ou serviço que o processo vai gerar, verificando suas necessidades através da efetiva 
investigação (sem interferência ou questionamentos, somente observação);
• protótipos - elaboração de diferentes ideias básicas ou preliminares, criando uma 
espécie de protótipo que pode ser apreciado e ao qual serão atribuídas as caracterís-
ticas necessárias;
• técnicas de delphi - define-se um grupo de especialistas naquele modelo de produ-
to ou serviço (às vezes algo análogo), que respondem questionários anonimamente 
e enviam a uma pessoa que fará a coleta das respostas, produzindo comentários a 
respeito das respostas.
É importante entender que nenhuma dessas técnicas 
parte “do nada”, tudo isso é elaborado com base no 
termo de abertura e suas definições.
O processo de coletar os requisitos tem como principais saídas o plano de ge-
renciamento dos requisitos e a matriz de rastreabilidade dos requisitos. O plano do-
cumenta como os requisitos serão analisados, documentados e gerenciados durante o 
projeto. A matriz é uma tabela que liga os requisitos às suas origens e os rastreia duran-
te todo o ciclo de vida do projeto.
31GERÊNCIA DE PROJETOS
 SUMÁRIO
Após serem coletados os requisitos, o processo seguinte é o de definir o escopo. 
Uma das principais entradas desse processo são os ativos de processos organizacio-
nais. Neste caso, são exemplos de ativos: planos formais e informais das organizações 
envolvidas no projeto, processos e procedimentos para realizar o trabalho (normas, 
políticas, diretrizes e procedimentos), modelos de documentos (estrutura analítica do 
projeto – EAP, cronogramas, listas de riscos, contratos e outros), aprendizado e co-
nhecimento obtido de projetos anteriores (arquivos do projeto, linhas de base, base de 
conhecimento de informações históricas e lições aprendidas de projetos anteriores).
Os projetos falham pela má definição de escopo!
As informações que compõe o escopo do projeto são: 
• descrição do escopo do produto, serviço ou resultado - são as características e 
funções que descreverão esse produto, isto é, a explicação ou formalização dos 
requisitos do produto;
• critérios de aceitação do produto, serviço ou resultado - definição, preferen-
cialmente usando dados técnicos ou numéricos, do que deve ser avaliado para 
verificar se o produto entregue atende às características desejadas;
• entregas do projeto - é um produto, resultado ou capacidade para realizar um 
serviço exclusivo que deve ser produzido para terminar um processo, uma fase 
ou um projeto; 
• exclusões do escopo ou restrições do projeto - são itens que limitam um ambiente de projeto- especificações ou requisitos do produto não devem ser listados como restrições ao projeto; 
• premissas do projeto - são criadas quando há ausência de certas informações em um projeto; 
é um “chute calculado”; conforme o projeto se desenvolve, as premissas devem diminuir.
Premissa = hipótese
Restrição = limite
O próximo processo que temos é o de criar a EAP, que é a estrutura analítica do projeto. Em 
inglês, utiliza-se o termo WBS – work breakdown structures. A EAP representa a subdivisão das 
entregas e do trabalho do projeto em componentes menores e de gerenciamento mais fácil, uma 
espécie de organograma de formação do projeto.
Ela é uma decomposição hierárquica orientada às entregas do trabalho a ser executado pela 
equipe para atingir os objetivos do projeto e criar as entregas requisitadas. No contexto da EAP, o 
trabalho se refere a produtos de trabalho ou entregas que são o resultado do esforço e não o pró-
prio esforço. Representa o trabalho especificado na declaração do escopo do projeto aprovada.
A decomposição realizada nesse processo é a subdivisão das entregas do projeto em compo-
nentes menores (e mais gerenciáveis) até que tenha sido identificado todo o trabalho do projeto.
As vantagens do detalhamento adequado do escopo são estimativas mais precisas de custo, 
tempo e recursos; trata-se de uma linha de base para medir o progresso e exercer controle e atri-
buição clara de responsabilidades.
32GERÊNCIA DE PROJETOS
 SUMÁRIO
Outro conceito importante em relação a EAP é o dos pacotes de trabalho. Conforme 
os níveis vão decrescendo, o escopo, a complexidade e o custo de cada componente ficam 
menores, até que sejam obtidas entregas que são completamente capazes de serem atingi-
das. Os pacotes de trabalhos são entregas ou componentes do trabalho do projeto no ní-
vel mais baixo de cada ramo da EAP. Os pacotes de trabalho devem ser identificados como 
unidades gerenciáveis, que podem ser quebradas em atividades e marcos do cronograma, 
necessários para determinar a entrega do pacote de trabalho fora da EAP.
A EAP estrutura o trabalho em pequenos elementos, que são: gerenciáveis – assim a 
autoridade e responsabilidade específica pode ser atribuída; independentes – ou com o mí-
nimo de conexão e dependência de outros elementos; integráveis – de maneira que o todo 
possa ser vislumbrado; mensuráveis – em termos de progresso.
Importante: a EAP não chega no nível de atribuir tarefas 
aos responsáveis.
Outros conceitos importantes que você precisa saber sobre a EAP:
• Códigos de contas: são conjuntos de identificadores únicos de cada item da EAP;
• Regra das 80 horas: como uma “regra prática” de mercado, cada tarefa deve ser 
decomposta em pacotes de trabalho que não requerem mais do que 80 horas para 
serem completados;
• Dicionário da EAP: contém o conteúdo detalhado dos componentes de uma EAP. As in-
formações que compõe o dicionário da EAP são o código identificador de conta, descrição 
do trabalho, organização responsável pela execução, recursos necessários, informações 
de contrato, lista de marcos do cronograma, atividades do cronograma associadas, re-
ferências técnicas, estimativa de custos, requisitos de qualidade e critérios de aceitação.
• Linha de base do escopo: composta pela declaração do escopo, EAP e dicionário da EAP.
33GERÊNCIA DE PROJETOS
 SUMÁRIO
Saindo do planejamento, temos o processo de verificar escopo. Esse processo consiste 
na formalização da aceitação das entregas terminadas em um projeto. Inclui a revisão das 
entregas com o cliente ou patrocinador para assegurar que foram concluídas satisfatoria-
mente e obter deles sua aceitação formal.
O processo de verificação do escopo pode se confundir com o processo de controlar a 
qualidade do projeto, mas eles são diferentes! A verificação do escopo é a aceitação dos re-
sultados do trabalho, ou seja, se o trabalho foi feito completamente ou não (eficácia). Já o 
controle da qualidade analisará a conformidade dos resultados do trabalho, isto é, se além 
de completos, atingiram seus objetivos (eficiência). 
O controle do escopo será usado para gerenciar as mudanças quando elas ocorrerem. 
As mudanças não controladas são frequentemente chamadas de “scope creep”, sendo esse o 
termo usado quando ocorre o aumento de escopo no gerenciamento de projetos e se refere a 
mudanças ou crescimento contínuo e descontrolado no escopo de um projeto, em qualquer 
ponto após seu início. Isso pode ocorrer quando o escopo de um projeto não está definido, 
documentado ou controlado adequadamente; portanto, a mudança de escopo é geralmente 
a grande fonte do processo de gerenciamento de mudanças.
Na prática, esse efeito costuma ser bastante corriqueiro, principalmente na implan-
tação de sistemas, em que se começa com uma ideia e toda a questão de tempo e recursos 
é atrelada a ela. Após o planejamento, portanto durante a implementação, vão surgindo 
“novos requisitos”, novas necessidades, melhorias propostas, mudanças de rumo e um au-
mento considerável no projeto; no entanto, não se observa a questão de tempo e recursos 
destinados, culminando em um efeito de desistência, desentendimento entre as partes, de-
sapontamento, enfim... situações não muito interessantes.
GERENCIAMENTO DO TEMPO
34GERÊNCIA DE PROJETOS
 SUMÁRIO
O gerenciamento do tempo do projeto inclui os processos necessários para gerenciar 
seu término pontual. Os processos de gerenciamento do tempo do projeto são:
• planejar o gerenciamento do cronograma: processo de estabelecer as políticas, os pro-
cedimentos e a documentação para o planejamento, desenvolvimento, gerenciamento, 
execução e controle do cronograma do projeto.
• definir as atividades: processo de identificação das ações específicas a serem realizadas 
para produzir as entregas do projeto.
• sequenciar as atividades: processo de identificação e documentação dos relacionamen-
tos entre as atividades do projeto.
• estimar os recursos das atividades: processo de estimativa dos tipos e quantidades de 
material, pessoas, equipamentos ou suprimentos que serão necessários para realizar 
cada atividade;
• estimar a duração das atividades: processo de estimativa do número de períodos de traba-
lho que serão necessários para terminar atividades específicas com os recursos estimados;
• desenvolver cronograma: processo de análise de sequências das atividades, suas du-
rações, recursos necessários e restrições do cronograma, visando a criar um modelo do 
cronograma do projeto;
• controlar o cronograma: processo de monitoramento do andamento das atividades do 
projeto para atualização no seu progresso, e gerenciamento das mudanças feitas na li-
nha de base do cronograma para realizar o planejado.
OBS: Apesar de serem vários, os processos de gerenciamento do tempo do projeto ocor-
rem quase que simultaneamente durante o planejamento.
Aqui temos normalmente o maior uso de SIGP específicos - sistemas que nos 
ajudam a montar e controlar as atividades ligadas à gestão do tempo (não se 
limitando somente a isso, claro). São vários os SIGP disponíveis no mercado, 
alguns mais simples e até gratuitos, outros mais complexos e mais caros; 
sua escolha varia muito de acordo com o gosto do usuário, sendo exemplos 
desses sistemas o Open Project e o Microsoft Project. Uma dica importante 
é a prática da elaboração e uso de controles de tempo utilizando planilhas 
eletrônicas (sendo o Microsoft Excel o mais conhecido); no entanto, salvo um 
conhecimento muito avançado de uso desse recurso, elas não costumam 
proporcionar um bom controle, pois normalmente as funcionalidades 
utilizadas se limitam à simples demonstração de um cronograma. Por 
exemplo, essas planilhas costumam proporcionar um baixo nível de 
funcionalidade a esses cronogramas, tornando sua modificação (como incluir 
tarefas intermediárias, mudanças de datas, dependência de atividades etc.) 
bastante complexa, imprecisa e com altos riscos e índices de erros.35GERÊNCIA DE PROJETOS
 SUMÁRIO
Depois de criada a EAP do projeto, o trabalho de planejamento segue com a definição 
das atividades necessárias para completar um pacote de trabalho. A lista de atividades deve 
ser organizada como uma extensão ou refinamento da EAP, assegurando que está completa 
e que não inclui quaisquer atividades que não são requeridas pelo escopo do projeto. Como a 
EAP, a lista de atividades deve incluir descrições de cada atividade para garantir que o time 
do projeto vai entender o que deve ser desenvolvido.
Uma vez descritas as atividades, será realizado o seu sequenciamento. Existem quatro 
tipos de dependências lógicas, a saber: 
• término para início (TI) (mais utilizado); 
• início para início (II); 
• término para término (TT); 
• início para término (IT).
Existem alguns tipos de dependências que são obrigatórias (dependência de lógica, 
hard logic, relações físicas de dependência), exigidas contratualmente ou inerentes à na-
tureza do trabalho; e outros tipos que são arbitrárias (lógica preferida, lógica preferencial, 
lógica flexível ou soft logic), estabelecidas pela equipe do projeto, orientadas por processos 
ou procedimentos, baseadas em experiências anteriores. Ainda, as dependências podem ser 
externas quando envolvem relacionamento de atividades externas com impacto nas ativi-
dades de projetos (aprovações externas, por exemplo).
Algumas vezes é necessário que se apliquem esperas ou antecipações às atividades do 
projeto. Por exemplo, temos uma atividade de pintura de paredes sucedida por uma ativi-
dade de reboco de paredes. Não podemos iniciar a pintura logo após a conclusão do reboco, 
pois ele precisa estar completamente seco para iniciar a próxima fase; nesse caso, aplica-
mos uma espera de dois dias para que seja dado seguimento à atividade de pintura. 
A espera (atraso ou latência), representa o tempo entre as atividades em um diagrama 
e pode ocasionar um atraso em uma atividade sucessora ou acrescentar tempo para iniciar/
encerrar a próxima atividade. A antecipação ocasiona uma aceleração em uma atividade su-
cessora, portanto subtrai tempo para iniciar (e encerrar) a próxima atividade.
O diagrama de rede é um gráfico esquemático das 
atividades do cronograma e das relações lógicas entre 
elas (dependências).
O próximo processo é o de estimar os recursos das atividades. Os recursos podem ser 
materiais, pessoas, equipamentos ou suprimentos que serão empregados para realizar as 
atividades do projeto. Uma das saídas desse processo é a estrutura analítica de recursos - 
EAR. A EAR é uma lista hierárquica de recursos relacionados por tipo de função e de recursos 
que são usados para facilitar o planejamento e controle do trabalho do projeto.
Em relação às estimativas de durações das atividades, temos algumas técnicas que po-
dem ser empregadas.
36GERÊNCIA DE PROJETOS
 SUMÁRIO
• Análise de reservas: definição de reservas de tempo pontuais para contingências (reservas 
de tempo ou buffers) no cronograma geral do projeto para considerar incertezas durante sua 
realização: significa uma parte do tempo que é adicionada à atividade para levar em conta 
os riscos e incertezas. Deve haver um grande cuidado para não causar efeitos de erros orça-
mentários ou de datas em função de sempre se prever tempos com muitas folgas, tornando 
o planejamento não realista. Essas são situações que somente a experiência acaba trazendo.
• Estimativa de três pontos: considera as incertezas das estimativas e riscos dentro de 
uma faixa de variabilidade; para isso, calcula a duração esperada da atividade usando 
uma média ponderada. Por exemplo, temos três estimativas de tempo por atividade: 
pessimista (P), mais provável (M) e otimista (O), com ênfase na mais provável. Assim, a 
teoria aponta o uso da seguinte equação:
Duração Esperada=
Até essa etapa, a ideia é que, no caso do uso de um SIGP, ele calcule automaticamente a 
duração total do projeto e a data prevista para o seu término. Contudo, no processo de desen-
volver o cronograma, é realizada uma avaliação nessa sugestão do sistema, considerando rever 
a sequência das atividades, suas durações, recursos necessários e restrições do cronograma. 
Nesse sentido, o método do caminho crítico (CPM – Critical Path Method) pode ser aplicado. 
O enfoque do CPM é o cálculo da flutuação ou folga com a finalidade de determinar 
quais atividades têm menor flexibilidade no cronograma, determinado assim o caminho 
crítico. Ao gerar o cronograma, para cada atividade é utilizada a estimativa de tempo mais 
• Opinião especializada: experiência empírica que alguém possui sobre o tempo normal 
de execução de uma atividade.
• Estimativa análoga (top-down): usa a duração de um projeto anterior para estimar a 
duração de um projeto futuro, ou seja, busca-se informações de atividades análogas em 
outros projetos concluídos (obviamente, precisa-se de histórico).
• Estimativa paramétrica: utiliza uma relação estatística entre dados históricos e outras 
variáveis, sendo um método de base quantitativa que multiplica a quantidade de traba-
lho através de seu valor. Por exemplo, em um projeto anterior, uma construtora levou 
seis meses para construir uma casa de 200 m2; logo, para uma casa de 400m2, a cons-
trutora levará 12 meses para entregar o projeto.
37GERÊNCIA DE PROJETOS
 SUMÁRIO
provável para sua duração, e não é considerada qualquer limitação no quadro de recursos. 
Então, o caminho crítico será o caminho mais longo através do diagrama. Ele represen-
ta a menor quantidade de tempo em que o projeto pode ser completado.
A duração do cronograma é a do caminho crítico.
• Adicionando-se tempos ao longo do caminho crítico, aumenta-se a duração total 
esperada do projeto. Essa atividade costuma ter folga zero, ou seja, não tem folga.
• A folga (folga total ou flutuação) é a quantia de tempo que uma atividade em parti-
cular pode atrasar antes que o caminho crítico seja afetado. É o quanto uma atividade 
pode atrasar sem atrasar o projeto.
• A folga livre é o tempo além do previsto que a atividade pode utilizar, supondo-se 
que comece e termine em suas datas mais cedo. É o tempo permitido para atraso de 
uma atividade do cronograma sem atrasar qualquer uma das atividades imediata-
mente subsequentes.
Ainda podemos aplicar algumas técnicas de compressão da duração, que visam a 
reduzir o cronograma do projeto (data de entrega) sem mudar o escopo:
Ao final do planejamento, o cronograma terá a estrutura análoga à apresentada na 
figura “cronograma”.
38GERÊNCIA DE PROJETOS
 SUMÁRIO
Cronograma
Elaborado pelo autor com base em PMBOK GUIDE (2018).
39GERÊNCIA DE PROJETOS
 SUMÁRIO
Fora do planejamento, é necessário acompanhar o desempenho do crono-
grama em relação ao seu progresso e gerenciamento das mudanças feitas na linha 
de base. O controle do cronograma é um componente do processo e as principais 
análises que são realizadas em relação ao cronograma são:
• Análises de desempenho: medem, comparam e analisam o desempenho do 
cronograma com as datas reais de início e término, porcentagem do quanto a 
tarefa está completa e duração restante para o trabalho em andamento;
• Análises de variação: medições do desempenho do cronograma usadas para 
avaliar a magnitude de variação em relação à linha de base do cronograma.
GERENCIAMENTO DO CUSTO
O gerenciamento dos custos do projeto inclui os processos envolvidos em 
planejamento, estimativas, orçamentos, financiamentos, gerenciamento e con-
trole dos custos, de modo que o projeto possa ser terminado dentro do orçamento 
aprovado. Os processos de gerenciamento dos custos do projeto são:
• planejar o gerenciamento dos custos - processo de estabelecer as políticas, os 
procedimentos e a documentação necessários para o planejamento, gerencia-
mento, despesas e controle dos custos do projeto;
• estimar os custos - processo de desenvolvimento de uma estimativa dos re-
cursos monetários necessários paraexecutar as atividades do projeto;
• determinar o orçamento - processo de agregação dos custos estimados de atividades individu-
ais ou pacotes de trabalho para estabelecer uma linha de base dos custos autorizada;
• controlar os custos - processo de monitoramento do andamento do projeto, para atualização no 
seu orçamento, e gerenciamento das mudanças feitas na linha de base de custos.
As técnicas para estimar custos são bem similares às que vimos para estimar a duração das 
atividades; no entanto, vamos acrescentar outras relacionadas aos custos do projeto:
• estimativa bottom-up (melhor técnica - apenas 5% de variação) - estima-se para cada atividade 
separadamente, para depois reuni-las e agregá-las em uma estimativa de custo total do projeto;
• custo da qualidade - custo total da geração do produto ou serviço do projeto de acordo com os 
padrões da qualidade necessários;
• análise da proposta do fornecedor: coleta de informações dos fornecedores para ajudar a definir 
as estimativas de custos, as quais vêm a partir da solicitação de propostas dos fornecedores.
No processo de determinar orçamento, a linha de base do 
desempenho de custos é gerada. 
O orçamento no término (ONT) consiste no valor total para executar o projeto sincronizado 
no tempo, e é utilizado para medir o desempenho de custo do projeto. Esse orçamento é desenvol-
vido através do acúmulo dos orçamentos aprovados por período de tempo.
crisd
Realce
crisd
Realce
crisd
Realce
crisd
Realce
crisd
Realce
40GERÊNCIA DE PROJETOS
 SUMÁRIO
Ao fim do planejamento, o controle de custos começa a ser executado. 
Esse processo faz parte do controle integrado de mudanças (integração). Ele irá 
gerenciar as mudanças conforme ocorrerem, detectar as variações em relação à 
linha de base de custos e procurar as suas causas, assegurar que os gastos não 
excedam o autorizado, manter os excessos dentro de limites aceitáveis, prevenir 
que mudanças não aprovadas sejam incluídas na linha de base de custo e infor-
mar as partes interessadas apropriadas sobre as mudanças e custos associados.
O gerenciamento do valor agregado é uma metodologia utilizada para 
medir o desempenho dos prazos e custos do projeto. Ele leva em consideração 
três variáveis que são:
• Valor Planejado (VP) - custo orçado do trabalho que deveria ter sido feito 
(agendado) - qual o valor estimado do trabalho planejado para o momento? 
• Valor Agregado (VA) - custo orçado (estimado) do trabalho realmente rea-
lizado - quanto vale o trabalho realizado?
• Custo Real (CR) - custo incorrido no trabalho realizado.
Com base nessas variáveis, pode ser calculada a variação de custos (VC) e 
a variação de prazos (VPR):
• Variação de custos (VC): VC = VA – CR
• Variação de prazos (VPR): VPR = VA – VP
Se o resultado for zero – não houve variação.
Se o resultado for negativo – houve estouro do orçamento ou atraso nos 
prazos.
Se o resultado por positivo – houve economia do orçamento ou 
antecipação nos prazos.
______________________________________________________________________
• Índice de desempenho de custos (IDC): ICD = VA / CR
• Índice de desempenho de prazos (IDP): IDP = VA / VP
Se o resultado for zero – não houve variação.
Se o resultado for menor que 1 – houve estouro do orçamento ou atraso 
nos prazos.
Se o resultado for maior que 1 – houve economia do orçamento ou 
antecipação nos prazos.
41GERÊNCIA DE PROJETOS
 SUMÁRIO
O gerenciamento do valor agregado ainda conta com outros índices. Os principais são:
ÍNDICE SIGLA RESPONDE A PERGUNTA:
Orçamento no término ONT Em quanto foi orçado inicialmente o trabalho total?
Estimativa no término ENT
Quanto nós, hoje, estimamos que o projeto total vá 
custar? O novo orçamento.
Estimativa para terminar EPT Quanto ainda temos que gastar para encerrar o projeto?
Variação no término VNT
Quanto acima ou abaixo do orçamento inicial nós 
esperamos ficar?
Índice de desempenho 
para término
IDPT
Que desempenho deve ser atingido no trabalho 
restante para acabar dentro do orçamento?
Elaborado pelo autor com base em PMBOK GUIDE (2017).
Aqui temos normalmente o outro grande uso de SIGP específicos, que 
costumam ter funções e ferramentas específicas tanto para montar o 
orçamento do projeto como para alocar nele o que já foi efetivamente 
realizado, demonstrando rapidamente a totalidade ou a grande maioria dos 
índices comentados de forma muito rápida, sem precisar montar grandes 
fórmulas ou parametrizar muitas funções.
Neste caso também vale a dica de evitar o uso de planilhas eletrônicas 
pois, salvo um conhecimento muito avançado de seu uso, elas não 
costumam proporcionar um bom controle de custos, já que normalmente 
as funcionalidades utilizadas se limitam à simples demonstração de um 
orçamento, por exemplo. Ademais, essas planilhas costumam proporcionar 
um baixo nível de funcionalidade a esses orçamentos, tornando seu 
acompanhamento e rápida verificação dos índices citados uma tarefa 
bastante suscetível a erros.
GERENCIAMENTO DA QUALIDADE
O gerenciamento da qualidade do projeto inclui os processos e as atividades da 
organização executora que determinam as políticas de qualidade, os objetivos e as res-
ponsabilidades, de modo que o projeto satisfaça às necessidades para as quais foi em-
preendido. Os processos de gerenciamento da qualidade do projeto são:
• planejar o gerenciamento da qualidade - processo de identificação dos requi-
sitos e/ou padrões de qualidade do projeto e suas entregas, e de documentação 
de como o projeto demonstrará conformidade com os requisitos relevantes e/ou 
padrões de qualidade;
• realizar a garantia da qualidade - processo de auditoria dos requisitos de quali-
dade e dos resultados das medições de controle de qualidade, para garantir o uso 
dos padrões de qualidade e definições operacionais apropriados;
• controlar a qualidade - processo de monitoramento e registro dos resultados da 
execução das atividades de qualidade, para avaliar o desempenho e recomendar 
as mudanças necessárias.
Qualidade é a totalidade de características de um projeto que o tornam capaz de 
satisfazer as necessidades (declaradas ou implícitas) das partes interessadas. Para o 
PMI, dar ao cliente mais do que foi especificado (gold-plating) não é indicado, pois 
vai contra o gerenciamento das expectativas e a gestão para obtê-la.
42GERÊNCIA DE PROJETOS
 SUMÁRIO
Gerenciar com qualidade é fazer o que você disse que iria fazer.
A qualidade também trabalha com a questão da prevenção e a inspeção para tratar os erros que podem acontecer em um projeto:
Prevenção: manter os erros fora do processo.
Na prevenção, o foco da qualidade está voltado para o planejamento e ação sobre as causas dos problemas, visando a 
melhoria dos processos e possibilitando a prevenção de ocorrência de falhas.
Inspeção: manter os erros fora da mão do cliente.
Embora a inspeção (ou teste) seja parte do plano de gerenciamento da qualidade, aumentar a inspeção não é considerado 
o melhor meio de elevar a qualidade.
O processo de planejar a qualidade determinará qual vai ser a qualidade do projeto e como ela será medida. Esse pro-
cesso tem função gerencial e é feito durante o planejamento. Os custos da qualidade e da não qualidade envolvidos nesse pla-
nejamento se organizam da seguinte forma:
CUSTO DA QUALIDADE CUSTO DA NÃO QUALIDADE
Prevenção de não conformidade: planejamento, estudo, pesquisa, 
treinamento, doutrinação, controle do processo, validação do de-
sign e do processo, manutenção e calibragem.
Custo de falhas internas (detectadas internamente): retrabalho, re-
paro, material adicional, estoque, perdas (sucata).
Avaliação em relação à conformidade: teste, avaliação, inspe-
ção, auditorias de qualidade.
Custos de falhas externas (detectadas pelo cliente): reparos em 
garantia e serviço, tratamento de reclamações, custos legais, re-
calls, serviço de campo (suporte e expedição), negócios perdidos.
Elaborado pelo autor com base em PMBOK GUIDE (2013).43GERÊNCIA DE PROJETOS
 SUMÁRIO
Por fim, o processo de planejar a qualidade gerará algumas saídas. As 
principais são:
• plano de gerenciamento da qualidade - descreve como a equipe do projeto 
implementará a política de qualidade da organização executora e informa 
como será feita a melhoria contínua, estando alinhado com o sistema de 
qualidade da organização;
• métricas da qualidade: descreve um atributo do projeto ou do produto, e 
como o processo de controle da qualidade irá medi-lo.
O processo de realizar a garantia da qualidade consiste em implementar 
a qualidade, ou seja, determinar que as medidas da qualidade são apropriadas 
ao projeto. Esse processo tem uma função administrativa de auditoria. Ele é 
realizado durante a execução do projeto.
A principal ferramenta desse processo são as auditorias da qualidade. Uma 
auditoria é uma análise estruturada e independente para determinar se o projeto 
está seguindo as políticas, procedimentos e padrões de projetos da organização. Os 
objetivos são identificar todas as boas práticas e deficiências, compartilhar as boas 
práticas utilizadas em projetos similares, oferecer apoio para melhorar a imple-
mentação de processos, ajudar a equipe a aumentar a produtividade e destacar as 
contribuições de cada auditoria no repositório de lições aprendidas da organização.
O processo de realizar o controle da qualidade consiste em verificar a qualidade: efetuar uma 
medição, comparando os resultados com o plano de gerenciamento da qualidade. Esse processo tem 
uma função técnica de inspeção da qualidade do produto. Ele é realizado no monitoramento e controle.
A inspeção é o exame de um produto de trabalho para determinar 
se ele está em conformidade com os padrões documentados (ou 
validar os reparos dos defeitos). Os resultados de uma inspeção 
incluem medições. É possível inspecionar os resultados de uma 
única atividade ou o produto final de um projeto.
44GERÊNCIA DE PROJETOS
 SUMÁRIO
Os gráficos de controle ajudam a entender a capacidade do processo, isto é, se ele é capaz 
de atender às especificações dos requisitos. As variações identificadas nesses gráficos podem ser 
aleatórias (variações normais, inerentes ao processo) ou causas especiais (não usuais, saltam aos 
olhos do observador). A chamada “regra dos sete” nos esclarece que sete ocorrências consecuti-
vas acima ou abaixo da média, ascendentes ou descendentes, devem ser sempre investigadas. O 
ideal é que tenhamos o menor desvio padrão (medida de dispersão em relação ao valor médio), 
para garantir a estabilidade do processo.
RESUMO DA UNIDADE
O PMI é uma das principais associações mundiais em gerenciamento de projetos. O PMBOK 
é o guia de boas práticas para gerenciamento de projetos, desenvolvido pelo PMI. O gerenciamen-
to de projetos tradicional, de acordo com o guia, é composto por cinco grupos de processos, que 
vão desde a iniciação do projeto até o seu encerramento, passando pelo planejamento, execução, 
monitoramento e controle.
Os 47 processos que estão agrupados nesses grupos pertencem a dez áreas de conhecimento 
distintas e complementares. Um projeto inicia pela criação do TA. Após autorizado por meio do 
TA, o projeto começa a ser planejado. O planejamento é o maior grupo de processos no gerencia-
mento tradicional. No planejamento, primeiramente é criado o escopo do projeto e logo após a 
EAP. A EAP é uma das estruturas principais do planejamento, pois nela é possível observar o es-
copo do projeto decomposto em pacotes de trabalho menores e mais facilmente gerenciáveis. 
Após a criação da EAP, já é possível iniciar o desenvolvimento do cronograma 
do projeto. O cronograma geralmente é feito em um SIGP, um sistema de informação 
próprio para essa finalidade. Então, são definidas as atividades, feito o seu sequencia-
mento, estimadas as durações das atividades e os recursos necessários para completar 
o trabalho do projeto. 
Na sequência é feita a estimativa do orçamento do projeto, considerando recur-
sos de trabalho e materiais que serão utilizados. Por fim, é salva a linha de base do 
cronograma, a qual posteriormente será utilizada para acompanhar o desempenho do 
projeto por meio de análises de valor agregado.
O gerenciamento da qualidade garantirá que os produtos, serviços ou resultados 
gerados pelo projeto satisfarão as expectativas das partes interessadas. Para isso, são 
estipuladas métricas, que serão monitoradas durante a execução do projeto. 
Mudanças ocorrerão no desenvolvimento do projeto, e o processo de realizar o 
controle integrado de mudanças garantirá que somente as mudanças aprovadas sejam 
incorporadas à linha de base do projeto. Os demais processos de integração também 
estão presentes nas etapas do projeto, até o seu encerramento. Por fim, o projeto será 
formalmente encerrado e serão geradas as lições aprendidas. Essas lições compreen-
dem um importante ativo de processos organizacionais que será utilizado com vistas 
a melhorar o desempenho de projetos futuros.
45GERÊNCIA DE PROJETOS
EXERCÍCIOS SUMÁRIO
Questões para reflexão que são importantes para o entendimento 
desta unidade.
1. Para que serve o termo de abertura?
2. Quais são as diferenças entre escopo de produto e de projeto?
3. Quais são os pontos a serem observados para definição do cronograma?
4. Na gestão do custo, como são definidas as informações necessárias?
5. Você, no seu âmbito profissional ou pessoal, entende como se encai-
xam os conceitos das áreas de conhecimento principais? Tem alguma 
experiência, mesmo que não estruturada, com isso? 
46
ÁREAS DE 
CONHECIMENTO DE 
SUPORTE
Quais são as áreas de conhecimento de suporte? Como elas funcionam?
47GERÊNCIA DE PROJETOS
 SUMÁRIO
Neste momento, já devemos ter entendido algumas nuances que permeiam a 
ideia de gerenciamento de projetos. Mas, retomando-as, temos primeiramente o 
fato de que o projeto tem como objetivo a entrega de um resultado único, portanto 
não estamos falando de gerenciamento de situações rotineiras, e sim de situações 
novas a cada vez. Por mais que, talvez, o processo para chegar a elas seja relativa-
mente corriqueiro em termos de fases e etapas a serem cumpridas, os resultados 
ao seu final, seus objetivos e suas necessidades a serem atendidas são únicas.
Vimos que existem diferentes metodologias de gerenciamento de projetos. 
Uma das mais conhecidas mundialmente é a descrita pelo PMI no PMBOK. Essa 
metodologia é bastante completa e relativamente complexa, pois acaba sendo 
utilizável desde projetos simples até em situações bastante complicadas. Por de-
finição, os projetos são divididos em cinco fases e, dentro de cada uma, existem 
dez partes distintas a serem avaliadas, conhecidas como áreas de conhecimento.
Em cada uma das fases, haverá alguma etapa a ser executada em relação a 
cada uma dessas áreas de conhecimento, o que vai totalizar 47 distintos proces-
sos a serem executados. Então, deve estar claro para você que esses 47 processos 
podem ser bastante burocráticos, se assim for a necessidade do seu projeto em 
virtude da complexidade, ou relativamente simples, também em virtude da baixa 
complexidade ou nível de maturidade da organização. Alguns desses 47 processos 
acontecem em conjunto e, dependendo do projeto, não ficam tão evidentes; no 
entanto, é importante conhecer para não deixarmos nada em descoberto.
Já comentamos sobre as fases e as áreas de conhecimento principais, e agora precisamos tra-
tar das áreas de conhecimento de suporte. Essas áreas nem sempre geram uma saída tão conhecida 
e óbvia como as anteriores, mas são pontos também cruciais para o bom e correto andamento do 
projeto. Você vai notar que algumas dessas áreas geram saídas que, dependendo do nível de maturi-
dade da organização, são situações conhecidas e rapidamente adequadas ao projeto. De todo modo, 
vamos comentar cada uma delas e descrever o que se espera e se necessita que seja avaliado nelas.
Vamos, então, paraas áreas de suporte dos projetos!
48GERÊNCIA DE PROJETOS
 SUMÁRIO
GERENCIAMENTO DOS RECURSOS HUMANOS
O gerenciamento dos recursos humanos do projeto inclui os processos que organizam e 
guiam a equipe do projeto. Os processos de gerenciamento dos recursos humanos do projeto são:
• planejar o gerenciamento dos recursos humanos - processo de identificação e docu-
mentação de papéis, responsabilidades, habilidades necessárias e relações hierárquicas 
do projeto, além da criação de um plano de gerenciamento de pessoal;
• mobilizar a equipe do projeto - processo de confirmação da disponibilidade dos recur-
sos humanos e obtenção da equipe necessária para terminar as atividades do projeto;
• desenvolver a equipe do projeto - processo de melhoria de competências, da interação 
e do ambiente global da equipe para aprimorar o desempenho do projeto;
• gerenciar a equipe do projeto - processo de acompanhar o desempenho do projeto.
Desenvolver o plano de recursos humanos requer a aplicação de algumas ferramentas 
e técnicas. Podemos considerar duas categorias, que são os gráficos hierárquicos, como a 
estrutura analítica organizacional (EAO) e a estrutura analítica de recursos (EAR), e os grá-
ficos matriciais como a matriz de responsabilidades (MR). Um exemplo de MR é o gráfico 
RACI (acrônimo de responsible, acountable, consult and inform – responsável pela execução, 
responsável pela aprovação, consultado e informado).
Além disso, o plano de recursos humanos é o documento que fornecerá orientação so-
bre como os recursos humanos do projeto devem ser definidos, mobilizados, gerenciados, 
controlados e, por fim, liberados. Ele conterá a descrição dos papéis e responsabilidades das 
pessoas no projeto, seu organograma e o plano de gerenciamento de pessoal.
49GERÊNCIA DE PROJETOS
 SUMÁRIO
O plano de gerenciamento de pessoal descreverá quando e como os requisitos de re-
cursos humanos serão atendidos. Ele conterá o plano de mobilização e liberação de pessoal 
(método e ocasião), as necessidades de treinamento, política de reconhecimento e recom-
pensas, conformidade com regulamentos governamentais, políticas de RH e acordos sin-
dicais, políticas e procedimentos de segurança e calendários de recursos (pode incluir um 
histograma – gráfico de barras que ilustra o número de períodos de trabalho em que um 
recurso será necessário, utilizado para o nivelamento de recursos).
Após realizar a mobilização dos recursos, temos que nos preocupar em desenvolver a 
equipe. Isso porque, talvez, os recursos que foram designados para o projeto podem não es-
tar correspondendo aos critérios de desempenho requeridos. 
O propósito das atividades de desenvolvimento da equipe 
é o incremento do desempenho.
Para isso, é necessário que sejam aprimorados os conhecimentos e habilidades da 
equipe, seus sentimentos de confiança e consenso e também que seja criada uma cultura de 
equipe dinâmica e coesa.
A construção da equipe é o processo de influenciar um grupo de indivíduos diversos, que 
possuem suas próprias metas, necessidades e perspectivas, para que trabalhem juntos, com efi-
cácia para o bem do projeto. As atividades envolvidas podem variar de uma experiência em outro 
local com um facilitador, até uma apresentação ou uma reunião de partida (kick-off meeting).
Importante: kick-off meeting é a reunião inicial na qual 
o gerente de projetos será apresentado, apresentará 
o projeto e como ele será gerenciado para as partes 
interessadas. 
Para gerenciar a equipe do projeto, o gerente pode exercer diferentes tipos de poder 
(habilidade de influenciar outras pessoas a fazerem o que se deseja). São eles:
• formal - posição do líder na estrutura hierárquica;
• recompensa - capacidade de oferecer recompensa financeira;
• penalidade (pior forma) - medo, capacidade de punir o liderado;
• especialista (melhor forma) - baseado na experiência, habilidade e conhecimento;
• referência - baseado na posse ou acesso a informações consideradas importantes e nas 
relações com pessoas importantes ou influentes.
O gerente pode optar por diferentes tipos de tomada de decisão para resolver as ques-
tões do projeto. Fazem parte do processo decisório: 
• decisão por comando - o gerente toma as decisões; 
• decisão por consulta - o gerente solicita informações e compartilha autoridade;
50GERÊNCIA DE PROJETOS
 SUMÁRIO
• decisão por consenso - é a melhor forma, pois o gerente apresenta os problemas 
para discussão e incentiva a tomada de decisão, aumentando o compromisso de 
todos com a decisão do grupo. 
As principais fontes de conflitos em ambiente de projeto são: cronogramas, prio-
ridades do projeto e recursos humanos escassos. Outros são: opiniões técnicas diver-
gentes sobre o desempenho do projeto, problemas administrativos, custos, persona-
lidades/estilos de trabalho pessoais. Para resolução de conflitos, o gerente pode optar 
por diferentes técnicas. Primeiramente, devemos nos focar nas questões que devem ser 
resolvidas, e não nas pessoas, suas características e personalidades. Também, devemos 
considerar o presente e projetar uma situação desejável para o futuro, e não nos basear-
mos em eventos passados. São técnicas para resolução de conflitos as listadas a seguir.
• Confronto / solução de problemas: consiste em tratar o conflito como um pro-
blema que deve ser solucionado com o exame de alternativas. Requer atitude de 
troca e diálogo aberto.
• Colaboração: compreende colocar todos os envolvidos no conflito frente a frente, 
ou influenciar para que isso ocorra. Podemos incorporar diversos pontos de vista e 
opiniões de diferentes perspectivas. Esta técnica desenvolve habilidades comple-
mentares, confiança e resulta em consenso e compromisso.
• Negociação: pressupõe a existência de concessões mútuas. As duas partes preci-
sam vencer para que se obtenha o sucesso na resolução do conflito.
• Panos quentes / acomodação: consiste em tentar contornar a situação sem enfrentamento; 
busca uma solução tentando reduzir o tamanho do problema. É indicada para atingir um ob-
jetivo extremamente difícil ou para manter a harmonia entre os envolvidos.
• Imposição: consiste em forçar um ponto de vista às custas de outro. Raramente produz o 
melhor resultado. É o uso da autoridade formal diante de altos riscos e pouco tempo.
• Retirada / evitar: é recuar de uma situação de conflito efetivo ou potencial. Ceder à posição 
do outro, desistir temporariamente, se ausentar e esvaziar o conflito; pode ser utilizada 
para ganhar tempo.
Vistos todos os pontos que comentamos, o mínimo que se espera é que, durante a fase de pla-
nejamento, fiquem claros quais são os recursos humanos necessários para a correta execução do 
projeto. É claro que quando realizamos um projeto utilizando a mão de obra existente na organiza-
ção, vamos contar com as habilidades dessas pessoas, mas o interessante é pensar que cada etapa 
precisa ser realizada por alguém que precisa de certos conhecimentos, habilidades e atitudes em 
relação ao projeto; dessa forma, nada mais coerente do que gerar uma espécie de lista, na qual esta-
rão definidos os recursos humanos necessários e suas características principais. Essa listagem deve, 
independentemente da metodologia que se use para chegar nela, conter as seguintes informações:
• nome definido para a função dentro do projeto;
• conhecimentos mínimos necessários para executar essa função (formação, cursos, conheci-
mento teórico ou prático em algo);
51GERÊNCIA DE PROJETOS
 SUMÁRIO
• habilidades necessárias - o nível de experiência mínimo necessário para executar tal função;
• atitudes - o perfil da pessoa que é necessária para a função, que pode ser definido pela maneira como a pes-
soa se porta em relação à função (proativo, analítico, liderança etc.).
Temos que entender que um projeto não se faz somente de pessoas com capacidade de liderança, de plane-
jamento ou de execução; na verdade, é totalmente ao contrário: é a soma de diferentesperfis que definirá uma 
equipe forte, que consiga “dar conta” da demanda imposta pelas atividades do projeto.
GERENCIAMENTO DAS COMUNICAÇÕES
O gerenciamento das comunicações do projeto inclui os processos necessários para assegurar que suas 
informações sejam planejadas, coletadas, criadas, distribuídas, armazenadas, recuperadas, gerenciadas, con-
troladas, monitoradas e finalmente dispostas de maneira oportuna e apropriada. Os processos de gerencia-
mento das comunicações do projeto são:
• planejar o gerenciamento das comunicações - processo de desenvolver uma abordagem apropriada e um 
plano de comunicação do projeto com base nas necessidades de informação e requisitos das partes interes-
sadas e nos ativos organizacionais disponíveis;
• gerenciar as comunicações – processo de criar, coletar, distribuir, armazenar, e recuperar, e de disposição 
final das informações do projeto de acordo com o plano de gerenciamento das comunicações;
• controlar as comunicações - processo de monitorar e controlar as comunicações no decorrer de todo o ciclo 
de vida do projeto, para assegurar que as necessidades de informação das partes interessadas sejam atendidas.
52GERÊNCIA DE PROJETOS
 SUMÁRIO
A comunicação eficaz se refere à troca de conteúdo corretamente for-
matado e no momento adequado. A comunicação eficiente é só a troca da in-
formação requerida e nada mais. São dimensões da comunicação em projetos:
• interna - dentro do projeto;
• externa - com o cliente, outros projetos, mídia e público; 
• oficial - boletins informativos, relatório anual; 
• não oficial - comunicações confidenciais;
• vertical e horizontal - para cima com a alta administração, para baixo 
com subordinados e equipe, lateral com outras partes interessadas; 
• formal escrita - legal, documentos do projeto, comunicação à distância 
- extrema complexidade envolvida, não pode haver má interpretação; 
• formal oral - situações oficiais, apresentações e outras comunicações 
unidirecionais - deve haver um roteiro prévio; 
• informal escrita - documentos sem caráter legal, gerais, que precedem 
contratos; 
• informal oral - conversações, reuniões, comunicações bidirecionais 
nas quais os participantes comunicam-se entre si; 
• não verbal - inflexões da voz, linguagem corporal – 55% da comunica-
ção é não verbal.
O plano de gerenciamento das comunicações faz parte do plano de gerenciamento do projeto e 
descreve seus requisitos de comunicação, incluindo o formato em que as informações serão comuni-
cadas, o método e a tecnologia de transmissão, quem é responsável pelo fornecimento de cada tipo de 
comunicação e restrições. 
Planejar as comunicações envolve determinar quem necessita de 
quais informações, quando as necessitam, como e por quem serão 
fornecidas a eles.
A tecnologia das comunicações é utilizada para transferir informações entre as partes interessadas 
do projeto. Para definir qual tecnologia de informação será empregada, devemos levar em consideração a 
urgência, a disponibilidade da tecnologia, a equipe designada, a duração e o ambiente do projeto.
O modelo de comunicações é formado por três elementos principais:
• feedback - a confirmação significa que o receptor sinalizou o recebimento da mensagem, mas não 
necessariamente que concordou com ela; a resposta significa que o receptor decodificou, entendeu e 
está respondendo a mensagem; o emissor codifica, o receptor decodifica;
• ruído - é qualquer fator que interfere na transmissão e na compreensão da mensagem;
• filtros - são telas de personalidade e percepção; reduzem a quantidade ou qualidade a comunicação.
53GERÊNCIA DE PROJETOS
 SUMÁRIO
Em relação aos métodos de comunicação, podemos ter a comunicação in-
terativa, comunicação ativa ou comunicação passiva. A comunicação interativa é 
multidirecional. Ela é a forma mais eficiente de garantir um entendimento comum 
por todos os participantes. São exemplos de comunicação interativa reuniões, te-
lefonemas e videoconferências.
As reuniões são essenciais para desenvolver equipes, tomar decisões, resolver 
problemas do grupo e atingir o consenso. Contudo, reuniões não planejadas e mal 
conduzidas podem gerar perda de credibilidade do gerente, transmissão de mensa-
gens erradas, perda de tempo dos constituintes, desmotivação e improdutividade 
na equipe. O roteiro para uma reunião eficaz envolve definir o motivo da reunião, 
participantes, agenda, infraestrutura, horário e divulgação. Se houver um bom e 
claro roteiro para a reunião, as chances de sucesso da comunicação serão melhores.
A comunicação ativa (push) garante que as informações sejam distribuídas, 
mas não verifica se chegaram ou foram compreendidas. São exemplos de comuni-
cação ativa: cartas, memorandos, relatórios, e-mail. A comunicação passiva (pull) 
é a pior forma de comunicação. Ela é utilizada para comunicar o público em geral, 
ou quando o volume de informações a ser comunicado é muito grande. Requer que 
os destinatários acessem o conteúdo da comunicação a seu próprio critério: intra-
net, e-learning, repositórios de conhecimento.
O gerente de projetos é a chave para todas as 
comunicações do projeto.
Para se comunicar de modo eficaz, o gerente de projetos deve conhecer a personalidade e o 
estilo de comunicação das outras partes. Além disso, deve ouvir ativamente e eficazmente. Desen-
volver comunicações eficazes envolve reconhecer a importância da rede de comunicações, enco-
rajar o retorno e o consenso e ser um acelerador da comunicação, unindo as pessoas. O gerente de 
projetos também deve incentivar um clima aberto para que a equipe possa explorar novas ideias, 
evitando barreiras à comunicação (falta de canais de comunicação claros, cultura, distância, difi-
culdades com a linguagem e outros).
Sempre que possível, o gerente deve tentar alocar todos os membros da equipe em um espaço 
próximo (matriz próxima), em vez de permitir que trabalhem no projeto a partir de escritórios ou 
em seus departamentos funcionais. Isso previne a diluição do esforço, diminui distrações e foca os 
esforços da equipe.
A comunicação também envolve realizar previsões sobre o desempenho futuro do projeto 
com base no desempenho real até a data. São métodos de previsão utilizados nesse caso: métodos 
de séries temporais (valor agregado); métodos causais/econométricos (vendas de guarda-chuvas 
podem estar associadas às condições climáticas); métodos subjetivos (intuições, opiniões e esti-
mativas) e outros como simulação, previsão probabilística e por conjunto.
Os relatórios de desempenho irão organizar e resumir as informações coletas e apresentar 
os resultados das análises de comparação com a linha de base da medição do desempenho. Tam-
bém mostrarão a situação e o progresso do projeto conforme requerido pelas partes interessadas. 
Temos diferentes tipos de relatórios que podem ser utilizados para apresentar o desempenho do 
projeto. Os principais são:
54GERÊNCIA DE PROJETOS
 SUMÁRIO
• previsão - mostra o que se espera ocorrer no projeto;
• andamento - mostra a posição atual do projeto; contém o percentual completo, 
análise de desempenho, painéis de indicadores da situação de cada área (escopo, 
cronograma, custo e qualidade), situação atual dos riscos e questões, trabalho 
concluído e a ser concluído, mudanças aprovadas, resultados da análise da varia-
ção e término previsto do projeto (incluindo tempo e custo);
• progresso - mostra o que foi completado desde o último período reportado;
• lições aprendidas - identificação dos sucessos e fracassos do projeto, inclui re-
comendações para melhorar o desempenho futuro dos projetos.
Portanto, o que se espera é que, durante a fase de planejamento, deva estar claro 
o plano de comunicação, descrevendo alguns pontos básicos:
• o que deve ser comunicado;
• quando isso deve ser comunicado;
• para que público isso deve ser comunicado;
• de que forma isso deve ser comunicado.
Menosprezar essa etapa de projeto pode incorrerem diversas situações, como falhas de co-
nhecimento, atraso de atividades, cobranças em momentos inoportunos, falha na divulgação de 
algo durante a execução do projeto, enfim... o plano de comunicação não pode ser tratado como 
algo óbvio, ele deve ser claro e consistente e, de preferência, deve abranger todas as partes inte-
ressadas no projeto, caso contrário não seriam partes interessadas.
GERENCIAMENTO DOS RISCOS
O gerenciamento dos riscos do projeto inclui os processos de planejamento, identificação, 
análise, planejamento de respostas e controle de riscos de um projeto. Os processos de gerencia-
mento dos riscos do projeto são:
• planejar o gerenciamento dos riscos - processo de definição de como conduzir as atividades 
de gerenciamento dos riscos de um projeto;
• identificar os riscos - processo de determinação dos riscos que podem afetar o projeto e do-
cumentação de suas características;
• realizar a análise qualitativa dos riscos - processo de priorização de riscos para análise ou ação 
adicional através da avaliação e combinação de sua probabilidade de ocorrência e impacto;
• realizar a análise quantitativa dos riscos - é o processo de analisar numericamente o efeito 
dos riscos identificados nos objetivos gerais do projeto;
55GERÊNCIA DE PROJETOS
 SUMÁRIO
• planejar as respostas aos riscos - é o processo de desenvolvimento de opções e ações para aumen-
tar as oportunidades e reduzir as ameaças aos objetivos do projeto;
• controlar os riscos - é o processo de implementação de planos de respostas aos riscos, acom-
panhamento dos riscos identificados, monitoramento dos riscos residuais, identificação de 
novos riscos e avaliação da eficácia do processo de riscos durante todo o projeto.
O plano de gerenciamento de riscos descreve como o tratamento dos riscos 
vai ser estruturado e executado no projeto. Ele inclui a definição de uma metodo-
logia, papéis e responsabilidades, orçamento, frequência, tolerâncias, formato, 
acompanhamento e categorias para eles. No planejamento também serão defini-
das escalas que posteriormente serão utilizadas na análise qualitativa de riscos:
• escalas e pesos da probabilidade de riscos - muito alta, alta etc.;
• escalas e pesos do impacto de riscos - muito elevado, elevado etc.
A representação hierárquica dos riscos do projeto é a EAR – estrutura ana-
lítica dos riscos. Na EAR, os riscos do projeto vão estar ordenados por categoria 
e subcategoria. Ela também identificará as áreas e causas de riscos potenciais.
Determinar riscos é um processo iterativo, que ocorre durante todo o ci-
clo de vida do projeto. Ao descrever um risco, é importante falar da causa (fato 
ou condição que pode originá-lo), o evento de risco (cada ocorrência discreta do 
risco, que pode afetar o projeto para o bem ou para o mal) e o efeito (sua con-
sequência). Um exemplo de risco escrito da forma correta é: causa – ocorrência 
de chuvas além do que foi previsto inicialmente; risco – trabalho na obra inter-
rompido; efeito – atraso da obra.
Os riscos de um projeto são eventos incertos.
56GERÊNCIA DE PROJETOS
 SUMÁRIO
Se os riscos acontecerem, podem ter efeitos positivos ou negativos nos 
objetivos do projeto. Riscos com mais recompensas percebidas para a orga-
nização do que consequências podem ser aceitos. Os riscos desconhecidos 
podem representar uma ameaça ou uma oportunidade, e o gerente do projeto 
deve manter reservas para contingência, para lidar com eles.
Cerca de 10% dos riscos são imprevisíveis.
A análise qualitativa de riscos tem como objetivo gerar uma lista prio-
rizada de riscos, utilizando a matriz de probabilidade e impacto. A proba-
bilidade do risco é a chance de o evento de risco ocorrer (geralmente estima-
da). O impacto do risco é o efeito sobre os objetivos do projeto, se o evento 
de risco ocorrer. É uma estimativa do que a ocorrência do risco vai produzir 
(efeito / consequências).
Os resultados desse processo serão: identificação de riscos de alta re-
levância ou prioridade; riscos de média relevância ou prioridade; riscos não 
críticos ou não prioritários (serão revisados durante a monitoração e contro-
le); riscos urgentes – riscos que requerem uma resposta urgente.
A análise quantitativa dos riscos consiste em analisar numericamente 
o efeito do risco. A quantificação é menos subjetiva que a análise qualitativa e 
contém uma melhor aproximação das probabilidades reais e consequências. 
57GERÊNCIA DE PROJETOS
 SUMÁRIO
Por fim, temos o planejamento das respostas aos riscos. As respostas têm como objetivo 
aumentar as oportunidades e reduzir as ameaças. O esforço para responder a um risco deve ser 
apropriado à severidade do risco. Não se deve gastar mais dinheiro para prevenir do que o impac-
to da ocorrência do risco.
Podemos adotar respostas de prevenção ou contingência para os riscos. A prevenção é uma 
ação que ocorre antes do risco e a contingência é uma ação que ocorre depois do risco. Os planos 
de contingência são projetados para serem usados somente se certos eventos de risco ocorrerem, 
ou se houver um alerta suficiente para acionar sua execução.
Importante: alertas são gatilhos, indicadores, sintomas, sinais 
de advertência ou indicações de que um risco está prestes a 
acontecer.
As reservas de contingência são calculadas com base na análise quantitativa dos limites de 
risco do projeto e da organização. Elas visam a reduzir o impacto no custo e prazo para determinados 
riscos do projeto. A reserva gerencial pode ser adicionada visando a cobrir os riscos desconhecidos.
Outras saídas desse processo (quando necessárias) são:
• planos alternativos (fallback) - para serem usados como uma resposta a um risco que ocorreu e 
cuja resposta principal foi inadequada - um plano B é desenvolvido se o risco tem alto impacto;
• riscos residuais - espera-se que permaneçam após a adoção das respostas planejadas;
• riscos secundários - surgem como um resultado direto da implementação de uma 
resposta a riscos;
• decisões contratuais relacionadas a riscos - contrato de seguro ou serviço, é en-
trada para o processo de planejar as aquisições.
São estratégias para respostas aos riscos negativos:
• eliminar (remover totalmente) - usado quando o risco é simplesmente inaceitá-
vel, apresenta alta probabilidade de acontecer ou apresenta impacto severo;
• transferir - transferir o risco para uma terceira parte, em geral mediante paga-
mento de prêmio – comprar seguro, garantia, outsourcing; transferir ou reduzir – 
segurar, subcontratar; o risco não é eliminado; alta conexão entre o risco e subcon-
tratação; é necessária uma análise de riscos completa antes de assinar contratos;
• mitigar - adotar ações antecipadas para reduzir a probabilidade de ocorrência e/
ou impacto para dentro de limites aceitáveis.
São estratégias para respostas aos riscos positivos:
• explorar - garantir que a oportunidade aconteça;
• compartilhar - atribuir a propriedade a terceiros que possam capturar melhor a 
oportunidade em benefício do projeto;
58GERÊNCIA DE PROJETOS
 SUMÁRIO
• melhorar - modificar o tamanho de uma oportunidade através do aumento da 
probabilidade e impacto maximizando seus principais acionadores.
Uma estratégia comum para responder aos riscos, tanto negativos quanto po-
sitivos, é a aceitação. Aceitar as consequências é recomendado para riscos com baixa 
probabilidade e efeito potencial.
O acompanhamento dos riscos e a aplicação de 
respostas ocorrem durante todo o projeto.
As atividades que são executadas nesse processo são: reavaliação dos riscos; 
riscos novos, modificados e desatualizados; monitoração dos riscos residuais; audi-
torias de políticas e procedimentos de gerenciamento dos riscos; análises de variação, 
tendências e desempenho técnico; análise das reservas, visando a determinar se de-
vem ser modificadas; execução dos planos de contingência; avaliação das respostas.
Sendo assim, existem diversas maneiras e técnicas de realizar a gestãode ris-
cos; no entanto, o mínimo que se espera é que algumas situações estejam bem claras:
• a declaração ou descrição do risco;
• uma avaliação do nível desse risco para este projeto;
• uma noção de qual a probabilidade desse risco ocorrer;
• uma definição clara do que deve ser feito para evitar esse risco; ou,
• no caso de não poder evitar, o que deve ser feito caso o risco efetivamente aconteça.
Essas definições é que formarão a EAR, que deve ser formalmente documentada e faz parte 
do nosso projeto; independentemente da metodologia ou técnica utilizada, essas são as informa-
ções mínimas que devem existir nessa avaliação.
GERENCIAMENTO DAS AQUISIÇÕES
O gerenciamento das aquisições do projeto inclui os processos necessários para comprar 
ou adquirir produtos, serviços ou resultados à equipe do projeto. Os processos de gerencia-
mento das aquisições são:
• planejar o gerenciamento das aquisições - processo de documentação das decisões de com-
pras do projeto, especificando a abordagem e identificando fornecedores em potencial;
• conduzir as aquisições - processo de obtenção de respostas de fornecedores, seleção de um 
fornecedor e adjudicação de um contrato;
• controlar as aquisições - processo de gerenciamento das relações de aquisições, monitora-
mento do desempenho do contrato e realização de mudanças e correções nos contratos con-
forme necessário;
• encerrar as aquisições - processo de finalizar todas as aquisições do projeto.
59GERÊNCIA DE PROJETOS
 SUMÁRIO
No planejamento das aquisições, ocorre a análise 
de fazer ou comprar e a preparação da requisição 
de compras.
O resultado desse processo é o escopo do que será adquirido, o tipo de contrato que será 
firmado e os critérios para realizar as aquisições. Alguns conceitos de base devem ser entendi-
dos ao realizar o planejamento das aquisições. 
• Restrições: são as datas de entrega requeridas, ou a qualificação dos recursos para o projeto.
• Requisitos: são implicações contratuais e legais (saúde, proteção, segurança, desempenho).
• Fatores ambientais: são condições de mercado, fornecedores, termos e condições usuais.
• Acordos de cooperação: são contratos legais entre duas ou mais entidades para formar uma 
parceria ou joint venture. São pré-definidos: papéis, escopo, requisitos. Quando a oportunida-
de de negócio termina, o acordo de cooperação também termina.
• Ativos de processos organizacionais havendo suporte às aquisições (utiliza o departamento 
de aquisições da empresa para dar suporte ao projeto): proporciona ganho de escala e maior 
economia; não havendo suporte às aquisições: torna o processo de aquisições mais rápido, 
mais flexível e adaptado às necessidades do projeto.
• Análise de fazer ou comprar: determina se um trabalho específico pode ser melhor realizado 
pela equipe do projeto ou se deve ser comprado de fontes externas. Uma das principais razões 
para comprar é evitar, mitigar ou transferir riscos para um fornecedor.
• O que é necessário para haver um contrato: uma oferta, uma aceitação, o acordo voluntário, 
objeto/consideração/causa, capacidade legal, propósito legal, boa-fé.
60GERÊNCIA DE PROJETOS
 SUMÁRIO
• Contrato: é um acordo legal que obriga o fornecedor a fornecer os produtos, serviços ou 
resultados especificados e obriga o comprador a remunerar o fornecedor. Pode ser um 
documento complexo ou um pedido de compra.
• Termos e condições: são cláusulas usuais em contrato, e podem inclusive prever rescisões.
Os tipos de contrato que podem ser firmados em um 
projeto são: preço fixo (PF), custos reembolsáveis (CR) e 
tempo e material (T&M). 
Os contratos de PF geram um menor risco para o comprador, pois independentemen-
te do que ocorrer no andamento do projeto, ele saberá quanto vai gastar no final. Portanto, 
é pior para o fornecedor, que assume todo o risco de algo dar errado no desenvolvimento 
do projeto. Geralmente, nesse tipo de contrato, o comprador sabe exatamente o que quer e 
define o escopo do que será entregue.
Os contratos de CR geram um maior risco para o comprador, pois o preço do projeto 
pode variar em relação aos recursos empregados nele. Esse tipo de contrato ocorre, geral-
mente, quando se sabe a necessidade, mas não como fazer. É o fornecedor que descreve o 
escopo detalhado do trabalho. 
Os contratos de T&M são firmados para projetos de curta duração. São usados quan-
do não é possível elaborar rapidamente uma declaração de trabalho precisa, em geral para 
períodos curtos e valores pequenos. São exemplos os trabalhos de emergência e o aumento 
temporário da equipe do projeto.
Para que haja um compartilhamento de riscos entre o comprador e o fornecedor, 
existem algumas subcategorias em relação a esses tipos de contratos:
61GERÊNCIA DE PROJETOS
 SUMÁRIO
TIPO DE CONTRATO SUBCATEGORIAS DESCRIÇÃO
Preço fixo (PF)
Garantido (PFG)
Este é o tipo de contrato mais usado; o comprador deve 
especificar precisamente o produto ou os serviços a serem 
adquiridos. O risco do fornecedor é maior, pois os custos 
podem estourar caso o escopo não seja bem definido.
Com ajuste econômi-
co do preço (PFAEP)
O PFAEP usa um índice financeiro confiável para ajustar 
com precisão o preço final.
Com remuneração 
de incentivo (PFRI)
O PFRI prevê um desvio em relação ao desempenho, com 
incentivos financeiros vinculados ao cumprimento das 
metas estabelecidas com teto de preços definido.
Custos reembolsáveis 
(CR)
Custo mais remune-
ração fixa (CMRF)
Projetos de P&D: o risco fica com o comprador, pois o for-
necedor não tem incentivo para economizar.
Custo mais 
remuneração de 
incentivo (CMRI)
Contratos de longos períodos e grande necessidade de 
equipamentos e testes, como navios e implantação de 
softwares de gestão integrada – ERP. Se os custos finais 
forem menores ou maiores do que os custos originais es-
timados, tanto o comprador como o fornecedor comparti-
lham os custos das diferenças com base em uma fórmula 
de compartilhamento de custos pré-negociada.
Custo mais 
remuneração 
concedida (CMRC)
A remuneração por mérito nos contratos funciona como 
a gorjeta para o garçom. O fornecedor é reembolsado por 
todos os custos legítimos, mas a maior parte da remune-
ração só é recebida se forem cumpridos determinados cri-
térios de desempenho amplos e subjetivos.
Elaborado pelo autor com base em PMBOK GUIDE (2017).
Os documentos de aquisição são usados para solicitar propostas dos 
fornecedores em potencial. Em geral, esses documentos contêm: declara-
ção de trabalho da aquisição (cada item a ser adquirido), descrição da for-
ma desejada de resposta, tipo de contrato, cláusulas contratuais e critérios 
de avaliação das propostas. São documentos de aquisição:
• solicitação de informações - o comprador solicita a um possível for-
necedor informações de produto, serviço ou capacidade do fornecedor;
• solicitação de cotação - usada para solicitar cotações de preços de 
possíveis fornecedores;
• solicitação de proposta - documentos preparados pelo fornecedor 
que descrevem a vontade e a habilidade para fornecer o produto requi-
sitado; devem apresentar uma oferta completa e inteira, e não podem 
mais ser modificada oralmente até que as negociações do contrato 
iniciem; lida com uma abordagem detalhada, adaptada especifica-
mente a uma solução;
• convite para licitação - equivale à solicitação de proposta, porém é 
tipicamente utilizado em contratações governamentais.
Na condução das aquisições, ocorre a recepção e 
avaliação de propostas de possíveis fornecedores 
e aplicação de critérios para fazer a seleção.
62GERÊNCIA DE PROJETOS
 SUMÁRIO
O resultado desse processo são os fornecedores selecionados e a adjudicação do 
contrato. Inicialmente, é realizada uma pré-seleção de fornecedores baseada em suas 
qualificações, experiência anterior, desempenho anterior, propostas preliminares, entre 
outros. Isso gerará uma lista dos fornecedores qualificados para passar à próxima etapa.As propostas compõem o conjunto de informações básico que será usado para se-
lecionar licitantes. As técnicas que podem ser empregadas neste caso são: reuniões com 
licitantes (ocorre antes da apresentação da licitação ou proposta; torna claro o objeto da 
aquisição; questões e respostas escritas tornam-se parte dos documentos da aquisição); 
publicidade (aumenta o número de licitantes; pode ser um requisito governamental) e 
pesquisa na internet.
Para a avaliação de propostas, são utilizadas técnicas de avaliação, como siste-
mas de ponderação e negociação das aquisições. Nos sistemas de ponderação, um único 
fornecedor é selecionado e se estabelece uma sequência de negociação, classificando as 
propostas por pontuações de avaliação ponderada. A negociação das aquisições esclare-
ce a estrutura, os requisitos e outros termos das compras de modo que seja possível obter 
um acordo mútuo antes de assinar o contrato. São elementos para negociação: respon-
sabilidade, autoridade, legislação, abordagens, direitos de propriedade, financiamento 
do contrato, pagamentos e preços.
Na administração das aquisições, ocorre o 
relacionamento, monitoração e mudanças.
O resultado desse processo é o trabalho feito e documentado. Faz parte desse processo 
realizar inspeções e autorias para verificar a conformidade nos processos de trabalho ou nas 
entregas do fornecedor. Também é avaliado o desempenho do fornecedor e a qualidade do 
projeto em comparação com o contrato. Reinvindicações como mudanças contestadas, dis-
putas ou recursos administrativos são administrados nesse processo. Ocorre o gerenciamen-
to dos registros e documentação do contrato e da aquisição. Por fim, à medida que os pro-
dutos são entregues, são efetuados os pagamentos e atualizados os documentos do projeto 
com as ações adotadas e as decisões tomadas.
No encerramento das aquisições, ocorre a auditoria final do 
projeto.
O resultado desse processo é o aceite final. Ele envolve verificar se todo o trabalho e as 
entregas são aceitáveis. Esse processo servirá de apoio ao processo de encerramento do pro-
jeto ou da fase. As auditorias de aquisições são avaliações estruturadas do processo de aqui-
sição, visando a identificar êxitos e fracassos na preparação ou administração das aquisições. 
A atualização nos ativos de processos organizacionais também é fundamental e envolve: ar-
quivos de aquisição, contrato, documento de lições aprendidas. Também podem ser realiza-
das auditorias nos fornecedores para verificar a conformidade nos processos do fornecedor 
e auditorias de aquisições no encerramento para identificar sucessos ou falhas.
Em termos práticos, temos neste caso uma junção de situações, pois precisamos ter claro, 
para cada material, a mão-de-obra, serviço ou o que quer que seja realizado por pessoal exter-
no ao projeto, e o que deve ser realizado. Com isso definido, é bem plausível que seja estipulado 
63GERÊNCIA DE PROJETOS
 SUMÁRIO
uma espécie de contrato entre as partes, havendo uma formalização. Isso pode se materializar 
de forma bastante simples, como um orçamento e, posteriormente, a aquisição do material/
mão-de-obra/serviço de acordo com ele, ou a efetiva descrição de um contrato mais formal. 
Um ponto a ser ressaltado nesse momento é que temos que ter em mente que, depen-
dendo do projeto, de sua extensão ou complexidade, os orçamentos ou algumas definições a 
respeito de material/mão-de-obra/serviço externos serão realizados em um momento e por 
um grupo de pessoas e que, fatalmente, serão efetivados em um outro momento e talvez por 
um outro grupo de pessoas. Portanto, é de praxe que haja, durante a fase de planejamento, 
pelo menos um registro ou uma formalização das características principais desse material/
mão-de-obra/serviço externo, para que não haja dúvida na hora de executar; ou ainda, que 
haja um local no qual todos esses contratos ou orçamentos sejam claramente agrupados.
GERENCIAMENTO DAS PARTES INTERESSADAS
O gerenciamento das partes interessadas do projeto inclui os processos exigidos para 
identificar todas as pessoas, grupos ou organizações que podem impactar ou serem impac-
tados pelo projeto. Os processos de gerenciamento das partes interessadas são:
• identificar as partes interessadas - processo de identificar pessoas, grupos ou orga-
nizações que podem ter impacto ou ser impactados por uma decisão, atividade ou re-
sultado do projeto, e analisar e documentar informações relevantes relativas aos seus 
interesses, nível de engajamento, interdependências, influência e seu impacto poten-
cial no sucesso do projeto;
• planejar o gerenciamento das partes interessadas - processo de desenvolver estra-
tégias apropriadas de gerenciamento para envolver as partes interessadas de maneira 
eficaz no decorrer de todo o ciclo de vida do projeto, com base na análise das suas ne-
cessidades, interesses e impacto potencial no êxito do projeto;
• gerenciar o engajamento das partes interessadas - processo de se comunicar e traba-
lhar com as partes interessadas para atender às suas necessidades/expectativas, abor-
dar as questões à medida que elas ocorrem e promover o engajamento apropriado das 
partes interessadas, no ciclo de vida do projeto;
• controlar o engajamento das partes interessadas - processo de monitorar os relacio-
namentos das partes interessadas no projeto em geral e ajustar as estratégias e planos 
para o seu engajamento.
64GERÊNCIA DE PROJETOS
 SUMÁRIO
Todos os projetos têm partes interessadas que são afetadas ou podem afetar o projeto de uma maneira 
positiva ou negativa. A habilidade do gerente de projetos de identificar e gerenciar essas partes interessadas de 
maneira apropriada pode fazer a diferença entre o êxito e o fracasso.
As partes interessadas podem englobar pessoas e organizações, como clientes, patrocinadores, a organi-
zação executora e o público que estão ativamente envolvidos no projeto, ou cujos interesses podem ser positiva 
ou negativamente afetados pela execução ou pela conclusão do projeto. Elas também podem exercer influência 
sobre o projeto e suas saídas. As partes interessadas podem estar em diversos níveis da organização e ter dife-
rentes níveis de autoridade, ou estar fora da organização executora do projeto.
Como o tempo do gerente de projetos é limitado e precisa ser usado com a maior eficiência possível, es-
sas partes interessadas devem ser classificadas de acordo com o seu interesse, influência e engajamento no 
projeto, levando em consideração o fato de que o efeito ou influência de uma parte interessada pode não ocor-
rer ou tornar-se evidente até os estágios finais do projeto ou fase. Isso permite que o gerente de projetos se 
concentre nos relacionamentos necessários para garantir o sucesso do projeto.
Há muitos modelos classificatórios usados na análise das partes interessadas.
• Grau de poder/interesse: agrupa as partes interessadas com base no seu nível de autoridade (poder) e seu 
nível de preocupação (interesse) em relação aos resultados do projeto.
• Grau de poder/influência: agrupa as partes interessadas com base no seu nível de autoridade (poder) e no 
seu engajamento ativo (influência) no projeto.
• Grau de influência/impacto: agrupa as partes interessadas com base no seu engajamento ativo (influên-
cia) no projeto e sua habilidade de efetuar mudanças no planejamento ou na execução do projeto (impacto).
• Modelo de relevância: descreve os tipos de partes interessadas 
com base no seu poder (capacidade de impor sua vontade) na ur-
gência (necessidade de atenção imediata) e na legitimidade (se 
seu envolvimento é apropriado).
65GERÊNCIA DE PROJETOS
 SUMÁRIO
O gerenciamento das partes interessadas envolve a criação e manutenção de relacio-
namentos entre a equipe do projeto e as partes interessadas, com o objetivo de satisfazer 
suas respectivas necessidades e requisitos dentro dos limites do projeto.
O nível de engajamento atual de todas as partes interessadasdeve ser comparado com 
os níveis de envolvimento planejados requeridos para a conclusão bem-sucedida do projeto. 
O engajamento das partes interessadas durante todo o 
ciclo de vida do projeto é essencial para o seu êxito.
Esse nível de engajamento classifica as partes interessadas do projeto como:
• desinformado - sem conhecimento do projeto e impactos potenciais;
• resistente - ciente do projeto e dos impactos potenciais e resistente à mudança;
• neutro - ciente do projeto e mesmo assim não dá apoio ou resiste;
• dá apoio - ciente do projeto e dos impactos potenciais e dá apoio à mudança;
• lidera - ciente do projeto e dos impactos potenciais e ativamente engajado em garantir 
o êxito do projeto.
Gerenciar o engajamento das partes interessadas envolve as seguintes atividades: 
• engajar as partes interessadas nas etapas apropriadas do projeto para obter ou confir-
mar seu compromisso;
• gerenciar as expectativas das partes interessadas;
• abordar as preocupações potenciais que ainda não se tornaram problemas e antecipar 
problemas futuros que podem ser colocados pelas partes interessadas;
• esclarecer e solucionar as questões que foram identificadas.
As atividades de engajamento das partes interessadas estão incluídas no plano de ge-
renciamento das partes interessadas e são executadas durante o ciclo de vida do projeto. O 
nível de engajamento das partes interessadas deve ser continuamente controlado.
Na prática, isso costuma acontecer com um levantamento de todas as partes interessa-
das que, posteriormente, serão verificadas quanto às suas necessidades em relação ao pro-
jeto, a fim de que elas estejam coerentemente atendidas por todas as outras fases, visto que 
esse projeto é um grande equilíbrio entre demandas. Assim, o mínimo que se espera é que 
se saiba quais são essas demandas e de quem vêm. Para isso, pode-se criar, inicialmente, 
uma lista de partes interessadas e suas necessidades, o que ajudará muito, principalmente 
na declaração do escopo e na definição do plano de comunicações.
66GERÊNCIA DE PROJETOS
 SUMÁRIO
RESUMO DA UNIDADE
O gerenciamento dos recursos humanos, das comunicações e das partes 
interessadas também precisa ser planejado, para que durante a execução o pro-
jeto possa fluir de uma maneira melhor.
O gerenciamento de riscos tem sido objeto de bastante foco nos últimos anos 
e, portanto, merece uma atenção especial. Ele irá compreender como identificar 
os riscos, priorizá-los considerando a probabilidade e impacto de ocorrência, 
quantificá-los monetariamente em relação aos objetivos do projeto e desenvol-
ver respostas para eles. As aquisições também serão tratadas e, nesse momento, 
será feita a análise “fazer ou comprar”, relacionada às entregas requeridas pelo 
projeto. Também serão selecionados fornecedores, solicitadas propostas de for-
necimento e elaborados contratos. Todos os planos auxiliares gerados em cada 
processo de planejamento irão compor o plano de gerenciamento do projeto.
Finalizada a etapa de planejamento, outros processos serão conduzidos para 
executar o projeto. O andamento do projeto também será monitorado e contro-
lado durante todo o ciclo de vida, para que tudo saia de acordo com o planejado.
Um bom projeto é aquele no qual os 47 processos que compreendem suas 5 
fases e as 10 áreas de conhecimento estão todos corretamente definidos e acom-
panhados, o que torna maior sua chance de sucesso.
67GERÊNCIA DE PROJETOS
EXERCÍCIOS SUMÁRIO
Questões para reflexão que são importantes para o entendimento 
desta unidade.
1. O que deve ser gerado no planejamento da gestão de recursos humanos?
2. Qual a importância de um plano de comunicações?
3. O que deve ser observado quando se executa uma estimativa de riscos?
4. Na gestão de aquisições, como são definidas as informações necessárias?
5. Você, no seu âmbito profissional ou pessoal, entende como se encai-
xam os conceitos das áreas de conhecimento de suporte? Tem alguma 
experiência, mesmo que não estruturada, com isso? 
68
MÉTODOS ÁGEIS DE 
GERENCIAMENTO DE 
PROJETOS
Você já ouviu falar em métodos ágeis, onde são aplicados e que modelos 
temos?
69GERÊNCIA DE PROJETOS
 SUMÁRIO
De acordo com The Standish Group, no relatório “The CHAOS Manifesto” de 2015, ape-
nas 29% dos projetos podem ser caracterizados como bem-sucedidos (no prazo, no orçamen-
to e com um resultado satisfatório). Para trabalhar com a atual complexidade, é necessária a 
utilização de soluções adaptativas, que deem espaço para práticas emergentes – aquelas que 
surgem especificamente para resolver um problema. Em função disso, a partir da década de 
1990, começaram a ser aplicados métodos ágeis para o gerenciamento de projetos. O mani-
festo ágil representa a ideologia sobre a qual foram desenvolvidos diferentes métodos. Dois 
dos mais difundidos mundialmente são o Scrum e o Project Model Canvas. Analisaremos com 
mais detalhes o funcionamento desses métodos e sua aplicação aos projetos.
MANIFESTO ÁGIL
Metodologias ágeis foram primeiramente aplicadas à Tecnologia da Informação 
(TI), tendo nesse segmento sua origem. Nos últimos 30 anos, foram inúmeros os benefícios 
atingidos por essa indústria, com a aplicação da agilidade: aumento das taxas de sucesso 
no desenvolvimento de softwares, melhoria da qualidade e velocidade de chegada ao mer-
cado, intensificação da motivação e da produtividade das equipes de TI.
A formação da “aliança ágil” ocorreu em fevereiro de 2001, nas montanhas de Wa-
satch, Utah – EUA. Na ocasião, 17 pessoas se reuniram para se divertir e encontrar um pon-
to de vista comum que estabelecesse os fundamentos do desenvolvimento ágil de software. 
Desse encontro emergiu um manifesto simbólico para o desenvolvimento ágil. 
O manifesto representa um marco na história da 
metodologia ágil. 
O propósito do manifesto está na descoberta de melhores maneiras de desenvolver 
softwares, no seu próprio desenvolvimento e em contribuir para que outros também possam 
fazê-lo. O manifesto ágil segue os seguintes valores: 
• indivíduos e intenções mais do que processos e ferramentas; 
• produto funcionando mais do que documentação abrangente; 
• colaboração mais do que negociação de contratos; 
• responder a mudanças mais do que seguir um plano. 
Seus idealizadores reconhecem o valor de processos, documentação, contratos e pla-
nejamento, porém atribuem maior valor aos indivíduos, produto, colaboração e mudan-
ças. Nesse sentido, a prototipagem rápida, os testes de mercado frequentes e a colaboração 
constante faz que com que as equipes mantenham o foco naquilo que o cliente realmente 
valoriza. Essa visão tem como premissa o fato de que as especificações devem evoluir, e que 
a velocidade de lançamento e custos é fundamental.
Com base no manifesto ágil, também foram criados 12 princípios, que ainda hoje ser-
vem como parâmetro para testar novos métodos ágeis e “agilistas”. São eles:
70GERÊNCIA DE PROJETOS
 SUMÁRIO
1. nossa maior prioridade é satisfazer o cliente através da entrega contínua e adiantada de 
software com valor agregado;
2. mudanças nos requisitos são bem-vindas, mesmo tardiamente, no desenvolvimento. 
Processos ágeis tiram vantagem das mudanças visando à vantagem competitiva para o 
cliente;
3. entregar frequentemente software funcionando, de poucas semanas a poucos meses, 
com preferência pela menor escala de tempo;
4. pessoas de negócio e desenvolvedores devem trabalhar diariamente em conjunto por 
todo o projeto;
5. construa projetos em torno de indivíduos motivados; dê a eles o ambiente e o suporte 
necessário e confie neles para fazer o trabalho;
6. o método mais eficiente e eficaz de transmitir informações para e entre uma equipe de 
desenvolvimento é através de conversa face a face;
7. software funcionando é a medida primária de progresso;
8. os processos ágeis promovem desenvolvimento sustentável; os patrocinadores, desen-
volvedores e usuários devem ser capazes de manter um ritmoconstante indefinidamente;
9. contínua atenção à excelência técnica e bom design aumenta a agilidade;
10. simplicidade – a arte de maximizar a quantidade de trabalho não realizado é essencial;
11. as melhores arquiteturas, requisitos e designs emergem de equipes auto-organizáveis;
12. em intervalos regulares, a equipe reflete sobre como se tornar mais eficaz, refina e ajus-
ta seu comportamento para isso.
Um método, para ser caracterizado como ágil, também deve apresentar algumas ca-
racterísticas, que são: adaptabilidade, incrementabilidade, iteratividade, colaboratividade, 
cooperação, orientação a pessoas, parcimônia e restrição de prazo. 
Diferentes metodologias e técnicas podem ser utilizadas como manifestações da agilida-
de. Elas têm em comum valores e características ágeis, mas possuem alguns traços distintos.
O SCRUM
O Scrum teve dois fundadores, Jeff Sutherland e Ken Schwaber, ambos da indústria de 
software. Tal qual no esporte rugby, o Scrum é uma forma de reiniciar o jogo, seja após um 
incidente, seja depois que a bola sai de jogo. A ideia é manter o jogo rolando e o desenvolvi-
mento de software também!
71GERÊNCIA DE PROJETOS
 SUMÁRIO
O Scrum se apresenta como um mecanismo de redução de riscos, uma vez 
que todos os envolvidos são responsáveis pelo seu planejamento e execução. Tam-
bém proporciona um ciclo de vida mais enxuto para o desenvolvimento do projeto. 
Ele tem um processo de gestão mais adaptativo, oposto de métodos que possuem 
fases sequenciais, com foco no planejamento. O Scrum considera a mudança como 
a única constante e dá espaço para que as práticas emerjam. Os pilares do Scrum 
são: transparência, inspeção e adaptação.
A transparência consiste em tornar todo o processo visível a todos os envol-
vidos na criação do produto. Como o Scrum trata do controle empírico de proces-
sos, ele deve ser inspecionado regularmente para detectar eventuais problemas. A 
adaptação consiste no melhoramento e adaptações feitas no processo, caso a ins-
peção detecte algum problema. 
Através da correta inspeção e adaptação, utilizamos 
o princípio de “Kaizen” ou melhoria contínua.
O ciclo de vida de um projeto de desenvolvimento de software, seguindo o pa-
drão tradicional (waterfall), torna o projeto mais demorado e suscetível a falhas. 
Isso porque o cliente só terá contato com o produto final quando todas as etapas 
tenham sido concluídas. Já o ciclo de vida ágil permite que inspeção e adaptação 
sejam contínuas, e que o cliente possa ter contato com algumas funcionalidades 
do produto antes mesmo de sua entrega.
72GERÊNCIA DE PROJETOS
 SUMÁRIO
O framework (estrutura processual) do Scrum está baseado 
em um conjunto de fluxo, papéis, eventos e artefatos.
 É possível que elementos sejam incluídos no modelo, conforme o perfil de cada projeto 
ou organização. Entretanto, não podemos suprimir ou ignorar qualquer um dos elementos 
que o compõe, para que este não perca sua identidade e efetividade enquanto modelo.
Framework Scrum
Elaborado pelo autor com base em SCRUM GUIDE (2011).
Fonte: SCRUM GUIDE (2011).
Fluxo Sprint
Artefatos Backlog do produto e backlog da sprint
Papéis Product owner, time de desenvolvimento e Scrum Master
Eventos Planejamento da sprint, reunião diária, revisão da sprint e retrospectiva da sprint
73GERÊNCIA DE PROJETOS
 SUMÁRIO
O coração do Scrum é a sprint.
A sprint é uma iteração time-boxed de um mês ou menos, durante o qual um incre-
mento potencialmente entregável do produto é gerado. No decorrer da sprint, ocorrem fee-
dbacks constantes sobre o produto que está sendo desenvolvido. Caso seja necessário, o que 
foi produzido pode ser analisado e reorganizado. A sprint irá englobar a reunião de plane-
jamento da sprint, a reunião diária, o trabalho de desenvolvimento, a revisão da sprint e a 
retrospectiva da sprint. Ela é um guarda-chuva para todos os outros eventos! Os artefatos 
do Scrum darão uma visão do andamento do projeto e das sprints.
O backlog do produto é uma lista ordenada de tudo que 
deve ser necessário no produto. 
Ele nunca está completo, é dinâmico. O backlog do produto muda constantemente para 
identificar o que o produto necessita para se tornar mais apropriado, competitivo e útil. No 
backlog do produto, serão listadas todas as características, funções, requisitos, melhorias e 
correções que compõe as mudanças que devem ser implementadas em futuras versões do pro-
duto. Atributos da descrição, ordem e estimativa também deverão ser descritos para os itens.
Ele geralmente é ordenado por valor, risco, prioridade e necessidade. Os itens de or-
dem mais alta (topo da lista) são os de maior prioridade. Eles devem ser mais claros e mais 
detalhados do que os itens de ordem mais baixa. Quanto melhor for o nível de detalhamen-
to dos itens de maior prioridade, melhor serão as estimativas vinculadas a eles. Esses itens 
ocuparão o desenvolvimento da próxima sprint e serão decompostos de modo que possam 
estar prontos dentro do time-box da sprint. Eles serão considerados como “disponíveis” ou 
“executáveis” para a seleção na reunião de planejamento da sprint.
A ação de adicionar detalhes, estimativas e ordem aos itens no backlog do produto é 
uma constante. Esta é uma atividade de tempo parcial, durante a sprint, na qual colaboram 
o product owner e o time de desenvolvimento. O time Scrum decidirá como e quando a pre-
paração pode ser considerada pronta. Essa preparação costuma consumir em torno de 10% 
da capacidade do time de desenvolvimento.
O backlog da sprint é o conjunto de itens do backlog do 
produto selecionados para a sprint. 
Ele representa a previsão do time de desenvolvimento sobre qual funcionalidade es-
tará no próximo incremento e o trabalho necessário para entregá-la. O time de desenvol-
vimento modifica o backlog da sprint ao longo de toda ela, e ele também vai se clarificando 
ao longo do processo. Sempre que um novo trabalho for necessário, a equipe de desenvolvi-
mento adiciona esse ao backlog da sprint. Conforme esse trabalho é realizado ou completa-
do, a estimativa do trabalho restante é atualizada. Da mesma forma, se algum elemento do 
plano for considerado desnecessário, ele será removido.
Somente o time de desenvolvimento poderá alterar o backlog da sprint durante ela. Ele 
sempre estará altamente visível, apresentando uma imagem em tempo real do trabalho que 
74GERÊNCIA DE PROJETOS
 SUMÁRIO
o time pretende completar para alcançar o objetivo da sprint. Nesse contexto, o incremento 
representa a soma de todos os itens do backlog do produto completados durante a sprint e tudo 
das sprints anteriores. Um incremento pronto é aquele que está na condição utilizável e aten-
de à definição de pronto do time Scrum. Ele deve estar na condição utilizável independente do 
product owner decidir por liberá-lo ou não.
O product owner é o responsável por gerenciar o backlog 
do produto.
Esse gerenciamento vai incluir: expressar claramente os itens do backlog do produto; 
ordenar os itens do backlog do produto para alcançar melhor as metas e missões; garantir o va-
lor do trabalho realizado pelo time Scrum; garantir que o backlog do produto seja transparente, 
mostrando o que o time Scrum vai trabalhar a seguir; e garantir que a equipe entenda os itens 
do backlog do produto no nível necessário. Mesmo delegando alguma das atividades acima, o 
product owner continua sendo o responsável.
O time de desenvolvimento é formado por profissionais que 
realizam o trabalho de entregar uma versão utilizável do 
produto pronto, ao final de cada sprint. 
Os times são estruturados e autorizados pela organização para organizar e gerenciar o 
seu próprio trabalho na sprint. Equipes multidisciplinares conseguem ter um melhor nível 
de flexibilidade no projeto. Por exemplo, se um membro da equipe identifica um possível 
atraso, ele pode atuar auxiliando os demais colegas. Ele terá as competências neces-
sárias para atuar e terá bom trânsito nos diferentesdomínios de conhecimento do 
projeto. Esse modelo é projetado para promover flexibilidade, criatividade e produ-
tividade. A equipe entrega produtos de forma iterativa e incremental, maximizando 
oportunidades de feedback.
O Scrum Master é responsável por garantir que o 
Scrum seja entendido e aplicado.
Ele é a pessoa que mais conhece o Scrum entre todos os papéis. A relação entre 
o Scrum Master e os outros membros do time é o de um líder no processo. Para isso, ele 
utiliza técnicas de facilitação e coaching, garantindo que os membros do time consigam 
visualizar os problemas e encontrar a melhor solução. Ele assegura a aderência do time 
à teoria, prática e regras do Scrum. Ele é o servo líder do time!
Os eventos do Scrum são prescritos para criar uma rotina e minimizar a necessida-
de de reuniões não definidas. Cada evento no Scrum é uma oportunidade para inspecionar 
e adaptar alguma coisa. Ao não executar alguma das cerimônias do Scrum, haverá propor-
cional redução da transparência e a perda de uma oportunidade para inspecionar e adaptar.
A reunião de planejamento da sprint é uma das 
cerimônias do Scrum na qual o trabalho a ser realizado 
na sprint é planejado com a colaboração de todo o time. 
75GERÊNCIA DE PROJETOS
 SUMÁRIO
Considerando uma sprint de um mês, a time-boxed da reunião de planejamento seria 
de 8 horas. Essa reunião é dividida em duas partes. A primeira responde à pergunta “O que 
será pronto nesta sprint?” e, a segunda, “Como o trabalho escolhido será pronto?”
Na primeira parte, o time de desenvolvimento atua prevendo as funcionalidades que se-
rão desenvolvidas durante a sprint. São entradas dessa etapa: backlog do produto; incremento 
mais recente do produto; capacidade projetada do time de desenvolvimento durante a sprint; 
e desempenho passado do time de desenvolvimento.
Com base nessas informações, o product owner apresenta o backlog do produto e o time 
colabora com o entendimento do trabalho da sprint. Depois disso, o time de desenvolvimento 
selecionará os itens do backlog do produto que serão prontos na sprint. Após, o time determina 
a meta da sprint. Esse será um objetivo conhecido, que fornecerá a orientação sobre por que a 
equipe está trabalhando no incremento.
Na segunda parte da reunião, o time decidirá como serão construídas as funcionalidades 
selecionadas, transformando-as em um incremento do produto pronto. Para isso, ele deverá 
tomar aqueles itens que foram selecionados e decompô-los em unidades de um dia de duração 
ou menos. Após, o time irá se auto-organizar para realizar todo o trabalho do backlog da sprint.
Nessa etapa, o product owner pode estar presente, com o objetivo de melhor explicar os 
itens do backlog do produto selecionado. Se o time percebe que há excesso ou falta de traba-
lho, os itens do backlog da sprint podem ser renegociados com o product owner. Outras pessoas 
também poderão ser convidadas, com o objetivo de fornecer opiniões técnicas acerca de 
domínios específicos. Ao final da reunião de planejamento, o time de desenvolvimento 
deve ser capaz de explicar ao product owner e ao Scrum Master como pretende trabalhar 
como equipe auto-organizada para completar o objetivo da sprint.
A reunião diária é um evento time-boxed de 15 minutos, 
na qual a equipe de desenvolvimento sincroniza as 
atividades e cria um plano para as próximas 24 horas. 
Nessa reunião, o trabalho realizado nas últimas 24 horas é inspecionado, e é pre-
visto o trabalho que deverá ser feito antes da próxima reunião. Ela é mantida no mesmo 
horário e local, para facilitar a criação da rotina. São perguntas que devem ser respondidas 
pela equipe durante a reunião: “o que foi completado desde a última reunião?”; “o que será 
feito até a próxima reunião?”; “quais os obstáculos que estão no caminho?”
Essa reunião é fundamental para avaliar o progresso em direção ao objetivo da 
sprint e se o progresso está adequado para completar o trabalho do backlog da sprint. Dia-
riamente, a equipe deve estar apta para posicionar o product owner e Scrum Master sobre 
como pretendem trabalhar em conjunto, com um time auto-organizado, para completar 
o objetivo da sprint e criar um incremento.
A revisão da sprint é executada ao seu final, com o 
objetivo de inspecionar o incremento e adaptar o 
backlog do produto se necessário.
76GERÊNCIA DE PROJETOS
 SUMÁRIO
A revisão da sprint é um evento time-boxed de 4 horas, para uma sprint de um mês. 
Nessa reunião: o product owner identifica o que foi pronto e o que não foi pronto; a equipe 
de desenvolvimento compartilha o que foi bem durante a sprint, quais problemas ocorreram 
e como esses problemas foram resolvidos; a equipe apresenta o trabalho que está pronto e 
responde às questões sobre o incremento; o product owner discute o backlog do produto tal 
como está, projetando as prováveis datas de conclusão; o time discute sobre o que fazer a 
seguir. O cliente poderá ser convidado para participar a fim de validar as entregas.
Esses elementos fazem com que a reunião de revisão gere valiosas entradas para a 
reunião de planejamento da próxima sprint. Como resultado, obteremos um backlog do pro-
duto revisado, que define o provável backlog do produto para a próxima sprint. Este também 
pode ser ajustado completamente para atender novas oportunidades. Além disso, a reunião 
de revisão irá motivar, informar e promover a colaboração da equipe.
A retrospectiva da sprint representa uma oportunidade 
para o time inspecionar a si próprio e criar um plano de 
melhorias a serem aplicadas na próxima sprint. 
Ela ocorre depois da revisão da sprint e é uma reunião time-boxed de 3 horas, para 
uma sprint de um mês. O propósito dessa reunião é inspecionar como as pessoas, relações, 
processos e ferramentas se comportaram na última sprint, identificar e ordenar os princi-
pais itens que foram bem e as potenciais melhorias e criar um plano para implementar me-
lhorias no modo como o time fez seu trabalho.
Ao final dessa reunião, o time identificará as melhorias que serão implementadas na 
próxima sprint. Essa reunião representa uma forma de adaptação à inspeção que o time faz 
de si próprio. O fato de haver essa reunião não impede que melhorias sejam adotadas a qual-
quer momento na sprint.
77GERÊNCIA DE PROJETOS
 SUMÁRIO
ELEMENTOS QUE PODEM SER ADICIONADOS AO FRAMEWORK
Nesta seção, vamos falar de alguns elementos que são muito úteis e podem 
ser adicionados à prática do Scrum para o desenvolvimento de projetos. São eles: 
user stories, planning poker, quadro do backlog da sprint e gráfico de burndown.
As user stories descrevem uma funcionalidade que tenha valor ao cliente, 
mas em termos de negócios e não de uma forma técnica. Uma user story é com-
posta de três aspectos:
• uma descrição escrita da história como um lembrete;
• conversas sobre a história que servem para detalhá-la;
• testes que conduzem e documentam aspectos importantes da história e que 
podem determinar quando ela está completa.
Geralmente, as user stories são escritas em cartões de notas, e convencio-
nou-se a utilização dos 3Cs para descrevê-las: cartão, conversação e confirma-
ção. O modelo mais utilizado para a descrição de uma user story é: 
“Eu, como um [papel], gostaria de 
[funcionalidade] para [motivo]”.
Nesse modelo, “papel” representa qualquer tipo de usuário que esteja utilizando o produto, “fun-
cionalidade” é a funcionalidade desejada e “motivo” é o que determina o propósito dessa funcionali-
dade. Com as user stories, o product owner é capaz de justificar a necessidade de uma determinada fun-
cionalidade e certificar que ela esteja alinhada à visão. Os membros do time de desenvolvimento terão 
como rastrear para qual papel/perfil/persona estão desenvolvendo aquela funcionalidade.
Quando utilizamos user stories, é comum utilizarmos outra unidade de medida ao invés do tempo 
para estimar o esforço para implementação das funcionalidades. Nesse caso, utilizamos story points.Story points é uma unidade de medida relativa que leva em 
consideração o esforço necessário para realizar uma determinada 
funcionalidade. 
Se uma funcionalidade requerer o dobro de esforço para ser implementada, ela receberá aproximada-
mente o dobro de story points. Uma das melhores formas de estimar story points é utilizando o planning poker. 
O planning poker combina a opinião de experts, analogia e desagregação em uma abordagem di-
vertida na estimação de itens ou user stories e elimina a influência que um membro do time de desen-
volvimento possa exercer sobre outros.
No início do planning poker, cada membro do time recebe um conjunto de cartas. Cada carta exibe 
um dos valores válidos para a estimativa (0,1,2,3,5,8,13,20,40 e 100, por exemplo). Para cada user story 
a ser estimado, o product owner lê a descrição e esclarece quaisquer dúvidas que os membros do time 
78GERÊNCIA DE PROJETOS
 SUMÁRIO
tenham. Após todas as questões serem respondidas, cada membro seleciona uma carta re-
presentando sua estimativa, mas sem mostrar aos outros. As cartas não são mostradas até 
o momento em que todos, simultaneamente, exibam seus valores.
Nesse ponto, é normal que haja estimativas significativamente diferentes, o que é um 
bom sinal! Quando isso ocorre, os membros com maior e menor valor expõem os motivos 
que os levaram a escolher aqueles valores. Depois dos esclarecimentos, todos recolhem suas 
cartas e estimam novamente, da mesma forma, até chegar ao consenso.
Na segunda parte da reunião de planejamento da sprint, o time de desenvolvimento de-
compõe os user stories selecionados e cria um plano para transformá-los em um incremento do 
produto ao final da sprint. Os itens decompostos mais o plano dão origem ao backlog da sprint.
79GERÊNCIA DE PROJETOS
 SUMÁRIO
É comum que os times de desenvolvimento criem 
quadros para acompanharem o andamento da sprint. 
Este pode ser chamado quadro do backlog da sprint.
A composição deste quadro difere de time para time, mas em geral é muito simples. 
A decomposição das user stories compõe a coluna mais à esquerda. Conforme os itens co-
meçam a ser trabalhados, eles vão sendo passados às colunas da direita, até que estejam 
finalizados. Um item finalizado deve obedecer à definição de pronto acordada pelo time 
Scrum. Para times de desenvolvimento trabalhando em um mesmo local, o quadro do ba-
cklog da sprint é bastante útil. Entretanto, quando existem membros trabalhando de forma 
remota, é necessária uma ferramenta on-line para obter o mesmo efeito.
Outro modo de tornar o trabalho visível é criar um gráfico de burndown. No gráfico, 
um eixo é o número de pontos que a equipe definiu para a sprint, e o outro é o número de 
dias. Todos os dias, o Scrum Master soma o número de pontos concluídos e marca no gráfi-
co. O ideal é que a curva vá descendo pelo gráfico até chegar ao zero no último dia do sprint.
O progresso ideal é a linha que deve ser tomada como referência para o êxito da sprint. 
Ela é traçada na diagonal, começando no ponto máximo do eixo Y e indo até o final do eixo 
X. Essa linha guiará o time na velocidade a ser seguida. Se o time conseguir acompanhar 
essa linha, o sucesso será atingido. A linha do progresso realizado estará sempre buscando 
se equiparar com o progresso ideal. Elas iniciam no mesmo ponto de origem, mas o seu pro-
gresso é dado com a conclusão das histórias de usuário.
O PROJECT MODEL CANVAS
Um plano de projeto é uma construção de hipóteses sobre um cenário futuro e des-
conhecido. Ele se torna consistente pela integração entre os diversos conceitos que o com-
põem. Mas, como construir um plano de projeto de uma nova forma, que deixe evidentes as 
conexões entre as partes, que seja mais fácil de elaborar e efetivamente aplicável?
A resposta para essa pergunta é o Project Model Canvas (PMC). O PMC é a união de ten-
dências com novas pesquisas em neurociências. Diferentemente de um template de plano de 
projeto, o qual vimos nas nossas primeiras unidades, o PMC é uma agenda sobre a qual os 
stakeholders se empenharão para conceber a lógica do projeto. O PMC pode ser usado de duas 
80GERÊNCIA DE PROJETOS
 SUMÁRIO
maneiras diferentes: como um documento único e consistente do planejamento do projeto, 
imediatamente seguida pela execução, ou como uma ferramenta preliminar que conforma-
rá a lógica do projeto, servindo de base para a transcrição posterior a um plano de projeto 
representado de modo formal. Vamos conhecer o funcionamento do PMC!
O PROPÓSITO E A LÓGICA DO PMC
O livro do PMC foi lançado em 2013 pelo reconhecido consultor especialista em geren-
ciamento de projetos José Finocchio Jr. Ele tem como princípios a simplicidade, agilidade 
e desburocratização do gerenciamento de projetos. Atualmente, o PMC tem se tornado um 
padrão para a elaboração colaborativa e simplificada de ideias de projetos que, posterior-
mente, podem ou não dar origem a um plano mais formal e melhor detalhado.
O PMBOK® é uma espécie de bíblia para o gerenciamento 
de projetos. Contudo, essa abordagem tradicional tem 
recebido críticas em função de seu formato linear e extenso.
De fato, a aplicação do gerenciamento de projetos tradicional parece não estar muito 
aderente com a complexidade do ambiente de negócios e realidade das organizações. O ge-
renciamento de projetos tradicional também desafia o entendimento dos profissionais, pela 
falta da conexão entre as ideias e a sua aplicação no cotidiano. Por exemplo, as ideias sobre o 
projeto vão sendo apresentadas e interligadas com as demais de maneira fragmentada: uma 
após a outra e uma de cada vez. Isso faz com que a maioria dos projetos seja colocada em 
prática sem que sua lógica geral tenha sido debatida e definida.
O PMC teve inspiração nos trabalhos de Osterwalder e Pigneur (2010), que criaram um 
modelo de plano de negócios baseado no preenchimento coletivo de um canvas (Business 
Model Canvas). Canvas é um termo em inglês que pode ser traduzido como quadro ou plano 
de fundo, sobre o qual vão sendo colocados pedações de papel autocolantes.
O processo de utilização do canvas é simples e possibilita a rápida visualização e parti-
cipação dos membros da equipe, que constroem juntos o resultado final. 
A ideia é que o gerente de projetos coordene uma espécie 
de brainstorming com os membros de sua equipe e o 
cliente, para que todos construam juntos o início do 
processo, tendo ao mesmo tempo uma visão de conjunto 
sobre seus objetivos, fases, custo e benefícios.
Para que uma metodologia de planejamento de projetos se desenvolva de forma har-
mônica com o nosso funcionamento cerebral, são colocadas algumas proposições.
• Preparo: estimular um ambiente positivo e acolhedor. Pedir no início para que todos da 
equipe se apresentem e resumam sua trajetória e/ou indiquem por que estão ali. Con-
vencionar como serão resolvidos conflitos e dúvidas ao longo do processo.
• Foco: conduzir sessões de planejamento mais curtas, aproveitando o pico de desempe-
nho do funcionamento cerebral evitando o desgaste excessivo.
81GERÊNCIA DE PROJETOS
 SUMÁRIO
• Integrar: integrar itens dois a dois, a fim de reduzir o esforço de processamento cerebral.
• Visualização: explorar melhor o pensamento visual, um dos mais poderosos e evoluídos 
no cérebro humano.
• Relacionar: manter todos os conceitos necessários ao plano no mesmo desenho, permi-
tindo que eles sejam relacionados imediatamente.
• Ordem: responder às questões do projeto sequencialmente, na ordem correta, evitando 
sobrecarregar a memória de trabalho.
• Participar: dar autonomia aos stakeholders, para que participem do plano de maneira 
ativa, desarmando a postura defensiva que é característica de quem se sente ameaçado.
• Agrupar: agrupar conceitos de maneira a diminuir o número de itens processados de 
uma única vez.
• Atenção: manter nível máximo de atenção dos stakeholders no problema (ao menos du-
rante um determinado intervalo de tempo).
Um exemplode estrutura de relacionamento que facilita o entendimento das cone-
xões que ocorrem durante a construção da ideia do projeto é a seguinte:
Essa figura mostra de que maneira stakeholders, premissas, riscos e restrições podem, 
de fato, estar intimamente relacionados em um plano de projeto.
O canvas é um espaço no qual você pode prototipar o modelo mental do seu projeto. 
Por ser preenchido com post-its, pode ser reajustado inúmeras vezes. Com o canvas pode-
mos, por opção, abrir mão do formalismo, mas não podemos abrir mão da lógica. É impor-
tante esclarecer que o canvas não é um fluxograma do projeto, já que um fluxograma mostra 
uma sequência de passos; o importante no canvas são as relações entre os conceitos.
Elaborado pelo autor com base em Finocchio Jr. (2013).
82GERÊNCIA DE PROJETOS
 SUMÁRIO
Essa lógica é bem diferente de um plano convencional, porque é feito em equipe e de modo ágil. 
Hoje, estimulados pelas novas tecnologias, tendemos a pensar juntos e em rede. Esse novo modelo para o 
plano de projeto, elaborado com o essencial e de forma pragmática, está em sintonia com essa realidade.
Os post-its oferecem, por si só, uma clara restrição à quantidade do que 
podemos escrever. Isso é ótimo: se não existe espaço para escrever muito, te-
mos que escrever melhor!
Ainda mais limitado que a superfície dos post-its é o precioso tempo dos 
stakeholders, eles irão agradecer essa simplificação do processo de elaboração 
do plano do projeto.
Vale observar que não existe um número, nem um tamanho obrigatório para 
os post-its. O ideal é comunicar tudo o que é necessário escrevendo o mínimo pos-
sível, pois assim será mais fácil relacionar visualmente os elementos no canvas.
Também podem ser trabalhados post-its de tamanhos e cores diferentes. 
Por exemplo, pode ser que em um plano de projeto seja necessário usar três pa-
péis autocolantes grandes para o objetivo, ao passo que, em outro, seja possível 
resumi-lo em um único post-it médio.
OS COMPONENTES E AS ETAPAS DE CONSTRUÇÃO DO PMC
O PMC pode ser feito com uma folha de papel, segmentada em 13 blocos, 
que será usada como uma tela de fundo. O canvas deve ter um tamanho sufi-
ciente para que um pequeno grupo de pessoas possa colaborar ao seu redor. O 
resultado fica na forma apresentada na figura do Quadro PMC.
83GERÊNCIA DE PROJETOS
 SUMÁRIO
Quadro PMC
Fonte: http://www.pmcanvas.com.br/download/.
No canvas, o GP é o gerente de projetos. A pich é uma frase 
que resume a essência do projeto. Toda a informação é colocada 
com post-its nos diferentes blocos. Os temas tratados no PMC não 
fogem daqueles tradicionais que vimos em unidades anteriores.
Não existem papéis predefinidos no PMC, apenas duas 
regras básicas: ele deve ser feito preferencialmente em equipe 
e pelo menos uma das pessoas presentes deve ter conhecimen-
to sobre os conceitos básicos envolvidos no gerenciamento de 
projetos e como eles se relacionam entre si. 
Há muitas configurações possíveis para a equipe-tarefa: o 
ideal é misturar pessoas que conhecem muito do negócio com 
pessoas que não o conhecem; colocar lado a lado indivíduos que 
dominam gerenciamento de projetos e outros que não domi-
nam. Os mais experientes trarão o conhecimento do trabalho 
a ser feito, domínio sobre riscos e cenários possíveis; os mais 
novos carregam a ousadia de não se deter diante de normas e 
costumes. Isso faz com que ideias divergentes surjam e, conse-
quente a criatividade seja estimulada. Assim, uma equipe ideal 
para montar o plano seria composta por:
• um gerente de projetos, que possui fundamentos de ge-
renciamento de projetos e que elaborará o plano;
84GERÊNCIA DE PROJETOS
 SUMÁRIO
• um especialista na área de negócio específica, que conhece o ramo, 
mas não conhece gerenciamento de projetos, nem a dinâmica do PMC;
• um especialista do escritório de projetos, que não construirá o 
plano, mas criticará de maneira propositiva as formas de integrar 
os conceitos.
As quatro etapas de construção do 
canvas são: conceber, integrar, resolver e 
comunicar/partilhar.
Na etapa “conceber” são respondidas seis perguntas funda-
mentais: “Por quê?”, “O quê?”, “Quem?”, “Como?”, “Quando?” e 
“Quanto?”. Disso resulta uma sequência com ordem específica. Ao 
preencher o PMC com post-its, aquilo que estava escuro ficará níti-
do: fragmentos de informação dos stakeholders serão expostos e um 
novo modelo mental completo e consistente trará convergência ao 
grupo que o criou.
Cada área demarcada no canvas representa componentes, con-
ceitos clássicos de gerenciamento de projetos, com uma função de 
planejamento específica, e essas áreas demarcadas estão agrupadas em 
blocos que respondem às questões:
Fonte: elaborado pelo autor com base em Finocchio Jr. (2013).
Elaborado pelo autor com base em Finocchio Jr. (2013).
Assim, cada post, composto por sentenças curtas escritas nos post-its, preencherá cada componente com 
as informações específicas do projeto. Por exemplo:
Justificativa Requisitos Riscos
Pedidos são perdidos devido à 
lentidão do atendimento.
O sistema deve permitir digitação 
do CPF no atendimento 
telefônico.
Se o banco de dados corromper 
por queda de energia.
85GERÊNCIA DE PROJETOS
 SUMÁRIO
Na etapa “integrar”, garantimos a consistência entre os blocos e estabelecemos uma rela-
ção entre os componentes. O plano de projeto elaborado por meio do PMC não é imune a inconsis-
tências. Ele é resultado da interação de pessoas, de um fluxo de ideias, pensamentos e debates que 
são, a princípio, gerados separadamente, na elaboração de cada um dos blocos de componentes.
O processo de integração vai tornar o modelo mental 
representado no canvas mais forte.
Ele será feito por meio de amarrações de dois ou três blocos por vez, dando uma segunda 
chance de a equipe articular e agrupar melhor suas ideias. É interessante que a etapa de inte-
gração seja feita imediatamente após o término da etapa de concepção, porque a equipe ainda 
está “aquecida”, com o problema em mente.
A metodologia do PMC fornece um protocolo de integração que está estruturado em 
oito passos e é composto de perguntas que podem acarretar ajustes no plano do projeto, 
dependendo das respostas. 
1. Os pontos mencionados nas justificativas são sanados?
2. O objetivo se revela suficiente e necessário?
3. Todos os requisitos “têm dono” e definem o produto?
4. Estão subordinados ao projeto aqueles que precisam estar?
5. Obtivemos convergência formulando premissas válidas?
6. As limitações aplicáveis ao trabalho estão identificadas na forma de restrições?
7. Os riscos cobrem o que já sabemos do projeto e vislumbram, ao mesmo tempo, o que 
ainda não sabemos?
8. O cronograma e o orçamento estão orientados por entregas?
Fazer um plano de projeto é admitir trabalhar com informações imperfeitas. Al-
gumas pessoas paralisam diante dessa situação, outras seguem adiante. De todo modo, 
pensar em fazer um plano com todas as informações é uma ilusão.
A etapa “resolver” tem foco em identificar os pontos em que a montagem do can-
vas “travou” por causa de indefinições, falta de informação ou contradições. Esses pro-
blemas devem ser levados como “lição de casa”. O travamento por falta de definição é 
chamado de nó. Esse é o ponto que estrangula o planejamento dali para frente e, portanto, 
precisa ser “desatado”, restaurando o fluxo de informações. A lição de casa é uma forma 
de os stakeholders contribuírem com a possível solução para o travamento.
Os principais nós ou problemas relacionados aos projetos são: projetos que não 
geram valor; o cliente não sabe o que quer; os recursos não estão garantidos/alocados 
para o projeto; o gerente de projeto não possui autoridade, nem influência para tocar 
o projeto; a equipe não consegue identificar as entregas a serem feitas; a equipe for-
86GERÊNCIA DE PROJETOS
 SUMÁRIO
mulou mal os riscos; a equipe está insegura quanto à duração do projeto; 
os parceiros de negócio nãose integram à equipe; a equipe fez um ótimo 
plano, mas se esqueceu dos aspectos de sustentabilidade; e existe resis-
tência em relação ao projeto.
Para tratar esses e outros problemas, a etapa de resolução do projeto 
ocorre seguindo o mesmo fluxo do trabalho da etapa de concepção, respei-
tando a ordem das questões fundamentais. Por exemplo, verificaremos pri-
meiramente se a pergunta “por que?” foi respondida, e se o propósito está 
embasado em sólida geração de valor para a organização. Em seguida, che-
caremos “o quê” o projeto vai produzir, com detalhamento de requisitos. 
Após, conferiremos a “quem” foi atribuído o trabalho, e se essa pessoa 
possui autoridade, responsabilidade, disponibilidade e conhecimento sufi-
cientes. Na sequência, verificamos se há clareza a respeito de “como” fazer o 
trabalho e se as condições de trabalho estão controladas. Por fim, verificare-
mos se as informações sobre as perguntas “quando?” e “quanto?” são con-
dizentes com o que já se sabe do projeto e a incerteza que existe (os riscos).
Na etapa de comunicar/compartilhar, o canvas servirá como base para 
gerar outros documentos, sejam eles apresentações, cronogramas, orça-
mentos, ou até mesmo planos de projeto. Além disso, cada elemento do can-
vas é relevante no processo de gestão do projeto. Seguem alguns exemplos:
• as justificativas podem ser usadas para mostrar aos clientes e a outros stakeholders que a equipe enten-
deu corretamente a situação atual da organização;
• o gerente pode colocar os objetivos do projeto visíveis para que todas as partes interessadas entendam, 
em poucas palavras, onde o projeto quer chegar;
• os benefícios podem ser utilizados para demonstrar a intensidade da contribuição do projeto para os 
objetivos estratégicos da organização;
• o bloco “produto” é importante para a validação do projeto;
• os requisitos dão o direcionamento para as ações de gestão da qualidade (por exemplo, os testes);
• o bloco “stakeholders e fatores externos” será usado pela equipe para inventariar as premissas;
• o gerente pode usar o bloco “equipe do projeto” para demonstrar ao patrocinador que existe coerência 
entre a amplitude da missão que lhe foi atribuída e os recursos que lhe foram subordinados;
• o bloco “premissas” dá a base para o gerente e a equipe construírem tanto o cronograma quanto o or-
çamento do projeto;
• os grupos de entrega ajudam a motivar quem trabalha no projeto, pois quando se visualizam nas entre-
gas, os indivíduos tendem a se sentirem mais responsáveis por aquilo que estão produzindo;
• as restrições devem estar desdobradas em todos os níveis de trabalho e em todos os subsistemas do pro-
jeto, para que as pessoas que fazem o projeto possam oferecer soluções viáveis para elas;
87GERÊNCIA DE PROJETOS
 SUMÁRIO
• por meio dos riscos, o patrocinador pode julgar se deseja realizar o projeto da maneira como foi concebido;
• a linha do tempo funciona como ligação entre o mundo dos compromissos e o mundo das atividades que devem 
ser realizadas para completar o trabalho do projeto;
• os custos registram as metas que foram acordadas e que, mais tarde, serão detalhadas no orçamento do projeto.
Atualmente, empresas como Ambev, Natura e outras vem aplicando o PMC com sucesso em seus projetos. A 
aplicação dessa metodologia é adequada a todos os tipos de projeto, não sendo focada em projeto de alguma área 
específica. Contudo, como todo o projeto serve a um planejamento estratégico, a ideia é que o PMC possa ser incor-
porado ao dia a dia das organizações, como uma ferramenta útil e facilitadora nas mais diversas áreas da gestão.
RESUMO DA UNIDADE
Nesta unidade, vimos que a agilidade se aplica ao gerenciamento de projetos em ambientes complexos. Em 
2001, o manifesto ágil deu origem aos métodos ágeis, sendo os mais difundidos o Scrum e o Project Model Canvas.
O Framework do Scrum é composto pelos seguintes elementos: fluxo (sprint); artefatos (backlog do produto 
e backlog da sprint); papéis (product owner, time de desenvolvimento e Scrum Master); e eventos (planejamento da 
sprint, reunião diária, revisão da sprint e retrospectiva da sprint).
O PMC surge como uma opção para simplificar a gestão dos projetos, nas mais diferentes áreas. Com o canvas, 
podemos prototipar o modelo mental do projeto. Por ser preenchido com post-its, pode ser reajustado inúmeras vezes. 
Lembrando que o mais importante no canvas são as relações entre os conceitos clássicos do gerenciamento de projetos.
88GERÊNCIA DE PROJETOS
EXERCÍCIOS SUMÁRIO
Questões para reflexão que são importantes para o entendimento desta unidade.
1. O que são e para que servem métodos ágeis de gerenciamento de projetos?
2. Que tipo de projetos são normalmente gerenciados através de métodos ágeis?
3. De forma geral, como funciona o Scrum?
4. Quais são os componentes do Project Model Canvas?
5. Você, no seu âmbito profissional ou pessoal, entende como se encaixam os 
conceitos dos métodos ágeis? Tem alguma experiência, mesmo que não estru-
turada, com isso? 
89GERÊNCIA DE PROJETOS
REFERÊNCIAS SUMÁRIO
PMI, Project Management Institute. A Guide to the Project Management Body of Knowledge (PMBOK® GUIDE). 6ed. – Portugue-
se. Project Management Institute Inc., 2017.
PMI, Project Management Institute. http://brasil.pmi.org/brazil/AboutUS/WhatisPMI.aspx. Acesso em 15/06/2021.
HELDMAN, Kim. Gerência de projetos. 5 ed. Tradução Edson Furmankiewics. Rio de Janeiro: Elsevier, 2009.
SCHWABER, K.; SUTHERLAND. J. Guia do Scrum. Scrum.org. 2013, p. 2. Disponível em: http://www.scrumguides.org/docs/scrum-
guide/v1/Scrum-Guide-Portuguese-BR.pdf Acesso em: 25/03/2017.
DINSMORE, Paul Campbell. Transformando estratégias em resultados: sucesso empresarial através da gestão por projetos. Rio de 
Janeiro,: Qualitymark, 2010.
SOBRAL, Filipe; PECI, Alketa. Teorias da administração: bibliografia universitária Pearson. São Paulo: Pearson Education do Brasil, 2012.
VALENTE, Edson. “Soft Skills” são tão importantes quanto habilidades técnicas. Jornal valor econômico. Disponível em: http://
www.valor.com.br/carreira/3517610/soft-skills-sao-tao-importantes-quanto-habilidades-tecnicas. Aceso em 10/06/2017.
PHAM, A.; PHAM, P. SCRUM em ação. Novatec Editora, 2011.
RIGBY, Darrell K.; SUTHERLAND, Jeff; TAKEUCHI, Hirotaka. Embracing agile. Harvard Business Review, v. 94, n. 5, p. 40-50, 2016.
FINOCCHIO JR., José. Project Model Canvas. Rio de Janeiro: Elsevier, 2013.
MALACHIAS, Iago. Project Model Canvas: planejamento em uma folha. Revista MundoPM, fevereiro/março, p. 70-79, 2013.
CONFORTO, Evandro. Design Thinking: uma poderosa ferramenta para projetos de inovação. Revista MundoPM, abril/maio, p.10-
16, 2015.
BROWN, Tim. Design Thinking: uma metodologia poderosa para decretar o fim das velhas ideias. Tradução Cristina Yamagami. Rio 
de Janeiro: Elsevier, 2010.
	INTRODUÇÃO AO GERENCIAMENTO DE PROJETOS
	Os projetos e o gerenciamento de projetos
	A seleção de projetos e o portfólio de projetos
	Os projetos e as operações
	A estrutura organizacional
	O ciclo de vida do projeto
	Os papéis em gerenciamento de projetos
	ÁREAS DE CONHECIMENTO DE INTEGRAÇÃO E PRINCIPAIS
	Grupos de processos em gerenciamento de projetos
	GERENCIAMENTO DA INTEGRAÇÃO
	GERENCIAMENTO DO ESCOPO
	GERENCIAMENTO DO TEMPO
	GERENCIAMENTO DO CUSTO
	GERENCIAMENTO DA QUALIDADE
	ÁREAS DE CONHECIMENTO DE SUPORTE
	GERENCIAMENTO DOS RECURSOS HUMANOS
	GERENCIAMENTO DAS COMUNICAÇÕES
	GERENCIAMENTO DOS RISCOS
	GERENCIAMENTO DAS AQUISIÇÕES
	GERENCIAMENTO DAS PARTES INTERESSADAS
	Métodos ágeis de gerenciamento de projetos
	Manifesto ágil
	O Scrum
	Elementos que podem ser adicionados ao Framework
	O Project Model Canvas
	O propósito e a lógica do PMC
	Os componentes e as etapas de construção do PMC