Gerenciamento de Projetos

GERENCIAMENTO
DE PROJETOS
Autoria: Anderson Gonzaga de Souza e Coaracy Gomes da Silva Junior
1ª Edição
Indaial - 2020
UNIASSELVI-PÓS
CENTRO UNIVERSITÁRIO LEONARDO DA VINCI
Rodovia BR 470, Km 71, no 1.040, Bairro Benedito
Cx. P. 191 - 89.130-000 – INDAIAL/SC
Fone Fax: (47) 3281-9000/3281-9090
Reitor: Prof. Hermínio Kloch
Diretor UNIASSELVI-PÓS: Prof. Carlos Fabiano Fistarol
Equipe Multidisciplinar da Pós-Graduação EAD:

Carlos Fabiano Fistarol
Ilana Gunilda Gerber Cavichioli
Jóice Gadotti Consatti
Norberto Siegel
Julia dos Santos
Ariana Monique Dalri
Marcelo Bucci
Revisão Gramatical: Equipe Produção de Materiais
Diagramação e Capa:
Centro Universitário Leonardo da Vinci – UNIASSELVI
Copyright © UNIASSELVI 2019

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri
UNIASSELVI – Indaial.
S729g
Souza, Anderson Gonzaga de
Gerenciamento de projetos. / Anderson Gonzaga de Souza; Coaracy

Gomes da Silva Junior. – Indaial: UNIASSELVI, 2020.
171 p.; il.
ISBN 978-65-5646-150-2
ISBN Digital 978-65-5646-151-9
1. Administração de projetos. - Brasil. I. Junior, Coaracy Gomes da

Silva. II. Centro Universitário Leonardo Da Vinci.
CDD 658.404
Impresso por:
Sumário
APRESENTAÇÃO.............................................................................5
CAPÍTULO 1
Definindo o Gerenciamento
de Projetos.....................................................................................7
CAPÍTULO 2
Principais Áreas de Conhecimento de Gerenciamento
de Projetos...................................................................................61
CAPÍTULO 3
Modelo Geral para Gerenciamento de Projetos..................127
APRESENTAÇÃO
Olá, pós-graduando. Segundo o Guia PMBOK® e Manual PRINCE2™, por
definição, os projetos são únicos e temporários. Eles envolvem todo o trabalho
necessário para criar e concluir algo totalmente novo. O desenvolvimento de um
novo produto é uma tarefa única, enquanto a implementação de um novo sistema
de software é algo único. Mais ainda, a execução de qualquer iniciativa estratégica
precisa de iniciativas diferentes das estratégias de anos atrás.
Com avanço e maior disponibilidade de novas tecnologias a um baixo custo,

como inteligência artificial, aprendizado de máquinas, realidade aumentada,
realidade virtual, drones, big data, robótica etc., muitas organizações, dentre elas,
as militares, precisam desenvolver projetos que acompanhem essa evolução
tecnológica e, consequentemente, estar mais preparadas para lidar com os
desafios do mundo digital. No vídeo disponível em: https://www.youtube.com/
watch?v=-Rg3PIuJkkg, podemos compreender como esse contexto influencia a
necessidade de novos projetos nas forças armadas.
Durante muitos anos, várias instituições foram inspiradas em modelos

militares na sua modelagem organizacional. Hierarquia, comando e controle,
estratégia bem definidas e planejamento. É um modelo que atendeu bem às
necessidades do momento e levou muitas instituições ao sucesso. Dadas as
mudanças sociais, tecnológicas e econômicas, a realidade tem se mostrado bem
mais dinâmica do que já foi um dia, o que significa que práticas antigas de sucesso,
não necessariamente levarão você ao sucesso daqui para frente, o que reforça a
necessidade de revisitar algumas práticas e refletir se a forma de responder às
mudanças nesse novo contexto está adequada. A burocracia necessária durante
muitos anos precisa de um novo olhar, buscando novas práticas que atendam
às necessidades organizacionais de forma mais flexível e ágil. Agilidade é um
movimento mundial que tem influenciado as mais diversas organizações, que vão
desde empresas privadas a empresas públicas, como maximizar a entrega de
valor para a sociedade de forma rápida e sustentável.
Seguindo essa lógica, no Capítulo 1, apresentaremos os conceitos básicos

de gestão de projetos, sua evolução no tempo, esclarecer o ciclo de vida do
projeto e como fazer isso de forma lúdica e colaborativa. No Capítulo 2, veremos
as áreas de conhecimento envolvidas no gerenciamento de projetos e como elas
se relacionam com o ciclo de vida do projeto. No Capítulo 3, veremos como utilizar
um modelo geral para gerenciamento de projetos e como utilizar abordagens mais
modernas para essas práticas. Lembrando que não existe bala de prata ou receita
de bolo. É necessário entender o contexto e ajustar as práticas de acordo com o
esforço e benefício gerado.
Bons estudos!
Professor Anderson Gonzaga de Souza.

C APÍTULO 1
Definindo o Gerenciamento
de Projetos
A partir da perspectiva do saber fazer, neste capítulo você terá os seguintes

objetivos de aprendizagem:
• reconhecer o papel estratégico da gestão de projetos no alcance de resultados

organizacionais;
• compreender e visualizar de forma sistêmica o papel do gerenciamento de

projetos dentro das organizações;
• esclarecer por que o gerenciamento de projetos é uma alternativa importante e

como ela impacta o desempenho das organizações públicas e privadas;
• aplicar de forma prática as ferramentas apresentadas no curso;
• permitir através de exercícios e fóruns aproximar o conhecimento a realidade.

Gerenciamento de Projetos
8
Capítulo 1 Definindo o Gerenciamento
1 CONTEXTUALIZAÇÃO
O gerenciamento de projetos não é um assunto novo. Acompanhamos o tema
há mais de 20 anos. As pesquisas e conjunto de práticas, conforme conhecemos nos
dias de hoje, possuem mais de 900 anos. Durante essa jornada, através de estudos e
muita prática, presenciamos uma evolução do cenário econômico, social, tecnológico e
cultural. A gestão de projetos tem procurado se adaptar aos mais diversos cenários com
objetivo de entregar valor para as partes interessadas.
Fazendo uma viagem no tempo, podemos resgatar as origens da gestão de

projetos e suas realizações ao longo da história. Dessa forma, compreender o passado
é a melhor maneira de entendermos o presente e projetarmos o nosso futuro. Vamos,
juntos, estudar como o contexto influenciou a gestão de projeto e dado o cenário VUCA.
"VUCA" é um termo cunhado pelas forças armadas dos EUA

na década de 1990 para lidar com uma mudança no cenário
de batalha após o término da Guerra Fria, com o surgimento
de um cenário global multilateral e não bilateral. Isso significa
estar preparado para situações em que os adversários não
são visíveis, a distinção entre combatentes e civis inocentes
não é aparente e as milícias mudam continuamente seus
parceiros, táticas e assim por diante, como no Iraque e no
Afeganistão e, mais tarde, na Somália e na Líbia. Os militares
dos EUA tiveram que se adaptar rapidamente e improvisar
para combater efetivamente as armas e as táticas desses
oponentes, geralmente com uma explosão de inteligência de
campo baseada em tecnologia, mas ambígua.
Hoje, os líderes empresariais enfrentam um cenário
semelhante, desafiador e dinâmico, especialmente
após a crise bancária nos anos 80, quando empresas e
organizações de todo o mundo se viram repentinamente
diante de uma turbulência comparável em seus ambientes
de negócios e, posteriormente, tiveram que repensar seus
negócios e modelos (ABIDI; JOSHI, 2015, p. 142).
Assim como devemos estruturar projetos mais flexíveis e que se adaptam às

constantes necessidades de mudanças.
A referência global em gestão de projetos é o PMI. O Project Management Institute

(PMI) é uma organização sem fins lucrativos que tem a missão de compartilhar as
melhores práticas de gerenciamento de projetos ao redor do mundo. Essa instituição
estimula o debate sobre o tema por meio de publicações, eventos e reuniões.
Reconhecida em diversos países, a instituição possui mais de 1.000.000 de integrantes
localizados em diferentes países e que estão em constante aperfeiçoamento profissional
(PMI, 2020a).
9
2 HISTÓRIA DA GESTÃO DE
PROJETOS
Vamos começar do início e traçar uma linha do tempo histórica sobre gerenciamento
de projetos, mas saiba que, embora histórica, o gerenciamento de projetos não é um
objeto empoeirado do passado disponível em bibliotecas universitárias. Ele continua
evoluindo e influenciando a maneira como as pessoas, instituições, governos fazem
quase tudo, que tem início, meio e fim.
Os faraós construíram as pirâmides do Egito por volta de 2500 a. C. e até hoje

temos dúvidas de como realizaram tal feito. Mão de obra, matéria-prima foram um
dos grandes obstáculos desse projeto. Os granitos utilizados na câmara do rei foram
extraídos a mais de 400 km do local da construção. O projeto levou mais de 20 anos
para ser concluído, tendo utilizado mais de 10.000 pessoas na sua construção. Os
registros mostram que, mesmo naquela época, havia responsáveis por cada uma das
quatro faces da Grande Pirâmide (SOUSA, 2020).
Em 208 a. C., a Grande Muralha da China foi construída com o objetivo de

proteger o império de Qin Shi Huang, apesar de não haver um perigo eminente.
Há registros que indicam que o planejamento deste grande projeto iniciou bem
antes da sua execução. Dados históricos revelam que a força de trabalho desse projeto
foi organizada em grupos (soldados, pessoas comuns e criminosos). Milhões foram
investidos para sua conclusão.
Mais recentemente, a necessidade de uma estrutura mais formulada na construção

civil, fabricação e transporte no século XIX levou ao nascimento do gerenciamento
de projetos, como o reconhecemos hoje. No período da Revolução Industrial, as
construções eram vistas como obras de arte, tornando o trabalho um pouco mais
complexo e com requisitos de qualidade mais criteriosos devido a sua necessidade de
acomodar: pessoas, máquinas, matéria-prima e produto acabado.
Nesse momento, a figura de um responsável pelo acompanhamento dos

projetos começou a surgir. Profissional com habilidade de leitura, escrita, matemática,
conhecimento de negócios e conhecimentos gerenciais. Outros exemplos incluem a
construção da Ferrovia Transcontinental e a reconstrução dos estados do Sul após a
devastação da Guerra Civil Americana.
Embora não houvesse considerações sobre gerenciamento de atividades,

escopo ou carga de trabalho naquela época, certamente havia liderança em jogo e
deve ter havido algum orçamento, mesmo que aberto, e algum tipo de programação do
10
trabalho. Mas com a prática veio processo e refinamento, como veremos mais adiante
(WESTLAND, 2020).
2.1 A HISTÓRIA MODERNA DO

GERENCIAMENTO DE PROJETOS
Não foi com a Revolução Industrial que o gerenciamento de projetos, como o
conhecemos, começou a tomar forma. À medida que os projetos foram “industrializados”,
o processo para gerenciá-los também passou por uma grande revolução.
Em 1911, a publicação de O Princípio da Gestão Científica, de Frederic Taylor, com

base em seu trabalho na indústria siderúrgica, foi uma tentativa de ajudar trabalhadores
com baixa qualificação a fazer a transição para novos projetos mais complexos através
de técnicas simples de aprendizado. Durante o seu estudo, Taylor procurava otimizar o
trabalho, quebrou o processo em tarefas e utilizou métodos científicos com objetivo de
tornar o trabalho mais eficiente. Ele foi pioneiro na necessidade de sistemas salariais
baseados em incentivos e em como tirar proveito das técnicas de economia de tempo.
Posteriormente, seu trabalho ficou conhecido como Estudo sobre tempos e movimentos
(CHIAVENATO, 1994).
Henry Gantt pode ser considerado o pai do gerenciamento de projetos moderno.

Em 1917, ele criou o diagrama de agendamento de mesmo nome. Foi uma inovação.
Ele usou uma linha do tempo visual para imprimir tarefas como pontos com durações e
as vinculava se fossem dependentes. Dessa forma, todos poderiam ver a programação
das atividades mais claramente.
GRÁFICO 1 – GRÁFICO DE GANTT
FONTE: <https://support.office.com/pt-br/article/apresentar-os-
dados-em-um-gr%C3%A1fico-de-gantt-no-excel-f8910ab4-ceda-
4521-8207-f0fb34d9e2b6>. Acesso em: 24 fev. 2020.
11
O gráfico de Gantt foi de extrema relevância no mundo do gerenciamento de

projetos. Foi usado na construção da barragem Hoover, em 1931, que foi uma de
suas primeiras grandes implementações. “Os gráficos de Gantt continuam sendo
usados hoje e passaram para o mundo digital com versões on-line que os tornam
mais fáceis de serem utilizados” (CHIU, 2010, p. 5).
Com a Segunda Revolução Industrial, tivemos uma evolução da tecnologia

até então utilizada. Com a chegada dos motores a combustão e energia elétrica,
a produção em massa sofreu uma grande transformação, aumentando a sua
produtividade. Esse fato trouxe grandes inovações na gestão de projetos.
Agora chamado de AACE Internacional (Association for the Advancement

of Cost Engineering ou Associação para o Desenvolvimento da Engenharia
de Custos), a AACE foi formada por uma coleção de gerentes de projeto e
especialistas associados de planejamento, programação, estimativa de custos e
outros campos relacionados. Continua hoje como uma das principais sociedades
profissionais de gerentes de projetos e áreas afins. Em 2006, eles lançaram o
primeiro processo integrado de gerenciamento de portfólio, programa e projeto
com sua estrutura de gerenciamento de custo total (AACE, 2020).
O método do caminho crítico inclui determinar o caminho mais longo no

diagrama de rede (o caminho crítico), a data mais cedo e mais tarde em que
uma atividade pode iniciar e a data mais cedo e mais tarde em que ela pode ser
terminada (MULCAHY, 2009, p. 196).
FIGURA 1 – MÉTODO DO CAMINHO CRÍTICO
FONTE: <https://www.smartsheet.com/critical-path-method>. Acesso em: 24 fev. 2020.
O Empire State Building, construído em 1930, famoso edifício de 102 andares,

localizado em Nova Iorque, foi uma das grandes construções que usufruíram das
boas práticas de gestão de projetos (SMITH, 2019).
Diferentemente das pirâmides do Egito, esse grande projeto tinha

como desafio um cronograma agressivo e uma variedade de mão de obra
12
multidisciplinar (mais de 60 tipos de profissionais). Dada a agressividade do

prazo, foi experimentado o paralelismo entre atividades. Técnica esta conhecida
como “fast track” (ao planejar um projeto é comum que o gerente estipule uma
ordem que deve ser seguida para a realização das atividades. Em vez de iniciar
uma tarefa após a finalização de outra, o gerente pode optar pelo fast tracking e
realizar tarefas simultâneas) (PROJECT BUILDER, 2017).
Foi iniciada a escavação do novo edifício antes mesmo da demolição do seu

predecessor. Foram construídas quatro lajes por semana, utilizando inovações
que otimizaram tempo e custo, sem impactar a qualidade e o escopo. 3.400
profissionais trabalharam nesse projeto, consumindo mais de 7 milhões de
horas. O projeto foi entregue três meses antes do prazo e com uma economia
aproximada de 18 milhões de dólares.
Outro método comum de gerenciamento de projetos, a Estrutura Analítica

do Projeto (EAP ou WBS – Work Breakdown Structure) surgiu pela primeira vez
no Departamento de Defesa dos Estados Unidos. A EAP é uma estrutura em
árvore hierárquica completa dos produtos e tarefas necessários para concluir
um projeto. Também fazia parte do projeto Polaris. Após a conclusão do projeto,
o Departamento de Defesa publicou a EAP e, em 1962, determinou o uso para
projetos futuros (DEPARTAMENTO DE DEFESA DOS ESTADOS UNIDOS DA
AMÉRICA, 1998).
FIGURA 2 – EXEMPLO DE EAP
FONTE: <https://www.euax.com.br/2019/02/modelo-de-eap/>. Acesso em: 5 mar. 2020.
13
Em 1965, foi fundada a Associação Internacional de Gerenciamento de Projetos

– IPMA. É a primeira associação de gerenciamento de projetos do mundo. Fundada
em Viena como um meio para os gerentes de projetos se conectarem, a organização
agora está registrada na Suíça e é compilada por 50 associações de gerenciamento
de projetos nacionais e internacionais. Em 2012, contava com mais de 120.000
membros (IPMA, 2020).
O Project Management Institute (PMI), sem fins lucrativos, foi fundado por
cinco voluntários em 1969. Incorporado na Pensilvânia, realizou seu primeiro
simpósio em Atlanta, em 1969. Desde então, publicou um Guia do Conhecimento em
Gerenciamento de Projetos (Guia PMBOK®), que descreve as processos e áreas
de conhecimento de gerenciamento de projetos e tornou-se padrão em 1998. O PMI
também é um organismo de certificação, oferecendo o Associado Certificado em
Gerenciamento de Projetos (CAPM) e o Profissional de Gerenciamento de Projetos
(PMP) (PMI, 2020).
A filosofia de gerenciamento da teoria das restrições (TOC) foi desenvolvida

para ajudar uma organização a atingir seus objetivos. O título deriva da ideia de que
um sistema gerenciável é limitado para atingir seus objetivos por várias restrições.
Em um fluxo de trabalho, precisamos identificar os “gargalos”, que tornam o sistema
de trabalho lento. Foi introduzido pela primeira vez pelo Dr. Eliyahu M. Goldratt, em
seu romance A meta, de 1984. A teoria foi aplicada à criação da Corrente crítica de
gestão de projetos (GOLDRATT, 2014).
O modelo ágil de desenvolvimento de software, que incorpora várias equipes

pequenas que trabalham intensa e interdependentemente, é muito conhecido
através de um framework que se chama Scrum, que foi nomeado como estilo de
gerenciamento de projetos em 1986. O termo vem de um artigo publicado pela
primeira vez na Harvard Business Review, chamado The New Product Development
Game, de Takeuchi e Nonaka. Desenvolvido para gerenciamento de software, passou
a ser usado em projetos gerais (TAKEUCHI; NONAKA, 1986).
14
FIGURA 3 – SCRUM FRAMEWORK ÁGIL DE GESTÃO DE PROJETOS
FONTE: <https://www.scrum.org/resources/what-is-scrum>. Acesso em: 24 fev. 2020.
A ideia de um conceito de valor agregado não é nova. Ela existe desde a

virada do século XX, mas ganhou destaque como técnica no gerenciamento de
projetos em 1989. O Earned Value Management (EVM ou Gerenciamento do
Valor Agregado) ajuda a medir o desempenho do projeto usando um processo
sistemático de gerenciamento de projetos para encontrar variações nos projetos
com base na comparação de trabalho realizado e planejado. É um poderoso
preditor de controle de custo e cronograma (MCGRECOR; BLISS, 2018).
FIGURA 4 – VISÃO GRÁFICA DO VALOR AGREGADO
FONTE: <https://www.gp3.com.br/artigo/181-o-que-e-analise-de-valor-
agregado-em-gestao-de-projetos/>. Acesso em: 29 fev. 2020.
15
Em 1996, o PRINCE2 foi lançado em resposta às solicitações de melhorias

dos usuários. A partir desse momento, o PRINCE2 não era apenas um método para
gerenciamento de projetos de sistema de informação, mas para o gerenciamento
de qualquer tipo de projeto. “PRINCE2 é baseado em muitas e nas mais diversas
experiências de Gerentes de Projeto, times de projeto e profissionais envolvidos em
projetos” (RIBEIRO, 2011, p. 5).
Em 1997, Eliyahu M. Goldratt desenvolveu o Critical Chain Project Management

(CCPM ou Cadeia crítica de gerenciamento de projetos), que é baseado nos métodos
e algoritmos de sua Teoria das Restrições. Ele mantém os recursos carregados de
maneira nivelada, mantendo-se flexível até o horário de início e alternando entre as
tarefas quando necessário para manter o projeto dentro do cronograma (CORREIA;
ABREU, 2011).
O uso de métodos de desenvolvimento iterativo e incremental remonta a 1957

com o gerenciamento evolutivo de projetos, embora o desenvolvimento de software
adaptável não tenha surgido até a década de 1970. Mas o amplo uso das práticas
ágeis, como estilo de projeto, foi codificado com a criação do Manifesto Agile ou
Manifesto de Desenvolvimento de Software, em 2001 (AGILE MANIFESTO, 2001).
Como podemos observar através desses marcos históricos, o tema

gerenciamento de projetos passou por várias atualizações ao longo dos anos. Até
os dias de hoje, vem sendo atualizado. O Guia PMBOK® passa por revisões a cada
quatro anos e com a colaboração de voluntários, dos mais diversos setores ao redor
do mundo, que revisam os processos e aplicações práticas. Mais recentemente, o
guia está na sua sexta edição, sendo incorporados temas como as práticas ágeis. As
instituições militares tiveram grandes contribuições no desenvolvimento da disciplina
de gerenciamento de projetos ao longo do tempo, principalmente influenciando sua
necessidade de planejamento e controle para alcance de resultados.
2.2 FUNDAMENTOS DO
GERENCIAMENTO DE PROJETOS
Com o advento da globalização e alta disponibilidade de tecnologia a um baixo
custo, o contexto em que vivemos passou por profundas transformações. A tecnologia
aproximou pessoas, reduzindo fronteiras de comunicação entre pessoas, instituições
e mudou a forma como nos relacionamos. Todo histórico citado anteriormente
estava dentro de um contexto onde havia poucas mudanças, o ambiente era mais
controlável, previsível, lento e estável. O mundo VUCA em que vivemos torna o
ambiente complexo, fora de controle, imprevisível, rápido e instável, o que requer
16
abordagens diferentes das tradicionais e conhecidas até então.
Dizemos isso, pois a forma como você vai gerenciar o seu projeto depende muito
do contexto em que você está inserido e da complexidade do trabalho que precisa
ser realizado. Se você for gerenciar projetos de construção, onde o contexto é mais
previsível, uma abordagem clássica pode ser a mais recomendada. Agora, projetos
de pesquisa e desenvolvimento de softwares são mais dinâmicos e precisarão de
uma abordagem mais flexível. Veremos a sua aplicação ao longo deste material.
Antes de mais nada, vamos entender o que é um Projeto. Segundo o Guia

PMBOK (2017), 6ª edição, projeto é um esforço temporário empreendido para criar
um produto, serviço ou resultado único.
A sua natureza temporária prevê um início e um término bem estabelecidos.

O término é alcançado quando os objetivos tiverem sido alcançados ou quando se
concluir que esses objetivos não serão ou não poderão ser atingidos, ou quando este
não mais for necessário ou justificável.
Temporário não significa necessariamente de curta duração. Além disso,

geralmente, o termo temporário não se aplica ao produto, serviço ou resultado criado
pelo projeto.
No manual do PRINCE2™, encontramos a seguinte definição: “Um projeto é

uma organização temporária criada com o propósito de entregar um ou mais produtos
de negócio, de acordo com um business case pré-acordado” (OGC, 2011, p. 3).
FIGURA 5 – DA ESTRATÉGIA AOS RESULTADOS
FONTE: O autor
17
A diferença entre o Guia PMBOK 6ª edição e o Manual PRINCE2™ é que o

primeiro livro traz um conjunto de boas práticas de gestão de projetos, enquanto o
segundo é uma metodologia. Um se preocupa em esclarecer “o que é e para que
serve determinados processos e ferramentas” e o outro, “como fazer e organizar o
trabalho”. A unificação desses dois livros pode ajudá-lo bastante com ideias sobre
como criar a sua própria metodologia de gestão de projetos. A forma como você
organiza projetos, depende muito do seu contexto. Logo, não existe uma “receita
de bolo” para gerenciar projetos. Você precisar entender as práticas e identificar
quais serão as melhores abordagens dentro da sua organização.
Devemos lembrar que os trabalhos executados pelas empresas e

organizações têm como objetivo atender às necessidades das partes interessadas,
sendo elas: sociedade, investidores, organização executora do projeto, equipe do
projeto e o público em geral, que de alguma forma podem ser impactados direta
ou indiretamente pelo projeto e seus resultados. Esses trabalhos são resultados
de serviços repetitivos e continuados e de serviços únicos e temporários.
Os serviços repetitivos podem ser chamados de processos e os serviços

únicos e diferentes entre si podem ser chamados de projetos. Não importando
essa classificação, esses trabalhos possuem características comuns e bem
explícitas. Eles são executados por colaboradores/funcionários, recursos são
limitados, devem ser planejados, executados, acompanhados e controlados pelo
gestor responsável pelo projeto.
Os projetos, objeto deste curso, são diferentes dos processos porque

pelas suas características possuem um tempo limitado e são únicos nos seus
resultados. Utilizando o maior significado das palavras acima, devemos destacar
que a singularidade e existência limitada dos projetos é o que mais chama atenção
na sua definição. Diz-se temporário por que seu início e fim são bem definidos e
conhecidos, e únicos porque não podem existir dois projetos iguais.
As organizações públicas apresentam características particulares que as

diferem das organizações do setor privado, visto que a missão fundamental do
governo é “fazer o bem, e não fazer dinheiro” (OSBORNE; GAEBLER, 1998 apud
CARNEIRO, 2010, p. 1).
Para Carneiro (2010), a esfera pública tem utilizado com mais intensidade as
práticas de gerenciamento de projetos como uma ferramenta facilitadora para o
atingimento de um índice maior no êxito na implementação das políticas públicas.
O surgimento dos projetos nasce da necessidade organizacional de atingir

determinado objetivo e/ou resolver alguma necessidade. Visto que os motivadores
18
são distintos, enquanto um ambiente privado busca o lucro através da entrega

de valor para os seus clientes que pagam por isso, as organizações públicas
procuram devolver algo de valor para a sociedade, que devolve para o governo a
sua contribuição através de impostos.
Nesse contexto, podemos compreender o nascimento dos projetos através

de um planejamento estratégico, necessidade operacional ou administrativa
que visa apoiar as organizações no atingimento de objetivos de curto, médio e
longo prazo. No ambiente militar, os direcionadores são definidos pela alta gestão
(estado-maior do exército brasileiro) que define algumas diretrizes.
O exército brasileiro possui um conjunto de normas para

elaboração, gerenciamento e acompanhamento de projetos.
Disponível em: http://www.epex.eb.mil.br/images/pdf/documentos_
download/nega-peb.pdf.
Ao ler o documento, podemos constatar que está alinhado ao conteúdo aqui

abordado. Segundo o guia, o exército está em constante busca pelas:
[...] incessantes concepções de soluções criativas e

sustentáveis no desempenho de suas atribuições, além da
busca por atualização doutrinária, organizacional e sistêmica.
Não obstante, certo é que o EB organiza suas experiências
institucionais inseridas na ordem social sem deixar de praticar
e vivenciar, nas dinâmicas da Defesa, os códigos de valores
fundamentais para a instituição, buscando-se o diálogo entre
Ordem e Progresso (EXÉRCITO BRASILEIRO, 2019, p. 5).
O direcionamento para os projetos deve estar alinhado com as diretrizes

propostas e devem ser priorizadas iniciativas que apoiam as diretrizes, conforme
segue:
• o fortalecimento da imagem do Exército como instituição de Estado,

coesa e integrada à sociedade;
• a capacitação técnica dos militares para enfrentar os desaﬁos da Guerra
Moderna, alicerçada nos valores, nas tradições e na ética militar;
• a continuidade do Processo de Transformação do Exército, impulsionado
por medidas imediatas e eﬁcazes de racionalização; e
• a manutenção de elevada capacidade dissuasória fundamentada em alto
nível de preparo e na incorporação de novas capacidades.
19
Toda e qualquer iniciativa deve apoiar as diretrizes apresentadas. Dada a

limitação de recursos, deve-se avaliar a priorização e urgência. O que estamos
fazendo, sustenta as diretrizes definidas pela organização? Questionamentos
como esse ajudarão o alinhamento estratégico como um todo. Dessa forma,
mantemos uma comunicação coesa, integrada e alinhada a um propósito maior
mesmo estando distribuídas fisicamente.
FIGURA 6 – ALINHAMENTO ESTRATÉGICO X ADEQUAÇÃO AO ORÇAMENTO
FONTE: Adaptada de UVAGPCLASS (2017)
Uma vez aprovadas as iniciativas, temos os projetos elegíveis para serem

executados. A seguir, conheceremos o ciclo de vida de um projeto, desde a sua
concepção até o seu encerramento.
3 CICLO DE VIDA DO PROJETO

Vamos estudar as etapas e estágios associados ao gerenciamento de
projetos, conforme definido pelo Project Management Institute® (PMI). Para
entender como o Project Management Institute (PMI) recomenda que os projetos
sejam executados é necessário entender o ciclo de vida do gerenciamento de
projetos.
O ciclo de vida do gerenciamento de projetos é a estrutura em torno da qual

as atividades de gerenciamento de projetos são organizadas. É um conceito-
chave no gerenciamento formal de projetos, de acordo com o PMI. A estrutura
e a função do ciclo de vida do gerenciamento de projetos serão apresentadas
20
com vários termos relacionados, que são comumente utilizados e servem de

vocabulário comum, evitando quaisquer falhas de comunicação.
Mas o que é um ciclo de vida? O termo "ciclo de vida" implica duas coisas:
que um processo é infinito e que a sequência de eventos é obrigatória ou
unidirecional. Um ciclo de vida típico é mostrado a seguir. Não há começo nem fim
para um ciclo de vida e a sequência de eventos não pode mudar. Uma semente
não pode passar diretamente para o estágio de uma planta madura nem voltar ao
estágio de floração.
FIGURA 7 – CICLO DE VIDA DE UMA PLANTA
FONTE: <https://pt.vecteezy.com/arte-vetorial/153487-vetor-
da-planta-ciclo-de-vida>. Acesso em: 26 fev. 2020.
O termo “ciclo de vida” é enganoso, porque não é um círculo perpétuo de

eventos, nem a sequência de eventos é rigidamente fixa. Existem cinco estágios
no ciclo de vida do gerenciamento de projetos:
• Iniciação.
• Planejamento.
• Execução.
• Monitoramento e controle.
• Encerramento.
21
Os cinco estágios geralmente ocorrem em sequência. Se o projeto é

relativamente simples e não há necessidade de repensar ou replanejar o projeto,
a sequência de etapas pode ser tão simples quanto a descrita a seguir:
GRÁFICO 2 – CICLO DE VIDA DE UM PROJETO
FONTE: <https://artia.com/blog/ciclo-de-vida-de-um-projeto/>. Acesso em: 25 fev. 2020.
Segundo o guia PMBOK® (2017), existem 49 processos mapeados em

cinco fases (iniciação, planejamento, execução, monitoramento e controle e
encerramento) e dez áreas de conhecimento. As dez áreas de conhecimento que
foram definidas no gerenciamento de projetos são:
• Gerenciamento integrado de projetos.

• Gerenciamento do escopo do projeto.
• Gerenciamento do cronograma do projeto.
• Gerenciamento de custos do projeto.
• Gerenciamento da qualidade do projeto.
• Gerenciamento de recursos do projeto.
• Gerenciamento de comunicações do projeto.
• Gerenciamento de riscos do projeto.
• Gerenciamento de aquisições de projetos.
• Gerenciamento das partes interessadas do projeto.
No quadro a seguir, vamos compreender como ficará a relação entre ciclo de

vida e áreas do conhecimento, segundo o guia PMBOK® (2017) 6ª edição:
22
QUADRO 1 – RELACIONAMENTO ENTRE CICLO DE

VIDA E ÁREA DE CONHECIMENTO
FONTE: Adaptado de Guia PMBOK (2017)
Antes de falarmos sobre cada uma dessas áreas de conhecimento em

detalhes, objeto de estudo do Capítulo 2, primeiro vamos detalhar os cinco grupos
de processos.
23
3.1 INICIAÇÃO DO PROJETO

A fase de iniciação é a primeira fase do projeto. Nesta fase, uma necessidade
de negócios é identificada e um plano de negócios ou Business Case, que fornece
várias opções de solução, é definido. Um estudo de viabilidade é então conduzido
para investigar a probabilidade de cada opção de solução abordar o problema de
negócios e uma solução final recomendada é apresentada. Deve-se avaliar se
a organização possui as competências necessárias para executar o projeto. Em
organizações públicas, caso seja necessária contratação externa, será necessário
seguir com um processo de licitação. Salvo exceções, conforme fundamentado
no artigo 24 da Lei nº 8666/93. Nesse momento, deve-se identificar quem é o
patrocinador do projeto, ou seja, quem tem poder para autorizar a execução
desse projeto.
Dentro de uma estrutura militar, deve-se avaliar o porte do projeto x hierarquia

do patrocinador. Patrocinador é aquele responsável por autorizar o início do
projeto, assim como designar os recursos necessários para sua execução. A
preocupação se dá ao nível de autoridade deste. Caso o patrocinador não tenho
poder de influência em outras áreas que envolvam o projeto, você terá problemas
na execução.
Outro ponto relevante nesse momento é a identificação de premissas e

restrições envolvidas no projeto. Segundo o Guia PMBOK (2017), premissa é tudo
aquilo que assumimos como verdade para efeito de planejamento. Exemplo: O
departamento de engenharia vai liberar um engenheiro civil para apoiar o projeto
cerca de 5 horas por dia. Para efeito de planejamento, você está considerando o
trabalho desse profissional durante 25 horas semanais. Logo, toda premissa vira
um risco, pois caso essa disponibilidade não se torne uma realidade, seu projeto
será impactado.
Restrição é tudo aquilo que limita as opções de planejamento. Exemplo:

Temos um orçamento de R$ 500.000,00 para o projeto. Logo, a restrição de custo
limita o planejamento do projeto. Não podendo ser excedida.
24
FIGURA 8 – DESDOBRAMENTO DA ESTRATÉGIA EM PROJETOS
FONTE: O autor
Depois que a solução recomendada é aprovada, um projeto é iniciado para

entregar valor através do projeto aprovado. Um Termo de abertura do Projeto
é finalizado, descrevendo os objetivos, escopo em alto nível (ou seja, macro) e
estrutura do novo projeto, e um Gerente de Projeto é nomeado. O gerente de
projeto começa a recrutar uma equipe de projeto. Após aprovação do início do
projeto, deve-se evoluir para a fase de planejamento.
3.2 PLANEJAMENTO DO PROJETO

Depois de definido o escopo macro do projeto no termo de abertura do
projeto, o projeto entra na fase de planejamento detalhado. Isso envolve a criação
de:
• Planejamento do Cronograma (descrevendo as atividades, tarefas,

dependências e prazos).
• Planejamento de Custos (identificando os custos de mão de obra,
equipamentos e materiais).
• Planejamento de Recursos (listando mão de obra, equipamentos e
materiais necessários).
• Planejamento da Qualidade (fornecendo metas de qualidade, medidas
25
de garantia e controle).
• Planejamento de risco (destacando riscos e ações possíveis para mitigá-
los).
• Planejamento dos benefícios (listando os critérios a serem atendidos
para obter a aceitação do cliente).
• Planejamento de comunicação (listando as informações necessárias
para informar as partes interessadas e como será feito).
• Planejamento das partes interessadas (categorias, partes interessadas
de primeiro e segundo nível e como serão gerenciadas).
• Planejamento de Aquisições (identificando produtos a serem adquiridos
de fornecedores externos).
Nesse ponto, o projeto foi planejado em detalhes e está pronto para ser
executado. Como resultado, teremos o plano de projeto que servirá de guia para
o processo de execução.
3.3 PROJETO DE EXECUÇÃO

Essa fase envolve a execução de cada atividade e tarefa listada no Plano do
Projeto. Enquanto as atividades e tarefas estão sendo executadas, uma série de
processos de gerenciamento é realizada para monitorar e controlar os produtos
a serem produzidos pelo projeto. Isso inclui a identificação de alterações
necessárias, riscos e problemas, a revisão da qualidade da entrega e a medição
de cada entrega produzida com base nos critérios de aceitação. Depois que todas
as entregas tiverem sido produzidas e o cliente aceitar a solução final, o projeto
estará pronto para o encerramento.
FIGURA 9 – GRUPO DE PROCESSOS DE GERENCIAMENTO DE PROJETOS
FONTE: Adaptado de Guia PMBOK (2017)
26
3.4 ENCERRAMENTO DO PROJETO

O encerramento do projeto envolve liberar as entregas finais ao cliente,
entregar a documentação do projeto, rescindir contratos com fornecedores,
liberar recursos do projeto e comunicar o fechamento do projeto a todas as partes
interessadas. A última etapa restante é realizar uma Revisão pós-Implementação
para quantificar o sucesso geral do projeto e listar as lições aprendidas para
projetos futuros.
A seguir, vamos compreender em detalhes o ciclo de vida de um projeto.
3.5 DETALHAMENTO DO CICLO DE

VIDA DE UM PROJETO
As seções a seguir fornecem uma descrição mais detalhada de cada fase e
listam os modelos de documentos que fornecem ao gerente de projeto orientações
sobre como concluir cada fase com êxito.
3.5.1 Iniciação
A fase de iniciação envolve essencialmente “Lançamento” do projeto ou da
sua fase. Dada a complexidade e tamanho do projeto, ele pode ser dividido em
várias fases que funcionarão como pequenos projetos. Logo, todos os grupos
de processo aqui apresentados serão utilizados em cada fase antes de iniciar
a próxima. É a fase em que necessidade do negócio é identificada, a solução é
acordada, um projeto formado para produzir a solução e uma equipe do projeto
nomeada.
3.5.1.1 Desenvolver Business Case

Depois que uma necessidade de negócios for identificada, um Business
Case ou Caso de Negócios – Um plano de negócio (ou business case) é um
guia para orientar a criação de um novo negócio ou empreendimento. Esse
documento descreve como estará estruturado o negócio com base em diferentes
perspectivas, como: análise do mercado; fatores econômicos; viabilidade
financeira, dentre outros levantamentos necessários que servirão de base para
justificar a implementação do novo projeto. Em resumo, o plano de negócios
27
é um instrumento que permite comunicar uma ideia de negócio para vender

(interna ou externamente) ou para obter um financiamento. Trata-se também de
uma ferramenta de uso interno para a organização, pois lhe permite validar a
viabilidade das suas iniciativas e serve também como métrica de avaliação pós-
implementação (PROJECT BUILDER, 2017).
Isso inclui:
• Uma definição detalhada do problema ou oportunidade.

• Uma análise das possíveis opções de solução disponíveis.
Para cada opção, os possíveis benefícios, custos, riscos e problemas são

documentados. Um estudo formal de viabilidade pode ser encomendado se a
viabilidade de qualquer opção de solução específica não for clara.
• A solução recomendada e um plano de implementação genérico.
O Business Case é aprovado pelo patrocinador do projeto e o financiamento

necessário é alocado para prosseguir com o projeto.
3.5.1.2 Realizar estudo de viabilidade

Em qualquer estágio (ou após) durante o desenvolvimento de um Business
Case, um estudo de viabilidade formal deve ser encomendado. O objetivo é
avaliar a probabilidade de uma opção de solução específica alcançar os benefícios
descritos no Business Case. O Estudo de Viabilidade também investigará se os
custos previstos são razoáveis, se a solução é viável, se os riscos são aceitáveis
e/ou se é possível evitar quaisquer problemas prováveis.
3.5.1.3 Estabelecer o termo de abertura

do projeto
Após a solução ter sido acordada e o financiamento alocado, um projeto
é formado. O termo de abertura do projeto define a visão, objetivos, escopo e
resultados do projeto. Ele também fornece a estrutura da organização (papéis
e responsabilidades), nível de autoridade atribuído ao gerente do projeto e um
plano resumido das atividades, recursos e financiamento necessários para a
realização do projeto. Por fim, são listados quaisquer riscos, questões, premissas
e restrições de planejamento.
28
3.5.1.4 Nomear a equipe do projeto

Neste ponto, o escopo do projeto foi definido em alto nível (macro) e a equipe
do projeto está pronta para ser nomeada. Embora um gerente de projeto possa
ser nomeado em qualquer estágio do projeto, ele precisará ser nomeado antes
do estabelecimento da equipe do projeto. O gerente de projeto documenta uma
descrição detalhada para cada função do projeto e designa os profissionais para
cada função com base em suas habilidades e experiência relevantes.
3.5.1.5 Identificar as partes interessadas

Uma parte interessada é qualquer indivíduo, grupo ou parte que tenha
interesse no projeto e nos resultados de suas ações, podendo ser pessoas que
serão beneficiadas ou não pelo projeto. Exemplos comuns de partes interessadas
incluem funcionários, clientes, acionistas, fornecedores, comunidades e governos.
Diferentes partes interessadas têm interesses diferentes, e as organizações
frequentemente enfrentam problemas ao tentar agradar a todas elas.
Gerenciar expectativas e estabelecer uma comunicação

adequada é uma das atribuições do gerente de projetos. No Guia de
Gestão de Projetos Do Exército, você encontrará uma lista de partes
interessadas que fazem parte do contexto militar. Disponível em:
http://www.epex.eb.mil.br/images/pdf/documentos_download/nega-
peb.pdf.
3.5.1.6 Plano de gerenciamento dos

benefícios
Segundo o Guia PMBOK® (2017), plano de gerenciamento de benefícios
é um documento que descreve como e quando os benefícios do projeto serão
entregues e descreve os mecanismos que devem ser implementados para medir
esses benefícios.
Se um benefício não puder ser definido ou mensurado de alguma forma, ele

não será realizável. Um perfil de benefício contém quatro itens:
29
1) Descrição: detalhamento do tipo de benefício que a organização obterá

após a conclusão do projeto ou fase. Muitos projetos são concluídos
dentro do prazo, custo, qualidade etc., porém deixam a desejar na
gestão dos benefícios esperados com o mesmo.
2) Resultados observáveis: os benefícios podem ser tangíveis ou
intangíveis. No caso de benefícios intangíveis, você deverá procurar
formas de materializar esses benefícios. Por exemplo: Projeto de
desenvolvimento dos profissionais através de capacitações. Como
através de um treinamento, você será capaz de mostrar os benefícios
nas competências dos profissionais. Talvez uma avaliação antes e
depois será capaz de mostrar o quanto eles aprenderam com o curso.
3) Atribuição: nesse momento, deve-se avaliar quem será responsável
por registrar, monitorar e verificar os benefícios propostos pelo projeto
durante a sua execução.
4) Mensuração: os benefícios precisam ser mensuráveis. Você deverá
estabelecer uma ordem de grandeza com o objetivo de medir os
resultados gerados pelo projeto. Exemplo: Redução de 30% no custo de
logística.
Esses são os principais pontos que você deverá considerar no início de um

projeto, segundo as melhores práticas do Guia PMBOK® (2017).
Um dos maiores desafios é ter os recursos disponíveis no momento certo

e contar com o engajamento das partes interessadas. Projetos iniciados e que
podem ultrapassar o mandato do atual patrocinador, corre o risco de perder forças
e não atingir os resultados esperados.
3.5.2 Planejamento
As atividades no planejamento do projeto são variadas porque você precisa
descobrir como atingir seus objetivos. E como gerente de projetos, você não
conseguirá atingir os resultados se tentar planejar tudo sozinho. Por esse motivo,
o detalhamento do projeto ocorre na fase de planejamento, pois você terá que
envolver a equipe e avaliar a necessidade de envolver parceiros estratégicos
para refinar as atividades. Cada projeto será diferente, pois os objetivos serão
diferentes. A maior parte do trabalho de planejamento está direcionada ao que
você precisa fazer para completar todo trabalho necessário e colocar a estrutura
em prática para que isso aconteça. Por estrutura, entendemos os processos e
governança para manter tudo funcionando sem problemas. São etapas como
o processo de gerenciamento de mudanças, o processo de orçamento, como
você obterá os aceites dos resultados quando chegar a hora, quais medidas de
qualidade são importantes etc.
30
Nas forças armadas, sempre há algum tipo de ação, que vai do treinamento à
manutenção e, por trás de tudo, existe um plano. A estrutura para o planejamento
militar é frequentemente descrita como os procedimentos de tropas e processos
de tomada de decisão. Os líderes bem-sucedidos, dentro e fora das forças
armadas, precisam saber como planejar e gerenciar projetos, o que inclui o ajuste
dos planos conforme necessário para garantir o alcance dos objetivos.
O gerenciamento de projetos estará presente em uma campanha de

marketing, um plano de negócios, um projeto de qualidade total, construção de
uma casa ou uma rodovia. Nas organizações empresariais e militares, existem
inúmeras abordagens de gerenciamento e planejamento, mas todos os projetos
têm um ciclo de vida e os mesmos componentes essenciais.
A fase de planejamento do projeto ocorre no início do projeto: é após

a fase de iniciação que tudo o que você realmente fez foi obter aprovação,
alinhar expectativas, entender o propósito e identificar riscos iniciais para
avançar. Planejamos no início para economizar tempo mais tarde. Um bom
plano significa que você não precisa se preocupar se os profissionais do projeto
estarão disponíveis nas datas certas – porque você planejou e acordou que elas
estivessem presentes.
Você não precisa se preocupar com o desembolso financeiro, porque

planejou seu processo de custos. Você não precisa se preocupar se todos
concordam com um resultado de qualidade – porque você já planejou e acordou
quais medidas de qualidade e benefícios serão usados no projeto.
Ele define os processos que todos devem seguir, para evitar muitas dores
de cabeça mais tarde. Por exemplo, se você especificar que as estimativas de
tempo e custos serão elaboradas por especialistas no assunto com base em seus
julgamentos, e isso é aprovado, mais tarde ninguém poderá reclamar que eles
queriam que você usasse uma técnica de estimativa diferente. Eles conhecem o
acordo desde o início. O planejamento agiliza o processo.
Os planos do projeto também são realmente úteis para monitorar o progresso.

Você pode voltar para eles e verificar o que disse que faria e como, comparando-o
com o que realmente está fazendo. Isso fornece uma boa verificação da realidade
e permite mudar de rumo, se necessário, trazendo o projeto de volta aos trilhos.
De fato, isso é o que mais acontece durante o processo de monitoramento e
controle.
O resultado final da sua fase de planejamento é um documento chamado

plano de projeto. O Guia PMBOK (2017), 6ª edição, diz que o plano do projeto é
31
composto de muitos planos subsidiários. Estes incluem:
• Um plano para gerenciar os recursos humanos da equipe em termos de

disponibilidade e desenvolvimento de habilidades.
• Um plano para gerenciar custos e os elementos orçamentários do projeto,
incluindo compras ou contratos com fornecedores, caso necessário.
• Um plano de comunicação que define quem receberá mensagens sobre
o projeto, quando e em que formato.
• Um plano para lidar com os riscos do projeto, incluindo os processos de
registro e rastreamento de riscos.
• Um plano de qualidade que especifica as metas de qualidade para o
produto do projeto e a gestão do projeto em si.
Na realidade, é raro que você os produza como documentos individuais.

O que você precisa é de um plano de projeto que fale sobre os elementos
importantes de cada um deles. Não faz sentido criar um grande documento que
defina exatamente como sua organização funciona, de qualquer maneira. Se
você já possui um processo estruturado de gerenciamento de riscos, não perca
tempo anotando tudo novamente no plano do projeto.
Seu plano de projeto precisa incluir informações suficientes para garantir que
você saiba exatamente quais processos e procedimentos precisam ser seguidos
e quem precisa estar envolvido.
Obtenha seu plano de projeto aprovado pelas partes interessadas, pelo

patrocinador do projeto e por sua equipe, para que não haja surpresas mais tarde.
3.5.2.1 Como criar um plano de projeto?

Até agora, você provavelmente já tem uma boa ideia de como criar seu plano
de projeto. Você precisa gastar tempo com sua equipe:
• Esclarecendo os objetivos que vocês precisam alcançar juntos.

• Trabalhando nos processos que vocês precisam para chegar lá.
• Desenvolvendo um plano de ação sobre como vocês levarão isso
adiante.
Nós gostamos de trabalhar utilizando recursos visuais. Apresentaremos para

vocês o Project Model Canvas, desenvolvido pelo professor José Finocchio Jr.
“Considerado uma metodologia inovadora de gerenciamento de projetos, Project
Model Canvas foi escrito com clareza e abordagem diferenciada para revolucionar
o campo da gestão de projetos. Em uma atmosfera altamente criativa, diferentes
32
pessoas criam em conjunto um plano de projeto utilizando post-its” (FINOCCHIO

JR. (2013; PROJECT MODEL CANVAS, 2017).
Trata-se de um método colaborativo pleno, no qual todos

os stakeholders do projeto participam com proatividade,
suprimindo a tão conhecida burocracia e o excessivo
preenchimento de documentos desnecessários. A metodologia
é ideal para ser utilizada em ambientes que priorizam a
criatividade e o dinamismo em seus negócios, permitindo
uma melhor compreensão visual dos conceitos de um projeto,
o engajamento da equipe e a rápida tomada de decisões
(PROJECT MODEL CANVAS, 2017, p. 1).
Esse documento ajudará a deixar claro, de forma sistêmica, as principais

etapas e servirá de base para um maior detalhamento, caso necessário.
FIGURA 10 – PROJECT MODEL CANVAS
FONTE: <http://pmcanvas.com.br/download/>. Acesso em: 3 mar. 2020.
Costumamos baixar este documento e imprimir em folha A0. Utilizamos post-

it e canetinhas. Normalmente, deixamos visível em uma parede e iniciamos o
trabalho com a equipe do projeto. Vamos ao passo a passo:
33
FIGURA 11 – ESTRUTURA DO PROJECT MODEL CANVAS
FONTE: Adaptada de Finocchio Jr. (2013)
A estrutura do Project Model Canvas é parecida com a ferramenta 5W2H

(5W: What (o que será feito?) – Why (por que será feito?) – Where (onde será
feito?) – When (quando?) – Who (por quem será feito?) 2H: How (como será
feito?) – How much (quanto vai custar?) (ENDEAVOR, 2020). Através dessa
estrutura, podemos entender os motivadores, descrição do produto do projeto,
envolvidos, entregas do projeto, quando e quanto será necessário.
34
FIGURA 12 – JUSTIFICATIVA PARA O PROJETO NO PM CANVAS
No processo de iniciação, você já deve ter levantado as informações

solicitadas nesse bloco inicial. O preenchimento do canvas inicia com o nome do
gerente de projetos responsável e depois o nome do projeto no pitch (algumas
empresas gostam de utilizar frases curtas e impactantes para descrever o projeto).
O primeiro bloco procura dar visibilidade da necessidade do projeto, ou seja: Qual
é a justificativa para esse projeto?
Posteriormente, você deve identificar uma meta para o projeto e

ela precisa ser SMART (o S corresponde ao termo specific, M atribui-se
a measurable (mensurável), A de achievable, que quer dizer atingível ou aquilo
que é alcançável, R corresponde a relevant, o que permite entender que as metas
precisam ser relevantes para a organização e, por fim, o T vem de time. Em toda
meta é preciso determinar um tempo para que ela se cumpra). Para finalizar o
primeiro bloco, deve-se deixar explícitos os benefícios esperados.
Vamos utilizar um projeto de exemplo: “Centro de distribuição N1”, conforme

descrito a seguir:
35
FIGURA 13 – EXEMPLO DE JUSTIFICATIVA PARA UM PROJETO
O gerente de projetos designado foi “José de Souza” e o Pitch é “Centro de

distribuição N1”. Como justificativa para esse projeto foi identificado: “Alto custo
de logística para abastecer de suprimentos a região norte do país”.
Através dessa necessidade, foi determinado um objetivo smart para

este projeto, que é: reduzir o custo de transporte para a região norte em 30%
até dezembro de 2020. Os benefícios esperados são: maior disponibilidade de
suprimentos para atender à região, redução dos custos logísticos para a região
norte e redução do risco de roubo de cargas.
Esse momento é muito rico, principalmente por ser colaborativo, o que já traz
um fator muito importante em projetos, que é a comunicação.
36
FIGURA 14 – ENTENDIMENTO DO ESCOPO E SEUS REQUISITOS
Nessa etapa, procuramos explorar como será o produto do projeto, ou seja:

O que será entregue ao final do projeto? Normalmente, nesse momento é criado
a EAP do projeto. Como exposto acima, a EAP é uma das principais ferramentas
para entendimento do escopo e demais planejamentos. Vamos aprender como
desenvolvê-la?
A estrutura analítica do trabalho (EAP ou WBS) é uma das primeiras etapas

de planejamento do projeto. A EAP é usada para descobrir todo o trabalho que
precisa ser construído no projeto. Compreender o trabalho do projeto e o trabalho
de gerenciamento do projeto fornece uma visão global do projeto.
Uma EAP é "decomposição" lógica e representação da "estrutura" hierárquica

do "trabalho" exigido pelo projeto. Simplesmente, fazendo isso, criamos uma
imagem organizada que nos permite ver, e mais importante, permite que as
partes interessadas vejam todo o trabalho necessário para alcançar os objetivos
do projeto. Durante a sua construção, você pode começar a ver o poder da EAP
no gerenciamento de expectativas das partes interessadas.
37
FIGURA 15 – EXEMPLO DE EAP DO PROJETO DO NOVO CENTRO DE DISTRIBUIÇÃO
FONTE: O autor
FIGURA 16 – EXEMPLO DE PRODUTO E SEUS REQUISITOS
38
Depois de identificar as partes de trabalho, repare que não focamos em atividades

necessárias para “fazer” o trabalho. As atividades podem ser incluídas na EAP, entretanto,
elas poderão ficar muito extensas. Já trabalhamos com cronogramas de mais de 1.500
linhas. Pense em como ficaria a representação gráfica se colocássemos as tarefas abaixo
das entregas? Uma boa prática é trabalhar no nível de pacotes de trabalho.
O próximo passo é detalhar os requisitos do produto do projeto, ou seja, quais são

as especificações do produto do meu projeto. No canvas, podemos iniciar a coleta desses
dados com as partes interessadas e, com a EAP, podemos entender as partes e seus
requisitos. Por exemplo: um requisito para o produto é a capacidade de armazenagem.
Nove fileiras com seis níveis com espaçamento de altura de 1,5 m. Os requisitos serão
uma das informações que o gerente de projetos poderá utilizar para determinar os critérios
de aceite junto à parte interessada, “cliente”, desse projeto. Não é simplesmente criar um
galpão. Ele precisa atender às especificações expostas e aos objetivos do projeto.
As atividades costumam ficar disponíveis debaixo de cada “pacote de trabalho”, ou

em um cronograma, que veremos mais à frente. Após você fazer uma decomposição do
trabalho, você poderá determinar quais recursos serão necessários para cada entrega,
quanto esforço cada tarefa levará, custos envolvidos, riscos, dependências lógicas entre
as tarefas.
FIGURA 17 – IDENTIFICAÇÃO DE PARTES INTERESSADAS EXTERNAS

E FATORES QUE PODERÃO INFLUENCIAR O PROJETO

39
A etapa seguinte é identificar as partes interessadas externas ao projeto.

Lembrando que partes interessadas são todas as pessoas e instituições que
podem impactar e serem impactadas pelo projeto ou seu produto. Nesse
momento, queremos apenas identificar as partes interessadas externas com o
objetivo de coletarmos algumas premissas.
FIGURA 18 – EXEMPLO DE IDENTIFICAÇÃO DE PARTES INTERESSADAS EXTERNAS

E PREMISSAS
Identificar as partes interessadas é de extrema importância para o projeto.

Como foi comentado, o exército possui um documento que já sinaliza as principais
categorias de partes interessadas de um projeto militar. Entretanto, dependendo
do contexto, isso pode mudar. As formas de identificação das partes interessadas
são muito variadas. Nossa sugestão é que você analise o organograma da
instituição e identifique quais áreas poderão ser impactadas com seu projeto.
A própria EAP o ajudará a identificar possíveis partes interessadas. Outra fonte
muito utilizada em projetos são os dados históricos de projetos anteriores, que
são os ativos organizacionais. Opinião de especialistas é outro ponto muito
comum a ser utilizado. Após o término do seu projeto, ele se tornará uma fonte de
informações históricas.
40
O que acontece se você esquecer de identificar uma parte interessada?

Bom, dependendo do nível de interesse e autoridade, você poderá ter problemas,
pois alguns requisitos e/ou premissas deixaram de ser levados em consideração
na etapa de planejamento. Vale ressaltar que existem as categorias e as pessoas
dessas categorias. A gestão das partes interessadas é relacionada às “pessoas”
e não categorias. As categorias servem para ajudá-lo a identificar as pessoas e
depois você poderá fazer a gestão adequadamente.
FIGURA 19 – EXEMPLO DE IDENTIFICAÇÃO DE PARTES

INTERESSADAS INTERNAS E RESTRIÇÕES
Após identificar as partes interessadas externas e premissas, vamos identificar

as partes interessadas internas ao projeto e algumas restrições. Vale ressaltar
que esse processo de trabalho utilizando, o canvas, é totalmente interativo. Os
passos citados aqui têm como intenção ajudá-lo a iniciar o preenchimento. À
medida que as informações vão sendo preenchidas, você pode identificar alguma
relação com algum item anterior e que poderá ser complementado, reescrito ou
criado um novo.
No nosso exemplo, como restrição temos um orçamento de no máximo R$

300.000,00 e uma restrição de tempo, em que o trabalho só poderá ser executado
de segunda a sexta-feira em horário comercial. Essa fase do planejamento tem
41
como premissa reduzir as incertezas do projeto. O que não significa que algo
poderá dar errado e precisará ser revisado e replanejado. Não existe projeto
que não sofrerá mudanças. Todo planejamento quando entra em contato com a
realidade, sofre impacto. Lembrando que no exemplo que estamos explorando,
estamos falando de um projeto de construção civil, que se feito corretamente,
terá pouca mudança. Em um projeto de tecnologia ou pesquisa, a existência
de incertezas é muito maior e requer outra abordagem no seu planejamento e
execução.
FIGURA 20 – GRUPOS DE ENTREGAS E CRONOGRAMA
Após desenvolvermos o planejamento até esse ponto, conseguimos identificar

qual é o escopo desse projeto, os requisitos, as premissas, as restrições e será
possível você avançar com as entregas do projeto e como será a sequência de
trabalho na linha do tempo. O trabalho de planejamento não é tão simples quanto
parece. Depende da complexidade do projeto e seu contexto.
Projetos com alta dependência de cronograma, onde existem amarrações

contratuais, como em projetos públicos que utilizaram licitações com fornecedores
para execução do projeto, parte do pagamento está atrelado a entregas. Logo,
se atrasar, multas poderão ser aplicadas ou a cadência de pessoas envolvidas
no projeto pode ser afetada. Para mitigar esses riscos de atraso, um bom
42
planejamento do seu cronograma e gestão de riscos precisa ser aplicado ao

projeto.
FIGURA 21 – EXEMPLO DE ENTREGAS E VISÃO MACRO DO CRONOGRAMA
Para o nosso projeto de exemplo, grupos de entregas foram identificadas

e o seu sequenciamento lógico permite um melhor entendimento de como o
trabalho se dará na linha do tempo. Precisamos nivelar o terreno antes de preparar
os alicerces para, posteriormente, levantar as paredes e o telhado.
43
FIGURA 22 – RELAÇÃO ENTRE PREMISSAS, ENTREGAS E RISCOS
Para Mulcahy (2009, p. 373), “O trabalho de um gerente de projetos não

deve se concentrar em lidar com problemas, mas sim se concentrar em evitá-los”.
Toda premissa vira risco, pois você assumiu algo como verdade para efeito de
planejamento. Mas, e se isso não acontecer? Medidas de contorno deverão ser
aplicadas.
44
FIGURA 23 – EXEMPLO DE RELAÇÃO ENTRE PREMISSAS, ENTREGAS E RISCOS
Os processos de identificação de riscos, assim como a sua gestão, serão

continuamente analisados, revisados, alterados e incluídos durante todo o ciclo de
vida do projeto, desde a iniciação até o momento do encerramento. É importante
ressaltar que nem todo risco é negativo. Existem riscos positivos que devem ser
explorados e os negativos eliminados, transferidos, mitigados ou aceitos. No
capítulo de áreas de conhecimento do gerenciamento de projetos, vamos estudar
mais detalhadamente os temas. Aqui estamos explorando apenas o ciclo de vida
(iniciação, planejamento, execução, monitoramento e controle e encerramento)
de gerenciamento de projetos.
45
FIGURA 24 – PLANEJAMENTO DOS CUSTOS
O orçamento de um projeto tem o potencial para impactar quase todas as

dimensões do projeto, tornando-o uma das responsabilidades mais críticas de
gestão de um gerente de projeto. Um orçamento mal projetado leva à alocação
inadequada de ativos, expectativas irreais e, potencialmente, um projeto com
falha e que não atingirá os benefícios esperados.
Um orçamento deve ser preciso para que um projeto seja bem-sucedido. As

estimativas iniciais de um projeto são de alto nível. O seu nível de assertividade vai
aumentando à medida que as incertezas vão sendo esclarecidas. Frequentemente
são usadas nos estágios iniciais do planejamento do projeto e podem determinar
se um projeto será ou não finalizado.
46
FIGURA 25 – EXEMPLO DE PLANEJAMENTO DOS CUSTOS
Nesses 13 blocos disponíveis no PM CANVAS, tivemos uma visão geral do

projeto através de um fluxo de trabalho de concepção. O próximo passo dessa
metodologia é fazer uma análise integrada dos blocos buscando inconsistências.
Após essa análise de consistência, muitas dúvidas ou problemas serão
identificados. O próximo passo é a resolução dessas questões pelo gerente de
projetos. Após esclarecimentos, resoluções e análise coesa, chega o momento de
compartilhar as informações com os envolvidos para o Kickoff do projeto, ou seja,
apresentação do plano de projeto e autorização dos envolvidos para execução.
3.5.3 Execução
Depois de passar com sucesso pela fase de planejamento, chegou a
hora de agir. Como gerente de projetos, você deverá tirar uma fotografia do
seu planejamento que servirá de linha de base ou referência inicial do seu
planejamento antes da execução. A fase de execução do projeto trata de entregas
e saídas como resultado. É aqui que o produto ou serviço pretendido é entregue
ao “cliente” para aprovação.
A fase de execução do projeto geralmente é a fase de maior duração do ciclo
47
de vida do gerenciamento de projetos e consome mais energia e recursos. Nesse

momento, ficará evidente o quão crucial será garantir que seus planos sejam
realistas e realizados com precisão e de preferência com nenhum desvio ou com
mínimo possível. A qualidade do seu planejamento será colocada à prova.
Nessa etapa, o gerente de projetos será desafiado nas suas habilidades

interpessoais. Negociação, mediação de conflitos, desenvolvimento de pessoas,
comunicação (cerca de 90% do tempo de um gerente de projetos será com
comunicação).
Necessidade de mudanças surgirão. E nesse momento, o gerente de

projetos, em conjunto com a equipe, deverá avaliar o impacto das mudanças
em relação à linha de base inicial do seu projeto. Se for escopo adicional, como
impactará o prazo, qualidade, riscos, custos, comunicação, aquisições, partes
interessadas, benefícios, integração e recursos humanos. Você percebe como
uma alteração pode impactar todo seu planejamento? O gerente de projetos
precisa ter uma visão sistêmica do projeto e fazer o controle integrado de
mudanças adequadamente.
Costumamos trabalhar com quadros do tipo Kanban. Os quadros Kanban

são uma visualização de tarefas que ajudam as equipes a ver o que está em
andamento e o quanto de trabalho restante precisa avançar para concluir um
projeto.
Ao aplicar a abordagem Kanban ao gerenciamento de projetos, o fluxo de

trabalho se torna totalmente transparente e visual. Cada membro da equipe pode
ver quem trabalha em uma tarefa específica, no que está sendo trabalhado e
assim por diante. Como resultado, suas equipes podem se concentrar nas tarefas
certas e você não excederá a capacidade delas.
Crie um quadro Kanban, físico ou virtual, para visualizar tarefas. Neste ponto,
apresentamos o projeto e as tarefas associadas. Você criará uma coluna para
cada um dos seguintes itens: para fazer, em andamento e concluído.
Post-its em um quadro branco ou uma folha de flip chart são ferramentas

populares para fluxos de trabalho Kanban. Primeiro, você pega um post-it, move-o
de “para fazer” para a coluna "em andamento" e depois começa a trabalhar.
Quando terminar, mova novamente o post-it para "concluído".
48
FIGURA 26 – QUADRO KANBAN TRADICIONAL
FONTE: <https://www.gradusct.com.br/kanban/>. Acesso em: 4 mar. 2020.
Toda a equipe participa até que as tarefas acordadas estejam todas na

coluna "concluída".
Kanban é uma disciplina à parte. É uma ferramenta muito poderosa para

gestão de fluxo de trabalho e possui uma abrangência e modelagens distintas
para cada contexto. Trouxemos como exemplo para ajudá-lo a inovar na forma
como você acompanha os seus projetos.
Não é porque uma solicitação de mudança foi feita, que ela deverá ser
executada. Primeiramente, você deve analisar os impactos no projeto e nos seus
objetivos.
3.5.4 Monitoramento e controle

Como o próprio nome sugere, essa etapa consiste em monitorar e
controlar o trabalho do projeto. Acompanhar, revisar e relatar o progresso para
atender aos objetivos de desempenho definidos no plano de gerenciamento do
projeto.
Vamos compreender a diferença entre monitoramento e controle:
49
QUADRO 2 – DIFERENÇA ENTRE MONITORAMENTO E CONTROLE
FONTE: O autor
Monitorar: coletar dados de desempenho do projeto em relação a um plano,

produzir medidas de desempenho, relatar e divulgar informações de desempenho
do projeto.
Controlar: comparar o desempenho real com o desempenho planejado,

analisando variações, avaliando tendências para efetuar melhorias no processo,
avaliando possíveis alternativas e recomendando as ações corretivas apropriadas,
conforme necessário.
As entradas para comparar o desempenho real do projeto com o desempenho

planejado são o plano de gerenciamento do projeto ou plano de projeto e
as informações de desempenho do trabalho realizado. As informações de
desempenho do trabalho são comparadas com a linha de base inicial do projeto e
os limites de variação acordados e documentados no plano de gerenciamento do
projeto.
3.5.5 Encerramento
Fechar um projeto não é como desligar um interruptor. Ainda há muito a ser
feito e muita coisa pode dar errado.
50
FIGURA 27 – CUIDADOS NO ENCERRAMENTO DE PROJETOS
FONTE: <https://pmkb.com.br/artigos/cuidados-na-etapa-de-
encerramento-de-empreendimentos/>. Acesso em: 7 mar. 2020.
O processo encerrar projeto ou fase é outro em que o gerente do projeto

assume o protagonismo e verifica se todo o trabalho do projeto foi concluído e
se o projeto atingiu seus objetivos, incluindo trabalho e objetivos que foram
adicionados ao longo do caminho como resultado de solicitações de mudanças
aprovadas.
Apenas um lembrete: o tipo de "fase" mencionado aqui é um miniprojeto

dentro do projeto principal. As atividades necessárias para o encerramento
administrativo do projeto ou fase incluem ações e atividades necessárias para
atender aos critérios de conclusão ou saída da fase ou do projeto, como:
• Garantir que todos os documentos e entregas estejam atualizados e que

todos os problemas sejam resolvidos.
• Confirmação da entrega e aceitação formal de entregas pelo cliente.
• Garantir que todos os custos sejam apropriados corretamente no projeto.
• Fechamento de contas do projeto.
• Liberação de pessoal.
Dependendo do tipo de organização, a equipe do projeto será designada para

outro projeto, ou eles retornarão as suas atividades habituais, ou seus contratos
serão finalizados e deixarão a organização para assumir o cargo.
51
Lidar com o excesso de material do projeto pode significar lidar com os

materiais e equipamentos existentes após o término do projeto. Por exemplo,
após a conclusão de um edifício, haverá pilhas de tijolos, areias, telhas, pedaços
de madeira, sacos de cimento e assim por diante. Tudo isso precisa ser tratado.
Alguns itens podem ser devolvidos ao estoque, as máquinas serão devolvidas à
loja ou devolvidas à empresa contratada e o material que não puder ser reutilizado
ou reciclado, deve ser retirado. O gerente de projeto deve levar em consideração
que as ações abaixo precisam ser realizadas na conclusão de um projeto ou fase.
Fique atento à:
• Realocação de instalações, equipamentos e outros recursos do projeto.

Para onde o material utilizado no projeto deverá ser direcionado após
o seu término? Para onde os profissionais que atuaram no projeto
precisarão atuar? São pontos que o gerente de projetos deverá levar em
consideração quando o projeto estiver sendo concluído.
• Elaboração dos relatórios finais do projeto, conforme exigido pelas
políticas organizacionais e legislação. Fique atento ao refletir o progresso
do projeto em relação às linhas de base. Os relatórios finais deverão
apresentar o quanto variamos em torno do planejado em relação aos
custos, prazo, qualidade e escopo.
Como gerente de projetos, você deve executar as atividades relacionadas à

conclusão dos acordos contratuais aplicáveis ao projeto ou fase do projeto.
A próxima atividade é “Confirmando a aceitação formal do trabalho”. Se o

trabalho não estiver dentro do padrão acordado, o fornecedor deve trazê-lo até o
padrão acordado. Geralmente, essa é uma área controversa, com o fornecedor
tentando cobrar pelo retrabalho como um "aprimoramento". É aqui que você
precisa ser o mais claro possível sobre os requisitos de escopo, benefícios e
qualidade.
Mas você não consegue pensar em tudo! Por exemplo, em um projeto que
estávamos gerenciando, para produzir um novo sistema de gestão empresarial
(ERP), uma das funções necessárias do sistema de contas a pagar, era pagar
contratados no final de cada mês pelo trabalho que haviam realizado durante o
mês. Testamos o módulo várias vezes. Alguns bugs foram descobertos, mas o
programador os corrigiu.
Em um teste em larga escala de todo o sistema, descobrimos que, se um

contratado não tivesse horas faturáveis durante o mês, o sistema processaria um
pagamento por zero real e tentaria fazer um pagamento com zero real. Relatamos
isso ao programador como um bug óbvio. Sua resposta foi: “É um aprimoramento.
Você não especificou que não deseja que o sistema faça pagamentos em dólar
52
reais por nenhum trabalho realizado”. Portanto, nunca assuma que o "bom senso"
ou o “óbvio” se aplica aos contratos.
Finalizando reivindicações em aberto. Foi aqui que você fez uma reclamação
contra um fornecedor por um trabalho que você acredita ser abaixo do padrão,
mas o fornecedor está discutindo o caso. Ou pode ser que as penalidades
incorporadas no contrato tenham sido acionadas. Por exemplo, pode haver uma
penalidade no contrato se o fornecedor não atender a determinados marcos. Mas
descobrimos na prática que as cláusulas penais raramente funcionam, e tentar
argumentá-las pode fazer com que o fornecedor pare de trabalhar. E se for para
uma esfera jurídica, você terá custos maiores do que o previsto.
Atualização de registros para refletir os resultados finais e arquivar essas

informações para uso futuro. Além de ser uma coisa sensata a ser feita, a maioria
dos países possui leis para garantir que os registros comerciais sejam mantidos e
armazenados com segurança.
Estamos examinando as atividades necessárias para o encerramento

administrativo de uma fase do projeto. Isso também incluiria:
• Coletar registros de projeto ou fase.

• Auditar o sucesso ou fracasso do projeto.
• Gerenciar compartilhamento e transferência de conhecimento.
• Identifique as lições aprendidas.
Observe que você deve registrar as lições aprendidas à medida que são
aprendidas, em vez de esperar até o final, por que as esquecerá.
Arquive informações do projeto para uso futuro pela organização. Ações

e atividades necessárias para transferir os produtos, serviços ou resultados do
projeto para a próxima fase ou produção e/ou operações. O objetivo principal do
projeto é criar um produto, serviço ou resultado exclusivo, mas isso significa que
você precisa entregá-los. Na maioria dos projetos, a entrega será concluída e
entregue ao longo do projeto, em vez de fazer tudo de uma só vez.
O único problema é que você pode descobrir uma falha grave, anteriormente
não detectada, nos estágios finais do projeto. Este é um momento muito ruim para
descobrir uma falha grave. Outro ponto é a gestão de mudanças que deve levar
em consideração a transição do projeto para a produção e/ou como a instituição
deixará de usar o velho para usar o novo.
Coletar sugestões para melhorar ou atualizar as políticas e procedimentos da

organização e enviá-las para a unidade organizacional apropriada. Provavelmente,
53
isso se sobrepõe às lições de aprendidas registradas. Lembre-se de ser o mais

específico e focado possível. Use métricas sempre que possível, porque se você
não puder mensurá-lo, não poderá saber se foi melhorado.
Medindo a satisfação das partes interessadas. O processo encerrar o projeto

ou fase também estabelece os procedimentos para investigar e documentar os
motivos das ações tomadas se um projeto for encerrado antes da conclusão.
Para conseguir isso com êxito, o gerente de projeto precisa envolver todas as
partes interessadas apropriadas no processo. Nossa maneira preferida de fazer
isso é através de questionário e pesquisa. E "não", questionário e pesquisa não
significa a mesma coisa. O questionário é a folha de perguntas e respostas, e
uma pesquisa é uma ferramenta para analisar os resultados.
Vale ressaltar que um projeto somente está concluído quando o seu produto
final foi concluído e entregue. A etapa de encerramento, assim como todas as
atividades administrativas necessárias, é fundamental para a conclusão do
projeto.
Celebrar é muito importante! Conversar sobre os aprendizados e lições

durante o projeto é algo fundamental para tornar o conhecimento fluído entre
os membros da equipe. Lembre-se, mesmo se o projeto não for concluído com
sucesso, faz-se necessária essa conversa para entender os motivadores e o que
poderia ter sido feito de diferente. Só assim você desenvolverá a competência de
um bom gestor de projetos.
1) Você conversou com seu superior sobre uma oportunidade

de inovação no seu departamento. Essa inovação vai reduzir
tempo na execução dos projetos e vai eliminar desperdícios nas
atividades operacionais do seu setor. Mediante interesse no seu
projeto, ele lhe pede para estruturar essa proposta de projeto,
pois ele levará para aprovação do comitê de projetos. Qual
documento você deverá preencher?
a) ( ) Termo de abertura do projeto.

b) ( ) Business Case ou Caso de Negócio.
c) ( ) Plano de Projeto.
d) ( ) Um plano de ação (O que? Por que? Quem? Como? Quando?
Quanto?).
54
2) O projeto foi autorizado pelo patrocinador. Ele deverá assinar um

documento que autoriza o projeto e lhe dê autorização formal
para o papel. Que documento seria este?
a) ( ) Business Case ou Caso de Negócio.

b) ( ) Plano de Projeto.
c) ( ) Estudo de viabilidade do projeto.
d) ( ) Termo de abertura do projeto.
4 ALGUMAS CONSIDERAÇÕES
O estudo da gestão de projetos é uma jornada. O objetivo deste curso é trazer
de forma prática a sua aplicação, assim como os conceitos fundamentais para o
seu entendimento. Existem cursos de pós-graduação, MBAs em gerenciamento
de projetos com mais de 400h de carga horária, o que, de certa forma, mostra
a sua extensão e profundidade. Esperamos que você tenha compreendido os
fundamentos da gestão de projetos e que seu conhecimento tenha expandido
para maior entendimento sobre o assunto.
No Capítulo 2, você estudará as dez áreas de conhecimento, segundo

o guia PMBOK® (2017) e entenderá melhor o ciclo de vida do projeto e como
explorar através das ferramentas e técnicas como planejar, executar e monitorar
projetos adequadamente. Será um conteúdo que complementará este capítulo e
aumentará sua competência em gestão de projetos.
REFERÊNCIAS
AACE – Associação para o Desenvolvimento da Engenharia de Custos. Página
inicial. 2020. Disponível em: http://brasil-aacei.org/. Acesso em: 10 mar. 2020.
ABIDI, S.; JOSHI, M. The VUCA Company: How Indian companies have faced
Volatility, Uncertainty, Complexity & Ambiguity. 1. ed. Jaico, 2015.
AGILE MANIFESTO. Manifesto para desenvolvimento ágil de software. 2001.

Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso em: 10
mar. 2020.
55
ANDERSON, D. J. Kanban: Mudança Evolucionária de Sucesso para seu

Negócio de Tecnologia. 1. ed. São Paulo: Martins Fontes, 2011.
BERMAN, C. História do método Critical Path. AZCentral. 2019. Disponível
em: https://yourbusiness.azcentral.com/history-critical-path-method-24351.html.
Acesso em: 10 mar. 2020.
BROWN, T. Design Thinking. 1. ed. Rio de Janeiro: Campus, 2009.
CARNEIRO, M. F. S. Gestão Pública: o papel do planejamento estratégico,

gerenciamento de portfólio, programas e projetos e dos escritórios de projetos na
modernização da gestão pública. Rio de Janeiro: Brasport, 2010.
CAROLI, P. Lean Inception: como alinhar pessoas e construir o produto certo. 1.

ed. São Paulo: Editora Caroli, 2018.
CAROLI, P. Direto ao Ponto. São Paulo: Casa do Código, 2017.
CHIAVENATO, I. Administração: Teoria, Processo e Prática. 2. ed. São Paulo:

Makron Books, 1994.
CHIU Y. C. Uma introdução à história do gerenciamento de projetos: dos

tempos mais remotos até o ano de 1900. Eburon Academic Publishers, 2010.
CORREIA, F.; ABREU, A. Uma visão geral da cadeia crítica aplicada ao

gerenciamento de projetos. Researchgate. 2011. Disponível em: https://www.
researchgate.net/publication/289770682_An_overview_of_Critical_Chain_
applied_to_Project_Management. Acesso em: 10 mar. 2020.
DEPARTAMENTO DE DEFESA ESTADOS UNIDOS DA AMÉRICA. Manual de

Estrutura Analítica do Projeto. 1998. Disponível em: https://web.archive.org/
web/20041015081401/http://www.acq.osd.mil/pm/newpolicy/wbs/mil_hdbk_881/
mil_hdbk_881.htm. Acesso em: 10 mar. 2020
ENDEAVOR. 5W2H: é hora de tirar as dúvidas e colocar a produtividade no seu

dia a dia. 2020. Disponível em: https://endeavor.org.br/pessoas/5w2h/. Acesso
em: 10 mar. 2020.
ESPINHA, R. Ciclo de vida de um projeto. Artia. 2020. Disponível em: https://

artia.com/blog/ciclo-de-vida-de-um-projeto/. Acesso em: 25 fev. 2020.
EVM – Earned Value Management. 20018. Disponível em: http://acqnotes.com/

wp-content/uploads/2014/09/DoD-Earned-Value-Management-Interpretation-
Guide-Jan-2018.pdf. Acesso em: 10 mar. 2020.
56
EXÉRCITO BRASILEIRO. Diretriz do Comandante do Exército.

2019. Disponível em https://www.eb.mil.br/documents/10138/9474894/
DIRETRIZ+DO+COMANDANTE+DO+EX%C3%89RCITO+2019+OTIMIZADO.
pdf/eca42421-8af4-ddfa-e94a-0572f280c37b. Acesso em: 1 jun. 2020.
FINOCCHIO JR., J. Project Model Canvas. São Paulo: ALTA BOOKS, 2013.
GÖDEL, K. F. Acerca das Proposições Formalmente Indecidíveis dos Principia

Mathematica e Sistemas Correlatos. In: LOURENÇO, M. (org.). O Teorema de
Gödel e a Hipótese do Contínuo. Lisboa: Fundação Calouste Gulberkian, 1977.
GOLDRATT, E. M. Corrente crítica: Teoria das Restrições (TOC) em gestão de

projetos. São Paulo: Nobel, 2014.
GOLDRATT, E. M.; COX, J. A meta: um processo de melhoria contínua. 2. ed.

Nobel, maio 2014.
GP3. O que é análise de valor agregado em gestão de projetos. 2020. Disponível

em: https://www.gp3.com.br/artigo/181-o-que-e-analise-de-valor-agregado-em-
gestao-de-projetos/. Acesso em: 29 fev. 2020.
GUIA PMBOK®. A Guide to Project Management Body of Knowledge – GUIA

PMBOK® ® Guide. 6. ed. Project Management Institute – PMI®, 2017.
IPMA – Secretaria Central da Associação Internacional de Gerenciamento de

Projetos. 2020. Página inicial. Disponível em: https://www.ipma.world/. Acesso
em: 10 mar. 2020.
KANBAN. 7 razões irresistíveis para implantar rápido. GradusCT Certificação

internacional de Belts, Executivos e Champions. 2020. Disponível em: https://
www.gradusct.com.br/kanban/. Acesso em: 4 mar. 2020.
MCGRECOR, J., S.; BLISS, G. R. Department of Defense Earned Value

Management System Interpretation Guide. Department of Defense United States
of America. Fevereiro, 2018.
MEADOWS, D. H. Thinking in Systems. 1. ed. Vermont, 2008.
MINISTÉRIO DA DEFESA EXÉRCITO BRASILEIRO ESTADO-MAIOR DO

EXÉRCITO. Normas para elaboração, gerenciamento e acompanhamento de
projetos no Exército Brasileiro. 2. ed. 2013. Disponível em: http://www.epex.
eb.mil.br/images/pdf/documentos_download/nega-peb.pdf. Acesso em: 29 fev.
57
2020.
MULCAHY, R. Preparatório para o Exame de PMP. 6. ed. RMC Publications,

2009.
OGC – Office of Government Commerce. Gerenciando Projetos de Sucesso

com Prince2. Londres: TSO, 2011.
OHNO, T. O Sistema Toyota de Produção: Além da Produção em Larga Escala.

Porto Alegre, 1997.
OSINGA, F. P. B. Science, Strategy and War – The strategic theory of John

Boyd. 1. ed. New York: Routledge, 2007.
PERIARD, G. Tudo sobre a Administração Científica de Taylor. Sobre

Administração. 2017. Disponível em: http://www.sobreadministracao.com/tudo-
sobre-a-administracao-cientifica-de-taylor/. Acesso em: 10 mar. 2020.
PMI – Project Management Institute. Sobre nós. 2020. Disponível em: https://
www.pmi.org/about. Acesso em: 24 fev. 2020.
PMI – Project Management Institute. Página inicial. 2020. Disponível em: https://
www.pmi.org/brasil. Acesso em: 10 mar. 2020.
PMKB. Cuidados no encerramento de projetos. 2014. Disponível em: https://

pmkb.com.br/artigos/cuidados-na-etapa-de-encerramento-de-empreendimentos/.
Acesso em: 10 mar. 2020.
PROJECT BUILDER. Como fazer um business case eficiente do seu projeto.

2019. Disponível em: https://www.projectbuilder.com.br/blog/como-fazer-um-
business-case-eficiente-do-seu-projeto/. Acesso em: 10 mar. 2020.
PROJECT BUILDER – Gerenciamento de Projetos. Você sabe o que é

Fast Tracking? 2017. Disponível em: https://www.projectbuilder.com.br/
blog/voce-sabe-o-que-e-fast-tracking/. Acesso em: 24 fev. 2020.
PROJECT MODEL CANVAS. 2017. Disponível em: http://pmcanvas.com.

br/livro/. Acesso em: 3 mar. 2020.
RIBEIRO, R. L. O. Gerenciando Projetos com Prince2. Rio de Janeiro:

Brasport, 2011.
RICHARDS, C. Certain to Win – The strategy of John Boyd, Applied to
58
Business. 1. ed. Indiana: Xlibris, 2004.
SCRUM ORG. 2020. Disponível em: https://www.scrum.org/resources/

what-is-scrum. Acesso em: 24 fev. 2020.
SENGE, P. M. A Quinta Disciplina: arte e prática da organização que

aprende. 23. ed. Rio de Janeiro: Best Seller, 2013.
SMITH, D. O Empire State Building. Historic Projects. 2019. Disponível

em: https://www.historicprojects.com/The_Empire_State.html. Acesso em:
10 mar. 2020.
SOUSA, R. A Grande Pirâmide de Gizé. História do Mundo. 2020.

Disponível em: https://www.historiadomundo.com.br/egipcia/a-grande-
piramide-de-gize.htm. Acesso em: 24 fev. 2020.
SUTHERLAND, J. SCRUM: a arte de fazer o dobro do trabalho na

metade do tempo. 2. ed. Lisboa: LeYa, 2016.
TAKEUCHI, H.; NONAKA, I. The New Product Development Game

Harvard Business Publishing. 1986. Disponível em: https://hbr.
org/1986/01/the-new-new-product-development-game. Acesso em: 24 fev.
2020.
TALEB, N. N. Antifrágil – Coisas que se beneficiam com o caos. 5. ed.

Rio de Janeiro: Best Business, 2017.
TALEB, N. N. A lógica do Cisne Negro – Impacto do altamente

improvável. 9. ed. Rio de Janeiro: Best Business, 2015.
UVAGPCLASS. Matriz de Priorização de Projetos. 2017. Disponível

em: https://uvagpclass.wordpress.com/2017/11/25/matriz-de-priorizacao-
de-projetos-2/. Acesso em: 24 fev. 2020
WESTLAND, J. História do Gerenciamento de Projetos. Project

Manager. 2020. Disponível em <https://www.projectmanager.com/blog/
history-project-management>. Acesso em: 24 fev. 2020.
59
60
C APÍTULO 2
Principais Áreas de Conhecimento
de Gerenciamento de Projetos

• apresentar e explicar as dez áreas de conhecimento de gerenciamento de

projetos;
• criar a narrativa de ligação entre as áreas de conhecimento de gerenciamento

de projetos e sua aplicação prática.
62
Capítulo 2 Principais Áreas de Conhecimento de
No capítulo anterior, estudamos que um projeto é um esforço temporário
empreendido para criar um produto ou serviço único. Com essa característica
específica, sua estrutura de informação, organização, controle e divulgação
necessita de cuidados especiais. Muitos princípios que serão discutidos neste
capítulo também existem na gestão de processos contínuos de produtos ou
serviços, o que diferencia no contexto do gerenciamento de projetos é a sua
utilização e intensidade nas fases do seu ciclo de vida.
Utilizaremos o GUIA PMBOK 6ª edição como principal base de conhecimento,

mas também utilizaremos princípios e conceitos que hoje influenciam a gestão
de projetos. O PMI, que é responsável pela gestão e desenvolvimento do GUIA
PMBOK ®, sempre tem como foco, ao lançar uma nova versão, estar alinhado
às práticas aplicadas em projetos de vários segmentos, em organização de
tamanhos variados e de continentes e países diferentes. Na 6ª edição, a influência
das práticas ágeis e seus frameworks mais populares (SCRUM, Xtreme Program,
SAFe, entre outros), além de outros conhecimentos agregados que influenciaram
a forma de pensar e organizar projetos (Lean Thinking, Toyota Production System,
Método Kanban, entre outros) estão incorporados às boas práticas dos processos
de gerenciamento e serão destacadas no decorrer do capítulo.
As áreas de conhecimento do gerenciamento de projetos são divisões com

dez áreas conforme a visão do GUIA PMBOK® 6ª edição. São elas:
4. Gerenciamento da Integração do Projeto.

5. Gerenciamento do Escopo do Projeto.
6. Gerenciamento do Cronograma do Projeto.
7. Gerenciamento dos Custos do Projeto.
8. Gerenciamento da Qualidade do Projeto.
9. Gerenciamento dos Recursos do Projeto.
10. Gerenciamento da Comunicação do Projeto.
11. Gerenciamento dos Riscos do Projeto.
12. Gerenciamento das Aquisições do Projeto.
13. Gerenciamento das Partes Integradas do Projeto.
A numeração que foi colocada à frente das áreas de conhecimento segue

os capítulos que estão descritos no GUIA PMBOK® 6ª edição. Para auxiliar os
estudos, indicamos a leitura desses capítulos em paralelo com esse texto, por
complementar a compreensão. As áreas de conhecimento englobam 49 processos
que ocorrem durante o ciclo de vida do projeto, viabilizando a sua gestão para
atingir o(s) seu(s) objetivo(s).
63
Um ponto importante que precisa estar claro para quem está gerenciando
um projeto é que o GUIA PMBOK® não é uma metodologia, confusão de
interpretação que muitas vezes ocorrem nas organizações, que leva a aplicar
de forma mecânica e processual as áreas de conhecimento e seus processos.
Devemos entender que o gerenciamento de projetos é a capacidade de interpretar
os objetivos de negócio que o projeto pretende atingir. Os processos das áreas de
conhecimento podem ajudar a alcançar esses resultados da forma mais eficaz
dentro da melhor eficiência do trabalho integrado das pessoas, utilizando os
recursos de negócio, financeiros, físicos e intelectuais disponíveis.
Nessa nova edição de 2017 do PMBOK®, a inclusão dos conceitos de

agilidade tem por objetivo deixar mais forte a ideia de que ele é um compêndio de
boas práticas e que sua leitura não deve ser linear, mas uma interpretação dentro
do contexto que seu projeto está inserido. Devemos entender que o excesso de
burocracia é um desperdício de tempo. Esse excesso não deve ser medido por
volume de documentações, que também é uma visão muito simplista sobre o
assunto. Podemos entender como burocracia excessiva todo o controle ou etapas
de atividades que não estão agregando valor à entrega final do projeto, por
exemplo, a construção de uma plataforma de petróleo marítima continuará com
todas as suas plantas, controles de segurança e documentações de engenharia
necessária, mas o que é preciso estar claro para o gerente de projetos é evitar
aquilo que não está diretamente focado no resultado, documentos que são
preenchidos para simples arquivos, controles excessivos ou outras formas
de gestão que em uma análise mais profunda não são agregadores para os
resultados.
Podemos olhar um projeto como um sistema que efetua trabalhos de forma

coletiva e integrada para atingir um resultado. Partindo desse entendimento, o
pensamento sistêmico, ideia defendida por Peter Senge em seu livro A Quinta
Disciplina, de 1990, consiste em criar uma forma de analisar e uma linguagem para
descrever e compreender as forças que interagem e modelam o comportamento
dos sistemas. Precisamos olhar as organizações e seus projetos como um
sistema de trabalho para atingir um resultado definido, alinhando e integrando
as informações de vários subsistemas que estão coligados e com dependências
mútuas. Durante muito tempo, a gestão do trabalho ficou focado nas atividades de
forma separada, dando ênfase à especialização em partes do processo. Com a
mudança do cenário atual para contextos mais complexos é necessário entender
o comportamento e resultados do sistema como um todo, pois a identificação de
causa e efeito das ações entre as partes (ou subsistemas) que interagem dentro
e fora dos projetos, propicia uma situação ideal para a aplicação do pensamento
sistêmico.
64
No modelo TPS (Toyota Production System), ao realizar a gestão do sistema

para a sua melhor eficácia, eles perceberam a importância e alto impacto nos
resultados, a eliminação ou minimização dos desperdícios percebidos no
processo. No modelo TPS, os desperdícios são classificados em três grupos.
Apesar de originalmente criados para a gestão de processos produtivos, sua
abrangência assumiu uma atuação muito ampla e o gerenciamento de projetos
pode aproveitar esses princípios:
• MUDA – é o desperdício pela ociosidade no seu sistema de trabalho.

Uma interpretação errada da capacidade de vazão cria uma situação
onde existe folgas e mau dimensionamento do fluxo de trabalho. Em um
projeto, é quando a(s) equipe(s) trabalha(m) abaixo de sua capacidade,
aumentando o prazo de entrega dos projetos, o ciclo entre o começo e o
fim dos processos, custos e outros efeitos prejudiciais.
• MURA – é a variabilidade excessiva do processo de trabalho. Em todo
processo sempre existe algum grau de variabilidade, o que precisa
ser entendida é a tolerância acordada pelas partes interessadas e
a realidade do sistema para trabalhar essa questão. Uma falha de
interpretação que muitas vezes ocorre no gerenciamento de projetos é
a de que mudanças são situações ruins e que devem ser evitadas, essa
é uma visão simplista sobre o assunto e de alto risco. Uma das poucas
certezas em um projeto é que ocorrerão mudanças e a variabilidade será
maior ou menor em cada momento que essas mudanças ocorrerem. O
que precisamos é uma visão sistêmica clara e com ações coordenadas
de adaptação à nova realidade.
• MURI – é a sobrecarga do sistema. Ao gerenciar um projeto, devemos
ter cuidado para não criar situações que provoquem a sobrecarga das
pessoas ou dos recursos alocados. Essas situações podem provocar
problemas como a perda de prazos, aumento dos riscos, queda da
qualidade e outras situações que podem levar a não atingir o resultado
esperado.
Projetos são parte integrante desse sistema organizacional atuando

fortemente para atingir os resultados estratégicos definidos. As áreas do
conhecimento não devem ser pensadas como partes separadas, distintas e
independentes. Elas fazem parte de um sistema de informações que interagem
com outros ambientes complexos. Com essa realidade é necessária a capacidade
de integração da informação e adaptação maior ou menor, dependendo da
realidade organizacional e os resultados esperados para o projeto.
Para um melhor entendimento é apresentado a seguir como as áreas de

conhecimento estão distribuídas no ciclo de vida do projeto:
65
FIGURA 1 – ÁREAS DE CONHECIMENTO DISTRIBUÍDAS NAS FASES DO PROJETO
FONTE: O autor
Essa distribuição segue uma ordem de organização dos processos para

gerar o melhor resultado integrado do trabalho realizado. Esse funcionamento
do sistema de trabalho do projeto não é uma sequência linear de sentindo
único. Essas fases ocorrem em ciclo completo do projeto ou a uma fase
específica, podendo se repetir de forma cíclica e interligada. Então, ao preparar
o planejamento e começar a execução não significa que não ocorrerá ajustes
no planejamento, lembrando que mudanças são uma constante, as revisões e
ajustes em cada fase do projeto para melhoria é algo necessário e indispensável.
Nos modelos de gestão do século XX, em que os processos e forma de

gestão eram baseados no pensamento mecanicista, essas mudanças e alteração
eram situações a serem evitadas, era o conceito que deveríamos manter o
planejamento inicial para o bom desempenho das entregas. Apesar do PMBOK já
indicar em edições anteriores o planejamento em ondas, ou seja, o planejamento
feito conforme o entendimento do projeto e suas necessidades ficam mais
amadurecidas. A leitura mais comum das organizações é a indicada na Figura 2.
66
FIGURA 2 – MODELO DE GESTÃO BASEADO NO

PENSAMENTO MECANICISTA LINEAR
FONTE: O autor
Essa é uma ideia que não condiz com a realidade que vivemos hoje
para a gestão de ambientes complexos, em que o pensamento sistêmico tem
atingido melhores resultados pela sua capacidade de adaptação a mudanças
com respostas rápidas e eficazes em um mercado em constantes mudanças.
Ambientes complexos são sistemas de interações de atividades e pessoas onde
mudanças e incertezas envolvidas sempre estão trazendo novas variáveis e a
necessidade de ajustes constantes para adaptação, conforme Figura 3.
FIGURA 3 – MODELO DE GESTÃO BASEADO NO

PENSAMENTO SISTÊMICO ADAPTATIVO
FONTE: O autor
Um fator inerente a esse tipo de ambiente é a aleatoriedade, que implica

em maior dificuldade de trabalhar com conceitos determinísticos de resultados.
No gerenciamento de projetos, as áreas de conhecimento podem ser entendidas
como uma forma de auxiliar a identificação e adaptação dessas aleatoriedades
baseadas em dados e fatos coletados antes e durante os processos do sistema
de trabalho. Veja que devemos manter o planejamento inicial do projeto, criando
as documentações no formato que mais estiver adaptada às necessidades
e contexto do projeto. Acreditar que esse planejamento é algo fixo e deve ser
mantido até o final sem modificação é uma visão incompatível com a realidade
67
dinâmica da atualidade. Efetuar ações para evitar essas mudanças, sem entender
as novas variáveis que entraram no contexto, é uma ação que aumentará a
possibilidade de a entrega final do projeto (mesmo dentro do prazo, custo, escopo
e qualidade) não atender o seu objetivo.
Para melhor entendimento, seguiremos os capítulos que o Guia PMBOK®

6ª edição utiliza para cada área de conhecimento. Estudaremos as áreas de
conhecimento, observando seus processos e as fases do ciclo de vida do projeto
que interagem, compreendendo ligações e interações. A leitura do Guia PMBOK®
como base para descrição detalhada de cada processo com suas entradas e
saídas é importante para criar uma base de conhecimento teórico dentro da visão
do PMI. Em nossos estudos, observaremos a interligação com outros ramos do
conhecimento, teorias de gestão, metodologias e outras influência internas e
externas nos projetos.
2 GERENCIAMENTO DA
INTEGRAÇÃO DO PROJETO
Como foi explicado anteriormente, precisamos pensar os projetos como um
sistema com interações com vários ambientes. O gerenciamento da integração
é a área de conhecimento que tem essa especialização de unir em uma visão
sistêmica as informações e conhecimentos das outras áreas de conhecimento
e criar a sinergia necessária para a obtenção de um resultado único e alinhado
ao propósito ao qual o sistema se destina. A Dra. Donella H. Meadows, em seu
livro Thinking in System (2008), define um sistema como sendo “um conjunto de
elementos interconectados e coerentemente organizado para se alcançar algo”
(MEADOWS, 2008, p. 11). Essa visão consegue sintetizar muito bem o porquê
um sistema existe, a interação entre as partes sempre busca algum objetivo. Um
projeto sendo pensado como um sistema precisa ter claro qual é o seu objetivo
e ser capaz, ao longo de sua construção, identificar as mudanças que estão
ocorrendo e realizar as adaptações necessárias.
68
FIGURA 4 – PROCESSOS DE INTEGRAÇÃO AO LONGO DAS FASES DO PROJETO
FONTE: O autor
Ao trabalhar com o conceito de adaptação em ambientes complexos nas

fases iniciais do projeto é importante estar entendido, por todos os envolvidos,
que o entendimento das informações disponíveis possui um grau de maturidade
baixa com uma visão distorcida das variáveis envolvidas, então podemos
dizer que, inicialmente, o que temos são hipóteses, ideias que pretendemos
aplicar com maior ou menor grau de confiança, para ao final de um processo
de interações, avaliar se o resultado atingiu seu objetivo, que é a validação da
hipótese. Esse processo, quanto mais longo, mais demorada será a validação de
nossas hipóteses de planejamento, então novas práticas e conceitos estão sendo
aplicados para diminuir esse ciclo, criando o que podemos chamar de redução
do ciclo de feedback para validação de hipótese. Esse conceito tem se mostrado
necessário pelos estudos realizados nas últimas décadas, comprovando que
muitas situações de desalinhando entre a velocidade das mudanças e adaptação
dos projetos é uma das principais causas de fracassos. A Dra. Meadows (2008,
p. 15) também identifica outros problemas que podem afetar um sistema: “Um dos
aspectos mais frustrantes dos sistemas é que os propósitos individuais de cada
elemento podem se combinar e gerar um comportamento do todo que nenhum
desses elementos gostaria que ele tivesse”.
Observar as partes de forma separada não melhora a eficácia da análise

das ações, pois essa forma de gestão cria um distanciamento prejudicial para o
entendimento do resultado. Quando o gerenciamento de projetos foi estruturado
pela primeira vez, como uma maneira de efetuar a gestão de trabalhos
temporários com resultados únicos e com um começo e fim definidos, as
organizações ainda estavam presas aos conceitos da gestão de planejamentos
de longo prazo, procurando evitar as variações e avaliando os resultados
somente no final, observando se as entregas correspondiam ao planejamento, o
foco estava nas entregas realizadas (outputs). Hoje, esse modelo não consegue
dar respostas satisfatórias à velocidade da era digital, com ambientes cada vez
69
mais dinâmicos, com interações e resultados mais suscetíveis à aleatoriedade,

a avaliação de sucesso de um projeto precisa estar vinculada aos resultados
alcançados, considerando as mudanças de contexto entre o início e o fim do
projeto (outcomes).
Muitas organizações estão enfrentando essa quebra de paradigma.

Independentemente do tamanho da sua estrutura ou segmento, o como lidar
com esse novo ambiente altamente volátil, incerto, complexo e ambíguo está na
capacidade de trabalhar com ciclos mais curtos entre a hipótese criada e a sua
validação, diminuindo os riscos inerentes a mudanças tardias ou não realizadas o
mais cedo possível no projeto, onde os custos, prazos e muitas vezes a imagem
da equipe, do gerente de projetos ou da organização responsável serão muito
mais prejudicadas.
Pensar em ciclos mais curtos de interação e validação de hipóteses

implementadas tem forte influência dos conceitos de agilidade, lean thinking,
método Kanban, Scrum e tantos outros frameworks e métodos que têm como
pensamento central reduzir esse ciclo de feedback. O gerenciamento de projetos
pode usar esses conhecimentos e práticas para fortalecer os seus resultados. O
gerenciamento da integração do projeto é que ajudará a todos os envolvidos a
compreender o que ocorreu, agir sobre as situações que estão acontecendo e
projetar possíveis cenários futuros.
A integração do projeto é a área de conhecimento por excelência que

o gerente de projetos demonstrará suas principais habilidades (skills) de
comunicação, agregar pessoas, liderança, organização e atitude perante os
desafios do projeto. Mais que simplesmente monitorar, controlar, organizar o
trabalho e criar uma montanha de documentos e comunicados, o gerente de
projetos deve ser a pessoa que une todos os interesses envolvidos com o projeto
e auxilia o alinhamento de todos para atingir um resultado esperado.
Vejamos os processos que são descritos no Guia PMBOK® para facilitar

esse entendimento.
2.1 DESENVOLVER O TERMO DE

ABERTURA DO PROJETO
Ao iniciar um projeto ou fase é necessário definir os seus primeiros
parâmetros, acordos, entendimento dos envolvidos, entre outras observações,
mas a principal é entender as seguintes perguntas: Qual é o objetivo que o projeto
70
pretende atingir? Qual é o resultado de negócio que pretendemos alcançar?
O termo de abertura é uma maneira de organizar o começo dos trabalhos do

projeto, ele é a primeira providência que precisa ser realizada. Muitas organizações
possuem formulários padrões ou normas específicas de como começar um
projeto e os processos que estão envolvidos. Essa atividade poderá ser realizada
de forma satisfatória através de leitura dos processos organizacionais ou apoio de
alguém com mais experiência. O gerente de projetos precisa estar preparado para
lidar com o que não está escrito no processo, os alinhamentos entre as pessoas
e o entendimento de uma forma mais ampla da realidade que está envolvida com
esse novo projeto ou fase em andamento.
O matemático Kurt Gödel, em seu segundo teorema da incompletude, através

de um conjunto de axiomas, explica que a consistência de um sistema não pode
ser provada no próprio sistema (GÖDEL, 1977). Ampliando essa visão para outros
ramos do conhecimento, além da matemática, podemos entender que nunca
teremos uma visão completa de tudo, temos limitações para a nossa capacidade
de entendimento de algo e que nossa avaliação sempre estará baseada em parte
da realidade que observamos. O gerente de projeto precisa criar mecanismos e
usar técnicas em que ele possa agrupar o máximo de pessoas com interesses
sobre o projeto para ampliar a capacidade de observação do que está envolvido
e integrar essas visões criando uma hipótese de planejamento mais consistente
possível, entendendo que essa é a primeira de várias interações que ocorrerão,
sempre procurando amadurecer o entendimento e expectativas com o resultado
a ser atingido.
Lembrando sobre a burocracia como fonte de desperdício, o termo de

abertura deve ser um documento objetivo, de linguagem clara e direta. Ele é o
resultado de uma visão de alto nível sobre o que será o projeto, não é seu objetivo
ser uma documentação definitiva.
Existem muitas técnicas que podem auxiliar a construção desse documento,

o gerente de projeto pode ser aquele que cria uma narrativa de uma visão que
um grupo de envolvidos apresentou, discutiu e chegou a uma definição comum.
Muitos projetos que fracassam ou atingem resultados decepcionantes não deram
a importância necessária para essa ampliação e alinhamento de expectativas e
entendimentos das partes interessadas (stakeholders) no início do projeto.
Uma técnica que pode ser utilizada nessa fase para esclarecer o verdadeiro
porquê do projeto é o Design Thinking. É uma técnica com foco em entender e
se aprofundar na resolução de um problema e de forma colaborativa e empática
achar uma proposta de solução. Geralmente, um projeto é a resolução de
algum problema ou oportunidade que foi identificado e que precisa de uma ação
71
coordenada para sua implementação, se houver uma interpretação errada ou

limitada nesse momento, podemos alocar pessoas e recursos que não estarão
focados no verdadeiro objetivo a ser atingido. O Design Thinking é de grande
ajuda nessa fase como uma fonte de informações, expectativas e mapeamento
de pessoas envolvidas e seus interesses. É possível trabalhar com entrevistas
individuais, mas essa prática tem se apresentado com menor eficácia de resultado,
pois somente contribui para a situação onde as visões e entendimentos continuam
isoladas, o que não consegue responder às necessidades de ambientes mais
complexos.
Nessa fase, dependendo do tipo do projeto, a construção de um protótipo

– muito comentada pelos textos mais avançados de Design Thinking e Design
estratégico – pode ser uma solução necessária. O grau de elaboração e
refinamento dependerá do que se quer avaliar, mas o importante é o entendimento
que devemos construir, algo com o mínimo necessário para validar inicialmente
uma ideia. O que pretendemos com esse modelo é criar informações mais claras
para construir um termo de abertura com um entendimento melhor.
Uma opção que muitas equipes estão adotando e que o Guia PMBOK® 6ª
edição inclui é o uso de ferramentas de gestão visual como a ideia de utilizar
canvas (quadros), como por exemplo, o Project Model Canvas, do Professor José
Finocchio Jr. Documentos descritivos são importantes e muitas vezes necessários
por questões de governança corporativa, regras governamentais, entre outras
razões, mas a gestão visual é uma forte aliada na integração das informações por
trabalhar com princípios que ajudam na divulgação, compreensão e transparência
da informação, criando mais engajamento de todos os envolvidos e contribuindo
para a construção das narrativas de documentações que possam ser necessárias,
diminuindo a chance de contradições entre as informações.
2.2 DESENVOLVER O PLANO DE

GERENCIAMENTO DO PROJETO
Desenvolver o plano de gerenciamento de projeto é criar as diretrizes
que orientarão as atividades e práticas de gestão que serão adotas durante a
existência do projeto. Segundo o Guia PMBOK® (2017), o plano de gerenciamento
do projeto deve ser um documento que abrange todo o trabalho e como ele será
realizado no projeto. Seguindo essa definição, precisamos entender um pouco
melhor a questão de ser abrangente.
O plano de gerenciamento é a criação de uma narrativa que torna mais

compreensível todos os aspectos previsíveis que envolvem o projeto com suas
72
ações, acordos, comunicações e procedimentos acordados entre as partes

interessadas mapeadas direta e indiretamente. Veja que destacamos os
aspectos previsíveis e as partes interessadas mapeadas para lembrarmos que,
durante o projeto, ocorreram situações não previstas e novas partes interessadas
que não estavam claras no início dos trabalhos. É muito difícil, ou quase, que
podemos afirmar que seja impossível ter no início do projeto TUDO mapeado
em detalhes para criar um plano completamente abrangente. Entendendo esse
aspecto, fica mais clara a questão de planejamento em ondas e a preocupação
em redução do ciclo entre hipótese e sua validação para efetuar os ajustes
necessários.
Em um projeto, a clareza de seu objetivo deve ser um balizador para as

ações e o plano de gerenciamento deve ser essa referência sobre o que, como,
quando e por que de todas as atividades do projeto.
Para ajudar nessa fase, novamente é interessante trabalhar com práticas

colaborativas para a coleta de informações e alinhamento de expectativas sobre
como será realizado o projeto e seus planos auxiliares baseados nas outras nove
áreas de conhecimento. Uma forma de trabalho muito interessante é a Lean
Inception, desenvolvida por Paulo Caroli (2018).
O conceito é uma variação da Inception, que é a fase inicial da metodologia

RUP (Rational Unificed Process), muito usada na construção de software que foi
criado no início dos anos 1980 e que até hoje é muito aplicado. A ideia inicial
do RUP era fazer os levantamentos para previsibilidade do que seria construído,
levantando aspectos de arquitetura, objetivos e planejamento do projeto, mas com
a evolução de sua aplicação e com a influência de aspectos comportamentais e
a jornada do cliente (influência de design thinking e user centered design), ele
ficou mais amplo, promovendo um encontro onde um grupo de pessoas com
conhecimentos diferentes e complementares contribuem de forma interativa
e com um visão sistêmica no entendimento sobre um produto ou projeto a ser
realizado. O conceito de Lean incorporado é de ser mais enxuto e direto ao ponto
do que realmente quer ser realizado e os principais aspectos que o cercam. Esse
método foi adaptado por Paulo Caroli (2018), em seu livro Lean Inception, o qual
explica em mais detalhes os seus principais aspectos. Para nossos estudos de
gerenciamento de projeto, ele pode ser utilizado como uma forma de criar um
ambiente de coleta de informações, alinhamento de expectativas, entendimento
de aspectos comportamentais, contribuição e comprometimento das partes
interessadas para a construção do(s) objetivo(s) do projeto e o preparo de um
documento de gerenciamento do projeto mais completo e abrangente.
73
2.3 ORIENTAR E GERENCIAR O

TRABALHO DO PROJETO
Esse processo está envolvido diretamente na gestão das atividades e suas
interações, analisando se o plano de gerenciamento do projeto está representando
a realidade do projeto ou se é necessário aplicar ajustes e mudanças. É o
momento de validação das hipóteses definidas no planejamento para o projeto.
Nessa fase, o papel do gerente do projeto tem um forte aspecto de

liderança, indiferente do modelo hierárquico adotado (liderança hierárquica,
situacional, matriz funcional de gestão, entre outras formas e variações). Ele
precisa estar preparado para lidar com os aspectos comportamentais que estão
envolvidos na execução das atividades pela equipe. Estudos indicam que a
maioria dos problemas e fracassos em projetos estão mais ligados a aspectos
comportamentais e sociais do que aspectos técnicos.
Projetos que utilizam conceitos e práticas ágeis têm adotado com muito
sucesso métodos de gestão que têm ajudado na capacidade de se adaptar às
aleatoriedades que os projetos apresentam durante a execução dos trabalhos.
Por exemplo, podemos destacar dois métodos que têm sido aplicados com
resultados bem expressivos: o Scrum e o Método Kanban. Eles nasceram
dentro de organizações de TI, mas a sua aplicação já ultrapassou esses limites
e já é utilizado em equipes de outras áreas e organizações dos mais diversos
segmentos.
Scrum tem como características básicas o trabalho de uma equipe

multidisciplinar com autonomia quanto à forma e organização de suas atividades,
trabalhando em curtos ciclos de construção (de 1 a 4 semanas) que, ao final, o
objetivo é entregar algo que possa ser utilizado pelo cliente e agregue valor as
suas expectativas. Essas informações são trazidas para a equipe por uma pessoa
que exerce o papel de PO (Product Owner), aquele que é a ponte entre o cliente
e a equipe. Esse modelo ajuda na redução dos ciclos de feedback e aproxima
mais o cliente do projeto, criando um engajamento e redução de riscos quanto
a entendimentos contraditórios e seus efeitos no sistema de trabalho do projeto.
Já o Método Kanban tem uma forte influência dos conceitos do TPS

(Toyota Production System, onde nasceu o nome kanban), teoria das restrições
de Goldratt (2014), OODA – Loop de John Boyd (OSINGA, 2007), entre outros
modelos que observam o funcionamento de nossos ecossistemas biológico, social
e organizacional como sistemas integrados, onde a observação do todo supera a
74
observação de uma parte para o entendimento de causa e efeito. Ele foi adaptado
do mundo da manufatura para a gestão do trabalho do conhecimento por David
Anderson (2011), que através do alinhamento dos objetivos, observando o fluxo
atual do trabalho e os problemas que impedem a melhor eficácia e eficiência, os
próprios envolvidos, independentemente do nível hierárquico ou da função que
exerce, pode participar e ter influência sobre as ações de melhorias. O foco está
na gestão do sistema e não nas pessoas, a melhoria tem que ser do sistema
como um todo e não somente de uma de suas partes.
2.4 GERENCIAR O CONHECIMENTO

DO PROJETO
Esse processo foi criado na 6ª edição do Guia PMBOK®, ele vem para
trabalhar com os conhecimentos disponíveis que podem contribuir com projeto,
são boas práticas existentes e novas práticas emergentes que surgirão durante
os trabalhos do projeto.
O conhecimento gerado em outros projetos e durante os trabalhos da equipe

é uma fonte muito rica para melhorar a eficácia dos resultados, a eficiência dos
processos e reduzir a exposição a riscos do projeto.
Não existe uma forma padrão de armazenar esse conhecimento, isso

dependerá de como a organização estrutura sua biblioteca de conhecimentos.
O que precisa estar no centro desse processo é o fato do uso efetivo desse
conhecimento para o auxílio da gestão do projeto. Em muitas organizações, essa
parte do processo é relegada a um segundo plano de importância, são aquelas
atividades que “caso sobrar tempo, iremos fazer”.
Uma prática que ajuda bastante na troca desses conhecimentos e da sua

aplicação nos projetos de uma forma muito mais orgânica e colaborativa é
através das retrospectivas. Equipes que utilizam agilidade já têm essa prática
mais disseminada, são encontros da equipe envolvida com o produto ou projeto
para analisar o que ocorreu no último ciclo de atividade (o tamanho desse ciclo
pode variar conforme a estrutura adotada), verificando aspectos positivos e
negativos, criando ações para maximizar, diminuir ou eliminar essas situações
em um próximo ciclo. Em uma abordagem mais processual dessa prática, ela
geralmente ocorre ao final do projeto, muitas vezes discutindo assuntos que já
passaram semanas ou meses do seu acontecimento para simplesmente alimentar
um banco de informações que pode ou não ser utilizado em um futuro projeto. Em
uma retrospectiva ágil estamos avaliando algo que acontece recentemente e que
gerará uma ação já para o próximo ciclo. Veja que essa abordagem é muito mais
75
marcante por estar falando de algo atual e aplicando uma correção, sendo muito
mais proativo e eficaz no seu resultado.
O gerenciamento do conhecimento é um processo importante para auxiliar

a definição de ações de adaptação do plano de gerenciamento do projeto e de
outras áreas de conhecimento.
2.5 MONITORAR E CONTROLAR O

TRABALHO DO PROJETO
Segundo William Edward Deming (1990, p. 125), “Não se gerencia o que não
mede, não se mede o que não se define, não se define o que não se entende e
não há sucesso no que não se gerencia”. Essa ideia que foi concebida na primeira
metade do século XX continua muito presente na atualidade. O monitoramento
e controle do trabalho tem o objetivo de mensurar, observar, organizar e ser
base para tomada de decisões sobre possíveis melhorias nos processos e a
implementação dessas mudanças, observando sua eficácia para atingir o objetivo
do projeto.
Esse processo, ao mesmo tempo, pode ser uma fonte de desperdícios

muito grande caso não se tenha uma compreensão clara sobre qual o nível de
monitoramento e controle é necessário ao projeto para não criar a burocracia
desnecessária.
Burocracia é toda estrutura organizacional composta de regras e

procedimentos para a gestão do trabalho. Essa estruturação tem por objetivo
diminuir ou eliminar riscos inerentes aos processos de trabalho. O cuidado que
deve ser tomado é não criar burocracia excessiva, com controle que tire toda a
capacidade de adaptação a novas situações, esse quadro é muito comum em
organizações que utilizam modelos de controle e comando com baixa tolerância
a riscos.
Quando trabalhamos com modelos excessivamente controladores, ficamos

muito focados em simplesmente medir a capacidade de o sistema repetir os
procedimentos e metas esperadas, sem efetuar uma análise mais aprofundada,
se os acordos firmados ainda continuam a corresponder à realidade do contexto
do projeto.
Na gestão de ambientes de projetos complexos é importante usar o

monitoramento e controle para a gestão do sistema e não das pessoas. O que
queremos dizer com a afirmação anterior é que no início da administração
76
científica até a virada para o século XXI, a gestão estava muito focada em
controlar a eficiência das pessoas, um olhar voltado para obter o máximo de
resultado individual, esse é um modelo que prioriza a eficiência dos recursos. Com
a evolução da compreensão do pensamento sistêmico e de suas implicações,
fica mais estruturado o entendimento que a soma das partes separadas não
necessariamente gerará o melhor resultado final, o que precisamos é otimizar o
trabalho integrado da equipe, avaliando o resultado da visão do sistema, esse é o
modelo que prioriza a eficiência do sistema.
Então, ao ler o Guia PMBOK® (2017), nesse processo (e todos os outros)

precisamos ter clara a busca do melhor resultado do sistema, monitorando e
controlando o trabalho integrado, avaliando seus impactos e ajustes que possam
ser necessários.
Outro resultado esperado desse processo é apresentar, às partes

interessadas (stakeholders), o andamento e evolução das entregas conforme o
que foi acordado no plano de gerenciamento do projeto e dos planos específicos
das áreas de conhecimento. Essa comunicação sempre deve refletir o que foi
acordado e o que está sendo realizado para a definição dos ajustes onde for mais
eficaz para atingir o objetivo do projeto, mudando os planos ou efetuando ajustes
nos procedimentos adotados. Uma observação importante é a capacidade
do gerente do projeto em realizar essa leitura de forma integrada e ajudar a
todos os envolvidos nos ajustes necessários, nesse momento fica muito claro
quando, durante as fases anteriores de iniciação e planejamento, não houve um
engajamento e envolvimento das partes interessadas e na compreensão de suas
expectativas, pois nas reuniões de monitoramento e controle durante os status
fica perceptível esse desalinhamento por falhas de comunicação durante os
acordos definidos nos planos do projeto.
2.6 REALIZAR O CONTROLE

INTEGRADO DE MUDANÇAS
Esse é momento de avaliar as mudanças que foram identificadas e aplicar ou
não sua implementação. Ele está diretamente influenciado pelo resultado de todos
os processos envolvidos nas fases de planejamento, execução e monitoramento
e controle, não sendo eficaz sua realização quando os processos não estiverem
funcionando de forma integrada e factível com a realidade do contexto atual.
Para a execução desse processo, o gerente de projeto precisa estar

preparado para lidar com diferentes interesses envolvidos e a necessidade de
77
um alinhamento direcionado para a realização do objetivo do projeto. Manter as

discussões e análises baseadas nos fatos apresentados no monitoramento e
controle evitando decisões baseadas em interpretações emocionais, que estão
ligadas diretamente aos paradigmas de pessoas ou grupos. Muitas vezes, essas
situações são desastrosas e é um atributo do gerente do projeto defender os
objetivos definidos.
Ao implementar mudanças no projeto é interessante evitar grandes mudanças

ou várias mudanças de uma só vez. Alterações em um sistema sempre possuem
um percentual de aleatoriedade que precisa ser considerado e observado para
avaliar a sua implementação e se está cumprindo o que se pretendia ao definir
essa mudança. Aqui podemos trazer dois conceitos sobre mudanças que estão
ligadas ao TPS e ao Lean: é o Kaikaku e o Kaizen.
Kaikaku são grandes mudanças revolucionárias que executam alterações

profundas e radicais. Ao aplicar um Kaikaku, devemos estar cientes que
provocarão um alto impacto no sistema do projeto e exigem um cuidado maior,
pois são situações que normalmente têm uma curva profunda para adaptação
até atingir o resultado esperado (Figura 5). Mudanças tão profundas geralmente
aumentam a exposição a riscos, com probabilidade maior de ocorrência pelo
ciclo longo que provavelmente será necessário para implementação e ganho de
produtividade por parte dos envolvidos. A sua implementação em determinados
casos é necessária, mas é cuidado e acompanhamento que consumirá tempo,
recursos, além do desgaste dos envolvidos.
FIGURA 5 – KAIKAKU – GRANDES MUDANÇAS REVOLUCIONÁRIAS
FONTE: O autor
78
Kaizen já segue uma outra linha para mudanças, com alterações

menores e mais gradativas, observando a evolução das mudanças aplicadas e
realizando ajustes para uma nova onda de mudanças (Figura 6). Como estamos
considerando projetos como ambientes complexos, as mudanças evolucionárias
do Kaizen possibilitam uma maior flexibilidade perante as aleatoriedades inerentes
a esses cenários, trabalhando em ciclos mais curtos de feedback. Em situações
que pedem mudanças mais drásticas ou de alguma emergência no projeto, ele
pode não ser o mais indicado, pois sua aplicação através da experimentação
evolucionária não apresenta o efeito de impacto necessário.
FIGURA 6 – KAIZEN – MUDANÇAS EVOLUCIONÁRIAS E GRADATIVAS
FONTE: O autor
2.7 ENCERRAR O PROJETO OU FASE

Ao encerrar um projeto ou fase, o gerente de projetos precisa estar preparado
para verificar se o que está definido no plano de gerenciamento do projeto foi
cumprindo. Mais que uma atividade administrativa é o momento de alinhamento
das percepções sobre a conclusão dos trabalhos de todos os envolvidos com o
projeto e que possuem interesses ligados ao resultado.
A apresentação do resultado final e coleta do aceite formal das entregas

podem ser um momento mais tranquilo e de transição do produto ou serviço
realizado pela equipe do projeto para quem ficará responsável pela sua gestão
79
e manutenção. Mas é comum surgirem surpresas, em sua maioria por falta de

alinhamento sobre expectativas dos resultados, mudanças que ocorreram e não
foram mapeadas, interesses que não foram devidamente tratados durante o
projeto e que no momento do encerramento vem à tona, criando situações de
stress, atrasos, aumento de custos e até inviabilização das entregas.
Tentar tratar essas situações somente na fase de encerramento é um risco

de alto impacto e de grande probabilidade de causar problemas. Devemos pensar
os processos das áreas de conhecimento do projeto não de forma isolada, mas
como uma interligação de causas e efeitos que ocorreram durante todo o ciclo de
vida do projeto ou fase que chegará até o encerramento. O procedimento mais
indicado é os envolvidos estarem concentrados na avaliação da transição das
entregas, de lições aprendidas e novas práticas emergentes, pois os processos
de monitoramento e controle cumpriram a função de retratar os acontecimentos
e efetuar os ajustes acordados. As questões administrativas de encerramento
devem seguir os procedimentos definidos nos processos acordados ou as normas
corporativas vigentes.
O gerente de projetos não deve se descuidar ou menosprezar essa fase,

pois o resultado de um projeto sempre será parte de um processo ou outro projeto
impactando pessoas, organizações e a sociedade. Boas práticas para essa fase
podem ser:
• Seguir os processos definidos pela organização (caso existam).

• Acompanhamento ou feedback de outro gerente de projetos ou do PMO
para aumentar a abrangência do conhecimento sobre essa fase.
• Um checklist para auxiliar a não esquecer nenhuma atividade necessária.
É importante lembrar que essa lista precisa estar em adaptação e
evolução constante.
3 GERENCIAMENTO DO ESCOPO DO
PROJETO
O escopo do projeto é tudo o que será construído no projeto para atingir
o objetivo que foi determinado no plano de gerenciamento do projeto. Com as
definições de negócio alinhados e aprovados pelas partes interessadas, o gerente
de projetos deve se concentrar na definição do escopo que será realizado com a
colaboração da equipe do projeto e de especialistas externos, se for necessário.
No Guia PMBOK® 6ª edição (2017) é feita a diferenciação entre o que é escopo
do produto e escopo do projeto:
80
• Escopo do Produto – são as características e funções do produto

resultado das atividades do projeto.
• Escopo do Projeto – são todas as atividades realizadas para a
construção de produto dentro do projeto. Em muitos casos é considerado
como parte do escopo do projeto, o escopo do produto.
FIGURA 7 – PROCESSOS DE GERENCIAMENTO DO ESCOPO AO LONGO DAS

FASES DO PROJETO
FONTE: O autor
Essa definição é muito importante para evitar a construção de produto ou

serviço que não atenda às expectativas e acordos firmados. Sem essas definições
claras e gerenciadas é muito possível ocorrer a construção de algo que não
estava definido, representando um desperdício de recursos, pessoas, tempo e
custos. Essas construções, fora do que foi definido, são conhecidas como “gold
plating”, ou seja, um acréscimo ao escopo do projeto que o cliente não solicitou
e que seu resultado pode não gerar valor aos olhos do cliente, desperdiçando
tempo, dinheiro e recursos.
Se o projeto seguir um modelo preditivo, as definições são todas tomadas no

início do projeto com a criação da Estrutura Analítica do Projeto (EAP) e a definição
da linha de base do projeto, que só pode ser alterada com os procedimentos
formais de gestão de mudanças que são avaliadas e implementadas no decorrer
do projeto. Esse tipo de abordagem possui a necessidade de um esforço inicial
muito grande para a definição de todos os trabalhos esperados para o projeto.
Vivemos um contexto de mercado onde as mudanças já não são situações
transitórias, mas uma constante pela necessidade de adaptação a novos desafios
e torna muito ineficaz e ineficiente esse tipo de abordagem. Não devemos
descartar o modelo preditivo, existem contextos onde ela atende às expectativas
e objetivos do projeto, o que é necessária é uma avaliação cuidadosa.
Em contrapartida, os modelos adaptativos ou ágeis, como é citado no Guia
81
PMBOK® 6ª edição (2017), têm se tornado mais popular por sua característica
de ciclos curtos de implementação, em que o direcionamento de negócio e suas
alterações influenciam diretamente no que será construído no projeto. Isso não
significa que o projeto é iniciado sem nenhuma previsão e direcionamento, o
que ocorre é o entendimento claro do objetivo a ser atingido dentro do contexto
atual e os direcionadores de negócio, assim o escopo planejado é mais flexível,
com a priorização das atividades conforme sua importância para o resultado do
momento. Esse grupo de atividades é conhecido por Backlog. A gestão desse
repositório de atividades é ativa e constantemente é aumentado ou diminuído
conforme as mudanças que o projeto tem para adaptação a novas necessidades.
Outra interpretação errônea sobre escopo em projetos ágeis é que não

teremos um fim para o projeto ou que as entregas realizadas podem virar um
emaranhado de pedaços sem sentido. Nesse modelo é avaliado o contexto atual
e o que já foi construído, é mais constante para ajustes o mais cedo possível e
otimizar a entrega de valor do produto do projeto. Por isso, a importância de ciclos
curtos para essa avaliação e ajustes visando diminuir os impactos possíveis. Em
análise para tomada de decisão, não é melhor perceber que um projeto se tornou
inviável e que não está atendendo ao seu objetivo o mais cedo possível, do que
somente ao final do projeto, aumentando o desperdício de tempo e dinheiro?
3.1 PLANEJAR O GERENCIAMENTO

DO ESCOPO
Com esse plano, ficam definidas as regras, acordos e práticas que serão
utilizados para a gestão do escopo do projeto. Essas definições devem ser
revistas constantemente no decorrer do projeto, independentemente do modelo
adotado (prescritivo ou adaptativo), para que possam ser ajustadas as mudanças
identificadas.
Para realizar esse planejamento, o gerente de projetos precisar conciliar,

com a equipe do projeto, questões de negócio, técnicas e interesses envolvidos
para aquilo que será construído durante o projeto. As verificações e ajustes do
plano, quando necessários durante o projeto, precisa ser capaz de sintetizar as
alterações do escopo.
82

DO ESCOPO
Junto à definição de um plano de gerenciamento do escopo é iniciada a
coleta dos requisitos do que será construído durante o projeto. Esse levantamento
tem por objetivo criar um grupo de informações que, interligadas de forma
complementar e dependente, possibilitarão a criação do produto do projeto.
Essas informações são vitais para a construção da visão de outras áreas de
conhecimento e como base para a construção da EAP (Estrutura Analítica do
Projeto).
Os requisitos durante o projeto, provavelmente, sofreram mudanças para a

adaptação e evolução com o melhor entendimento do que está sendo construído
através dos feedbacks. O gerente de projetos e a equipe precisam ter claro que
a prioridade do projeto é atingir o seu objetivo, mais que somente entregar o
escopo acordado. Essa visão precisa ter a participação das partes interessadas
fora da equipe, necessitando de alinhamento do entendimento sobre adaptações
e mudanças através de avaliações das entregas. A proximidade das partes
interessadas para a revisão dos requisitos é uma ação de mitigação de riscos e a
prática de ciclos mais curtos de entrega e feedback são de grande ajuda.
No Guia PMBOK® (2017), em ferramentas e técnicas é dado destaque na

6ª edição em práticas colaborativas e interativas, e uma técnica que pode ajudar
muito nesse levantamento de requisitos é a Lean Inception, citada anteriormente.
Através do alinhamento sobre produto, jornada do usuário, alinhamento de visão e
objetivos, de uma forma colaborativa entre os principais interessados e detentores
de conhecimento sobre o produto que será construído no projeto, é possível fazer
um levantamento com maior confiabilidade dos requisitos. É indicado dependendo
do tamanho do projeto fazer a Lean Inception em outros momentos-chaves, para
ajuste e novos alinhamentos.
A linguagem utilizada para a descrição desses requisitos é outro ponto de

debates e dúvidas de muitas pessoas envolvidas com projetos. Não existe um
padrão a ser adotado como regra, o que precisa ser avaliado é o contexto em
que o projeto está inserido, a cultura de comunicação dos envolvidos e as regras
e processos definidos da organização. Um projeto de uma construtora usará
uma linguagem adaptada à realidade da construção civil, em TI, a linguagem
da realidade de equipes de tecnologia, e assim para todos os segmentos e
organizações com suas particularidades e cultura.
83
No Guia PMBOK® 6ª edição (2017) é destacado um método de escrever

requisitos do projeto, que é a história de usuário. É uma forma de escrita curta
e textual que descreve a interação da parte interessada mostrando seu papel,
meta e motivação com o produto do projeto. Essa descrição será a base para a
equipe do projeto desdobrar essa história do usuário em atividades técnicas, que
será possível ajustar para a construção conforme sua prioridade, e se encaixa
com outras atividades identificadas em outras histórias de usuário ou atividades
técnicas e a criação dos pacotes de trabalho da EAP.
Trabalhar com protótipos também é uma maneira de validar uma hipótese

que não ficou muito clara a todos. Importante destacar novamente que um
protótipo é a construção de modelo para a validação de uma ideia, deve ser
claro a todos que ele deve ter o mínimo viável para a validação dessa hipótese e,
assim, evitar expectativas erradas. Um protótipo pode ser desde um desenho ou
modelo construído com materiais de papelaria (caixa de papelão, post it, durex
etc.) até um modelo operacional com funções mais complexas, o que deve estar
em foco é não construir nada além da ideia que se pretende validar.
3.3 DEFINIR O ESCOPO DO PROJETO

Esse processo avalia todos os requisitos coletados, os planos de
gerenciamento do projeto e gerenciamento do escopo e definir o que irá compor
as atividades de construção do produto do projeto. Nesse momento, pode
ocorrer a definição que certos requisitos coletados não serão incluídos no escopo
do projeto, ou novas divisões e agrupamentos é outra possibilidade. O que é
importante ser trabalhado nesse processo é deixar claras quais as atividades que
serão trabalhadas pela equipe do projeto e alinhar as expectativas das partes
interessadas do que será construído no projeto.
Essa definição é uma visão acordada e passível de ajustes no decorrer

do projeto para se ajustar às mudanças necessárias com a inclusão, exclusão
ou outros agrupamentos mudando o escopo. Em projetos prescritivos, isso fica
caracterizado pela mudança da linha de base do projeto e em modelos adaptativos
significa mudanças no backlog.
3.4 CRIAR A EAP DO PROJETO

A EAP (Estrutura Analítica do Projeto) é uma visão gráfica da decomposição
hierárquica do escopo total do projeto. Ela é uma foto de um determinado momento
do projeto onde um escopo foi definido, mas com o decorrer dos trabalhos e os
ajustes que ocorrer, deve estar representado em ajustes na EAP, então, ele é
84
um documento em constante atualização. O gerente do projeto pode usar essa

ferramenta como um apoio visual e de fácil entendimento do projeto facilitando
decisões e alinhamentos com a equipe e as outras partes interessadas.
A estruturação da EAP deve seguir a melhor forma de entendimento

das partes interessadas, pois esse documento precisa ser algo de entendimento
claro e objetivo. A construção de um dicionário da EAP é parte dessa atividade,
ela conterá as explicações acordadas sobre termos, entregas, fases, grupos de
atividades e componentes da EAP. Pode ser representada de várias formas,
conforme descrito no Guia PMBOK® 6ª edição (2017) (cap. 5.3), a mais usual
é a indicada na Figura 8, a seguir, não existe uma regra, mas estudos de PNL
(Programação Neurolinguística) mostram que a visualização de uma imagem
ajuda nosso cérebro a entender melhor e guardar informações principais sobre
um determinado assunto.
FIGURA 8 – GUIA PMBOK 6ª ED.
FONTE: Guia PMBOK 6ª ed. (2017, p.158)
3.5 VALIDAR O ESCOPO DO

PROJETO
Nesse processo é realizado o aceite por parte do cliente ou patrocinador do
projeto da entrega da fase ou do projeto. Com base no atendimento do processo
de Controle da Qualidade e do escopo definido, o cliente formaliza a entrega.
85
Para gerar uma atividade eficaz de validação é importante que os

alinhamentos realizados anteriormente e os ajustes realizados durante o
andamento do projeto estejam claros para as partes interessadas, que têm a
prerrogativa da validação das entregas do projeto.
Em um projeto esse processo é muito importante, pois é a formalização da

validação da hipótese inicial do projeto ou da fase. Ciclos muito longos para essa
validação aumentam o risco de distorções de entendimento, criando expectativas
que não condizem com a realidade do produto que foi desenvolvido, por isso a
proposta de trabalhar em ciclos curtos de entrega para obtenção de um feedback
mais rápido do cliente é praticada em projetos adaptativos. A proximidade do
cliente e de outras partes interessadas durante a fase e execução com inspeções,
reuniões de status e demonstrações são importantes para manter a eficácia dos
resultados na melhor eficiência de construção.
3.6 CONTROLAR O ESCOPO DO

PROJETO
É o processo responsável por monitorar e controlar se o escopo que está
sendo construído é o acordado nos planos do projeto, do gerenciamento do
escopo e seguindo os requisitos que foram definidos para construção. Ele controla
se as mudanças que estão sendo implementadas estão acordadas conforme o
processo de controle e implementação das mudanças, para evitar alterações que
não foram alinhadas conforme o processo. Para esse controle pode ser utilizado:
• Softwares integrados de gestão de projetos, como por exemplo, o Jira

da Atlassian, que é mais voltado a projetos de software, ou o Project da
Microsoft, que é bem utilizado no mercado integrando informações de
um ou mais projetos.
• Planilhas eletrônicas são bem populares por sua flexibilidade e fácil
acesso, e dependendo do tamanho, complexidade e quantidade de
projetos podem ser bem úteis.
• Gestão visual é muito utilizada em projetos com práticas adaptativas
ágeis, em que a transparência das informações e facilidade de criar uma
visão sintética rápida são primordiais para percepção de possíveis riscos
ao projeto.
O importante é a coerência entre o que está sendo controlado e medido com

o que está acordado para o projeto.

86
4 GERENCIAMENTO DO
CRONOGRAMA DO PROJETO
Seu objetivo é garantir que o projeto seja entregado no prazo acordado com
uma visão geral das atividades que serão realizadas com suas dependências,
sequenciamento e previsão de tempo necessário. Em edições anteriores do Guia
PMBOK® era conhecimento com Gerenciamento do Tempo.
FIGURA 9 – PROCESSOS DE GERENCIAMENTO DO CRONOGRAMA AO LONGO DAS

FASES DO PROJETO
FONTE: O autor
A equipe do projeto define o método de construção do cronograma conforme

as normas e procedimentos de governança da organização ou o acordado para o
projeto. Podemos citar como modelos o uso do caminho crítico, abordagens ágeis
ou modelos híbridos dos exemplos apresentados ou outros modelos existentes no
mercado. O importante é a indicação em uma linguagem clara à equipe do projeto
e outras partes interessadas de como está planejado o cronograma, sendo uma
fonte de informações e controle das atividades que estão sendo realizadas.
Um fator importante e que está destacado no Guia PMBOK® 6ª edição (2017)

é a flexibilidade necessária para os cronogramas, pois no mercado atual, com a
velocidade e constância das mudanças necessárias para ajustes nos projetos,
um formato rígido ou que não estão claros os mecanismos de ajustes, pode criar
muitas dificuldades e desperdícios com a construção de atividades desalinhadas
com a realidade dos rumos do projeto. A dedicação do gerente de projetos nesse
processo deve estar direcionada a criar uma visão mais completa possível até
aquele momento do cronograma das atividades a serem realizadas e usar as
informações dos processos de controle, monitoramento a execução para realizar
os ajustes necessários.
87

DO CRONOGRAMA DO PROJETO
Esse processo é o momento de definir as políticas, acordos e processos e
a documentação necessária para criar o cronograma do projeto. Os processos
indicados na fase de planejamento, conforme indicados nas figura 2 e 3, não
são uma sequência de dependência para sua construção, em muitos casos eles
ocorrem de forma simultânea influenciando e sendo influenciado pelos outros
processos, o objetivo central é construir o cronograma e cada processo contribui
com uma parte para esse resultado.
Se o projeto estiver utilizando os conceitos da Lean Inception ou outra

abordagem colaborativa, muitas informações geradas durante a atividade são
entradas valiosas para os processos de gerenciamento do cronograma.
4.2 DEFINIR AS ATIVIDADES DO

PROJETO
Nesse processo é realizada a divisão das atividades para realização das
entregas do projeto. É o momento em que os pacotes de trabalho são quebrados
em partes executáveis e gerenciáveis que fornecem uma base para estimar,
planejar, executar, monitorar e controlar as atividades do projeto.
É importante o cuidado na quebra dos pacotes de trabalho em atividades

para evitar o microgerenciamento, essa situação sempre é acompanhada de
desperdícios com excesso de burocracia, criando mais problemas que prevenção
a falhas e riscos. A EAP é uma fonte de informações importante e a sincronização
de suas informações é fundamental para uma boa gestão do projeto.
Em projetos com abordagem adaptativa, o planejamento por ondas,

trabalhando com ciclos de interação menores, precisa de flexibilidade de controle
para ajustes e mudanças nas atividades para sua adaptação a ambientes
complexos. Na abordagem prescritiva é necessário estar preparado para
ajustar as atividades, evitando as situações de desalinhamento entre o escopo
determinado na linha de base do projeto e a realidade das mudanças ocorridas.
88
4.3 SEQUENCIAR AS ATIVIDADES DO

PROJETO
O objetivo é identificar o relacionamento entre as atividades e seu
sequenciamento, conforme as dependências existentes, esse processo é
construído durante o projeto com uma visão inicial e posteriores ajustes conforme
novas atividades são incluídas, excluídas ou agrupadas de formas diferentes,
mudando o relacionamento das atividades para a melhor eficácia no resultado final
do projeto através da melhor eficiência das pessoas e dos recursos envolvidos.
Todas as atividades têm algum relacionamento entre si com dependências

ou restrições para sua execução. Dependo do contexto do projeto essa dinâmica
pode ser mais intensa de mudanças ou mais estática, podendo variar entre uma e
outra durante o projeto.
4.4 ESTIMAR A DURAÇÃO DAS

ATIVIDADES DO PROJETO
Durante esse processo é estimado o tempo que as atividades definidas
e sequenciadas irão demorar. Com esse planejamento, temos uma visão da
hipótese de duração de cada atividade e do projeto como um todo, considerando
os tempos e as dependências mapeadas. É importante o entendimento de que
essas estimativas podem sofrer alterações, dependendo das mudanças que
forem implementadas no projeto ou por aleatoriedades que ocorram durante a
execução.
Estimativas sempre envolvem riscos. Uma prática é as estimativas estarem

sendo consideradas buffers de segurança, que são estimativas de tempo
consideradas para eventuais mudanças e impactos que são provocados quando
trabalhamos conscientes das aleatoriedades.
Existem várias formas de estimativas, conforme indicado no Guia PMBOK®

6ª edição (2017) (capítulo 6.4.2), como:
• Opinião de especialistas que são baseadas no conhecimento dos

envolvidos com o projeto ou de consultores externos.
• Estimativa análoga que é a utilização de uma base histórica de outros
projetos semelhantes para uma base inicial de definições.
• Estimativa paramétrica utiliza relações estatísticas de dados e variáveis
89
para determinar um padrão que melhor se adéqua à realidade do projeto,

como por exemplo, o valor de construção do metro quadrado na região
do projeto para cálculo de custos aproximado.
• Estimativa de três pontos, que é a visão das dimensões mais otimistas,
pessimistas e mais provável para avaliação de riscos e incertezas.
O mais importante é compreender qual a melhor forma para a realidade

do projeto, pois escolher uma forma de estimativa que não está condizente
com contexto do projeto pode provocar falhas e não atingimento dos objetivos
acordados.
4.5 DESENVOLVER O CRONOGRAMA

DO PROJETO
É a unificação dos resultados dos outros processos de gerenciamento do
cronograma indicado na fase de planejamento para criar uma visão que orientará
a execução, monitoramento e controle do projeto. Durante a execução desse
processo é possível a necessidade de ajuste de outros processos. Serão definidos
marcos do projeto, sequenciamentos e dependências, sempre avaliando possíveis
conflitos de lógica e se o nivelamento dos recursos e alocação da equipe está de
forma a criar a maior eficiência para o atingimento dos objetivos com a maior
eficácia possível.
É possível utilizar modelos mais descritivos ou mais visuais, essa

definição está muito atrelada à cultura da organização e das partes interessadas
no projeto dependendo da abordagem que for definida (prescritiva ou adaptativa).
É possível aplicar várias técnicas que estão descritas no Guia PMBOK® 6ª edição
(2017) (cap. 6.5.2) e que não se limitam somente a elas:
• Análise de rede do cronograma.

• Método do caminho crítico.
• Otimização de recursos.
• Análise de dados.
• Antecipações e esperas nas atividades e entregas.
• Compressão e paralelismo do cronograma.
• Planejamento ágil com uma visão de mais alto nível inicial e refinamentos
posteriores.
Uma prática que tem sido adotada em projetos com abordagem ágil é
evitar grandes entregas com prazos muito longos, não atendendo à premissa
dos modelos adaptativos de ciclos mais curtos de feedback da validação das
90
hipóteses de planejamento. O cronograma deve estar preparado para esse tipo

de abordagem.
4.6 CONTROLAR O CRONOGRAMA

DO PROJETO
Esse processo é responsável pelo monitoramento e controle do cronograma
que está sendo realizado em relação ao planejado, essa gestão é entrada para
o controle integrado das mudanças para efetuar os ajustes necessários no
cronograma ou ajustes nos processos para recuperar prazos ou ajustar etapas. O
controle deve estar em forte sintonia com a execução para que alterações sejam
identificadas o mais cedo possível no projeto e tomadas as devidas providências
definidas no plano do projeto, ou caso seja uma situação não prevista, tomar as
ações mais adequadas de ajustes dos planos e do andamento do cronograma do
projeto.
Com esse controle é possível ter uma visão do andamento do projeto com
previsões mais assertivas de entrega do projeto e ajustando possíveis distorções
do cronograma e alinhar às expectativas das partes interessadas. É possível usar
várias técnicas de análise das informações, como os exemplos indicados no Guia
PMBOK® 6ª edição (2017) (capítulo 6.6.2.1), como análise de valor agregado,
gráfico de evolução regressiva, entre outros. O importante, ao aplicar a técnica
que melhor se adaptar à realidade do projeto, é identificar o mais cedo possível as
mudanças entre o planejado e o realizado, e realizar as ações mais adequadas.
5 GERENCIAMENTO DOS CUSTOS

DO PROJETO
O Gerenciamento dos Custos é a área de conhecimento que trata de todos os
aspectos relacionados aos desembolsos de valores necessários para a realização
do projeto. Em seus processos são avaliados, mensurados e direcionados os
custos do projeto e os seus impactos internos (custos relacionados a ações dentro
do projeto) e externos (definições sobre o produto do projeto e seu desdobramento
na utilização pelo cliente). Um exemplo pode ser a situação de um projeto de
infraestrutura que necessita de um grupo de testes de desempenho. É avaliada
a possibilidade de não realizar esses testes, com essa decisão é esperada uma
economia de 13% do custo total do projeto, em contrapartida, caso ocorra a
falha que pode ser prevenida com os testes, o valor que será necessário para
a correção é quatro vezes maior que o valor da economia para o projeto. Nesse
momento, a equipe de gerenciamento do projeto responsável pelos custos deve
91
avaliar o maior custo-benefício na mitigação de um risco.
FIGURA 10 – PROCESSOS DE GERENCIAMENTO DE CUSTOS AO LONGO

DAS FASES DO PROJETO
FONTE: O autor
Em um mundo onde a velocidade das mudanças está em um ritmo frenético

e as crises econômicas têm cada vez mais impactos em vários mercados pela
interligação maior que vivemos, em um mundo de comércio globalizado, a gestão
dos custos é um fator crucial para o sucesso. Para um projeto ser saudável, ele
precisa:
• Construir um produto alinhado às expectativas do cliente.

• Ter definições claras e um bom canal de comunicação para equipe do
projeto.
• Respeitar os valores financeiros disponíveis para investimento.
Caso alguns dos itens anteriores estiverem dessincronizados é o momento

que os projetos começam a falhar e a maioria dos problemas surgem, gerando
estresse e conflitos. O gerenciamento dos custos é uma fonte de informações
importantes para a avaliação da saúde financeira dos projetos e contribui com a
tomada de decisões estratégicas.

DOS CUSTOS DO PROJETO
É a decisão de como serão as regras para as estimativas, orçamentos,
gestão, monitoramento e controle dos custos do projeto. Como os custos do
projeto são geridos ao longo de todo o projeto é necessário pensar um modelo
de plano com mecanismos e gatilhos para tomadas de decisões rápidas e com o
máximo de informações relevantes.
92
É importante destacar o conceito de Custo Afundado, também conhecido

como Custos Irrecuperáveis, que são aqueles custos já realizados que não podem
ser recuperados. Essa teoria defende que os custos já realizados no projeto não
podem ser recuperados, então, detectar o mais cedo possível um desvio ou
mudança no planejamento pode evitar gastos que não poderão ser recuperados.
A questão dos custos em um projeto sempre são uma situação delicada e

cercada de cuidados e olhares de várias partes interessadas que geralmente têm
um poder de influência grande. O gerente de projetos precisa trabalhar os custos
da forma transparente para evitar entendimentos distorcidos, expectativas irreais
ou surpresas aos envolvidos.
5.2 ESTIMAR OS CUSTOS DO

PROJETO
O objetivo desse processo é quantificar os prováveis custos necessários para
a construção do produto, que é objetivo do projeto. Para a composição dessas
estimativas, as atividades definidas no cronograma com suas dependências
e prazos de entrega são informações fundamentais, pois o resultado de seu
planejamento e ajustes durante o projeto precisam estar alinhadas para manter
factíveis os prazos, análise de riscos envolvidos e os custos previstos.
No início do projeto, essa visão ainda é de alto nível, é muito complicado

conseguir uma visão detalhada com alta dos custos necessários. No início do
projeto existem mais hipóteses que validações dessas ideias, por isso estimar os
custos é uma atividade que será ajustada durante o andamento dos trabalhos.
Para criar essas estimativas iniciais é possível usar várias técnicas no Guia
PMBOK® 6ª edição (2017) e que foram explicadas anteriormente.
Independentemente do modelo a ser adotado para as estimativas é

fundamental estar claro a todos que sempre ocorrerão variações. Para um plano
contribuir para o resultado do projeto, este precisa estar preparado para identificar
essas variações, auxiliar a análise dos impactos para a realização de ações de
ajuste conforme as definições da equipe de gerenciamento dos custos.
93
5.3 DETERMINAR O ORÇAMENTO DO

PROJETO
Nesse processo, os custos apurados são agrupados dentro de uma lógica
das atividades relacionadas ao projeto com seus respectivos pacotes de trabalho,
com entregas, marcos importantes do projeto e outros pontos indicados no
cronograma para criar uma linha de base dos custos do projeto.
Esses valores definidos serão monitorados durante os trabalhos, realizando

ajustes conforme o refinamento e entendimento mais apurado das entregas do
projeto, criando novas versões sobre os custos envolvidos.
O orçamento é composto pelos custos das atividades do projeto, reservas

gerenciais e contingências (essa parte analisaremos com mais profundidade no
gerenciamento dos riscos). Esses fatores têm uma forte ligação e possibilitará a
análise dos valores envolvidos.
5.4 CONTROLAR OS CUSTOS DO

PROJETO
É o monitoramento e controle do andamento dos custos do projeto em
comparação ao orçamento acordado, essa gestão é responsável por apurar e
fornecer informações para a tomada de decisão sobre a implementação de
mudanças referente aos custos. Nesse processo, pretendemos manter a linha de
base de custos atualizada e alinhada com as partes interessadas.
Um fator que precisa ser avaliado mais que valores nominais associados ao
projeto é o custo-benefício que está sendo agregado ao(s) objetivo(s) do projeto.
Quando o foco maior são custos e resultados, podemos cair na situação em que
“tudo é custo e nada parece ter valor”, as decisões estão somente baseadas
em números e pouco se tem foco no contexto, projeções de mercado e outras
variáveis envolvidas além das econômicas.
94
Existem muitas técnicas de análise das informações relacionadas a custos,

como indicado no Guia PMBOK® 6ª edição (2017) (capítulo 7.4.2.2):
QUADRO 1 – FÓRMULAS PARA AVALIAÇÃO DE CUSTOS EM PROJETOS
FONTE: O autor
Para otimizar os cálculos para análise é possível usar o Project da Microsoft,

que tem essa funcionalidade, planilhas eletrônicas disponíveis na internet,
construções corporativas para esse tipo de cálculo seguindo os critérios de
governança da organização, entre outras formas. O que, independentemente da
técnica utilizada, está sendo avaliado são informações de fatos já ocorridos com
a apuração do seu resultado, ajustes nas previsões futuras que sofrem impacto
direto das informações apuradas e que serão base para ações que devem ser
implementadas o quanto antes.
Na página 247 do Guia PMBOK® 6ª edição (2017) tem uma tabela com
as principais análises utilizadas em projetos com suas respectivas fórmulas e
explicações, segundo a visão do PMI.
95
6 GERENCIAMENTO DA QUALIDADE
DO PROJETO
FIGURA 11 – PROCESSOS DE GERENCIAMENTO DA
QUALIDADE AO LONGO DAS FASES
DO PROJETO
FONTE: O autor
Essa área de conhecimento incorpora o gerenciamento dos critérios de

qualidade relacionados ao projeto e ao produto que será entregue, gerando
suporte para as políticas e ações de melhoria dos processos e produtos do
projeto.
Os padrões de qualidade que o projeto utilizará devem estar de acordo

com as regras e políticas da organização ou aos acordos definidos nos planos
de gerenciamento do projeto e seus planos auxiliares. A ideia de qualidade, sua
definição e padrões esperados devem estar acordados com todas as partes
interessadas e ser um dos principais pontos de avaliação do bom andamento e
sucesso dos trabalhos realizados. O não cumprimento de requisitos de qualidade
definidos pode acarretar problemas e aumento de riscos ao projeto e ao produto
resultante.
Novas práticas de gerenciamento de projetos têm um olhar sobre a qualidade

trazendo o cliente e suas expectativas mais para o centro de todas as definições.
Em projetos adaptativos, o engajamento do cliente mais próximo ao projeto
garante feedbacks e alinhamentos mais rápidos e ajustes mais assertivos. Com
os processos de produção em massa, que foi o modelo de maior sucesso no
século XX, a visão do cliente como influenciador do produto a ser entregue não
era uma realidade, diferente nos tempos atuais onde se inverteu completamente.
A Toyota, e seu modelo de gestão adotado no pós-guerra, colocou esse conceito
como a filosofia central na criação de seus produtos e projetos, trazendo um
96
sentindo de estar sempre se adaptando às novas necessidades do mercado. A

ideia de verificação e ajustes de qualidade, no decorrer dos trabalhos, em vez de
somente ao final do processo foi uma revolução que foi amadurecendo durante
as últimas décadas e está influenciando outros modelos de gestão, como é caso
dos conceitos ágeis e todos as metodologias subsequentes que têm na melhoria
contínua um de seus fundamentos.

DA QUALIDADE DO PROJETO
O foco é definir os padrões e critérios para avaliação da qualidade do
projeto e suas entregas em um plano integrado para gerenciamentos das ações
relacionadas à qualidade. As definições acordadas serão base para tomadas de
decisão relacionadas ao aceite das entregas.
Os critérios para a definição dos padrões passam pelo entendimento

dos padrões de qualidade da organização, padrões de mercado, exigências
governamentais, aplicação do produto do projeto, entre outras variáveis que
podem mudar, ou sofrendo ajustes no decorrer do projeto. Será avaliado o custo-
benefício integrando a visão das outras áreas de conhecimento para definições
mais assertivas, factíveis e alinhadas com as partes interessadas.
6.2 GERENCIAR A QUALIDADE DO

PROJETO
Durante a fase de execução do projeto, esse processo é responsável por
materializar os planos de qualidade em ações integradas, garantindo os padrões
acordados para os processos e produtos do projeto, atendendo às expectativas
definidas com as partes interessadas.
É importante destacar que garantir a qualidade do produto tem diferenças de

abrangência quando comparado a gerenciar a qualidade do projeto. Na segunda
situação, além de garantir a qualidade do produto, também são avaliados critérios
de qualidade das outras atividades do projeto, como por exemplo, um projeto
de construção de uma nova unidade de tratamento de água em uma indústria,
um dos critérios de qualidade do projeto é estar dentro dos padrões de impactos
sociais e ambientais, definidos os objetivos de responsabilidade social que são
acompanhados e avaliados no planejamento estratégico da organização.
A qualidade é um conceito percebido, um tanto abstrato, e pode gerar
97
discussão na própria equipe sobre o que é considerado qualidade para aquela

organização. Para cada parte de implemento no projeto, os critérios de qualidade
precisam ser considerados e avaliados. O gerente de projeto precisa zelar por
essas questões, trabalhando a conscientização de todos os envolvidos sobre os
critérios e padrões acordados.
O modelo de análise e representação dos dados pode variar conforme

as necessidades do projeto. Alguns têm uma aplicação mais comum, como o
diagrama de dispersão, diagrama de causa e efeito (também conhecido como
diagrama de Ishikawa ou espinha de peixe), fluxogramas, entre outros. O que
deve ser o pensamento central ao efetuar a escolha do(s) modelo(s) é indicar
de forma adequada se a evolução do projeto segue a qualidade determinada,
evitando surpresas ou desperdícios provocados pela necessidade de retrabalhos
que poderiam ser evitados. Porém, a escolha do modelo de análise e
representação dos dados não resolverá os problemas de qualidade identificados,
é necessária ação nesse sentindo e um conceito que está sendo muito aplicado é
o de melhoria contínua.
Melhoria contínua é o processo de ações constantes visando melhorar a

eficiência e eficácia dos processos e produtos de uma organização ou projeto.
Ele não tem um fim previsto enquanto existir o sistema para a construção de algo,
então, quando pensamos em projetos, podemos dizer que enquanto o projeto
existir, todos os seus processos podem ser melhorados em algum aspecto.
Para sua efetiva adoção e gerar resultados de evolução é preciso estar

enraizado na cultura da organização, visando sempre trazer benefícios ao
sistema como um todo. É a visão onde o coletivo que trabalha para entrega de
um produto ou projeto supera a visão individual ou de parte desse sistema. Para
exemplificar a aplicação desse conceito, apresentaremos duas práticas populares
da atualidade por seus resultados comprovados:
• PDCA – esse conceito se tornou popular através de William Deming,

consultor e estudioso sobre qualidade que contribuiu fortemente com a
reconstrução da indústria japonesa do pós-guerra, ele é a composição
das iniciais das palavras Plan, Do, Check and Act (Planejar, Fazer, Checar
e Agir). Com base nessas quatro ações é possível manter o ciclo de
melhoria contínua dentro de um processo, ação, verificação e melhorias
sobre a ação anterior. Em uma visão mais avançada do conceito, a ideia
de Act é substituída por Learning (Aprendendo), passando a ser PDCL,
em que se fortifica a ideia de aprendizado evolutivo em ciclos.
• Cultura Kaizen – sob a influência de Deming, com seus conceitos
de qualidade, aliado à cultura japonesa de harmonia e constante
aperfeiçoamento, a Toyota e outras empresas japonesas trouxeram no
98
pós-guerra um conceito de qualidade, onde garantir que as coisas estão

sendo feitas com a melhor eficiência e eficácia para o resultado de um
produto alinhado à necessidade dos clientes é atribuição de todos dentro
da organização, independentemente de seu cargo ou atividade atribuída.
A Cultura Kaizen inclui mudanças e monitoramento de resultados,
e então, ajustes. Planejamento em grande escala e cronogramas
extensivos de projetos são substituídos por experimentos menores,
que podem ser rapidamente ajustados quando novas melhorias são
sugeridas.
6.3 CONTROLAR A QUALIDADE DO

PROJETO
É o processo responsável por monitorar e controlar os resultados das
atividades relacionadas ao projeto e ao produto que será entregue, estão
seguindo os padrões e regras determinados no plano de gerenciamento de
qualidade. Quando é detectada alguma anomalia ou variação acima dos acordos
estabelecidos, devem ser acionados os gatilhos das ações definidas.
Em projetos que o conceito de melhoria contínua é aplicado, esses

processos são o indicador de possíveis melhorias que serão implementadas pelo
processo integrado de mudanças. Quanto mais rápida a percepção de ajustes
e mais cedo aplicá-las, melhor o resultado do projeto na geração de valor para
as partes interessadas. Ele deve ser aplicado ao longo de todo o projeto para
demonstrar, dentro de padrões estabelecidos, informações confiáveis para
tomada de decisões.
Outro cuidado necessário é o equilíbrio do custo-benefício das práticas e

controle implementados para qualidade. Em certos segmentos ou dependendo
da aplicação do produto do projeto, regras de governança corporativa ou normas
governamentais, as ações de qualidade podem sofrer variações. O que não pode
ocorrer é trabalhar com controles e padrões que não condizem com a realidade do
projeto quanto à mitigação de riscos, custos, prazos, escopo ou outras variáveis
de influência no resultado esperado.
7 GERENCIAMENTO DOS RECURSOS

DO PROJETO
Em edições anteriores do Guia PMBOK®, essa área de conhecimento
era chamada de gerenciamento dos recursos humanos do projeto, mas com a
99
evolução do entendimento por parte do PMI, essa visão era limitada à abrangência
dos recursos necessários para um projeto. Para ampliar essa visão, foi englobado
o gerenciamento dos recursos físicos (equipamentos, materiais, instalações,
infraestrutura, entre outros) e o gerenciamento das habilidades intelectuais
humanas necessárias à realização do projeto (recursos humanos).
FIGURA 12 – PROCESSOS DE GERENCIAMENTO

DOS RECURSOS AO LONGO DAS FASES
DO PROJETO
FONTE: O autor
Um ponto importante sobre o termo “recursos humanos” é que certas

vertentes de estudo e gestão de pessoas, ligadas a conceitos mais novos sobre
pessoas nas organizações, considera o uso da expressão “recursos” inadequado,
pois dessa forma existe a possibilidade de desumanização das pessoas, então é
possível encontrar referências como colaboradores, equipe do projeto ou outras
formas que deixem explícito o cuidado quanto ao respeito da individualidade.
O gerente de projeto, como uma das lideranças, precisa ter um cuidado

especial nos aspectos comportamentais envolvidos. Como citado anteriormente,
os principais motivos de falha em projetos são problemas de origem
comportamental, então o gerenciamento dos recursos humanos é fundamental
para o bom andamento dos resultados. Desde o início do século XXI, vem
aumentando a tendência de mudanças na gestão das organizações de um
modelo de controle e comando altamente hierarquizado para um modelo mais
colaborativo e horizontalizado. Com práticas de administrar e motivar, as pessoas
mudaram, alguns exemplos são:
• Inteligência Emocional – trabalhar com a ideia de empatia para

evoluir o autoconhecimento e melhorar o relacionamento com outras
pessoas que interagem no seu ambiente de trabalho, compreendendo
as diversidades quanto à sexualidade, raça, credos e convicções morais
para maior respeito a opiniões divergentes, criando um ambiente de
100
tolerância e segurança para todos.

• Equipes Auto-organizáveis – o aumento no uso de práticas e conceitos
ágeis criou a ideia de equipes que não necessitam de uma centralização
dos controles relacionados ao dia a dia das atividades. O trabalho do
gerente de projetos e de outros gestores envolvidos é de ser o apoio
necessário para orientação e amadurecimento da consciência coletiva
da equipe sobre os impactos e importância de suas ações no contexto
do sistema do projeto.
• Management 3.0 – esse conceito foi desenvolvido por Jurgen
Appelo para ser uma forma de otimizar os processos de gestão de
equipes através de práticas e ferramentas para desenvolvimento de
comportamentos em ambientes de alta complexidade. Equipes nesse
contexto devem estar preparadas parar analisar e gerar soluções frente
aos desafios apresentados, o gerente de projetos ou gestor nesse tipo
de estrutura tem o papel de orientador e liderança no sentindo de ajudar
no direcionamento estratégico da equipe e não mais para controlar a
dinâmica da organização das atividades.

DOS RECURSOS DO PROJETO
Nesse processo, o foco é criar um plano para o gerenciamento dos recursos
físicos e humanos necessários para o projeto. Também são considerados o
nível de esforço de gerenciamento necessário à complexidade envolvida e ao
modelo que será utilizado, avaliando os aspectos da equipe envolvida com o
projeto e cultura da organização. Para ficar mais claro, imagine uma empresa
com uma cultura tradicional de controle e comando profundamente enraizada nos
principais patrocinadores e aprovadores do resultado do projeto, onde a equipe
que trabalhará com o projeto tem um perfil e motivação maior em trabalhar com
modelos mais colaborativos e liberais nos aspectos de autonomia de decisão
sobre o andamento dos trabalhos, provavelmente existirão pontos de conflito que
podem ser prejudiciais ao projeto.
O gerente de projetos precisa estar preparado para ser um agente de

conciliação e equilíbrio entre as diferenças dessas abordagens. Sem esse
equilíbrio, a distribuição de recursos físicos e pessoas, conforme a necessidade
do projeto, pode ficar prejudicada por discórdias e aumentar a exposição a riscos.
A definição dos recursos físicos precisa equilibrar as necessidades da

equipe para executar as atividades definidas para o projeto e as questões de
custos aprovados no orçamento. Os recursos sempre são finitos e essa balança
101
precisa ser equilibrada constantemente, conforme o andamento dos trabalhos.

O gerenciamento dos riscos pode ser uma forma de manter esse equilíbrio,
para aplicar os melhores ajustes aos recursos necessários dentro dos custos
acordados ou na revisão do orçamento para viabilizar as entregas, observando o
custo-benefício envolvido.
Já para os recursos humanos existem várias ferramentas que podemos

avaliar. Como exemplo, para ajudar nessa definição do gerenciamento e dos
níveis de atuação e responsabilidade da equipe do projeto, vamos analisar dois
modelos:
• Matriz RACI – é uma ferramenta pela qual cada recurso humano tem
o entendimento do seu papel dentro do contexto do projeto. O nome
corresponde à sigla para Responsible, Accountable, Consulted e Informed
(Responsável, Aprovador, Consultado e Informado). Ela é utilizada em
uma representação gráfica do objetivo do projeto e a ação necessária
de cada participante para que esse objetivo seja atingido. Foi criada
para eliminar a confusão na hora de definir o papel de cada um no
projeto e para aumentar a eficiência. É uma matriz de distribuição de
responsabilidades, em uma visão mais genérica.
• Delegation Board – é uma ferramenta do Management 3.0 utilizada
para estabelecer o relacionamento da equipe e da gestão quanto às
atividades existentes no projeto e o nível de autonomia para cada uma.
O modelo possui sete níveis diferentes, que vão do controle total do
gestor sobre a ação até a total delegação para equipe, sendo construído
em conjunto, de uma forma democrática e alinhando expectativas e
entendimentos.
7.2 ESTIMAR OS RECURSOS DO

PROJETO
O objetivo desse processo é estimar os recursos, tanto humanos quanto
físicos, necessários para o projeto executar as atividades definidas. Para essa
estimativa é necessário o equilibro entre as necessidades apuradas do escopo,
as atividades que foram definidas para sua realização e os custos aprovados
no orçamento do projeto. Serão avaliadas as habilidades intelectuais e
comportamentais da equipe do projeto e os recursos materiais mais adequados e
factíveis dentro da disponibilidade e capacidade de aquisição aprovada. É possível
utilizar uma estrutura analítica de recursos (EAR) para uma representação visual
da sua utilização para o projeto, sua contribuição é criar uma forma de fácil
entendimento e análise.
102
7.3 ADQUIRIR RECURSOS DO

PROJETO
É o momento de conseguir os recursos que foram definidos para o projeto,
conforme as necessidades determinadas pelo planejamento. Esses recursos
podem ser internos ou externos à organização do projeto, sendo que os
procedimentos para a alocação podem ser diferentes em cada tipo. Para recursos
internos é uma questão de acordos firmados com os gestores responsáveis pelas
pessoas e materiais do momento de sua liberação para o projeto e posterior
desligamento. Alterações que possam ocorrer nesses acordos precisam ser
tratadas no gerenciamento integrado de mudanças. Os recursos externos são
adquiridos ou contratados seguindo o processo de aquisição do projeto.
Outro aspecto que tem ganhado força na era digital para os trabalhadores
da era do conhecimento é o trabalho remoto com equipes. Essa possibilidade
tem viabilizado formas de efetuar as atividades com pessoas independentemente
de sua localização geográfica, diminuindo custos e viabilizando habilidades
importantes ao projeto. Esse modelo exige novas formas de gerenciamento que
privilegiam a auto-organização, como citado anteriormente.
7.4 DESENVOLVER A EQUIPE DO

PROJETO
É o processo focado no desenvolvimento das competências técnicas e
comportamentais da equipe do projeto, criando um ambiente de segurança
e confiança para as pessoas desempenharem suas atividades na melhor de
sua capacidade. O gerente de projeto precisa trabalhar com suas habilidades
de liderança, o equilíbrio entre o objetivo do projeto e os objetivos pessoais de
cada membro. O fator motivacional das equipes é muito importante, mas para
ter motivação, as pessoas precisam estar engajadas, e esse comprometimento
só é possível quando as pessoas entendem e se sentem pertencentes àquele
grupo emocional e racionalmente, equilibrando sentimentos e senso de
responsabilidade.
Modelos como o management 3.0, e outras variações de modelos

colaborativos, têm se apresentado como os mais coerentes com os anseios e
perspectivas do profissional do século XXI. O modelo de Tuckman, que inclui
cinco etapas na formação de equipes (formação, conflito, acordo, desempenho
e dispersão para o caso de projetos) é um exemplo de estudo para orientar, da
103
melhor forma possível, o entendimento do nível de maturidade das equipes e

definir ações evolutivas mais adequadas.
Outro aspecto importante é a avaliação do desempenho. Existe a tendência

em projetos adaptativos de não trabalhar mais avaliações individuais das
entregas realizadas, mas avaliação do time e o resultado alcançado em relação
ao objetivo do projeto. Os gestores e as equipes precisam estar preparados para
essa mudança de paradigma, pois é uma mudança de um foco em eficiência
das partes para a eficácia do sistema através do trabalho coletivo e não mais no
individual.
7.5 GERENCIAR A EQUIPE DO

PROJETO
É o processo de acompanhar o desempenho da equipe fornecendo
feedbacks, resolver problemas e otimizar as relações dentro e fora do ambiente
do projeto. Novamente, a capacidade agregadora do gerente do projeto será
importante para criar a sinergia esperada para o resultado do projeto. Gestão
de conflitos, implementação de mudanças, alinhamentos entre as expectativas
individuais e o objetivo do projeto são algumas das situações tratadas nesse
processo.
7.6 CONTROLAR OS RECURSOS DO

PROJETO
Para esse processo, o foco é monitorar e controlar os recursos do projeto
quanto a sua alocação e distribuição no projeto nos momentos planejados,
verificando a aplicação real e o previsto, para que em casos de distorções, aplicar
ações de gerenciamento integrado de mudanças. Ele é um processo aplicado
continuamente no projeto até a sua conclusão, pois provavelmente ocorrerá a
necessidade de ajustes dos planos.
O monitoramento e controle dos recursos é fundamental para análise e

tomada de decisões sobre problemas com recursos físicos, conflitos envolvendo
a parte comportamental e técnica das equipes. O gerente de projeto precisa estar
preparado e munido de informações para ser o agente catalisador para resolver
esses conflitos e divergências envolvendo os recursos.
104
8 GERENCIAMENTO DAS
COMUNICAÇÕES DO PROJETO
FIGURA 13 – PROCESSOS DE GERENCIAMENTO DAS
COMUNICAÇÕES AO LONGO DAS FASES
DO PROJETO
FONTE: O autor
Garantir que as informações circulem da melhor forma dentro e fora do

projeto, chegando às partes interessadas que desejam e precisam recebê-las no
momento necessário, no formato mais adequado, criando a menor quantidade de
ruídos no projeto é o que está englobado nessa área de conhecimento. Entender
as formas de comunicação utilizadas pelas partes interessadas, as necessidades
que o projeto apresenta e criar uma estratégia de comunicação serão tratados
pelos processos relacionados à comunicação.
A comunicação pode ocorrer de forma intencional ou não, sendo que usamos

várias formas de expressá-la:
• Através de expressões corporais – a maior parte de nossa

comunicação é feita através de expressões e comportamentos físicos.
• Falando – a expressão de ideias e informações através da fala é muito
utilizada, podemos usar por meio de conversas presenciais ou formas
remotas, através de equipamentos (telefone, internet, entre outras).
• Formais e informais – dependendo do receptor e da mensagem que
se deseja repassar é possível optar por maneiras mais formais (por
exemplo, documentos padrões que seguem uma linguagem específica)
ou informais (usar alguma mídia social como o Twitter ou WhatsApp).
Outro fator que defini os níveis de formalidade ou não da comunicação
são os aspectos culturais e sociais das partes interessadas.
• Através de mídias – imagens, ações ou a escolha de palavras
específicas.
• Escolha de palavras – conforme as palavras utilizadas, o tom de
105
expressão e momentos para comunicação podem impactar como o

receptor interpretará a mensagem enviada.
A maior parte do tempo do gerente de projeto é dedicado à comunicação,

em que o alinhamento das expectativas das partes interessadas, mudanças
no projeto e novas variáveis são compartilhadas. A comunicação desenvolve
os relacionamentos e a sua forma de aplicação e amplitude tem uma variação
enorme. Uma boa comunicação se desenvolve em dois aspectos, que é formular
uma estratégia aderente à cultura e entendimento das partes interessadas e
o segundo é a aplicação dessa estratégia, transmitindo essas informações
e recebendo o feedback de quem recebeu essa comunicação sobre o seu
entendimento. Mudanças e ajustes são constantes, conforme o andamento do
projeto e a complexidade envolvida nos relacionamentos.
Tão importante quanto gerar informações nessa comunicação, o gerente de

projetos e a equipe de gerenciamento do projeto precisam trabalhar para diminuir
os ruídos que podem ocorrer, dificuldade de entendimento e informações fora
de contexto. Melhorar a comunicação trabalhando a empatia, compreensão das
diferenças culturais, respeito pelas orientações e valores das partes interessadas
são fundamentais para evitar esses ruídos e mal-entendidos quanto às
informações que estão circulando sobre o projeto. Uma comunicação bem-feita é
uma maneira muito poderosa de engajamento, conscientização e direcionamento
das pessoas rumo aos objetivos do projeto. O gerente de projeto precisa ter um
domínio nas técnicas de comunicação com a utilização de comunicação não
violenta, escuta ativa das partes, coerência entre discurso e atitude, respeito
e liberdade de expressão de opiniões e ideias são algumas capacidades e
comportamentos necessários.
O uso de formas digitais de comunicação e o crescimento das redes sociais

como canais mudou radicalmente nossos hábitos de comunicação quanto à forma,
tempo de respostas e disseminação das informações. Em uma sociedade cada
vez mais conectada, onde todos expressam suas opiniões com maior frequência
e liberdade, as organizações não podem ficar alheias ou dissonantes quanto ao
gerenciamento dos projetos. Trabalhar formas cada vez mais inclusivas, onde os
canais de comunicação são vias de mão dupla entre as partes interessadas é
fundamental.
Em equipes que trabalham com os conceitos de agilidade, a comunicação

é uma troca constante sustentada no conceito de equipes menores, diminuindo
os canais e ruídos. Essa troca constante de informações deve ser pautada em
assuntos que estão diretamente ligados a gerar valor nas entregas do projeto,
com esse foco principal são descartadas discussões de geram desperdícios e são
distrações para a eficácia dos resultados do projeto.
106
O trabalho de equipes em localizações diferentes tem se tornado uma

realidade para as organizações e a gestão dessas equipes exige novos modelos
e formas de comunicação. No mercado existem muitas ferramentas que podem
contribuir para reuniões, transmissão de documentações e armazenamento de
informações.

DAS COMUNICAÇÕES DO PROJETO
A ideia é definir formas, canais, frequência, linguagem a ser utilizada e quem
receberá quais informações no plano de comunicação. Gerenciar atividades
de comunicação é trabalhar com situações de alta complexidade, em que os
desdobramentos das informações divulgadas podem gerar efeitos que os planos
não têm como prever, então a necessidade de ações constantes de ajustes e
adaptação são de forte impacto e necessitam de boa parte do tempo do gerente
de projetos na coordenação. O processo de integrar as mudanças tem na
comunicação um dos aspectos mais cruciais, e muitas organizações e gestores de
projeto falham nesse aspecto. Comunicar as partes interessadas das mudanças
e os seus motivadores é muito importante para o feedback tratar ajustes ou
esclarecimentos necessários e o plano de gerenciamento das comunicações
deve ser o orientador dessas ações.
A equipe de gerenciamento do projeto precisa trabalhar a comunicação

para grupos diferentes, que desejam informações de aspectos diferentes e que
tem graus de influência variados no projeto. O excesso de comunicação é tão
prejudicial quanto a falta, um exemplo são os grupos de WhatsApp. Como é um
canal de comunicação, geralmente informal, em que não existe ou são ignorados
acordos sobre conteúdo e o que deve ser postado, facilmente caem no descrédito
e começam a não ser acompanhados, caindo no desuso.
Mas quantos canais e artefatos de informação dentro das organizações ou

nos projetos não acabam sendo tratados com o mesmo descrédito? Por exemplo:
• Status Reports que ficam na caixa de entrada sem ser lidos ou

automaticamente encaminhados para as caixas de spam.
• Reuniões que são ignoradas ou os presentes estão concentrados em
outros assuntos.
• Artefatos de comunicação que possuíam um objetivo quando foram
criados e que perderam seu sentindo no decorrer do tempo para algumas
ou todas as partes interessadas.
107
O gerente de projetos deve estar preparado para identificar essas situações

e alinhar o que, para quem e por que das informações para as partes interessadas
e efetuar os ajustes ao plano de gerenciamento da comunicação.
8.2 GERENCIAR AS COMUNICAÇÕES

DO PROJETO
Gerenciar as comunicações do projeto consiste em assegurar formas, canais
e partes interessadas definidas que estão recebendo as informações nos prazos
adequados e que esse sistema criado para a comunicação está funcionando
corretamente e continua adequado aos objetivos do projeto. Durante esse
processo é necessário não só efetuar ações ativas de comunicação, passando de
emissor da mensagem para receptor, abrindo canais de feedback para confirmar
entendimento das informações e se estas fazem sentindo para os seus interesses
relacionados ao projeto.
As práticas de melhoria contínua podem ser de grande ajuda na evolução

dos modelos de redação, layouts de status, melhoria na eficácia de reuniões,
frequência das interações entre as partes interessadas, entre outros aspectos
relacionados à comunicação.
Com as práticas ágeis, a gestão visual se tornou muito popular como forma
de comunicação, um exemplo interessante é o método Kanban. Ele envolve o
alinhando entre o propósito do cliente, objetivos organizacionais, fluxo do sistema
de trabalho atual e os problemas que causam desperdícios, tudo sintetizado e
exposto nos quadros visuais de gestão do fluxo (Kanban Board). Com o Kanban
Board é possível fazer uma comunicação visual e fácil do andamento do projeto,
das atividades que estão prontas, sobrecargas do sistema e os gargalos
formados, impedimentos existentes e outros aspectos relacionados ao projeto
e seu contexto específico. Para as partes interessadas, que não podem por
questões de localização físicas usufruir dessas informações, existem ferramentas
virtuais que possibilitam esse acesso.
É muito importante, quanto ao uso da informação recebida,

independentemente do modelo escolhido, avaliar a efetividade e geração de valor
da comunicação realizado.
108
8.3 MONITORAR AS COMUNICAÇÕES

DO PROJETO
O trabalho desse processo, junto a gerenciar as comunicações é garantir
que o que está ocorrendo com as comunicações está alinhado ao plano de
gerenciamento do projeto e ao plano de gerenciamento da comunicação. Seu
objetivo é identificar distorções e gerar as mudanças nas comunicações e nos
planos de gerenciamento para eliminar os ruídos percebidos.
Para o monitoramento das comunicações existem fatores que necessitam da

capacidade do gerente de projetos no entendimento do que não está escrito e do
que não é falado, são as sutilezas não verbais que são a maior parte da nossa
comunicação. Para conseguir criar canais e decodificar os sinais e rumores, o
gerente de projetos precisam criar uma rede de contato, criando liberdade e
confiança entre as partes interessadas para conseguir identificar situações onde
a comunicação está com ruídos não identificados. Como já foi dito anteriormente,
a maioria dos problemas dos projetos estão relacionados ao comportamento dos
envolvidos direta e indiretamente, em que a comunicação é um dos aspectos que
mais deixa explícita essa observação.
9 GERENCIAMENTO DOS RISCOS DO

PROJETO
Risco é inerente a qualquer ação gerando situações positivas ou negativas,
pois sempre existe mais de uma opção possível além da aplicada. Projetos,
por suas características de prazo finito, criação de um produto único e recursos
delimitados, aumentam a complexidade de equilibrar essas características com
as premissas e restrições planejadas, além de responder às expectativas das
partes interessadas. Todo esse contexto cria uma situação de avaliação de riscos
envolvidos e tomada de decisão, gerando situações de novos riscos, eliminando
outros ou mudando seus impactos e probabilidades.
Ao gerenciar os riscos do projeto, as organizações optam por correr riscos

de forma controlada e intencional. Mas com a realidade volátil dos mercados,
relações sociais com maior grau de mudanças e a dificuldade de identificar causa
e efeito das situações atuais, a previsibilidade de resultados fica comprometida
com uma análise superficial dos riscos envolvidos com os projetos.
109
FIGURA 14 – PROCESSOS DE GERENCIAMENTO DOS

RISCOS AO LONGO DAS FASES DO PROJETO
FONTE: O autor
O Guia PMBOK® 6ª edição (2017) afirma que em todos os projetos existem

dois níveis de riscos: o individual do projeto, que afeta um ou mais objetivos do
projeto, e o risco geral do projeto, que inclui o risco individual em um contexto de
análise do impacto sobre o projeto como um todo. Observando essas definições
em uma realidade de maior complexidade dos projetos, a gestão dos riscos
individuais e gerais começam a não ter uma clara fronteira, onde a variabilidade
de efeitos vem exigindo um modelo de análise com uma visão sistêmica de riscos
e seus efeitos. Projetos podem fazer parte de programas ou portfólios e os riscos
existentes em cada um deles e sua influência tem impactos e necessitam de ações
diferentes. Gerenciar riscos em projetos é estar preparado para a aleatoriedade
dos eventos.
Nassim Taleb (2015), escritor, estático e analista de riscos criou o conceito

de Antifragilidade. Esse conceito é o amadurecimento de sua visão sobre a
gestão de riscos em um mundo de ações que geram efeitos globais e mudam o
contexto de forma rápida e abrupta, a qual ele fundamenta no seu livro A Lógica
do Cisne Negro. O autor analisou esse tipo de situação e como os modelos de
gestão de riscos precisam ser repensados. No seu livro Antifrágil (2017), ele cria
um olhar sobre a aleatoriedade e como ela faz parte de nossas vidas, sociedade
e organizações, e que tentar retirar ou simplesmente ignorar a sua existência
é a falha mais perigosa e ingênua (nas palavras do próprio Taleb) para essas
situações.
Os processos que analisaremos a seguir trabalham de forma coesa e

simultânea com variações de intensidade de influência na identificação, avaliação
e definição de planos de contingência para riscos.
110

DOS RISCOS DO PROJETO
É o processo responsável por criar o planejamento para identificação,
análise e ações sobre riscos do projeto. Os processos que fazem parte da área de
conhecimento de riscos ocorrem de forma simultânea e com influências mútuas, o
plano de gerenciamento definirá comportamentos, práticas e gatilhos para ações
relacionadas a riscos.
O plano é um documento em constante revisão e adaptação, pois durante

o projeto, conforme as interações evoluem e a compreensão sobre os objetivos
a serem atingidos ganham maior refinamento e entendimento, os riscos também
acompanham essas mudanças – com surgimento de novos, outros que deixam
de existir, ou riscos já existentes que mudam sua probabilidade de impacto e
ocorrência.
As boas práticas apresentadas pelo Guia PMOK 6ª edição (2017), para um

plano de gerenciamento ser mais aderente, deve tratar dos seguintes aspectos
(não se limitando somente a essa lista):
• Estratégia de riscos.
• Metodologia para gestão dos riscos.
• Papéis e responsabilidades para os planos de ações sobre riscos.
• Financiamento para o gerenciamento dos riscos.
• Prazos das atividades sobre riscos do decorrer do projeto.
• Categorias para agrupar os riscos individuais pela lógica de estrutura
do projeto, ela pode ser representada na EAR (Estrutura Analítica de
Riscos), como no exemplo a seguir.
111
FIGURA 15 – EAR – ESTRUTURA ANALÍTICA DE RISCOS
FONTE: O autor
A utilização da EAR contribui para uma visão estruturada e compreensão

dos níveis e distribuição dos riscos no projeto. Outra ferramenta que geralmente
trabalha em conjunto para gestão de riscos é a Matriz de Probabilidade de
Impacto (Figura 16), que ajuda na análise sobre probabilidade de ocorrência de
um determinado com a avaliação do possível de impacto, caso ele ocorra, criando
áreas onde os riscos são tratados com maior ou menor prioridade. A matriz
trabalha com uma divisão entre riscos de ameaça e oportunidade.
Na figura a seguir, retirada do Guia PMBOK® 6ª edição (2017), a parte cinza

mais escura representa essa parte de maior risco, o cinza mais claro mostra uma
área de risco médio e, a branca, com riscos mais baixos.
112
FIGURA 16 – MATRIZ DE PROBABILIDADE DE IMPACTO
FONTE: Guia PMBOK 6ª edição (2017, p. 408)
Com os riscos classificados é tomada a decisão de ação seguindo as

definições de governança organizacional, grau de tolerância a risco para o projeto,
entre outros fatores:
• Eliminar – o risco não deverá mais existir, as ações definidas devem ser
com a intenção de acabar com ele.
• Mitigar – é reduzir a probabilidade de ocorrência, grau de impacto ou
ambos a um nível dentro dos parâmetros de tolerância acordado para o
contexto do projeto.
• Delegar – a organização junto à equipe de gerenciamento de projetos
pode chegar à conclusão de que o melhor é repassar os impactos de
ocorrência do risco para um terceiro, como por exemplo, uma agência de
seguros, dessa forma, resguardando o projeto.
• Aceitar – determinados riscos são simplesmente aceitos pela sua baixa
influência no projeto ou por estarem dentro da tolerância determinada
para esse tipo de ação.
Lembrando sempre que riscos podem ser positivos ou negativos e as

classificações e ações são válidas para os dois casos.
Essa estruturação deve atender às necessidades que o projeto

apresenta sobre as informações relacionadas a riscos, disposição e diretrizes
organizacionais, órgãos governamentais e internacionais e expectativas de outras
partes interessadas.
113
9.2 IDENTIFICAR OS RISCOS

Identificar os riscos é uma ação que começa logo no início do projeto, ou
podemos aumentar o seu alcance para a fase de concepção, pois observar
e identificar possíveis problemas ou oportunidade é ação incorporada no
comportamento humano e nos projetos. Os riscos envolvidos são um fator crucial
de tomada de decisão.
Nesse momento, quanto maior as fontes de informações e visões sobre

o projeto, para identificar e analisar riscos, melhor. Em modelos adaptativos,
a participação e contribuição de partes interessadas com opiniões, ideias e
conhecimentos é sempre incentivada e atividades de refinamento e entendimento
sobre o projeto em conjunto são momentos importantes para essa identificação.
Técnicas como Project Model Canvas, Design Thinking e a Lean Inception são
formas de trabalho em grupo para coleta de informações e alinhamentos sobre o
entendimento do projeto.
9.3 REALIZAR A ANÁLISE

QUALITATIVA DOS RISCOS DO
PROJETO
Nesse processo, os riscos são priorizados conforme sua classificação por
probabilidade de ocorrência e impacto previsto sobre os objetivos do projeto.
Essas avaliações são feitas com alto grau de subjetividade por estarem apoiadas
sobre percepções e entendimentos. Para uma boa utilização dessa classificação
é preciso alinhar as expectativas e quais os objetivos a serem atingidos,
equilibrando opiniões, interesses e outras variáveis que podem influenciar a
percepção das partes interessadas envolvidas nessa análise. Esse processo é
dinâmico e ocorre por todos os ciclos de vida do projeto.
A utilização da matriz de probabilidade de impacto é uma ferramenta eficaz

para essa atividade e visualização do quadro geral do projeto diante dos riscos
identificados.
114
9.4 REALIZAR A ANÁLISE

QUANTITATIVA DOS RISCOS DO
PROJETO
Essa análise cria uma visão numérica para avaliação dos riscos
individualmente e no contexto do projeto sobre os impactos que podem ocorrer,
caso se concretizem. Todo o projeto precisa fazer a quantificação de seus
riscos, as características e expectativas relacionadas ao projeto determinarão a
sofisticação dos modelos de análise e profundidade de avaliação. Podemos usar
softwares ou planilhas eletrônicas para registro de dados e calcular fórmulas
e probabilidades através de técnicas como Monte Carlo, Análise da Árvore de
Decisão, Curva S de Análise de Riscos, entre outras.
Os riscos classificados na análise qualitativa são a entrada para esse

processo, mas a influência é mútua, pois as análises são complementares. As
avaliações precisam considerar o grau de incerteza envolvido para saber se estão
dentro do percentual aceitável de tolerância acordado.
9.5 PLANEJAR AS RESPOSTAS AOS

RISCOS DO PROJETO
É o processo que após a classificação dos riscos e sua avaliação quantitativa
cria planos para as ações necessárias de forma coordenada entre os responsáveis
definidos para a sua execução. A capacidade de implementar essas ações da
forma mais rápida e eficaz pode ser a diferença entre o sucesso ou fracasso de
um projeto.
As respostas devem ser coerentes com a relevância do risco ao projeto.

O cuidado para evitar um excesso de cuidado e precaução pode gerar gastos
desnecessários de recursos financeiros, físicos e de pessoas. A capacidade de
lidar com situações novas provará a antifragilidade da estrutura de gerenciamento
de riscos e o gerente de projetos precisa interligar o que acontece no processo
de integração das ações de mudança, avaliando com a equipe de gerenciamento
dos riscos, novos possíveis riscos.
115
9.6 IMPLEMENTAR AS RESPOSTAS A

RISCOS DO PROJETO
São as ações de implementação e efetivação das respostas definidas no
plano de gerenciamento de riscos. É fundamental que o engajamento de todos os
envolvidos identificados nos planos de gerenciamento de riscos, e responsáveis
pelas ações, realizem suas funções nos momentos determinados.
9.7 MONITORAR OS RISCOS DO

PROJETO
Nesse processo é monitorada a implementação das respostas aos riscos,
avaliando se estão seguindo o que foi determinado no plano de gerenciamento
dos riscos quanto a prazos, papéis-chaves, resultado alcançado e outros
parâmetros acordados. As informações coletas são utilizadas para comunicação
do andamento do projeto quanto a sua exposição a riscos e impactos dos casos
que se concretizaram.
10 GERENCIAMENTO DAS
AQUISIÇÕES DO PROJETO
É a área de conhecimento que cuida dos processos relacionados a
comprar ou adquirir produtos, serviços externos à equipe do projeto. Os
impactos de obrigações legais e penalidades relacionadas a contratos e acordos
comerciais são um ponto crucial para mitigar ou eliminar os riscos envolvidos.
Por essas questões, muitas organizações utilizam a sua própria estrutura de
compras e logística para esse gerenciamento, mas também pode ser definido o
acompanhamento de um profissional com as especializações necessárias para
116
a equipe de gerenciamento de aquisições, repassar para o gerente de projetos,

terceirizar esse processo para uma empresa especializada ou outra solução mais
adequada à realidade das aquisições necessárias ao projeto.
FIGURA 17 – PROCESSOS DE GERENCIAMENTO DAS

AQUISIÇÕES AO LONGO DAS FASES DO PROJETO
FONTE: O autor
Os acordos firmados entre as partes (projeto e fornecedor) precisam

ser claros, respeitando as regras legais e de governança de ambas as partes.
Geralmente, as organizações possuem regras específicas sobre aquisições que
serão aplicadas ao projeto ou novas regras podem ser acordadas, caso o projeto
seja uma situação que foge dos padrões e experiências anteriores à organização.
O envolvimento de uma equipe jurídica especializada em contratos comerciais
é aconselhado para projetos que envolvem maior complexidade, como vários
fornecedores com ações coordenadas, jurisdições internacionais, altos valores
vinculados, financiamentos bancários e públicos, entre outras possibilidades.
Tem aumentado a visão do fornecedor como um parceiro para o atingimento

dos resultados esperados pelo projeto, a ideia de “ganha-ganha”, em que o
equilíbrio dos resultados entre as partes é um dos principais balizadores para a
condução desse tipo de relação comercial. O compartilhamento de riscos, tanto
positivos como negativos, ajuda no engajamento das partes com a qualidade e
resultado esperado ao projeto.

DAS AQUISIÇÕES DO PROJETO
É a criação de plano de gerenciamento das compras definidas para o projeto
e principais fornecedores em potencial. Serão definidas as regras de aquisição
a ser realizada para as compras, prazos, orçamentos aprovados, percentual de
117
tolerância a variações, aprovadores, documentação necessária, regras legais e

comerciais a serem seguidas, avaliação jurídica quando necessária, padrões de
qualidade e outros aspectos que sejam necessários para a realização da compra
e sua incorporação ao projeto. Definições entre fazer ou comprar estão incluídas
nesse processo para deixar claro o que será realizado pela equipe do projeto ou
fornecedor.
O gerente de projetos e a equipe de gerenciamento das aquisições devem

estar preparados para equilibrar as variáveis das outras áreas de conhecimento
em relação às aquisições, pois mudanças ocorridas em qualquer uma delas
podem ter impactos sobre as aquisições. Os contratos podem seguir dois tipos:
• Preço fixo – quando os preços são definidos na celebração do contrato,

geralmente eles são usados para requisitos que são bem definidos e
não são esperadas grandes variações no decorrer do projeto. Existem
variações como de preço fixo garantido, com remuneração de incentivo,
ajuste econômicos de preço, entre outros.
• Custos reembolsáveis – é quando existe o acordo de reembolso dos
custos relacionados e acordados para a entrega do produto ou serviço
adquirido, mais o lucro previsto ao fornecedor. Esse tipo de contrato é
utilizado quando existe previsão de mudanças durante a duração do
contrato. Existem variações com remuneração fixa, remuneração de
incentivo, remuneração concedida, entre outras.
Também é comum situações híbridas para atender melhor às necessidades

do projeto. A visão de equilíbrio entre as partes é o orientador para essas
definições.
10.2 CONDUZIR AS AQUISIÇÕES DO

PROJETO
É a efetivação dos planejamentos de aquisições com a seleção dos
fornecedores, celebração dos contratos e seu acompanhando. Esse processo
ocorrerá conforme o cronograma do projeto e conforme os ajustes de adaptação
ocorrerem.
Esse processo pode ser conduzido pela equipe de aquisições da organização

responsável pelo projeto, pela equipe de gerenciamento do projeto, por terceiros
ou variações dos modelos anteriores, conforme o acordado para o projeto. A
transparência, ética e legalidade dessas transações são atributos cada vez mais
exigidos pelo mercado nacional e internacional.
118
10.3 CONTROLAR AS AQUISIÇÕES

DO PROJETO
As ações relacionadas à controle dos contratos, ajustes através
demudanças, realizar os alinhamentos necessários e encerramento de contratos
finalizados ou suspensos estão relacionados ao processo de controlar as
aquisições. Ele quer garantir que os acordos firmados sejam cumpridos e mantido
o equilíbrio entre as partes. Essa gestão pode ser compartilhada entre o projeto e
o fornecedor e a coordenação das informações para evitar distorções.
O gerenciamento integrado das mudanças para aquisições necessita que

a equipe do projeto tenha consciência e domínio dos impactos, principalmente
legais, que as mudanças podem causar aos contratos firmados.
As informações sobre o andamento dos contratos quanto a prazos e

entregas são parte dos controles que serão fundamentos para pagamentos aos
fornecedores e continuidade dos trabalhos do projeto para atingir os prazos e
objetivos determinados. Durante o encerramento desse processo, os contratos
finalizados são formalizados com o fornecedor com o encerramento de
pagamentos pendentes e outros acordos firmados.
11 GERENCIAMENTO DAS PARTES

INTERESSADAS DO PROJETO
As partes interessadas, ou Stakeholders, como algumas literaturas usam é
algo que todo o projeto, independentemente do seu tamanho, contexto ou segmento
de mercado precisa para realizar um gerenciamento equilibrado e equitativo.
Identificar as pessoas, organizações, grupos, entidades governamentais,
representações sociais e outros possíveis agentes que podem ser impactados ou
impactar o projeto. A avaliação, engajamento e comunicação com os diferentes
grupos são a base para essa área de conhecimento, entendendo expectativas
e alinhando todos os interesses em uma estratégia baseada na transparência,
respeito e responsabilidades sociais do resultado do projeto.
119
FIGURA 18 – PROCESSOS DE GERENCIAMENTO DAS PARTES

INTERESSADAS AO LONGO DAS FASES DO PROJETO
FONTE: O autor
Essa identificação de partes interessadas começa na iniciação do projeto e

ocorre até o momento do encerramento, pois um mapeado que não considere
alguma parte do interessado pode gerar atrasos, aumento de custos, inviabilização
de entregas ou o projeto gerando disputas legais. Um exemplo é o projeto da
Usina de Belo Monte, onde o mapeamento de partes interessadas não identificou
grupos sociais que seriam profundamente impactados e que em um determinado
momento causaram vários problemas com ações para resguardar seus direitos
sobre os impactos decorrentes.
O gerente de projetos tem nessa área de conhecimento suas habilidades

de alinhamento muito exigidas, conciliação e ações agregadoras, trabalhando
a empatia, entendimento dos motivadores e criando ambiente de discussão e
acordos entre as partes interessadas em torno das decisões que melhor atendam
ao projeto.
Ambientes de alta complexidade, que trabalham modelos adaptativos,

utilizam uma maior frequência de alinhamentos e ajustes nos acordos entre
as partes interessadas. Para uma melhor fluidez e redução de ruídos de
comunicação, a proximidade com esses grupos, criando canais de comunicação
democráticos e transparentes para a troca de experiências e opiniões, pode ser
realizada com técnicas de facilitação, como por exemplo, o Design Thinking, Lean
Inception, Project Model Canvas, entre outros.
120
11.1 IDENTIFICAR AS PARTES

INTERESSADAS DO PROJETO
Esse é um dos primeiros processos a ser realizado na iniciação do projeto.
Em um levantamento inicial, junto ao termo de abertura do projeto é feito o
mapeamento de interesses, interdependências, influência e impactos ao projeto
dos grupos de interesse identificados.
Esses levantamentos contribuirão para as outras áreas de conhecimento

no direcionar dos seus esforços para atingir às expectativas definidas nos
objetivos do projeto. O gerente de projetos e a equipe de gerenciamento precisam
considerar as partes interessadas da forma mais abrangente possível, para
aumentar as chances de sucesso do projeto, reduzindo riscos.
Uma prática que vem ganhando força para o trabalho com as partes
interessadas para o alinhamento de expectativas, identificação de problemas
e direcionamento de soluções com práticas e conhecimentos emergentes do
trabalho em grupo são as Estruturas Libertadoras. São um conjunto de dinâmicas
e ações desenvolvidas inicialmente por Keith McCandless e Henri Lipmanowicz
(2013), no livro The Surprising Power of Liberating Structures, em que apresentam
a capacidade de grupos trabalharem o melhor dos seus conhecimentos, de
forma ordenada e dinâmica, criando o ambiente adequado para discussões e
engajamento de todos pelo sentimento de pertencimento e objetividade das
discussões em torno de resoluções coletivas, ampliando a visão sobre aspectos
cruciais dos assuntos tratados.
11.2 PLANEJAR O ENGAJAMENTO

DAS PARTES INTERESSADAS DO
PROJETO
É o processo para desenvolver como será realizado o engajamento das
partes interessadas ao projeto, contribuindo para a construção dos seus objetivos,
alinhamento das expectativas, mapeamento na influência e impactos sobre o
projeto desses grupos e como o projeto os impactará. O objetivo é criar um plano
para que essas ações sigam uma estrutura lógica, tendo a capacidade de se
adaptar às novas variáveis ao longo do projeto.
A criação de listas, mapas mentais ou outras formas de representação

são criadas para esse plano, deixando claro quais são as partes interessadas
121
identificadas, seu impacto ao projeto e o quanto serão impactados para criar

planos de comunicação, definir canais, riscos envolvidos e planos de ações
relacionados. A importante informação que esse plano quer ajudar a amadurecer
é a compreensão do engajamento ao projeto de cada parte interessada,
classificando da seguinte forma:
• Desinformado – sem conhecimento do projeto e dos impactos.

• Resistente – tem consciência do projeto, mas é contra as mudanças que
o impactaram.
• Neutro – tem consciência do projeto, mas não apoia e nem é contra.
• Apoiador – tem consciência do projeto e é a favor dos resultados
esperados.
• Líder – tem consciência do projeto e está engajado para sua realização e
sucesso.
É importante estar consciente de que esses planos e classificações são

situações que precisam de revisões constantes, pois dependendo da dinâmica de
complexidade envolvida, os ajustes podem ter frequências que podem variar mais
ou menos ao longo do projeto.
11.3 GERENCIAR O ENGAJAMENTO

PROJETO
Esse processo se concentra em comunicar e trabalhar com as partes
interessadas para sua participação no projeto, realização de suas expectativas,
lidar com situações não previstas e alterações percebidas no mapeado realizados
até o momento, seguindo o plano de gerenciamento definido. O que o gerente
de projetos mais trabalha é a comunicação e avaliação dos feedbacks sobre
o entendimento dos grupos de interesse sobre o andamento do projeto e seus
resultados, diminuindo os possíveis ruídos que podem prejudicar o engajamento.
A gestão de conflitos é uma constante para a equipe de gerenciamento do

projeto, trabalhando a negociação entre as partes com transparência e respeito
às diversidades dos grupos envolvidos, às políticas organizacionais e aos valores
éticos e morais envolvidos. Essas situações devem ser tratadas em conjunto com
a integração das mudanças para evitar que os planos fiquem desalinhados às
novas decisões e à realidade do projeto.
122
11.4 MONITORAR O ENGAJAMENTO

PROJETO
São as ações associadas ao monitoramento das ações implementadas e o
plano de gerenciamento para efetuar os ajustes e mudanças necessários para
manter o alinhamento entre o previsto e realizado. A velocidade na identificação
através do monitoramento de desalinhamentos pode evitar muitos problemas de
comunicação e boatos sobre o projeto.
O gerente de projetos, além das técnicas de monitoramento e gerenciamento,

precisa saber criar canais de comunicação de confiança com as partes
interessadas, muitas vezes mais informais, para conseguir extrair informações
e opiniões que podem não estar expostas e que têm grande impacto sobre o
engajamento aos objetivos do projeto.
Uma indicação interessante para estudos é um mapa criado

dos processos distribuídos ao logo das fases dos projetos com as
ligações mais prováveis entre as suas ações. Este material foi feito
por Ricardo Vargas e está disponível em seu site, no link https://
ricardo-vargas.com/pt/pmbok6-processes-flow/.
1) Esta área de conhecimento incorpora o gerenciamento dos

critérios de ___________ relacionados ao projeto e ao produto
que será entregue, gerando suporte para as políticas e ações de
melhoria dos processos e produtos do projeto. De qual área de
conhecimento estamos falando?
a) ( ) Gerenciamento dos riscos.

b) ( ) Gerenciamento dos custos.
c) ( ) Gerenciamento da qualidade.
d) ( ) Gerenciamento do escopo.
123
2) É o processo para desenvolver como será realizado o

engajamento das partes interessadas ao projeto, contribuindo
para a construção dos seus objetivos, alinhamento das
expectativas, mapeamento na influência e impactos sobre o
projeto desses grupos e como o projeto os impactará. Estamos
falando de qual processo?
a) ( ) Identificar as Partes Interessadas do Projeto.

b) ( ) Gerenciar o Engajamento das Partes Interessadas do Projeto.
c) ( ) Planejar o Engajamento das Partes Interessadas do Projeto.
d) ( ) Monitorar o Engajamento das Partes Interessadas do Projeto.
Ao longo deste capítulo, observamos e avaliamos as áreas de conhecimento
entendendo seus processos, principais responsabilidades e a interligação
existente para a realização do projeto.
Um projeto precisa ser direcionado ao resultado dos objetivos acordados.

Existem ações aplicadas a uma área de conhecimento específica através de um
determinado processo, mas os resultados e impactos não se limitaram somente
a ele, irradiando consequência em todo o projeto com maior ou menor impacto.
A capacidade de observação, análise dos cenários e adaptação à nova realidade
serão habilidades essenciais a todos os envolvidos com o projeto, pois o resultado
do projeto é uma soma de ações, processos, comportamentos e atitudes.
REFERÊNCIAS
ANDERSON, D. J. Kanban: mudança evolucionária de sucesso para seu
negócio de tecnologia. 1. ed. São Paulo: Martins Fontes, 2011.
BROWN, T. Design Thinking. 1. ed. Rio de Janeiro: Campus, 2009.
CARNEIRO, M. F. Santos. Gestão Pública: o papel do planejamento estratégico,

124
CAROLI, P. Lean Inception: como alinhar pessoas e construir o produto certo.

1ª. ed. São Paulo: Editora Caroli, 2018.
DEMING. W. Edwards. Qualidade: a revolução da administração. 3. ed. Rio de

Janeiro: Saraiva, 1990.
GÖDEL, K. F. Acerca das proposições formalmente indecidíveis dos principia

mathematica e sistemas correlatos. In: LOURENÇO, M. (org.). O Teorema de
Gödel e a Hipótese do Contínuo. Lisboa: Fundação Calouste Gulberkian, 1977.
GOLDRATT, E. M. A Meta: Teoria das Restrições (TOC) aplicada à indústria. 3.

ed. São Paulo: Nobel, 2014.
GOLDRATT, E. M. Corrente crítica: Teoria das Restrições (TOC) em gestão de

projetos. São Paulo: Nobel, 2014.
GUIA PMBOK®. A Guide to Project Management Body of Knowledge. 6. ed.

Project Management Institute – PMI®, 2017.
MACCANDLESS, K.; LIPMANOWICZ, H. The Surprising Power of Liberating

Structures. 1. ed. Seatle: Liberating Structures Press, 2013.
MEADOWS, D. H. Thinking in Systems. 1. ed. Vermont, 2008.

OHNO, T. O Sistema Toyota de Produção: além da produção em larga escala.

Porto Alegre, 1997.
OSINGA, F. P.B. Science, Strategy and War – The strategic theory of John
Boyd. 1. ed. New York: Routledge, 2007.

Brasport, 2011.
RICHARDS, C. Certain to Win – The strategy of John Boyd, Applied to Business.

1. ed. Indiana: Xlibris, 2004.
SENGE, P. M. A Quinta Disciplina: arte e prática da organização que aprende.

23. ed. Rio de Janeiro: Best Seller, 2013.
125
SUTHERLAND, J. SCRUM: a arte de fazer o dobro do trabalho na metade do

tempo. 1. ed. São Paulo: Leya, 2014.
TALEB, N. N. Antifrágil: coisas que se beneficiam com o caos. 5. ed. Rio de

Janeiro: Best Business, 2017.
TALEB, N. N. A lógica do Cisne Negro: impacto do altamente improvável. 9. ed.

Rio de Janeiro: Best Business, 2015.
126
C APÍTULO 3
Modelo Geral para Gerenciamento
de Projetos

• aprender a utilizar as boas práticas de gestão de projetos segundo

o Guia PMBOK® do Project Management Institute — PMI,
PRINCE2™ – Manual de Gerenciamento de projetos do Reino Unido
e amplamente utilizado e SCRUM para projetos de práticas ágeis;
• reconhecer o papel estratégico da gestão de projetos no alcance de resultados;
• visualizar completa e sistemicamente o papel do gerenciamento de projetos

dentro das organizações e entender porque essa alternativa é importante e
como ela impacta o desempenho das organizações públicas e privadas;
• aplicar a prática em todo o aprendizado com objetivo de

garantir o melhor uso das ferramentas exploradas.
128
Capítulo 3 Modelo Geral para Gerenciamento de Projetos
Para ser um gerente de projeto bem-sucedido, você precisa ter condições
de visualizar todo o projeto do início ao fim, entender a sua complexidade e ter a
capacidade de atingir os resultados esperados com o seu projeto, utilizando os
métodos adequados. Essa necessidade é de extrema importância para que você
possa acompanhar o dinamismo e complexidade presentes nos dias de hoje. Os
gerentes de projeto precisam tornar suas práticas de gerenciamento mais flexíveis
e adaptáveis.
As metodologias tradicionais de gerenciamento de projetos têm se mostrado

muito rígidas, burocráticas e lentas. De fato, essas metodologias tradicionais
podem funcionar em ambientes com necessidades mais conservadoras. Hoje,
precisamos responder com agilidade a problemas e mudanças crescentes e
constantes. A documentação formal e os processos envolvidos no gerenciamento
tradicional de projetos podem sobrecarregá-lo se você quiser adotar todas as
práticas apresentadas.
Alguns gerentes de projeto podem ser excessivamente analíticos e investir

muito tempo no aperfeiçoamento ou preocupações com detalhes, quando
realmente deveriam se concentrar em alcançar marcos e na conclusão do projeto.
O gerenciamento flexível de projetos requer um equilíbrio entre o lado emocional
e o lado racional, ou seja, precisamos balancear habilidades técnicas com
habilidades comportamentais.
Não seria ótimo trabalhar sem pressão de prazo, restrições de dinheiro,

pessoas e recursos? Na prática, não é assim que funciona, temos 24 horas por dia
e uma semana de 7 dias e fomos ensinados desde o início sobre a importância de
utilizarmos o nosso tempo adequadamente. Como os projetos possuem restrições
de cronograma, orçamento, pessoas e recursos, é de extrema importância que
o processo do projeto seja constantemente conduzido para a sua conclusão.
Mais acabativas e menos iniciativas. Atualizações nas documentações, reuniões
e acompanhamentos regulares são essenciais para atingimento dos resultados
propostos.
O pensamento de escalar uma grande montanha de uma só vez pode ser

impossível. Mas vê-la como uma sucessão de etapas é mais fácil e motivador.
Da mesma forma, você não deveria entrar em um projeto com a intenção de criar
todos os resultados do projeto de uma só vez. Trabalhe em cada entrega passo a
passo, obtenha revisões e aprovações e mantenha sempre um senso de direção.
Encoraje atos de liderança em todos os membros da equipe, criando um
129
ambiente onde eles não se sintam desconfortáveis ao relatar preocupações ou

dificuldades. Com isso, você obterá maior engajamento e terá mais controle sobre
as situações de riscos. Isso reduz o risco de erros, economizando tempo e dinheiro.
Lembre-se, a comunicação é vital em todos os aspectos do gerenciamento de
projetos. Adote uma política de comunicação aberta, incentivando todos os
membros a expressarem.
Embora as práticas de gerenciamento de projetos tenham mudado para

serem mais flexíveis e abertas, a base permanece a mesma. O sucesso do
projeto ocorre quando é entregue dentro do cronograma, dentro do custo, com
resultados satisfatórios para o cliente.
Neste capítulo, vamos apresentar a metodologia PRINCE2™ de gestão de

projetos e como conduzir projetos de software utilizando o framework de gestão
ágil SCRUM. Vale ressaltar que este material não pretende substituir o manual
oficial do PRINCE2™, por essa razão, para continuar evoluindo o seu aprendizado
sobre o tema, recomenda-se a leitura do livro oficial.
Indicamos a leitura do seguinte material: OGC – Office of

Government Commerce. Gerenciando Projetos de Sucesso com
Prince2. Londres: TSO, 2011.
2 METODOLOGIA PRINCE2™ DE
GESTÃO DE PROJETOS
PRojects IN Controlled Environments ou Projetos em ambientes controlados
(PRINCE) é um método de gerenciamento de projetos não proprietário genérico,
a ponto de poder ser aplicado a qualquer projeto, independentemente de seu
porte, tipo, organização, região geográfica ou cultura (OGC, 2011).
Isso é possível porque o PRINCE2™ isola o gerenciamento do projeto

(ex.: aspectos ligados ao escopo, tempo, custo, qualidade, riscos, benefícios,
tolerâncias etc.) das contribuições especializadas (o esforço para realizar o
produto, ex.: design, construção etc.). Assim, os métodos de produção dos
aspectos especializados são facilmente integrados com o método PRINCE2™,
formando um framework completo para o projeto (OGC, 2011).
130
FIGURA1 – ESTRUTURA DO PRINCE2
FONTE: O autor
Como o PRINCE2™ é genérico e se baseia em princípios práticos

comprovados do método que são necessários para o alcance de sucesso nos seus
projetos, as organizações que adotam o método como padrão podem melhorar
substancialmente sua capacidade organizacional e maturidade em diversas áreas
de atividade. A metodologia possui flexibilidade bastante interessante que permite
a ligação com outras abordagens de condução de projetos como o SCRUM para
projetos Ágeis (HIFLEX, 2018).
A contextualização inicial deste capítulo trouxe a importância de

entendermos os princípios por trás dos modelos que utilizamos no nosso dia a
dia. Por que fazemos o que fazemos? O que nos motiva na adoção de um novo
comportamento? Se você optar por utilizar o PRINCE2 como metodologia de
gerenciamento de projetos, você precisa seguir os princípios que sustentam essa
prática.
Para Ribeiro (2011, p. 12), “O método PRINCE2 é composto por Princípios,

Temas, Processos e Ambiente do projeto, cobrindo todos os aspectos necessários
para proporcionar um bom gerenciamento de projetos”. Assim, não basta copiar
os modelos apresentados, se você não praticar os princípios que o sustentam.
3 PRINCÍPIOS
Os princípios nos quais o PRINCE2 se baseia têm origem em lições
aprendidas em projetos tanto positivas quanto negativas. Elas proporcionam um
131
framework de boas práticas para os envolvidos em projetos. Se um projeto não

aderir a esses princípios, não será gerenciado de acordo com o PRINCE2, porque
os princípios são o elemento que define um projeto PRINCE2 (OGC, 2011).
FIGURA 2 – PRINCÍPIOS DO PRINCE2™
FONTE: O autor
• Justificativa para o negócio: justificativa continuada para iniciar, criar e

o/ou manter o projeto para o negócio.
• Aprendizado através da experiência: à medida que você utiliza a
metodologia para conduzir os projetos, você deverá aprender com suas
experiências anteriores.
• Papéis e responsabilidades: clareza na definição de papéis e
responsabilidades acordadas com a organização.
• Gerenciamento por estágios: dada a complexidade do seu projeto,
você precisa definir, planejar, monitorar e controlar os estágios.
• Gerenciamento por exceção: podemos comparar a exceção com
alçadas. Ou seja, os níveis de tolerância precisam ser definidos para
o projeto. Através dele, serão tratadas as opções de delegação de
autoridade.
• Foco em produto: foco na definição e entrega dos produtos do projeto.
• Adaptação: o modelo tem aderência para se adequar ao tamanho
do projeto. Contexto da organização, complexidade, importância,
capacidade e riscos envolvidos.
Projetos que utilizam os princípios do PRINCE2™ possuem alta flexibilidade

de adaptação para atender às necessidades organizacionais.
132
4 TEMAS
Os temas fornecem informações sobre como o projeto deve ser gerenciado.
Eles podem ser considerados áreas de conhecimento ou como os princípios
são colocados em prática. Eles são configurados no início do projeto e depois
monitorados. Os projetos são mantidos no caminho, abordando constantemente
os seguintes temas:
FIGURA 3 – TEMAS DO PRINCE2
FONTE: O autor
• Business Case: é o documento que contém todas as informações do

porquê o projeto está sendo realizado e quais benefícios esperados.
• Organização: foco na organização temporária criada para viabilizar o
projeto, tendo claro os papéis e responsabilidades.
• Qualidade: definição dos indicadores de qualidade do produto do
projeto.
• Planos: planos são produtos do planejamento. O Ato de planejar
é contínuo e os planos devem deixar claros os procedimentos de
comunicação, controle das entregas previstas no projeto conforme
acordado nos critérios de qualidade.
• Riscos: gerenciamento dos riscos do projeto. Risco é um evento
que pode trazer impactos negativos ou positivos em projetos. São as
incertezas previstas no contexto do projeto.
• Mudanças: sabido que o projeto sofrerá mudanças na sua execução,
essa é a única certeza que temos quando iniciamos um projeto. Como
133
você fará a gestão de mudanças? Qual o impacto no todo?

• Progresso: gestão da evolução do projeto, monitorando o seu
desempenho e tomando ações necessárias para atingimento do objetivo
e entrega dos benefícios esperados. Onde estamos nesse momento?
Quanto falta para terminarmos?
Os temas PRINCE2™ são categorias funcionais – ou áreas de conhecimento

– que um projeto deve usar em qualquer momento do seu ciclo de vida. Cada
parte trabalha em conjunto para permitir que se chegue ao destino com o máximo
conforto.
5 PROCESSOS
A metodologia PRINCE2™ separa o projeto inteiro em várias etapas e cada
uma é gerenciada de maneira separada. São sete os processos envolvidos, a
saber:
FIGURA 4 – CICLO DE VIDA DE PROJETOS PRINCE2
FONTE: O autor
134
• Lançar um projeto: responsável por garantir a viabilidade do projeto

antes da sua iniciação.
• Direcionar projeto: responsável por assegurar condições adequadas
para um bom direcionamento do projeto. As ações desse processo são
conduzidas pelo comitê diretor do projeto e lidam com a tomada de
decisão.
• Iniciar projeto: responsável por assegurar que todos estejam alinhados
sobre o projeto (objetivos, escopo, qualidade, benefícios etc.).
• Gerenciar transição dos estágios: responsável por levar informações
ao Comitê diretor do projeto para tomada de decisões sobre a
continuidade ou não do projeto.
• Controlar estágios: responsável pelas atividades de monitoramento
e controle do projeto. Normalmente, ocorrem entregas parciais até a
conclusão do projeto.
• Gerenciar entregas do produto: responsável por inspecionar os
padrões de qualidade pré-estabelecidos e dentro do planejamento
previsto.
• Encerrar projeto: responsável por garantir o encerramento controlado
do projeto.
6 ADAPTABILIDADE DO PRINCE2™
“O processo de adaptação ou Tailoring do PRINCE2 é realizado de acordo
com a necessidade do projeto. Nesse caso, deve-se avaliar a sua aplicação
projeto por projeto. Isso é muito diferente da implementação do PRINCE2 por
toda uma organização, ou seja, 'incorporação'.
Existem várias razões pelas quais as organizações optam por adaptar em

vez de incorporar. Isso pode ser devido ao tamanho da empresa, à cultura da
empresa ou à frequência de projetos de longo prazo. A complicação excessiva
do seu projeto para atender a todas as facetas da metodologia PRINCE2 anula o
propósito de usá-lo em primeiro lugar. Afinal, um dos sete princípios do PRINCE2
é “adaptado ao ambiente” (PRINCE2, 2017).
Para Ribeiro (2011, p. 17), “Vale ressaltar que a ‘adaptação’,

principalmente nos processos e temas, não significa que esses elementos ou
parte deles podem ser retirados. A retirada total ou parcial destes elementos e dos
princípios, descaracteriza o uso do método PRINCE2™”. A grande reflexão é se a
abordagem e controles escolhidos estão adequados ao tamanho e complexidade
do projeto e o seu ambiente organizacional.
135
7 CICLO DE VIDA OU JORNADA DE

UM PROJETO PRINCE2™
O PRINCE2 é uma abordagem baseada em processos para gerenciamento
de projetos, fornecendo um método facilmente adaptável e escalável para o
gerenciamento de todos os tipos de projetos. Cada processo é definido com suas
principais entradas e saídas, junto aos objetivos específicos a serem alcançados
e às atividades a serem realizadas.
Um processo é uma série de etapas e decisões envolvidas na maneira como

o trabalho é concluído. Podemos não perceber, mas os processos estão em toda
parte e em todos os aspectos de nosso lazer e trabalho. Um processo consiste
em quatro elementos principais:
1) Etapas e decisões – o fluxograma. Uma série de etapas e decisões que

descrevem a maneira como o trabalho é concluído.
2) Variabilidade do tempo e fluxo de processamento – o padrão dos tempos
de processamento.
3) Momento e interdependência – quando as chegadas acontecem,
quando as pessoas trabalham etc.
4) Atribuição de recursos – quantos e onde eles estão atribuídos.
A definição expandida de um processo descreve o comportamento do

sistema atual.
Segundo o Guia PMBOK® (2017), um processo é um conjunto de ações

e atividades inter-relacionadas, que são executadas para alcançar um produto,
resultado ou serviço predefinido. Cada processo é caracterizado por suas
entradas, as ferramentas e as técnicas que podem ser aplicadas e as saídas
resultantes.
FIGURA 5 – ESTRUTURA DE UM PROCESSO
FONTE: O autor
136
A figura a seguir representa os processos relacionados ao ciclo de vida de

um projeto PRINCE™. Vamos explorar cada um deles.
FIGURA 6 – PROCESSO DO PRINCE2
FONTE: O autor
7.1 LANÇANDO UM PROJETO OU

STARTING UP A PROJECT (LP/SU)
Este é o primeiro dos sete processos PRINCE2. Responsável por garantir
que os requisitos para o início do projeto estejam bem definidos e sua viabilidade
analisada. Repare que esse processo inicia dentro do estágio de pré-projeto.
Busca-se nesse momento validar a necessidade de execução do projeto e quais
benefícios o projeto terá para a organização. Lembrando que a organização não
consegue executar todas as propostas de projeto. Existe uma limitação de custo,
tempo e pessoas que precisam ser analisadas. Por enquanto, nada poderá ser
realizado antes de:
• Apresentar estudo de viabilidade (Business Case preliminar) consistente

que será avaliado pelo comitê diretor do projeto.
• Definir os níveis de autoridades necessárias para a iniciação do projeto.
• Obter informações suficientes sobre o escopo do projeto.
• Analisar, junto à opinião especializada, as várias opções de viabilizar a
execução/entrega do projeto.
• Identificar e nomear as pessoas responsáveis pela execução do projeto
e/ou de grande importância para o gerenciamento do projeto.
137
• Documentar um plano de estágio, identificando e planejando o trabalho

necessário para iniciar o projeto.
Esse processo utiliza o “mandato do projeto” ou “project mandate”, que

fornece uma definição básica de quais razões existem para o projeto ser iniciado
e quais são os resultados esperados do projeto. É um documento de proposição
inicial do projeto.
FIGURA 7 – VISÃO GERAL DO SU/LP
FONTE: O autor
Durante o processo de LP/SU, o plano da etapa de Iniciação será criado,

o resumo do projeto será preparado, a equipe de gerenciamento de projetos
será nomeada e as informações exigidas pela equipe de projeto PRINCE2 serão
compiladas.
Atividades realizadas:
• Revisar a proposição de projeto e verificar o entendimento.

• Nomear o executivo e o Gerente de projetos.
• Definir responsabilidades do executivo.
• Elaborar a descrição do papel do executivo.
• Estimar o tempo e esforço requeridos para o papel.
• Identificar, entre os elegíveis, a pessoa mais apropriada.
• Confirmar a disponibilidade do selecionado e seu interesse.
• Designar a pessoa à função de executivo.
• Definir as responsabilidades do gerente de projetos.
• Elaborar a descrição do papel do gerente de projetos e obter aprovação
138
dos demais membros da gerência corporativa ou do programa.

• Estimar o tempo e esforço requeridos para o papel de gerente de
projetos.
• Confirmar a disponibilidade do selecionado e seu interesse no papel de
gerente de projetos.
• Designar a pessoa à função de gerente de projetos.
• Confirmar a nomeação com a gerência corporativa ou do programa.
• Aprender com experiências anteriores, um dos princípios do PRINCE™,
é uma atividade prática que busca nos ativos dos processos
organizacionais, lições de projetos anteriores com objetivo de apoiar
o planejamento do projeto atual. É uso da gestão do conhecimento do
projeto. Em projetos similares, você pode encontrar respostas para
questões, como por exemplo: Como foi feita a gestão dos times? Como
foram definidas as exceções ou alçadas do projeto? Quais foram os
riscos e quais aconteceram e quais foram as respostas adequadas e por
quê?
• Definir e nomear a equipe de gerenciamento do projeto. Projetos são
realizados por pessoas e é de fundamental importância identificar as
pessoas e competências necessárias para executar o projeto com
sucesso. Importante não esquecer dos aspectos comportamentais nessa
etapa. Já vimos projetos não evoluírem como o esperado, simplesmente
por terem pessoas de perfis parecidos (muito analíticos), o excesso
desse perfil estava tornando o projeto extremamente detalhado e que
estava o deixando com atrasos no cronograma. A solução foi buscar um
profissional com a mesma competência técnica, porém com um perfil
mais executor. Clareza na definição de papéis e responsabilidades e
níveis de alçadas precisa ser de conhecimento de todos. Você pode
juntar essa etapa com o Guia PMBOK® (2017) e vincular a estratégia de
gerenciamento das partes interessadas.
• Desenvolver o Business Case ou Caso de negócio. Um dos elementos
fundamentais dentro da metodologia, o Caso de negócio é o documento
que vai deixar claro para todos o porquê daquele projeto ser realizado. É
a expressão do propósito daquele projeto. No estágio de pré-projeto, a
proposição de projeto gera um documento que será o Caso de negócio
preliminar. Esse documento deve conter:
- Definir objetivos e as motivações para o projeto.
- Deixar claros os benefícios esperados.
- Clarificar a fonte de financiamento.
- Reunir informações históricas relevantes.
- Buscar aprovação, se necessário.
- Detalhamento do produto que será entregue pelo projeto. Geralmente
essa etapa é realizada pelo gerente de projetos em conversas com
as partes interessadas mais relevantes do projeto. Identificando e
139
detalhando os requisitos do produto (O que?) e do projeto (Como?).

Você também poderá utilizar uma WBS ou EAP para comunicar de
forma clara o produto do projeto e seus requisitos.
- Identificar e acordar as expectativas de qualidade.
- Identificar e acordar os critérios de aceite das entregas do projeto.
- Identificar e acordar os pontos de controle principais.
- Identificar os riscos e suas respostas, principalmente relacionados à
viabilidade.
• Selecionar a abordagem do projeto e montar o sumário do projeto. Dada
a complexidade e urgência do projeto, qual a melhor abordagem de
gestão para se alcançar os objetivos do projeto? Essa etapa tem como
objetivo compreender quais são as alternativas, estratégia para condução
do projeto. Um processo disponível no Guia PMBOK (2017), na área de
conhecimento de aquisições, é a decisão de fazer ou comprar. Com base
no entendimento do escopo, avalia-se a decisão de fazer internamente
ou se é melhor fazer a contratação de terceiros para entregar o escopo
e atender às necessidades descritas no caso de negócios. Segundo o
Manual PRINCE2 (2011), os seguintes pontos devem ser observados:
- Avaliar as opções para entrega do projeto e utilizar a abordagem
adequada.
- Revisar as lições aprendidas de projetos anteriores e compreender
as abordagens escolhidas e seus motivos.
- Analisar as dependências do projeto com outras iniciativas ou
projetos da organização.
- Compreender o ambiente operacional em que o produto do projeto
deverá se ajustar e fazer integração. Identificar as implicações e
restrições operacionais ou de manutenção.
- Considerar restrições de segurança que se aplicam ao projeto ou
operações de seus produtos.
- Identificar as necessidades de treinamento para a equipe e usuários.
• Montar o sumário do projeto.
- Definir projeto.
- Confirmar os objetivos e os resultados esperados.
- Confirmar o escopo (O que será entregue e o que não será entregue).
- Identificação de premissas e restrições.
- Identificar e definir os níveis de alçadas ou tolerâncias.
- Identificar partes interessadas.
- Identificar as interfaces que o projeto deve manter.
- Incorporar as informações do caso de negócio preliminar (Alto nível).
- Validar a descrição do produto do projeto.
- Revisar a organização do time, papéis e responsabilidades.
- Incorporar no documento a estrutura organizacional do projeto e a
descrição dos papéis.
140
- Usar diário do projeto para registrar novas questões ou riscos.

• Planejar o estágio de iniciação. O trabalho de iniciação de um projeto
requer esforços e consome recursos. Por essa razão, um projeto nasce
no estágio inicial, através do processo “Iniciando um projeto”.
- De acordo com a abordagem escolhida, se deve decidir se os
controles do projeto são suficientes para iniciar o projeto.
- Identificar as restrições de tempo e custos para o estágio de iniciação
e produzir o plano de estágio para este estágio.
- Atualizar o registro dos riscos disponíveis no diário do projeto,
identificando seu impacto no plano de estágio para o estágio de
iniciação.
- Solicitar autorização para iniciar o projeto
7.2 DIRECIONAMENTO DO PROJETO

(DP)
O processo de direcionamento de um projeto é executado desde o início de
qualquer projeto até o seu encerramento. Esse processo é direcionado ao Comitê
diretor do Projeto, que gerencia e monitora a evolução do projeto. O processo
de direcionamento não lida com as atividades diárias do Gerente de projetos. As
responsabilidades contidas nesse processo são:
QUADRO 1 – PROCESSOS X AÇÕES
Processos Ação necessária
SU/LP Autorizar a iniciação
IP Autorizar o projeto
MSB/GTE Autorizar um plano de estágios ou Plano de exceções
Direcionar o projeto (ad hoc)
CS/EP Autorizar o encerramento do projeto
FONTE: O autor
Esse processo do PRINCE2 tem quatro responsabilidades principais em

termos do projeto:
1) Iniciar o projeto PRINCE2, se for considerado viável.

2) Monitorar o progresso enquanto fornece orientação e lidar com situações
de exceção.
141
3) Abordar os limites do estágio.

4) Encerramento do projeto PRINCE2 (planejado ou prematuro).
FIGURA 8 – DIRECIONAMENTO DO PROJETO
FONTE: O autor
A responsabilidade do sucesso ou fracasso do projeto é do Comitê diretor

do projeto, pois é seu dever dar direcionamento e tomar decisões estratégicas
necessárias para o alcance dos objetivos do projeto. Segundo o Manual PRINCE2
(OGC, 2011), o comitê diretor do projeto gerencia por exceção. Monitora através
de relatórios e controla por meio de um pequeno número de pontos de decisão.
A gestão diária do projeto é responsabilidade do gerente de projetos. O Comitê
diretor do projeto é consultado nas cerimônias planejadas e/ou quando algo foge
ou tende a sair dos limites de alçada/tolerância por ele estabelecidos para o
Gerente do Projeto gerenciar os estágios do projeto.
FIGURA 9 – INTERAÇÕES DE APROVAÇÃO COM O COMITÊ DIRETOR DO PROJETO
FONTE: O autor
Segundo Ribeiro (2011), para cada estágio a ser iniciado ou finalizado,

o Comitê diretor do projeto precisa ser acionado para verificar e analisar as
informações e assim tomar decisões sobre o projeto. Um Estágio ou um Plano de
Exceção só podem ser executados após serem aprovados pelo Comitê diretor do
142
projeto.
Pelo fato de o PRINCE2 gerenciar o projeto através de estágios, existem

algumas premissas que precisam ser atendidas antes de transitar de um estágio
para o outro. O objetivo do estágio atual foi atendido? O Plano do estágio seguinte
foi elaborado? Os resultados alcançados, assim como o plano do próximo
estágio, devem ser submetidos ao Project Board para aprovação. O método
PRINCE2 recomenda que o status Final de Estágio com as informações sobre
o andamento do projeto seja aprovado pelo comitê diretor do projeto. Dúvidas
quanto às informações contidas no relatório devem ser esclarecidas pelo Gerente
do Projeto.
7.3 INICIANDO O PROJETO

O processo é realizado durante o estágio de iniciação para garantir que os
seguintes pontos sejam claros para a equipe de gerenciamento do projeto e as
partes interessadas externas. Com base nessas informações, o comitê diretor do
projeto analisa as abordagens e consistência do planejamento feito pelo gerente
de projetos e este deverá elaborar os seguintes planos:
a) Preparar a estratégia de gerenciamento de riscos
Nesta seção, você identifica os riscos de alto nível que você prevê ao
assumir o projeto. Em resposta aos riscos que você identificou, defina o plano
de mitigação de riscos e um plano de exceção detalhado para garantir que
o projeto continue evoluindo e que o nível de motivação da equipe seja alto. A
Estratégia de Gerenciamento de Riscos descreve o procedimento, as funções e
responsabilidades e as diretrizes para o gerenciamento de riscos, incluindo os
padrões para avaliar o impacto no risco. Lembrando que lições aprendidas são
uma excelente fonte de consulta.
b) Preparar a estratégia de gerenciamento de configuração
O gerenciamento de configuração abrange as atividades técnicas e

administrativas relacionadas à criação, manutenção, mudança controlada
e controle de qualidade do escopo do trabalho. Uma configuração são as
características funcionais e físicas de um produto, conforme definido em suas
especificações e alcançado através da implantação de planos de gerenciamento
de projetos. A Estratégia de gerenciamento de configuração descreve como
o gerenciamento de configuração será realizado em um projeto. Durante essa
atividade, o Gerente de Projeto também cria o Registro de Problemas, que será
143
usado para manter o status de todos os problemas formais ao longo do projeto.

Um conjunto inicial de registros de itens de configuração (um artefato comum é
o versionamento dos documentos) também é configurado para acompanhar os
produtos de gerenciamento da linha de base.
De acordo com a metodologia PRINCE2 (2011), uma estratégia de

gerenciamento de configuração do projeto inclui:
• Procedimento de controle de mudança e questões.

• Ferramentas e técnicas que serão utilizadas para a gestão dos itens de
configuração.
• Procedimento para o gerenciamento da configuração com papéis e
responsabilidades bem definidos.
• Cronograma para as atividades de gerenciamento de configuração do
projeto Etc.
c) Preparar a estratégia de gestão da qualidade
Para facilitar as necessidades dos usuários é importante que suas

expectativas de qualidade sejam claramente documentadas, acordadas e
sustentadas durante o projeto. A Estratégia de Gerenciamento da Qualidade
contribui para isso, especificando técnicas, padrões e responsabilidades para
manter a qualidade no projeto. Também é criado um registro de qualidade
durante essa atividade. Isso manterá o status de todas as atividades de controle
de qualidade que serão executadas ao longo do projeto. Uma estratégia de
gerenciamento da qualidade, de acordo com o Manual PRINCE2 (2011), pode
conter:
• Procedimento de gerenciamento da qualidade.

• Ferramentas e técnicas que serão utilizadas no projeto.
• Cronograma para realização das atividades de gerenciamento da
qualidade.
• Papéis e responsabilidades muito bem definidos.
d) Preparar a estratégia de gerenciamento de comunicação
Definir o conteúdo e a frequência das atividades de comunicação na equipe

de gerenciamento de projetos e com as partes interessadas externas é essencial
para garantir que todos saibam o que é esperado um do outro e de si mesmos.
A estratégia de gerenciamento de comunicação define esses requisitos de
comunicação. De acordo com o Manual PRINCE2 (2011), pode incluir:
• Forma pela qual as comunicações do projeto serão realizadas, ou seja,
144
procedimentos.
• Cronograma para realização das atividades formais de comunicação do
projeto.
• Papéis e responsabilidades dos envolvidos nas atividades de
gerenciamento das comunicações do projeto.
• Análise de stakeholders.
e) Configurar os controles do projetos
Para permitir que o Comitê diretor do projeto delegue efetivamente as

atividades diárias do projeto ao Gerente do Projeto é importante definir níveis e
mecanismos de controle apropriados. Isso inclui o seguinte:
• Requisitos dos relatórios de status (frequência, formato).

• A quantidade de estágios e avaliações necessárias.
• Gerenciamento de problemas, exceções e alterações (captura, análise,
escalação para um nível mais alto de gerenciamento).
• Tolerâncias.
• Métodos utilizados para monitoramento pelos diferentes níveis de
gerenciamento.
• Criar o plano do projeto.
• O plano para o projeto geral é criado em consulta com os usuários e
fornecedores.
f) Refinar o caso de negócios
Um Business Case básico é desenvolvido pelo Executivo como parte do início

de um projeto. Durante o início de um processo de projeto, o Gerente de Projeto
distribui esse produto de gerenciamento com informações mais detalhadas,
por exemplo, estimativas de custo e tempo; riscos (principais) recentemente
identificados; benefícios esperados.
O Business Case atualizado contribui para a decisão da Diretoria do Projeto

sobre a autorização ou não do projeto. Ele será atualizado no final de cada etapa,
com novas previsões para o tempo, custos e benefícios do projeto.
g) Preparar o Plano de Projeto
De acordo com o Manual PRINCE2TM (2011), o planejamento não deve ser

uma atividade isolada do Gerente do Projeto. É muito arriscado deixar todo o
planejamento do projeto centralizado em uma única pessoa. O envolvimento das
partes interessadas, visando reunir maiores detalhes sobre os produtos e suas
dependências, é fundamental para criar um plano coeso.
145
h) Montar o documento de iniciação do projeto
Seu objetivo é ser o guia do projeto, a fim de formar uma linha de base para
avaliação do seu sucesso. Fornece a direção e o escopo do projeto (junto ao
plano do estágio), formalizando os acordos entre o gerente do projeto e a diretoria
do projeto. Este é um documento vivo, pois deve sempre refletir o status atual,
planos e controles do projeto. Vários produtos de gerenciamento (Planos) são
desenvolvidos durante o início do projeto, nesse momento, você pode unificá-
los. Não é uma obrigação! O mais importante é você ter todas as informações
necessárias para iniciar, consultar e comunicar as partes interessadas com
segurança.
FIGURA 10 – CRIAÇÃO DO DOCUMENTO DE INICIAÇÃO DO PROJETO
FONTE: O autor
7.4 CONTROLANDO UM ESTÁGIO

De acordo com o Manual PRINCE2 (2011), este processo tem como
proposta atribuir e monitorar os trabalhos, lidar com questões que interfiram no
projeto, fazer relatórios de acompanhamento, avaliar riscos, controlar mudanças
etc. O objetivo do controle de um estágio é garantir que a atenção seja focada na
entrega dos produtos do estágio, certificando que:
• Os produtos acordados no início do estágio sejam monitorados para

evitar mudanças desnecessárias.
• Riscos e problemas sejam mantidos sob controle.
146
• Caso de negócios será revisado e atualizado.

• Os produtos acordados para o estágio sejam entregues dentro dos
padrões de qualidade, dentro do custo, esforço e tempo acordados.
• Apoio à obtenção dos benefícios definidos.
• Garantir que a equipe de gerenciamento do projeto está focada na
entrega dentro das exceções acordadas.
As principais atividades realizadas pelo gerente de projetos são:
• Autorizar um pacote de trabalho.

• Revisar status do pacote de trabalho.
• Receber pacotes de trabalho concluídos.
• Revisar o status do estágio.
• Relatar desempenho.
• Coletar e analisar questões e riscos.
• Tomar ações corretivas.
Vamos conhecê-las com um pouco mais de detalhes.
a) Autorizar um pacote de trabalho
É necessária uma sincronização dos trabalhos do projeto. As atividades

não podem ser executadas de forma aleatória. O Gerente de projetos e a equipe
devem combinar quando um determinado trabalho será iniciado pela equipe. O
Pacote de Trabalho detalha as seguintes informações:
• O que será produzido?

• Quanto vai custar?
• Quanto tempo vai demorar?
• Quando os relatórios devem ser enviados?
• Requisitos de gerenciamento de configuração?
• Quem aprovará os produtos acabados?
b) Revisar o status de um pacote de trabalho
Segundo o Manual PRINCE2 (2011), essa atividade fornece meios para uma
avaliação regular do status dos pacotes de trabalho. A frequência e formalidade
desse pacote deve estar acordada previamente no plano de estágio para o
estágio atual.
c) Receber o pacote de trabalho concluído
147
Ao receber um pacote de trabalho, o responsável deve garantir que o trabalho

realmente foi concluído. Os requisitos de qualidade para o pacote de trabalho
devem ser conferidos, assim como a confirmação se o registro de configuração
para cada produto aprovado foi atualizado. O gerente de projeto deve verificar
os status dos produtos e, se necessário, estimar esforços extras para concluir os
trabalhos que tiveram desvio durante a execução.
d) Revisar o status do estágio
Um gerente de projetos deve se antecipar às situações adversas fazendo

uma boa gestão de riscos. Essa atividade está relacionada ao monitoramento
e controle do projeto. O gerente de projetos deve acompanhar o andamento
das atividades e compará-las aos planos originais. Em caso de imprevistos ou
variações, ele deve buscar ações que possam deixar o projeto sob controle
novamente.
O manual PRINCE2 (2011) recomenda as seguintes ações:
• Revisar o progresso dos estágios.

• Revisar os relatórios de ponto de controle do período.
• Revisar a previsão e o custo atual do plano de estágio atual.
• Solicitar uma descrição do status do produto, suporte do projeto, para
identificar qualquer variação entre o progresso planejado, progresso
relatado e o progresso real.
• Buscar as informações de qualidade no plano.
• Verificar no plano de gerenciamento de riscos se há algum risco novo ou
revisado e avaliar seu impacto no caso de negócio, plano de estágio ou
plano de projeto.
• Verificar no diário do projeto se algo aconteceu no projeto ou
externamente, que causará impacto nos objetivos do caso de negócio,
plano de estágio ou plano de projeto.
• Verificar o status das ações corretivas.
• Avaliar a utilização dos recursos no período, sendo revisado e a
disponibilidade deles para o restante do estágio (ou projeto). Buscar
variações esperadas na disponibilidade de recursos futuros.
• Verificar no plano de revisão de benefícios se existe alguma revisão de
benefícios que seja devida e realizá-la conforme necessidade.
e) Relatórios gerenciais
O comitê diretor do projeto recebe informações sobre o andamento do projeto

através do gerente de projetos, que deverá respeitar o plano de comunicação
previamente acordado. Geralmente, essa equipe possui restrições de tempo e o
148
gerente de projetos deve se preocupar em apresentar de forma sucinta os pontos

positivos e negativos durante a execução do trabalho.
Normalmente, um relatório gerencial apresenta os seguintes pontos:
• Riscos e questões.
• Status dos produtos.
• Desvios (tempo, custo etc.).
• Ações corretivas empregadas.
• Lições aprendidas.
f) Identificar e analisar riscos e questões
Durante o gerenciamento do projeto, vários problemas ocorrerão e poderão

ser identificados novos riscos, eles chegarão de maneira emergente e precisarão
ser capturados de maneira consistente e confiável. Qualquer membro do time, ou
outras partes interessadas, podem levantar um risco ou questão.
Antes de tomar uma decisão sobre o curso da ação, cada questão ou risco
deve ser registrado e depois avaliado quanto ao seu impacto. O gerente de projeto
deve garantir que os vários registros do projeto sejam mantidos atualizados com
objetivo de direcioná-los conforme autoridade apropriada. Para Ribeiro (2011), o
método PRINCE2TM recomenda que todos os riscos e questões do projeto sejam
documentados, avaliados, monitorados e que seus eventos sejam comunicados.
Para tratar questões do projeto, se deve utilizar o procedimento de controle de
mudança que deve estar descrito na estratégia de gerenciamento de configuração
do projeto.
g) Escalar riscos e questões
Com base no controle de alçadas ou tolerâncias, acordado com o comitê

diretor do projeto, o gerente de projetos deve respeitar esses limites e quando
alguma ação extrapolar as tolerâncias acordadas para o estágio, deve-se
comunicar o fato urgentemente ao comitê diretor do projeto. Segundo o Manual
PRINCE2 (2011), o gerente de projetos deve comunicar antecipadamente ao
comitê diretor do projeto sobre a situação através de relatório de exceção. Após
escalar o fato, o gerente de projetos deve executar as decisões tomadas pelo
comitê.
h) Ações corretivas
Assim como um motorista que sai do ponto A ao ponto B tem um

direcionamento a ser seguido, caso aconteça algum imprevisto, ajuste de rotas
149
serão necessários. O gerente de projetos precisa identificar alterações na rota

e tomar ações necessárias para colocar o projeto “nos trilhos” novamente. O
Manual PRINCE2 deixa claro que essas ações precisam estar de acordo com os
limites do estágio e as tolerâncias definidas pelo comitê diretor do projeto.
7.5 GERENCIANDO ENTREGA DO

PRODUTO
Segundo o Manual PRINCE2 (2011), o propósito deste processo é controlar
o vínculo entre o gerente de projetos e o gerente especialista de times, colocando
os requisitos formais em: aceitar, executar e entregar o trabalho do projeto. Ou
seja, estabelecer os requisitos formais para aceitação, execução, entrega dos
produtos e trabalhos do projeto para as partes interessadas.
FIGURA 11 – GERENCIANDO ENTREGAS DO PRODUTO
FONTE: O autor
Durante cada estágio, seria bastante normal para o gerente de projeto emitir
vários pacotes de trabalho ao mesmo tempo; isso pode ocorrer quando existem
várias equipes especializadas ou uma equipe interna e uma equipe externa.
150
7.6 GERENCIANDO TRANSIÇÃO DE

ESTÁGIOS
O propósito desse processo é possibilitar que o comitê diretor do projeto
receba informações adequadas do projeto para que ele possa revisar o sucesso
do estágio atual, aprovar o plano de estágio para o próximo estágio, revisar o
plano de projeto e confirmar a justificativa contínua para o negócio e aceitação dos
riscos. Ao final de cada estágio, se executa esse processo mediante informações
realistas e seguras para o processo decisório. Segundo o Manual PRINCE2
(2011), as seguintes atividades são necessárias:
• Planejar o próximo estágio.

• Atualizar o plano de projeto.
• Atualizar o caso de negócio.
• Relatar o fim do estágio.
• Preparar um novo plano de exceção.
7.7 ENCERRANDO UM PROJETO

Esse processo é responsável por assegurar o encerramento do projeto de
forma organizada. Confirmar a aceitação do produto do projeto e reconhecer que
os objetivos definidos no documento de iniciação do projeto foram alcançados
(ou se mudanças aprovadas para os objetivos foram alcançadas). Não é raro o
encerramento prematuro de projetos. Durante os estágios, se os objetivos de
negócios não forem mais válidos, o projeto poderá ser encerrado. O Manual
PRINCE2 (2011) recomenda as seguintes atividades:
• Preparar o encerramento planejado do projeto.

• Preparar o encerramento prematuro do projeto.
• Entregar os produtos.
• Avaliar o projeto.
• Recomendar o encerramento do projeto.
a) Preparar o encerramento planejado do projeto
Antes de solicitar o encerramento do projeto para o comitê de gerenciamento

do projeto e notificá-los sobre a liberação dos recursos do projeto, o Gerente de
Projeto deve confirmar se o projeto alcançou o seu objetivo.
b) Preparar fechamento prematuro
151
Em alguns casos, a Diretoria do Projeto pode solicitar o encerramento

prematuro do projeto. Quando isso ocorre, o gerente de projeto ainda deve
buscar autorização para liberar recursos do projeto, mas antes de fazê-lo, deve
garantir que o que foi realizado de valor até o momento não se perca. Um efeito
indesejado do cancelamento prematuro do projeto pode acontecer e o gerente de
projetos deve alertar o comitê diretor do projeto sobre os impactos.
c) Entregar produtos
Segundo o Manual PRINCE2 (2011), os produtos do projeto devem passar

para um ambiente operacional e de manutenção antes que o projeto seja
encerrado. A entrega de produtos a clientes/usuários pode assumir várias formas.
Em alguns casos, todos os produtos são transferidos como uma única liberação
no encerramento do projeto; em outros casos, pode haver um período de entrega
faseado. Muito cuidado nesse momento! Essa decisão precisa ser bem analisada
junto a seus impactos e benefícios. Durante muitos anos, vimos projetos sendo
desenvolvidos de forma espetacular e pecaram na hora de colá-los em produção.
A Gestão de Mudanças é muito importante nesse momento.
Antes de entregar qualquer produto, o Gerente de Projetos deve garantir

que os preparativos adequados para as ações subsequentes estejam em vigor
e confirmar que o Plano de Revisão de Benefícios contenha revisões planejadas
para quaisquer benefícios que não possam ser avaliados até que o produto já
esteja em uso. A manutenção e suporte ao produto do projeto são atividades
operacionais (não tem fim) e precisam estar alinhadas com a equipe que
desenvolveu o projeto para evitar riscos futuros.
d) Avalie o projeto
A metodologia PRINCE2 não se refere apenas ao sucesso ou fracasso de

um único projeto. O aprimoramento contínuo da metodologia e das técnicas de
gerenciamento de projetos e o aprendizado eficaz das lições anteriores exigem
que o gerente de projetos avalie como um projeto foi conduzido, medindo os
dados reais do projeto em relação às expectativas iniciais. Esta avaliação, junto a
um Relatório de Lições, é registrada em um Relatório Final do Projeto.
e) Recomendar encerramento do projeto
O gerente do projeto é responsável por recomendar que o comitê diretor do

projeto encerre o projeto. Após a aprovação dessa recomendação, os recursos
do projeto são liberados e este é fechado. Quando isso ocorre, nenhum trabalho
adicional é realizado neste projeto.
152
O Manual PRINCE2 é bem extenso, possui aproximadamente 340 páginas.

O objetivo desse conteúdo é mostrar a você que existem metodologias disponíveis
e que, apesar das pessoas considerarem o Guia PMBOK uma metodologia, ele
não é. É um guia de boas práticas e que não diz como você deve gerenciar um
projeto de forma integrada. Essa é a proposta do PRINCE2.
Recomendamos a leitura do material oficial que complementará

o seu conhecimento em detalhes. OGC – Office of Government
Commerce. Gerenciando Projetos de Sucesso com Prince2.
Londres: TSO, 2011.
8 GESTÃO ÁGIL DE PROJETOS COM

SCRUM
Como foi mencionado no nosso curso, as empresas, sejam elas privadas
ou públicas, estão inseridas em um ambiente de trabalho dinâmico, incerto,
desafiador e com mudanças constantes. Isso requer abordagens que consigam se
adaptar às diversas situações que fogem do planejado. Dentro das organizações é
comum encontrarmos planejamentos de períodos extensos (6 meses a 1 ano), que
não são seguidos devido ao fato de que mudanças acontecem inesperadamente
e as equipes necessitam replanejar o trabalho inicialmente previsto, por isso a
importância do Framework Scrum.
Durante um bom tempo, as empresas ou equipes que trabalham com

tecnologia e/ou desenvolvimento de softwares utilizavam os modelos tradicionais
de projeto como forma de organização do trabalho. Com o tempo, percebeu-se
que essa abordagem estava sendo pouco eficiente. Algumas práticas e técnicas
estavam sendo aplicadas em projetos de software e gerando resultados positivos.
Foi quando em fevereiro de 2001, um grupo de 17 profissionais da indústria de
software resolveu se juntar e debater as lições aprendidas, como eles poderiam
juntar conhecimento e criar uma abordagem mais adequada.
153
FIGURA 12 – MODELO TRADICIONAL X MODELO ÁGIL
FONTE: O autor
O resultado desse encontro foi a criação do Manifesto para o Desenvolvimento

Ágil de Software, assinado por todos os participantes. As metodologias e
frameworks mais conhecidos geralmente possuem princípios, valores e propósito.
O Manifesto para o Desenvolvimento Ágil de software foi constituído sobre quatro
valores e doze princípios.
Esses fundamentos tinham como objetivo apresentar os fatores que

sustentariam as práticas ágeis, independentemente do framework ágil utilizado.
Os fundadores do movimento queriam mostrar para os profissionais da área quais
eram os fatores valorizados por eles que estavam presentes na reunião, ajudando
outros profissionais a fazer o mesmo. As técnicas de gerenciamento de projetos
ágeis transcenderam o desenvolvimento de software e conseguiram atingir áreas
fora da TI.
Atualmente, diversos profissionais utilizam abordagens ágeis para criar

produtos em uma variedade de indústrias, incluindo: recursos humanos, medicina,
engenharia, marketing, ONGs e até construção civil. Assim, definiram como mais
importante a se valorizar:
• Indivíduos e a interação entre eles, mais que processos e ferramentas.

• Software em funcionamento, mais que documentação abrangente.
154
• Colaboração com o cliente, mais que negociação de contratos.

• Responder a mudanças, mais que seguir um plano.
FIGURA 13 – VALORES DO MANIFESTO ÁGIL
FONTE: O autor
De forma prática, esses valores sinalizam que os profissionais devem saber

da importância dos itens à direita, mas que os itens à esquerda possuem maior
valor. Vamos entender um pouco mais sobre esses pontos.
a) Indivíduos e interações mais que processos e ferramentas
Um dos problemas clássicos em gestão de projetos é a comunicação. Diante

disso, esse valor tende a resolver esse problema ou minimizar ao máximo os seus
impactos no projeto. Entregar projetos é um processo desenvolvido por pessoas
e que a qualidade da interação entre as pessoas é fundamental para entregar
projetos de sucesso. Processos e ferramentas são importantes, mas devem
ser simples e úteis. Ex.: Um colega tem dúvidas em relação a um determinado
processo. Conversar com ele e esclarecer as dúvidas parece uma alternativa
mais eficaz do que mandá-lo ler a instrução de trabalho disponível na intranet da
empresa.
b) Software em funcionamento mais que documentação abrangente
As reuniões de status do projeto normalmente apresentam indicadores de

progresso do projeto através de apresentações em PowerPoint. O manifesto ágil
considera que a melhor métrica de evolução é apresentar o que está concluído.
Contra fatos não há argumentos. O maior indicador de que seu time realmente
construiu algo é software funcionando. O cliente do produto do seu projeto quer
ver o quanto já existe de produto funcionando e não porcentagem de conclusão.
Documentação também é importante, mas que seja somente o suficiente e que
agregue valor.
155
c) Colaboração com o cliente mais que negociação de contratos
Devemos trabalhar em conjunto com o cliente. O que deve acontecer é

colaboração, tomada de decisões em conjunto e trabalho em equipe, buscando
conciliar os esforços para atingir o objetivo. Geralmente, esse ponto é o mais
polêmico dos valores. Entretanto, ele traz a reflexão no uso de contratos. Mesmo
que algo acordado tenha mudança de requisitos, é de fundamental importância
focar no que é valor para o cliente ao invés de entregar algo que perdeu sentido e
não agregará valor.
d) Responder a mudanças mais que seguir um plano
Desenvolver produtos de software é um ambiente de incertezas e por isso

não podemos nos apoiar em planos rígidos enormes e cheio de premissas. O
que deve ser feito é aprender com as interações e feedbacks e adaptar o plano
constantemente. Estamos focados em receber, analisar e fazer as mudanças
da melhor forma. Adaptação do processo e a inspeção durante a produção do
produto são pilares fundamentais para as boas práticas ágeis.
FIGURA 14 – RESTRIÇÕES EM PROJETOS TRADICIONAIS X PROJETOS ÁGEIS
FONTE: <http://www.mundoagil.com/responder-a-mudancas-
mais-que-seguir-um-plano/>. Acesso em: 30 mar. 2020.
Os doze princípios são:
1. Nossa maior prioridade é satisfazer o cliente, através da entrega

adiantada e contínua de software de valor.
2. Aceitar mudanças de requisitos, mesmo no fim do desenvolvimento.
Processos ágeis se adéquam a mudanças, para que o cliente possa tirar
vantagens competitivas.
3. Entregar software funcionando com frequência, na escala de semanas
até meses, com preferência aos períodos mais curtos.
156
4. Pessoas relacionadas a negócios e desenvolvedores devem trabalhar

em conjunto e diariamente, durante todo o curso do projeto.
5. Construir projetos ao redor de indivíduos motivados, dando a eles o
ambiente e suporte necessários e confiar que farão seu trabalho.
6. O método mais eficiente e eficaz de transmitir informações para, e por
dentro de, um time de desenvolvimento é através de uma conversa cara
a cara.
7. Software funcional é a medida primária de progresso.
8. Processos ágeis promovem um ambiente sustentável. Os
patrocinadores, desenvolvedores e usuários devem ser capazes de
manter, indefinidamente, passos constantes.
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 que não
precisou ser feito.
11. As melhores arquiteturas, requisitos e designs emergem de times auto-
organizáveis.
12. Em intervalos regulares, o time reflete em como ficar mais efetivo, então,
se ajustam e otimizam seu comportamento de acordo.
Existem diversos frameworks ágeis no mercado, mas apresentaremos

o Framework Scrum para ilustrar como as abordagens ágeis podem ajudá-
lo. Segundo o Guia do Scrum (SCHWABER; SUTHERLAND, 2017), ele é
um framework para desenvolver, entregar e manter produtos complexos. Um
framework dentro do qual pessoas podem tratar e resolver problemas complexos
e adaptativos, enquanto de forma produtiva e criativamente entregam produtos
com o mais alto valor possível.
8.1 PRÁTICAS DO SCRUM

O escopo dos trabalhos é definido com base nas necessidades e prioridades
determinadas pelo cliente e pode ser detalhado à medida que o projeto avança.
A WBS ou EAP pode ajudá-lo a entender o escopo do projeto e alguns de seus
requisitos. A forma como a EAP é organizada ajuda a identificar se todos os
componentes necessários para criação do produto foram identificados. Entretanto,
sabemos que algo pode ficar de fora e, se posteriormente identificado, deve ser
incorporado.
A entrega do projeto é dividida em ciclos/pacotes menores, que geram

um “incremento” de valor do produto final, preferencialmente funcionando/
implementável.
157
A condução por ciclos/pacotes permite melhor gerenciamento do risco e

maior aderência às necessidades do cliente, devido à realização de inspeções/
aprovações frequentes. Quando falamos de software, essa forma de organização
do trabalho ajuda a mostrar para o usuário como o produto está evoluindo.
Quando criamos um software através de projetos, muitas vezes não temos ideia
de como será o produto. A utilização de protótipos antes da construção ajuda
nesse entendimento. Porém, será através da entrega incremental em ciclos curtos
que o usuário terá consciência do produto e seu funcionamento.
O progresso das atividades é monitorado constantemente através do uso de

recursos visuais de gestão e reuniões diárias com a equipe de projeto e o cliente.
Em nossa experiência com ambos modelos, percebemos que a transparência
(um dos pilares do Scrum) das práticas ágeis elimina a necessidade de alguns
controles propostos pelos modelos tradicionais.
A evolução da prática é perseguida sistematicamente através da identificação

de oportunidades de melhoria, com base nas lições aprendidas em cada ciclo/
pacote executado. A possibilidade de fazer uma reflexão ao final do ciclo,
em conjunto com as inspeções realizadas, ajuda no processo de adaptação e
consequentemente no aprendizado da equipe. Assim, pilares fundamentais do
Scrum são: Transparência, Inspeção e adaptação.
Existem três papéis no Scrum, conforme apresentado a seguir.
1) Product owner
O Product owner, às vezes chamado de representante do cliente em

ambientes não Scrum, é responsável por preencher as lacunas entre o cliente,
os stakeholders da organização e da equipe de desenvolvimento. O Product
owner é um especialista no produto e nas necessidades e prioridades do cliente.
É um membro da equipe de Scrum e trabalha com a equipe de desenvolvimento
diariamente para ajudar a esclarecer os requisitos. Em um projeto ágil, o Product
owner:
• Defende os interesses da empresa/negócio.

• Comunica necessidades, dores e expectativas.
• Representa os demais stakeholders.
• Divide a gestão do projeto com Scrum master.
• Prioriza entregas.
• Inspeciona e aprova produtos.
• Confirma valor agregado pela solução.
• Cria os critérios de aceite.
158
2) Scrum master
O scrum master, às vezes chamado de facilitador do projeto em ambientes

não scrum, é responsável por apoiar a equipe de desenvolvimento, removendo
barreiras organizacionais e mantendo os processos fiéis aos princípios ágeis.
Um Scrum master é diferente de um gerente de projeto. As equipes que

usam abordagens tradicionais de projeto atuam para um gerente de projeto. Um
scrum master, por outro lado, é um líder-servidor que apoia a equipe de modo
que é totalmente funcional e produtivo. A função de Scrum master é um papel
de facilitador, ao invés de um papel de alocação de responsabilidades. Em um
projeto ágil, o Scrum master:
• Orienta a equipe de projeto sobre práticas Scrum.

• Monitora o progresso dos trabalhos.
• Atua como facilitador.
• Remove impedimentos e negocia itens não planejados.
• Define limites (controla o escopo).
• Protege o time.
• Ajuda na resolução de conflitos.
3) Time scrum
O Time scrum é composto por profissionais que criarão os incrementos no

produto. O Scrum não atribui títulos para os membros do time, então, todos os
seus membros são essencialmente “Desenvolvedores”, independentemente
da sua função dentro da estrutura. O tamanho do time varia de acordo com a
necessidade do projeto, sendo uma boa prática trabalhar com o time de 5 a 9
membros. Em um projeto ágil, o Time scrum:
• Cuida da entrega.
• Pratica auto-organização e autogestão.
• Composição multidisciplinar.
• Define os requisitos incluídos em cada Sprint.
• Negocia prazos e a forma de execução dos trabalhos.
• Propõe soluções e alternativas.
• Reporta progressos, impedimentos e itens não planejados.
159
8.2 PROCESSOS DO SCRUM

Os processos estabelecidos no Scrum são utilizados para criar uma
regularidade e minimizar a necessidade de eventos de planejamento ou
acompanhamento do trabalho aleatórios durante a execução das atividades. Todos
as cerimônias são eventos time-boxed (duração pré-definida), de tal modo que
todo evento tem uma duração máxima sugerida (SCHWABER; SUTHERLAND,
2017).
FIGURA 15 – PROCESSO SCRUM
FONTE: O autor
a) História de usuário
User story ou história de usuário é uma descrição sintetizada de uma

necessidade do usuário (ou seja, de um “requisito”) sob a perspectiva desse
usuário de forma simples. Um dos princípios por trás das User stories é a de que
o produto poderia ser integralmente representado por meio das necessidades de
seus usuários (JEFFRIES et al., 2015).
Um projeto que utiliza o scrum como framework descreve por meio de user
story os itens do Product Backlog. As histórias de usuário visam pensar sempre
em três perguntas:
160
1. Quem? – essa pergunta vai indicar o ator (tesoureiro, faturista, analista

contábil etc.) da ação.
2. O quê? – indica a funcionalidade desejada.
3. Por quê? – indica o valor agregado pela funcionalidade.
b) Backlog do Produto
O Product backlog é uma lista detalhada de tudo o que precisa ser realizado
para atingir os objetivos do projeto. Essa lista evolui ao longo do desenvolvimento
do produto, ela é o mapa do projeto que leva para o seu objetivo principal. O
segredo para atender integralmente à necessidade do cliente é um backlog
bem estruturado. Para que se ganhe em produtividade, o mais importante é a
atuação do Product owner priorizando seus respectivos itens. O Product owner
é o único responsável por tudo o que acontece nessa lista, ele deve consultar os
stakeholders e a equipe para se certificar de que elas representam tanto o que as
pessoas querem, como também o que precisa ser devidamente construído.
FIGURA 16 – BACKLOG DE PRODUTOS
FONTE: O autor
c) Backlog da Sprint
Para cada Sprint é definido um Sprint Backlog, que é a meta principal a ser
realizada dentro do tempo determinado para aquele Sprint.
161
FIGURA 17 – BACKLOG DA SPRINT
FONTE: O autor
d) Sprint
Representa um ciclo de trabalho no Scrum. Esse ciclo pode ser de qualquer

tamanho, mas normalmente é de uma, duas ou quatro semanas, que é o Timebox
das Sprints. As Sprints devem ter sempre a mesma duração. A cada Sprint,
um conjunto de requisitos (histórias de usuários) é implementado, tendo como
resultado um incremento do produto que está sendo desenvolvido pelo projeto.
Recomendamos a utilização de no máximo sprints de duas semanas. Queremos
reduzir o tempo de feedback entre o que foi planejado e o que foi entregue.
FIGURA 18 – SPRINT
FONTE: O autor
162
e) Incremento do produto
O incremento do produto é um dos produtos ou artefatos importantes do

Scrum. Incremento do produto é a integração de toda a lista completa de itens
do backlog do produto durante o sprint. Como o nome sugere, o incremento do
produto continua sendo incrementado nos sprints subsequentes. Portanto, em um
sprint específico, o incremento do produto é a integração de toda a lista completa
de itens do backlog do produto, enquanto que em um projeto, o incremento do
produto é a integração de toda a lista completa dos itens do backlog do sprint.
Em cada sprint, o incremento do produto aumenta em termos de funcionalidade
entregue.
FIGURA 19 – INCREMENTO DE PRODUTO
FONTE: O autor
f) Reunião de revisão
A revisão da sprint é uma reunião para analisar e demonstrar as histórias de

usuários que a equipe de desenvolvimento concluiu durante a sprint. A revisão da
sprint é aberta a qualquer pessoa interessada em rever as realizações da sprint.
Isso significa que todas as partes interessadas têm a chance de ver o progresso
sobre o produto e fornecer feedback.
163
FIGURA 20 – REUNIÃO DE REVISÃO
FONTE: O autor
g) Reunião de retrospectiva
A retrospectiva da sprint ocorre após a revisão da sprint e antes do próximo

planejamento da sprint. Esta é uma reunião de, no máximo, duas horas. O
Scrum master garante que o evento ocorra e que os participantes entendam
seu propósito. Esta é a oportunidade para a equipe Scrum melhorar e todos os
membros devem estar presentes. Durante a retrospectiva da sprint, a equipe
discute:
• O que correu bem no Sprint.

• O que poderia ser melhorado.
• O que nos comprometemos a melhorar no próximo Sprint.
O Scrum master incentiva a equipe Scrum a melhorar seu processo e

práticas de desenvolvimento para torná-lo mais eficaz e agradável para o próximo
Sprint. No final da Retrospectiva da Sprint, a equipe Scrum deveria ter identificado
melhorias que serão implementadas na próxima Sprint. A implementação dessas
melhorias no próximo Sprint é a adaptação à inspeção da própria equipe Scrum.
Embora as melhorias possam ser implementadas a qualquer momento, a
Retrospectiva da Sprint oferece uma oportunidade formal para se concentrar na
inspeção e adaptação.
164
FIGURA 21 – RETROSPECTIVA
FONTE: O autor
h) Lições aprendidas
O registro das lições aprendidas deve ser um esforço contínuo durante todo
o projeto. O uso das lições aprendidas durante uma sprint pode nos ajudar no
projeto atual ou identificar melhorias no processo gestão do projeto. Aprender com
as falhas do projeto e com os sucessos do projeto é um dos grandes desafios
das práticas ágeis. Ainda existe uma cultura de punição em muitas organizações.
Trabalho complexo geralmente é variável e imprevisível. Por não aprendermos
com as falhas do projeto, estamos fadados a repetir situações semelhantes. Ao
não maximizar o sucesso do projeto, perdemos oportunidades de implementar e
melhorar os processos e práticas para concluir com êxito.
165
FIGURA 22 – REGISTRO DE LIÇÕES APRENDIDAS
FONTE: O autor
Esse ciclo se repete até a conclusão do projeto. Não existe um limite para a
quantidade de sprints de um projeto.
FIGURA 23 – SPRINTS DE DESENVOLVIMENTO
FONTE: O autor
i) Gestão
O Burndown chart é uma ferramenta de medição visual que mostra o trabalho

concluído por dia em relação à taxa de conclusão projetada para a versão atual
166
do projeto. Seu objetivo é permitir que o projeto esteja no caminho certo para
fornecer a solução esperada dentro do cronograma desejado.
FIGURA 24 – ACOMPANHAMENTO DO PROGRESSO DO PROJETO
FONTE: O autor
Quando a curva de evolução é superior ao planejado, o projeto está atrasado.

Abaixo, adiantado. Caminhando junto à linha prevista, o projeto está no prazo. O
Kanban citado no curso também é uma excelente ferramenta de acompanhamento
visual do projeto.
FIGURA 25 – QUADRO DE ACOMPANHAMENTO DO PROJETO
FONTE: O autor
167
j) Benefícios
Existem boas razões para usar o Scrum para se tornar ágil. A seguir estão
alguns dos mais populares.
Manter a qualidade é um princípio fundamental do desenvolvimento com o

Scrum. Os testes ocorrem a cada Sprint, permitindo a inspeção regular do produto
em funcionamento à medida que ele se desenvolve. Isso permite à equipe do
Scrum visibilidade antecipada de quaisquer problemas de qualidade e permite
que você faça ajustes, se necessário.
O desenvolvimento do Scrum incentiva o envolvimento ativo do Product

owner e das partes interessadas durante o desenvolvimento do produto. Portanto,
a transparência é muito maior para os principais interessados, tanto no andamento
dos projetos quanto no próprio produto, o que, por sua vez, ajuda a garantir que
as expectativas sejam gerenciadas com eficácia.
Pequenos incrementos do software/produto em funcionamento, tornados

visíveis para o Product owner e a Equipe Scrum por meio do desenvolvimento,
ajudam a identificar cedo os riscos e facilitam a resposta a eles. A transparência
no desenvolvimento do Scrum ajuda a garantir que todas as decisões necessárias
possam ser tomadas em um momento adequado, enquanto ainda pode fazer
a diferença no resultado. Os riscos são de propriedade da equipe Scrum e são
revisados regularmente (geralmente como parte do Backlog do produto). O risco
de um projeto com falha é reduzido.
Nos projetos de desenvolvimento tradicionais, escrevemos uma grande

especificação antecipadamente e depois informamos aos proprietários do
negócio como é caro mudar alguma coisa, especialmente à medida que o projeto
continua. Resistimos às mudanças e usamos um comitê de controle de mudanças
para mantê-las, no mínimo, essencial. Essa abordagem geralmente falha, pois
pressupõe que podemos saber o que queremos com 100% de clareza no início
de um projeto (o que geralmente não fazemos) e que não serão necessárias
alterações que tornem o produto mais valioso (o que é improvável, hoje, com a
velocidade da mudança em muitas organizações e mercados).
No desenvolvimento ágil, a mudança é aceita e esperada. Frequentemente,

a escala de tempo é fixa e requisitos detalhados emergem e evoluem à medida
que o produto é desenvolvido. Para que isso funcione, é imperativo ter um Dono
do Produto envolvido ativamente, que entenda esse conceito e tome as decisões
168
de troca necessárias, trocando o escopo existente por novo, onde agrega maior
valor.
A abordagem acima de prazos fixos e requisitos em evolução permite um

orçamento fixo. O escopo do produto e seus recursos são variáveis, e não o
custo. Enquanto desenvolvemos fatias completas de funcionalidade, podemos
medir o custo real do desenvolvimento à medida que prossegue, o que nos dará
uma visão mais precisa do custo de futuras atividades de desenvolvimento.
1) Qual é o processo que tem como proposta atribuir e monitorar

os trabalhos, lidar com questões que interfiram no projeto,
fazer relatórios de acompanhamento, avaliar riscos, controlar
mudanças etc.?
a) ( ) Preparar o Plano de Projeto.

b) ( ) Montar o documento de iniciação do projeto.
c) ( ) Autorizar um pacote de trabalho.
d) ( ) Controlando um estágio.
2) O __________, chamado de representante do cliente em

ambientes não Scrum, é responsável por preencher as lacunas
entre o cliente, os stakeholders da organização e da equipe de
desenvolvimento. A palavra que preenche corretamente o espaço
é:
a) ( ) Scrum Master.
b) ( ) Product Owner.
c) ( ) Time Scrum.
d) ( ) Gerente de Projetos.
Neste capítulo, tivemos a oportunidade de explorar a importância do olhar
sistêmico para os projetos, de compreender que agilidade é a nossa capacidade
de lidar com a complexidade e, consequentemente, se adaptar. Lembre-se de que
não existe metodologia de projetos como solução única para alcançar o sucesso.
Você precisará compreender o contexto onde você está inserido, compreender as
169
necessidades de controles e adaptá-las a sua necessidade.
Planejamento de longo prazo tem se mostrado um equívoco nos dias de hoje.

A dinâmica de um mundo complexo requer que façamos planejamentos de curto
prazo e busquemos o feedback do nosso cliente com as entregas incrementais
que ocorrem durante o projeto. Essas entregas incrementais e de curto prazo
direcionam os próximos passos do projeto com transparência, inspeção e novas
adaptações. A estrutura de gestão de projetos, do Manual PRINCE2, auxilia o
processo de governança do projeto e propõe uma dinâmica de controle, com
papéis e responsabilidades bem definidos e mudança de estágio entre as fases,
garantindo a evolução do projeto de acordo os benefícios declarados no Business
Case ou Plano de negócio do projeto.
Para concluir o capítulo, estudamos a dinâmica de um framework ágil com

SCRUM. Amplamente utilizado no mercado, o SCRUM propõe uma estrutura
simples e clara de cerimônias, com papéis e responsabilidades que auxiliam a
entrega de valor através do projeto. Esperamos que este aprendizado o ajude a
fazer um movimento diferente para o alcance de resultados diferentes.
REFERÊNCIAS
AGILE MANIFESTO. Manifesto Para Desenvolvimento Ágil De Software.
2001. Disponível em: https://agilemanifesto.org/iso/ptbr/manifesto.html. Acesso
em: 10 mar. 2020.
CARNEIRO, M. F. Santos. Gestão Pública: o papel do planejamento estratégico,

FINOCCHIO, J. Project Model Canvas. São Paulo: Alta Books, 2013.
GUIA PMBOK®. A Guide to Project Management Body of Knowledge – GUIA

PMBOK® ® Guide. 6. ed. Project Management Institute – PMI®, 2017.
HIFLEX. Já Ouviram Falar No PRINCE2 AGILE®? 2018. Disponível em: https://

hiflexconsultoria.com.br/ja-ouviram-falar-no-prince2-agile/. Acesso em: 14 mar.
2020
JEFFRIES, R. et al. The Nature of Software Development: Keep It Simple, Make

It Valuable, Build It Piece by Piece. United States of America: The Pragmatic
170
Programmers, 2015.

PRINCE2. O que adaptar e o que manter. Prince2. 2017. Disponível em: https://
www.prince2.com/usa/blog/how-to-tailor-prince2. Acesso em: 25 mar. 2020.

Brasport, 2011.
SCHWABER, K.; SUTHERLAND, J. Guia do Scrum. Um guia definitivo para o

Scrum: as regras do Jogo. 2017. Disponível em: https://www.scrumguides.org/
docs/scrumguide/v2017/2017-Scrum-Guide-Portuguese-Brazilian.pdf. Acesso
em: 28 mar. 2020.
ZAMBON, R. Responder a mudanças mais que seguir um plano. Mundo Ágil.

2016. Disponível em: http://www.mundoagil.com/responder-a-mudancas-mais-
que-seguir-um-plano/. Acesso em: 30 mar. 2020.
171

Gerenciamento de Projetos

Enviado por

Dados do documento

Título original

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Gerenciamento de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

GERENCIAMENTO

Autoria: Anderson Gonzaga de Souza e Coaracy Gomes da Silva Junior

Reitor: Prof. Hermínio Kloch

Diretor UNIASSELVI-PÓS: Prof. Carlos Fabiano Fistarol

Equipe Multidisciplinar da Pós-Graduação EAD:

Revisão Gramatical: Equipe Produção de Materiais

Copyright © UNIASSELVI 2019

Souza, Anderson Gonzaga de

Gerenciamento de projetos. / Anderson Gonzaga de Souza; Coaracy

171 p.; il.

1. Administração de projetos. - Brasil. I. Junior, Coaracy Gomes da

Com avanço e maior disponibilidade de novas tecnologias a um baixo custo,

Durante muitos anos, várias instituições foram inspiradas em modelos

Seguindo essa lógica, no Capítulo 1, apresentaremos os conceitos básicos

Professor Anderson Gonzaga de Souza.

A partir da perspectiva do saber fazer, neste capítulo você terá os seguintes

• reconhecer o papel estratégico da gestão de projetos no alcance de resultados

• compreender e visualizar de forma sistêmica o papel do gerenciamento de

• esclarecer por que o gerenciamento de projetos é uma alternativa importante e

• aplicar de forma prática as ferramentas apresentadas no curso;

• permitir através de exercícios e fóruns aproximar o conhecimento a realidade.

Fazendo uma viagem no tempo, podemos resgatar as origens da gestão de

"VUCA" é um termo cunhado pelas forças armadas dos EUA

Assim como devemos estruturar projetos mais flexíveis e que se adaptam às

A referência global em gestão de projetos é o PMI. O Project Management Institute

Os faraós construíram as pirâmides do Egito por volta de 2500 a. C. e até hoje

Em 208 a. C., a Grande Muralha da China foi construída com o objetivo de

Mais recentemente, a necessidade de uma estrutura mais formulada na construção

Nesse momento, a figura de um responsável pelo acompanhamento dos

Embora não houvesse considerações sobre gerenciamento de atividades,

2.1 A HISTÓRIA MODERNA DO

Em 1911, a publicação de O Princípio da Gestão Científica, de Frederic Taylor, com

Henry Gantt pode ser considerado o pai do gerenciamento de projetos moderno.

GRÁFICO 1 – GRÁFICO DE GANTT

O gráfico de Gantt foi de extrema relevância no mundo do gerenciamento de

Com a Segunda Revolução Industrial, tivemos uma evolução da tecnologia

Agora chamado de AACE Internacional (Association for the Advancement

O método do caminho crítico inclui determinar o caminho mais longo no

FIGURA 1 – MÉTODO DO CAMINHO CRÍTICO

FONTE: <https://www.smartsheet.com/critical-path-method>. Acesso em: 24 fev. 2020.

O Empire State Building, construído em 1930, famoso edifício de 102 andares,

Diferentemente das pirâmides do Egito, esse grande projeto tinha

multidisciplinar (mais de 60 tipos de profissionais). Dada a agressividade do

Foi iniciada a escavação do novo edifício antes mesmo da demolição do seu

Outro método comum de gerenciamento de projetos, a Estrutura Analítica

FIGURA 2 – EXEMPLO DE EAP

FONTE: <https://www.euax.com.br/2019/02/modelo-de-eap/>. Acesso em: 5 mar. 2020.

Em 1965, foi fundada a Associação Internacional de Gerenciamento de Projetos

A filosofia de gerenciamento da teoria das restrições (TOC) foi desenvolvida

O modelo ágil de desenvolvimento de software, que incorpora várias equipes

FIGURA 3 – SCRUM FRAMEWORK ÁGIL DE GESTÃO DE PROJETOS

FONTE: <https://www.scrum.org/resources/what-is-scrum>. Acesso em: 24 fev. 2020.

A ideia de um conceito de valor agregado não é nova. Ela existe desde a

FIGURA 4 – VISÃO GRÁFICA DO VALOR AGREGADO

Em 1996, o PRINCE2 foi lançado em resposta às solicitações de melhorias

Em 1997, Eliyahu M. Goldratt desenvolveu o Critical Chain Project Management

O uso de métodos de desenvolvimento iterativo e incremental remonta a 1957

Como podemos observar através desses marcos históricos, o tema

abordagens diferentes das tradicionais e conhecidas até então.

Antes de mais nada, vamos entender o que é um Projeto. Segundo o Guia

A sua natureza temporária prevê um início e um término bem estabelecidos.

Temporário não significa necessariamente de curta duração. Além disso,

No manual do PRINCE2™, encontramos a seguinte definição: “Um projeto é