102 - APOSTILA - GERÊNCIA DE PROJETOS EM TI

Prévia do material em texto

Gerência de 
Projetos em TI
Professor Mestre André Dias Martins
Diretor Geral 
Gilmar de Oliveira
Diretor de Ensino e Pós-graduação
Daniel de Lima
Diretor Administrativo 
Eduardo Santini
Coordenador NEAD - Núcleo
de Educação a Distância
Jorge Van Dal
Coordenador do Núcleo de Pesquisa
Victor Biazon
Secretário Acadêmico
Tiago Pereira da Silva
Projeto Gráfico e Editoração
André Oliveira Vaz
Revisão Textual
Kauê Berto
Web Designer
Thiago Azenha
UNIFATECIE Unidade 1
Rua Getúlio Vargas, 333,
Centro, Paranavaí-PR
(44) 3045 9898
UNIFATECIE Unidade 2
Rua Candido Berthier
Fortes, 2177, Centro
Paranavaí-PR
(44) 3045 9898
UNIFATECIE Unidade 3
Rua Pernambuco, 1.169,
Centro, Paranavaí-PR
(44) 3045 9898
UNIFATECIE Unidade 4
BR-376 , km 102, 
Saída para Nova Londrina
Paranavaí-PR
(44) 3045 9898
www.fatecie.edu.br
As imagens utilizadas neste 
livro foram obtidas a partir
do site ShutterStock
FICHA CATALOGRÁFICA
FACULDADE DE TECNOLOGIA E 
CIÊNCIAS DO NORTE DO PARANÁ. 
Núcleo de Educação a Distância;
MARTINS, André Dias.
Gerência de Projetos em TI. André. Dias Martins.
Paranavaí - PR.: Fatecie, 2020. 112 p.
Ficha catalográfica elaborada pela bibliotecária
Zineide Pereira dos Santos.
AUTOR
Prof. Me. André Dias Martins
Professional & Life COACHING, Leader COACH e Mentor COACH pelo Instituto 
Global de Coaching IGC de Maringá (2019). Bacharel em Sistemas de Informação pela 
UNIPAR, Universidade Paranaense, Campus Paranavaí (2004-2007), Licenciado em 
Sistemas de Informação pelo Plano Nacional de Formação de Professores PARFOR, UEM, 
Universidade Estadual de Maringá (2013-2014). Licenciado em Pedagogia pelo Instituto 
Superior de Educação Alvorada Plus (UniPiaget) de Maringá (2012-2015). Licenciado em 
Matemática pelo Centro Universitário de Jales, UNIJALES (2016-2018), Especialista em 
Desenvolvimento de Sistemas para Web, pela UEM, Universidade Estadual de Maringá 
(2008-2010). Especialista em Pesquisa Educacional, pela UEM, Universidade Estadual 
de Maringá (2012-2013). Especialista em Docência no Ensino Técnico e Profissional pelo 
Instituto Cotemar de Educação (2015-2016). Especialista em Docência com Ênfase em 
Distúrbios de Aprendizagem pelo Instituto Cotemar de Educação (2016-2017). Mestre 
em Ensino e Tecnologia pelo Programa de Mestrado em Metodologias para o Ensino de 
Linguagens e suas Tecnologias da UNOPAR - Universidade do Norte do Paraná, Campus 
Londrina (2014-2015). Doutorando pelo Programa de Pós-Graduação em Educação para 
o Ensino da Ciência e Matemática, PCM-UEM, Universidade Estadual de Maringá (2017-
2020). Coordenador dos Cursos Superiores de Tecnologia em Análise e Desenvolvimento 
de Sistemas e Design Gráfico e Professor na Graduação e Pós-Graduação do Centro 
Universitário Cidade Verde UNIFCV, atuando nos Cursos de: Administração de Empresas, 
Ciências Contábeis, Análise e Desenvolvimento de Sistemas, Marketing e Design Gráfico. 
Tem experiência na área de Ciência da Computação, com ênfase em Desenvolvimento 
de Sistemas para Web e Formação de Professores, tendo especial interesse nas 
seguintes áreas: Engenharia de Software I, II e III, Planejamento e Métricas de Software, 
Gerenciamento de Projetos de Software, Gestão de Projetos, Tecnologia da Informação e 
Comunicação, Informática na Educação, Novas Tecnologias da Informação e Comunicação, 
Ética e Sociedade, Gestão de Marcas e Produtos e Comunicação Empresarial.
INFORMAÇÕES RELEVANTES:
• Bacharel em Sistemas de Informação
• Licenciado em Sistemas de Informação
• Licenciado em Pedagogia
• Licenciado em Matemática
• Especialista em Docência no Ensino Técnico e Profissional
• Especialista em Docência com Ênfase em Distúrbios de Aprendizagem
• Especialista em Desenvolvimento de Sistemas para Web
• Especialista em Pesquisa Educacional
• MBA em Gestão Empresarial com Ênfase em Gestão de Pessoas
• Mestre em Ensino e Tecnologia
• Doutorando em Educação para a Ciência e a Matemática
• Currículo lattes: http://lattes.cnpq.br/3396673427993412
http://lattes.cnpq.br/3396673427993412
APRESENTAÇÃO DO MATERIAL
Olá, prezado(a) aluno(a), seja bem-vindo(a) à apostila de Gerenciamento de Projeto 
em TI. Sou o Professor André Dias Martins. O assunto que abordarei no decorrer do nosso 
estudo poderá auxiliá-lo(a) em sua carreira ou abrir portas para o mundo dos negócios, 
mostrando-lhe como é bom gerenciar projetos. Com o passar do tempo, os processos 
padronizados de gestão de empresas tornam-se não mais uma tendência e sim uma prática 
comum no ambiente corporativo. Assim, profissionais de TI precisam estudar e conhecer 
sobre essa fabulosa ferramenta e tudo o que ela pode proporcional.
Meu objetivo, por meio desta apostila, é ensiná-lo(a) como gerenciar um projeto, 
seguindo como guia o PMBOK, e apresentar algumas ferramentas que podem auxiliá-lo(a) 
nesse processo. Além disso, pretendo deixar claro que o uso correto dessa técnica poderá 
ajudá-lo(a) a alcançar os objetivos estratégicos de sua empresa ou auxiliá-lo(a) a colocar 
em prática uma nova ideia.
Então, meu(minha) amigo(a), acompanhar e dominar as boas práticas de gestão de 
projetos não é mais um diferencial, mas sim uma questão de posicionamento de mercado.
Esta apostila está organizada em quatro unidades, cada uma delas correspondendo 
a uma das áreas de conhecimento do PMBOK 6ª edição (Project Management Body Of 
Knowledge). Espero, desta forma, que esta disciplina faça uma grande diferença no seu 
conhecimento e possa lhe auxiliar em assuntos gerais sobre a Gestão em TI.
Grande abraço.
SUMÁRIO
UNIDADE I ...................................................................................................... 7
Introdução à Gerência de Projetos 
UNIDADE II ................................................................................................... 24
Definição e Planejamento 
UNIDADE III .................................................................................................. 72
Execução, Controle e Finalização
UNIDADE IV .................................................................................................. 94
Metodologias de Gerência de Projetos de TI
7
Plano de Estudo:
• Histórico do Gerenciamento de Projetos.
• Conceitos Principais do Gerenciamento de Projetos.
• Características dos Produtos de Software.
Objetivos da Aprendizagem
• Conhecer a origem do Gerenciamento de Projetos.
• Conceituar sobre Gestão de Projetos.
• Objetivos da Gerência de Projetos.
• Benefícios da Gerência de Projetos.
UNIDADE I
Introdução à Gerência de Projetos 
Professor Mestre André Dias Martins
8UNIDADE I Introdução à Gerência de Projetos 
INTRODUÇÃO
Esta unidade inicia os estudos sobre gerenciamento de projetos, tratando de temas 
como os primeiros esforços na área, as principais motivações para que o tema tenha sido 
desenvolvido e os principais aspectos relacionados com a conceituação do tema. Embora 
o assunto seja relativamente novo, tem sido estudado por muitas áreas da ciência, gerando 
uma base de conhecimento sólida que iremos tratar ao longo desta apostila.
A gestão de projetos evoluiu de uma filosofia de gestão restrita a algumas áreas 
funcionais para ser considerada como algo agradável dentro de um sistema de gerenciamento 
de projetos corporativos que afeta todas as unidades funcionais da empresa. Simplificando, 
o gerenciamento de projetos evoluiu para um processo de negócios e não apenas para um 
processo de organização de trabalho.
Cada vez mais empresas estão considerando a gestão de projetos como sendo 
obrigatória para a sobrevivência da empresa. As organizações, que eram resistentes 
à aplicação das boas práticas de gerenciamento de projetos, são agora defensoras. 
Educadores de gestão tradicional, que tratavam com resistência sobre essa técnica, agora 
são partidários. O gerenciamento de projetos chegou para ficar. Colégios e universidades 
estão agora oferecendo cursos de graduações e de pós-graduação em gerenciamento de 
projetos.
Portanto,não fique fora dessa! Vamos entrar neste novo universo de jargões, 
processos, fluxos, planilhas e diagramas. E iniciando os trabalhos, vamos estudar o histórico 
do gerenciamento de projetos que trará fatos interessantes sobre esta área.
9UNIDADE I Introdução à Gerência de Projetos 
1. HISTÓRICO DO GERENCIAMENTO DE PROJETOS
O conceito de gerenciamento de projetos não tinha sido utilizado de forma isolada 
até o lançamento do Sputnik pela União Soviética no período da Guerra Fria. Na década 
de 50, período de grandes investimentos militares, muitos projetos demandavam grande 
esforço, tanto financeiro como de recursos e tempo. Por esse motivo era necessário 
repensar as estratégias vigências para gestão de projetos, bem como o desenvolvimento 
de ferramentas específicas para planejamento e controle das atividades do projeto.
Depois de ser surpreendido com o lançamento do Sputnik, o departamento de 
defesa dos Estados Unidos resolveu investir em técnicas e ferramentas para potencializar 
os projetos militares.
Esse esforço foi decisivo para o desenvolvimento da técnica Program Evaluation 
and Review Technique (PERT), utilizada no projeto de construção do míssil nuclear Polaris, 
para submarinos. Esse projeto se tornou emblemático, pois foi desenvolvido em 1957 e 
possuía cerca de 9 mil fornecedores e um cronograma com mais de 70 mil tarefas. No 
mesmo período, a empresa Dupont buscou também técnicas para melhorar seus projetos e 
desenvolver a técnica Critical Path Method (CPM – técnica do caminho crítico). Já em 1959, 
Gaddis cita o termo Gerente de Projetos (GP) com o significado que conhecemos hoje.
Em 1967, o Departamento de Defesa americano publica o chamado Cost/Schedule 
Control systems Criteria (C/SCSC), composto por mais de 35 padrões de gestão e controle 
de projetos, com o qual seus fornecedores deveriam mostrar alinhamento e adequação. 
10UNIDADE I Introdução à Gerência de Projetos 
Esses padrões servirão de inspiração para a construção e manutenção de um guia de boas 
práticas em gerenciamento de projetos em publicações futuras.
1.1. Fatores Influenciadores
Depois do uso militar, essas técnicas foram, aos poucos, sendo incorporadas por 
inúmeras empresas. Além disso, diversos outros fatores incentivaram a adoção do geren-
ciamento de projetos, conforme descrito no Quadro 1.
Quadro 1 - Fatores influenciadores
Fonte: o autor.
Porém a história antiga traz análises que demonstram que esses conceitos podem 
ser mais antigos do que parecem.
1.2. Projetos da Antiguidade
Caso: O Coliseu
Seu desenvolvimento data de três grandes momentos, entre 70 a.C. e 90 a.C., 
passando por três imperadores, Vespasiano, Tito e Domiciano. Era o centro social e 
esportivo do Império Romano e sua construção foi bastante sofistica para a época, tendo 
sido utilizado concreto pela primeira vez neste tipo de obra. Sua capacidade inicial era 
para 50.000 pessoas, sendo estendida para 90.000 em sua fase final. Possui 76 entradas 
diferentes, o que evitava tumultos na entrada e saída do local (Gibbon, 1996).
11UNIDADE I Introdução à Gerência de Projetos 
Caso: O Parthenon
Templo grego construído em Atenas, na parte superior da Acrópole, no ano de 
438 a.C. Seu projeto foi do arquiteto Itkinos e o gerenciamento da sua construção foi 
realizado pelo escultor Pheidias. Construído com mármore branco e esculturas pintadas. 
Uma característica interessante é que, a despeito de parecer ser formado por colunas 
retas, praticamente todas as suas colunas são curvas, anulando efeitos visuais advindos 
da perspectiva, conforme descrevem Kezsbom e Edward (2001).
1.3. Gerenciamento de Projetos Contemporâneos
Um dos primeiros estudiosos na área do gerenciamento de projetos foi Taylor (1911), 
que verificou que o trabalho poderia ser aperfeiçoado se suas etapas fossem estudadas 
e melhoradas de forma individual. Seu primeiro trabalho prático foi em uma siderúrgica, 
melhorando a produtividade no transporte de peças e remoção de areia, processo este que 
até o momento somente poderia ser melhorado se as horas de jornada dos trabalhadores 
fossem aumentadas.
Para Gantt (1919), a área de estudo a ser analisada era a ordem das operações, 
que aplicou nas construções navais para a primeira grande guerra. Seus estudos geraram 
o famoso gráfico de Gantt, em que as barras horizontais representam a sequência e a 
duração das atividades.
Os estudos destes grandes cientistas foram cruciais para o desenvolvimento e 
crescimento da área de gerenciamento de projetos, bem como para sua conceituação e 
caracterização.
12UNIDADE I Introdução à Gerência de Projetos 
2. CONCEITOS PRINCIPAIS DO GERENCIAMENTO DE PROJETOS
O conhecimento sobre projetos, acumulado até o presente momento, permite notar 
que, por mais diferentes que sejam o propósito e a dimensão dos projetos em diferentes 
organizações, eles são baseados nos mesmo conceitos comuns, como apresentados a 
seguir.
2.1. Singularidade dos Projetos
É curioso notar que na maioria das famílias um exemplo de projeto é um filho. Assim, 
o primogênito, desde o momento da gravidez, é aguardado com os devidos preparativos, 
como o enxoval do bebê e o preparativo do quarto. Após o nascimento o projeto ainda 
continua, montando o diário do bebê, como fotos, vídeos e festas para os aniversários.
Porém esse tratamento já não é mais aplicado quando a mesma família recebe seu 
quarto filho. Muitas famílias relatam que os últimos filhos são “criados pelos irmãos”. Não há 
diferença de amor paterno, mas a diferença essencial é que o primeiro filho foi um projeto e o 
último, por nada mais apresentar de diferente, é incorporado ao processo administrativo da 
família. Portanto, percebe-se que projeto tem algo de inusitado ou desconhecido, diríamos 
único, e, por isso, se torna tão desafiador.
13UNIDADE I Introdução à Gerência de Projetos 
2.2. Temporariedade dos Projetos
Outros exemplos de projetos: pessoas vão casar, viajar ou graduar-se com previsão 
de curta ou média duração. A expectativa do prazo norteia esses projetos. Ora, se há esse 
tipo de meta, logo os projetos são temporários. Caso sejam temporários, possuem um ciclo 
de vida a considerar. Projetos são concebidos, evoluem até sua maturidade, apresentam 
declínio e são concluídos. A data de término é crucial para todo projeto e perceberemos, ao 
longo da apostila, como isso se torna um problema para as organizações.
Em nossos exemplos não consideramos o projeto ganhar na loteria, pois, caso 
fosse, teríamos que determinar um prazo, levantar um planejamento, escolher as condições 
mais favoráveis para a seleção dos números. Há quem estude as probabilidades de acerto 
e as combinações mais adequadas, porém é importante acrescentar que isso é um sonho 
intangível e não um projeto. Sem realizar juízo de valor sobre a importância de sonhar, não 
podemos misturar sonhos insertos com realidade.
2.3. O que É Gerenciamento de Projetos
Podemos descrevê-lo como a aplicação de conhecimento, habilidades, ferramentas 
e técnicas às atividades do projeto buscando atender às suas demandas, sendo realizado 
por meio da integração dos seguintes processos: iniciação, planejamento, execução, 
encerramento e monitoramento e controle (PMI, 2017).
Assim, o que percebemos é que existem fatores em comum entre vários projetos, 
tanto pessoais quanto institucionais, a saber:
• São oportunidades que, se “deixar rolar“, tendem a não ocorrer: projetos 
requerem esforço deliberado e compromisso;
• Envolvem interesses elevados, vontade ambição e preocupação com o futuro;
• Não são devaneios, são sonhos viáveis em que há o compromisso de realizar;
• São temporários, com ciclo de vida e horizonte de médio prazo;
• Envolvem recursos escassos, o que os transforma em desafios;
• São únicos, incomuns ou extraordinários;
• Sempre envolvem muito risco e incerteza;
• São conquistas memoráveis que geram satisfação.
2.4. Teoria da Tripla Restrição
Veremos mais adiante queo gerenciamento de projeto possui várias áreas que 
devem ser acompanhadas para aumentar a probabilidade de sucesso do projeto. Porém, 
dependendo das características do projeto ou dos recursos financeiros dedicados à gestão 
14UNIDADE I Introdução à Gerência de Projetos 
do projeto, o GP tem que decidir a quais aspectos do projeto ele dará maior atenção. Desse 
modo, as áreas que são geralmente escolhidas são aquelas que fazem parte do fator 
crítico de sucesso do projeto e que geralmente são: Escopo, Tempo e Custo.
A questão é que essas três forças também são conhecidas como a Tríplice 
Restrição, pois exercem força de balanceamento e conflito entre elas. Além das três forças 
citadas, a qualidade também acaba sendo impactada com o conflito das forças. Dessa 
forma, se algum deles mudar, pelo menos um dos outros provavelmente será alterado.
Figura 1 - Tríplice Restrição
Fonte: o autor.
15UNIDADE I Introdução à Gerência de Projetos 
3. CARACTERÍSTICAS DOS PRODUTOS DE SOFTWARE
Dentro desse universo de estudo, que permite ser aplicado em várias frentes de 
trabalho possíveis, encontram-se características e aplicações que são únicas a esta área 
de conhecimento e são aproveitadas por todos que necessitam dos benefícios da aplicação 
da gestão de projetos em seu contexto. Agora discutiremos esses aspectos, permitindo, em 
alguns casos, categorizá-los.
3.1. Aprendizado por meio dos Erros
Provavelmente hoje, no momento em que você está lendo essa apostila, vários 
projetos estão sendo iniciados e outros tantos estão sendo encerrados, sejam eles por 
sucesso ou não, interrompidos ou não. E outros tantos projetos já foram desenvolvidos e 
suas histórias estão disponíveis, no âmbito público ou no privado, em que você agora pode 
estar inserido(a) (projetos anteriores da sua organização). Assim, com tanta informação 
disponível, por que sempre temos a tendência de buscar aprender com “nossos próprios 
erros”?
Essa não deveria ser nossa resposta padrão, pois somos contratados e pagos 
para exercermos tarefas inteligentes. Assim, o modo mais racional de aprendizado é com a 
descrição de sucessos e fracassos daqueles ao nosso redor. Neste ponto, o gerenciamento 
de projetos trata uma área específica de trabalho, as lições aprendidas, que têm grande 
16UNIDADE I Introdução à Gerência de Projetos 
contribuição para a coleta, armazenamento e distribuição das informações de sucesso e 
fracasso dos projetos.
Empresas como Boeing e Ferrari, desde sua fundação, têm mantido esse conjunto 
de informações disponíveis a seus projetistas contemporâneos para aprenderem com os 
erros e acertos do passado, potencializando as possibilidades de sucesso dos projetos 
atuais.
Além de permitir guiar os novos projetos, o conjunto de lições aprendidas também 
é útil para considerar as falhas no projeto, como um ambiente rico para discussão, e assim 
promover o crescimento dos integrantes e não considerá-los como algo a ser negado e 
escondido.
3.2. Progressividade dos Projetos
Outra característica importante dos projetos é a elaboração progressiva, que 
possibilita o seu desenvolvimento em etapas incrementais.
Um exemplo de desenvolvimento progressivo de projetos é a criação de um 
comércio eletrônico na internet. O seu desenvolvimento se inicia com a definição das 
principais características do portal. Elas são utilizadas para a escolha da plataforma a ser 
utilizada, a tecnologia e as premissas de acesso, bem como o público-alvo a ser alcançado 
pelo portal. Com a implementação, são feitas adequações e customizações e, depois de 
certo tempo, o portal fica pronto para testes.
Essa abordagem progressiva se reflete também na diferença entre projetos e 
trabalhos operacionais, que veremos a seguir.
3.3. Diferença entre Projetos e Processos
Ambos, projetos e processos operacionais, são desenvolvidos pelas empresas 
para atingir um conjunto de objetivos. Embora sejam diferentes, compartilham de algumas 
semelhanças que geram confusão nos estudiosos de primeira viagem. O fato de que 
processo corresponde a atividades sequenciais e que podemos definir também o projeto 
com essa mesma característica, está feita a confusão. Assim, qual é a real diferença entre 
os dois conceitos?
Para responder a esta pergunta, vamos começar tratando sobre a cadência de 
informações que cada um dos conceitos aborda. Os projetos são descontínuos, ou seja, 
não exige uma ordem certa para a execução de seus processos, embora exista uma linha 
de base, dependendo das escolhas do gerente de projetos. Já o processo é estritamente 
contínuo e a alteração de suas etapas pode gerar sérios problemas para a organização 
17UNIDADE I Introdução à Gerência de Projetos 
que a gerencia. Além disso, os projetos são únicos e desafiadores, diferentemente dos 
processos que têm o objetivo de gerar produtos extremamente iguais (quanto mais melhor) 
e devem gerar o mínimo de desafio a seus operadores e gestores.
3.4. Organizações de Gerenciamento de Projetos
Comparativamente a outras instituições tradicionais, como a American National 
Standards Institute (ANSI) e a Internacional Organization for Standardization (ISO), outras 
instituições foram criadas com o propósito de discutir boas práticas e gerenciar documentos 
técnicos sobre a área de gerenciamento de projetos. Dentre estas organizações temos o 
Project Management Institute (PMI), que mantém o guia PMBOK e oferece a certificação 
PMP. Temos também a International Project Management Association (IPMA), que oferece 
a certificação 4-L-C (four Level Certification), e o Office of Government Commerce (OCG), 
que mantém sua versão de um guia de boas práticas de gerenciamento de projeto chamado, 
em sua última edição, de Prince2.
3.5. Project Management Body Of Knowledge (PMBOK)
Desenvolvido pelo PMI, e já em sua sexta edição (lançada em setembro de 
2017), é definido como: um termo que descreve o conhecimento dentro da profissão de 
gerenciamento de projetos (PMI, 2017). O corpo de conhecimento do gerenciamento de 
projetos inclui práticas tradicionais comprovadas que são amplamente aplicadas, bem 
como práticas inovadoras que estão surgindo na profissão. Esse corpo de conhecimento 
está em constante evolução. Esse guia PMBOK® identifica um subconjunto do corpo de 
conhecimento do gerenciamento de projetos que geralmente é reconhecido como uma boa 
prática.
3.6. Stakeholders, Variáves e Etapas do Projeto
O PMBOK trata o gerenciamento de projetos dividindo a gestão em 10 áreas de 
conhecimento – Escopo, Cronograma, Integração, Qualidade, Risco, Aquisição, Recursos, 
Custo, Stakeholders e Comunicação –, separadas em 49 processos (vinculados às áreas 
de conhecimento) que estão espalhados por 5 grandes grupos de processos – Iniciação, 
Planejamento, Execução, Encerramento e Monitoramento e Controle.
18UNIDADE I Introdução à Gerência de Projetos 
Figura 2 - Distribuição dos Processos do PMBOK por grupo de Processos
Fonte: Beware (2000).
19UNIDADE I Introdução à Gerência de Projetos 
SAIBA MAIS
Saia da sua zona de conforto!
O estudo dos conceitos de Gerenciamento de Projetos, algumas vezes, está vinculado ao 
objetivo individual de empreender. Assim, estudar a gestão de projetos e suas ferramentas 
nem sempre é suficiente para atingir bons resultados. Para tanto, é necessário buscar 
dicas e informações sobre os desafios desse novo paradigma de vida. Dentre esses 
desafios está o medo de sair da zona de conforto.
Agora, sem mais delongas leia e reflita sobre as dicas de empreendedorismo da Bel 
Pesce, uma brasileira, filha de família simples de São Paulo, que estudou no MIT 
(Massachusetts Institute of Technology) e trabalhou no Vale do Silício em empresas 
como Microsoft e Google e, mesmo muito nova, tem muita experiência a nos passar.
“As pessoas geralmente adoram comodidade, o que os faz continuar a viver a vida 
do mesmo jeito, dia após dia. Muitas pessoas evitam mudanças, e se apegam a seus 
hábitosdiários, sempre fugindo do desconhecido. No entanto, ao fazer isso, elas acabam 
fechando as portas para aventuras emocionantes.
Começar uma empresa requer que você faça uma grande mudança em sua vida, e 
mergulhe em uma experiência impressionante, cheia de coisas que você não conhece. 
Você acertará algumas coisas e errará outras. Não se preocupe: contanto que você 
esteja realmente interessado em aprender e fazer as coisas acontecerem, você terá a 
melhor época da sua vida.
Para administrar a sua empresa, você terá que correr riscos. As decisões que você tomar 
pode influenciar a vida de todos os seus funcionários e clientes. Você precisa trabalhar 
o quanto for possível para aprender tudo que puder antes de tomar uma decisão. Mas 
na maioria das vezes você terá que decidir várias coisas diante de incertezas enormes. 
Isso é parte de ser um empreendedor.
Sair da sua zona de conforto é muito mais fácil do que você imagina. Comece por sair 
por aí para conhecer pessoas novas. Repare nas diferentes maneiras como as pessoas 
vivem suas vidas. A zona de conforto delas pode ser completamente diferente da sua. 
Faça amigos e com eles faça coisas que você nunca tenha feito antes.
Não tenha medo de viver o momento. Aceite que você não pode saber ou ter tudo, 
então não seja excessivamente preocupado com o que os outros vão pensar. Faça 
20UNIDADE I Introdução à Gerência de Projetos 
umas bobeiras de vez em quando. Mande mensagens para pessoas que talvez 
nunca responderão para você. Cante em público. Viaje com os amigos para lugares 
desconhecidos. As pessoas mais carismáticas que eu conheço não têm medo de serem 
espontâneas. Pelo contrário, elas têm medo de perder uma boa oportunidade.
Quando você sai da sua zona de conforto, você ve que as possibilidades são infinitas. 
Você entende que nada é impossível de se conseguir, e de repente tem a coragem de 
tomar as medidas necessárias para atingir cada um dos seus sonhos, mesmo que isso 
requeira que você enfrente seus medos. No começo é difícil e você pode querer voltar 
aos seus hábitos de costume. Mas depois que você passa dessa fase, sentirá uma 
sensação incrível. Pratique sair da sua zona de conforto hoje mesmo”.
Fonte: http://lelivros.love/book/download-a-menina-do-vale-bel-pesce-em-epub-mobi-ou-pdf/
http://lelivros.love/book/download-a-menina-do-vale-bel-pesce-em-epub-mobi-ou-pdf/
21UNIDADE I Introdução à Gerência de Projetos 
REFLITA
Leia o texto escrito por Aníbal Marcondes, no Capítulo Mato Grosso do PMI BRASIL, 
publicado em Abril de 2017, acessando o link: http://pmimt.org.br/site/index.php/artigo/
vis/4
Nesse texto, Aníbal faz um recorte sobre o Histórico do gerenciamento de projetos, 
passando por projetos como o Templo de Salomão, Torre Eiffel, Bomba Atômica e a Ida 
do Homem a Lua. Trata sobre os autores que, ao longo de nossas revoluções durante o 
período contemporâneo, contribuíram para adicionar novas teorias, técnicas e práticas 
ao arcabouço de conteúdos até então existentes. Também auxiliaram a provar teorias 
que até então tinham base simplesmente empírica. Além disso, conta a história do 
surgimento do PMI e como ele se tornou o maior instituto sem fins lucrativos no campo 
da ciência do gerenciamento de projetos.
22UNIDADE I Introdução à Gerência de Projetos 
CONSIDERAÇÕES FINAIS
Até aqui tivemos a oportunidade de conhecer um pouco do que é um projeto e o 
que a história, tanto antiga quanto contemporânea, nos apresenta sobre seus resultados, 
fatores influenciadores e suas características. Além disso, muitos pesquisadores e cientistas 
estudaram e formularam métodos e técnicas para construir o conjunto de conhecimento 
que consideramos hoje a base para a formação do que se considera como alicerce de 
conhecimento do gerenciamento de projetos.
Vimos também como é singular um projeto e como essa singularidade afeta e 
motiva os stakeholders. Outra característica estudada é o conceito temporal inevitável que 
todo o projeto tem, ou seja, exige que tenha começo, meio e fim bem definidos. Por fim, 
analisamos e comparamos os projetos com os processos contínuos, identificando suas 
semelhanças (que causam dúvidas sobre seus conceitos) e suas diferenças, nos ajudando 
a separá-los de forma correta.
Na próxima unidade vamos estudar sobre o planejamento e como os projetos podem 
impactar na missão e visão das organizações. Aprofundaremos nosso conhecimento, 
abordando o tópico sobre estimativa de custo e como ele pode auxiliar no trabalho dos GPs.
Até a próxima unidade.
23UNIDADE I Introdução à Gerência de Projetos 
MATERIAL COMPLEMENTAR 
LIVRO 
Título: Um Guia do Conhecimento em Gerenciamento de Projetos 
(Guia PMBOK®) 6ª edição
Autor: Project Management Institute
Editora: Project Management Institute
Sinopse: Pela primeira vez, o Guia PMBOK inclui orientação 
sobre a aplicação de práticas recomendadas em gerenciamento 
de projetos para ambientes ágeis ou adaptativos. A inclusão desse 
novo conhecimento faz com que o Guia seja um dos recursos mais 
consistentes e mais versáteis para o profissional de gerenciamento 
de projetos da atualidade. Agora, cada seção (ou área de 
conhecimento) do Guia tem quatro partes introdutórias: Conceitos 
chave; Tendências e práticas emergentes; Considerações sobre 
tailoring e Considerações para ambientes ágeis ou adaptativos. A 
sexta edição também apresenta maior ênfase sobre os aspectos 
do conhecimento estratégico e empresarial do gerenciamento de 
projetos, com uma discussão sobre os documentos de negócios 
do gerenciamento de projetos nos três primeiros capítulos. O Guia 
ainda inclui uma nova seção sobre o papel do gerente do projeto 
que discute o PMI Talent Triangle e os conjuntos de habilidades 
exigidos pelas organizações que tornam os gerentes de projetos 
mais competitivos e relevantes: gerenciamento técnico, estratégico, 
de liderança e negócios. Além disso, você encontrará um apêndice 
sobre ambientes de projeto ágeis ou adaptativos.
FILME/VÍDEO 
Título: Conhecendo o PMBOK
Ano: 2018
Sinopse: O PMBOK consiste em uma padronização que identifica 
e conceitua processos, áreas de conhecimento, ferramentas e téc-
nicas. Fornece e promove um vocabulário comum para se discutir, 
escrever e aplicar o gerenciamento de projetos, possibilitando a 
troca eficiente de informações entre os profissionais de gerência 
de projetos.
Link: https://www.youtube.com/watch?v=O60YatFBVu4
24
Plano de Estudo:
• Fundamentos do Gerenciamento de Escopo;
• Coletar os Requisitos; 
• Definir o Escopo; 
• Criar a EAP; 
• Validar e Controlar o Escopo; 
• Definição das Atividades;
• Sequenciamento das Atividades;
• Estimando a duração das Atividades;
• Elaborar o Cronograma do Projeto;
• Controlar o Cronograma;
• Estimativas de Custo;
• Análise e Gestão de Risco.
Objetivos da Aprendizagem
• Conhecer a origem dos Fundamentos do Gerenciamento de Escopo;
• Conceituar sobre Escopo, EAP e Entregáveis;
• Conhecer as atividades do projeto;
• Discutir sobre Cronograma de projeto.
UNIDADE II
Definição e Planejamento 
Professor Mestre André Dias Martins
25UNIDADE II Definição e Planejamento
INTRODUÇÃO
Esta unidade inicia os estudos sobre gerenciamento de projetos, segundo o PMBOK, 
tratando as áreas do conhecimento: ESCOPO, CRONOGRAMA, CUSTO, QUALIDADE e 
RECURSOS. Embora o assunto seja relativamente novo, tem sido estudado por muitas 
áreas da ciência, gerando uma base de conhecimento sólida, que iremos tratar ao longo 
desta apostila.
A gestão de projetos evoluiu de uma filosofia de gestão restrita a algumas áreas 
funcionais para ser considerada como algo agradável dentro de um sistema de gerenciamento 
de projetos corporativos que afeta todas as unidades funcionais da empresa. Simplificando, 
o gerenciamento de projetos evoluiu para um processo de negócios e não apenas para um 
processo de organização de trabalho.
Portanto, não fique fora dessa! Vamos entrar neste novo universo de jargões, 
processos, fluxos, planilhas e diagramas.E iniciando os trabalhos, vamos estudar a área 
de conhecimento ESCOPO.
Gerenciamento de projetos é assunto sério. Muito se investe em treinamento, 
processos, ferramentas e estruturas, para aumentar a maturidade de um ambiente de 
gerenciamento, mas ainda é possível observar uma série de problemas ligados a essa 
prática. Muitos deles estão relacionados a uma das variáveis mais imponderáveis e 
implacáveis de todas: o tempo. Nesta unidade iremos tratar sobre as atividades, como 
sequenciá-las, como definir sua duração e como colocar tudo isso no cronograma.
Portanto, você está intimado(a) a entrar comigo nessa grande aventura do 
conhecimento! Vamos estudar estes conceitos e entender como tudo isso poderá ser 
utilizado a seu favor na gestão de um projeto e no controle de uma ferramenta para apoiá-
lo(a) nesta gestão.
26UNIDADE II Definição e Planejamento
1. FUNDAMENTOS DO GERENCIAMENTO DE ESCOPO
Existem muitas técnicas, métodos e guias para conduzir de forma satisfatório um 
projeto. Nesta apostila irei seguir o guia de boas práticas de gerenciamento de projetos 
conhecido como PMBOK® (Project Management Body Of Knowledge) produzido e mantido 
pelo PMI (Project Management Institute). Este guia é constantemente atualizado e sua última 
versão é a número 6, nela o gerenciamento de projetos é dividido em 10 grandes áreas de 
conhecimento, a saber: Escopo, Cronograma, Custo, Qualidade, Recursos, Comunicação, 
Riscos, Aquisições, Partes Interessadas e Integração. Cada área de conhecimento é dividida 
em processos e na 6a edição temos 49. Esses processos são agrupados em 5 Grupos de 
processos: Iniciação, Planejamento, Execução, Monitoramento e Controle e Encerramento, 
como apresentado na Figura 1.
A construção do plano do projeto, tarefa extremamente importante e realizada no 
grupo de processos de planejamento (vide Figura 1), servirá como base e guia durante toda 
a condução da execução, monitoramento, controle e encerramento do projeto.
Assim, a primeira tarefa na elaboração do plano do projeto é produzir uma 
Declaração de Escopos do Projeto (Scape Statement) que será referência de controle. 
Esse documento relata o que pertence e o que não pertence ao escopo do projeto. Delimita 
suas fronteiras, portanto, esclarece dúvidas. Como exemplo, projetos de implantação de 
software fracassam se não houver uma boa Declaração de Escopo: o cliente julga que 
tudo o que for preciso fazer é parte do escopo, enquanto o implantador contratado limita 
27UNIDADE II Definição e Planejamento
sua atuação, supondo que existem tarefas que devem ser efetuadas pelo cliente (e estima 
custo apenas de seu trabalho). As suposições ou os pequenos detalhes podem levar a 
gestão do projeto à discussão do “sexo dos anjos”. Esse tipo de situação é extremamente 
indesejado e deve ser a todo custo evitado.
Para o PMI (2017), o escopo deve “assegurar que o projeto contém somente o 
trabalho requerido para o sucesso da execução”. O sucesso da execução deve ser 
interpretado como atingir os objetivos e resultados esperados. O trabalho requerido envolve 
não somente as atividades a serem realizadas como também aquilo que não será realizado 
dentro deste projeto.
28UNIDADE II Definição e Planejamento
Figura 1 - Distribuição dos Processos do PMBOK por grupo de Processos
Fonte: Vargas (2017).
29UNIDADE II Definição e Planejamento
Se o projeto visa implantar um sistema, o software em si é um produto do projeto; 
se visa implantar um empreendimento imobiliário, é fácil perceber o produto do projeto. 
Contudo qual é o produto de um projeto de consultoria? Por envolver apenas trabalho 
intelectual, não há um produto tangível resultante desse projeto, mas, para haver foco em 
resultado, é preciso tornar tangível o resultado do trabalho dos consultores. A solução é 
criar um ou mais entregáveis (deliverables): por exemplo, os relatórios de cada fase do 
projeto. O escopo de um projeto reúne todas as atividades, produtos e entregáveis obtidos 
em sua execução.
É raro um projeto iniciar tendo uma definição detalhada do que fazer: o escopo é 
progressivamente elaborado. Mas, sem o escopo definido, não há como planejar o projeto, 
dimensionar recursos etc. Aceitamos essa incerteza, porém adotamos a estratégia de 
aproximações sucessivas: na fase de planejamento o escopo é criado e vai sendo detalhado 
até permitir criar a referência de controle (baseline).
30UNIDADE II Definição e Planejamento
2. COLETAR OS REQUISITOS
O Escopo do Projeto é uma lista completa, mas não detalhada, de atividades e 
entregáveis. Muitas vezes esse documento é acompanhado de uma descrição do produto 
do projeto (SOW - Statement of Work), que o PMI denomina Escopo do Produto. Ele pode 
ser um memorial descritivo (caso da construção civil) ou uma especificação técnica e/ou 
funcional (business requirements, caso da informática).
Por isso, o segundo processo listado no PMBOK na área de conhecimento “escopo” 
é a coleta de requisitos (collect requirements). Cabe aqui uma ressalva, o primeiro processo 
de todas as áreas de conhecimento, menos a de integração e partes interessadas, é o 
planejar o gerenciamento. Neste processo o PMBOK indica que o Gerente de Projetos 
(GP), junto a sua equipe, deve pensar e definir como cada área de conhecimento será 
abordada dentro do planejamento.
Assim, requisitos são a condição ou capacidade que um sistema, produto, resultado 
ou componente deve possuir para satisfazer aquele que demanda o projeto. Coletar 
requisitos envolve entrevistar quem demanda o projeto, traduzindo suas demandas em 
um conjunto de frases objetivas, claras e consistentes. Nesta etapa pode-se utilizar de 
ferramentas como Entrevistas, Construção de cenários, Caso de Uso entre outras técnicas 
conhecidas pela área da Computação.
31UNIDADE II Definição e Planejamento
3. DEFINIR O ESCOPO
O Escopo do Projeto contém, sem se limitar, as seguintes macroatividades:
• Gerenciamento do projeto: planejamento e controle, relacionamento, gestão da 
equipe do projeto, avaliação de resultados etc.;
• Estudos, levantamento de informação, diagnósticos, aprovações e divulgação 
delas;
• Atividades e entregáveis relativas a escopos (produto e projeto): documentos de 
engenharia, especificações, protótipos, detalhamento de processos;
• Tarefas executivas de todo tipo: compras e contratações (inclusive de pessoal), 
atividades de comunicação (reuniões, eventos, relatórios), atividades de 
controle, atividades de testes;
• Aceitação provisória e final, homologação, comissionamento, obtenção de 
licenças, preparo de manuais e de documentação final do projeto;
• Planejamento, preparação e execução de recrutamento e seleção e de 
treinamentos;
• Atividades de pré-operação, operação experimental ou apoio à operação por 
período pré-determinado.
É fácil perceber se os responsáveis pelo projeto dominam a metodologia gerencial: 
basta verificar se as atividades de gestão foram destacadas no escopo do projeto. Há quem 
32UNIDADE II Definição e Planejamento
só identifique as atividades técnicas e operacionais. Ora, o fator mais diretamente ligado 
ao sucesso da realização de um projeto não são as atividades técnicas ou executivas, mas 
as atividades de gerenciamento. Note que um projeto nunca termina abruptamente. Há, 
de fato, um período de transição, ocasião em que a equipe prepara-se para encerrar sua 
atuação, enquanto a equipe criada para operar o produto paulatinamente assume suas 
responsabilidades.
33UNIDADE II Definição e Planejamento
4. CRIAR A EAP
Muitos empreendedores têm dificuldade em definir o escopo do projeto nessa fase 
inicial. Isso é normalmente causado por uma falta de maturidade da própria ideia do projeto: 
quando se sabe de fato onde se quer chegar, não é difícil definir o escopo no nível macro. 
Detalhar escopo é outra coisa.
Como há grande chance do escopo mudar à medida que o projeto fica maduro e 
o planejamento vai sendo elaborado, a simpleslista de atividades, produtos e entregáveis 
que formam o escopo do projeto não é a melhor forma de organizar esse escopo.
A equipe responsável pelo planejamento precisa organizar o escopo de tal modo 
que seja fácil acrescentar novas atividades ou detalhar cada macroatividade. A técnica 
para organizar componentes do escopo do projeto é chamada de EAP - Estrutura Analítica 
do Projeto (WBS - Work Breakdown Structure). Para indicar a importância histórica dessa 
técnica, note que, depois de publicar a norma PMBOK Guide em 1986, a norma publicada 
logo a seguir explanava sobre como elaborar EAP. Não porque essa técnica seja complicada, 
mas pela importância que tem na disciplina do gerenciamento de projetos.
Vou usar um exemplo comum de organização de componentes. Reflita: como seus 
arquivos são organizados em seu computador? Há aqueles que simplesmente juntam todos 
os arquivos na pasta “Documentos”. Mas há aqueles que criam subpastas, estabelecendo 
um primeiro nível de repartição. Outros criam subpastas em cada subpasta, formando um 
34UNIDADE II Definição e Planejamento
segundo nível. Em certos casos, a existência de um terceiro nível de repartição pode ser 
útil. Quem assim procede não “perde” arquivos nem perde tempo os procurando.
Observe que o processo requer um breakdown, ou seja, a ideia não é agrupar 
atividades correlatas para formar o escopo e sim quebrar ou repartir o trabalho. Desmembrar 
o todo em partes, de cima para baixo, e não agrupar atividades de mesmo tipo, de baixo 
para cima, para formar o todo. Portanto, é uma técnica que requer a visão sistêmica do 
projeto.
Há dois modos de apresentar o escopo do projeto na EAP: o modo pictórico, 
na forma de uma árvore invertida, e o modo lista enumerada. Cada indivíduo tem uma 
preferência e deve segui-la para obter melhor resultado. O importante é raciocinar nível 
por nível: o primeiro contém uma forma de repartição macro (é usual repartir por fases 
cronológicas); o segundo nível reparte cada pedaço do nível anterior de acordo com outro 
critério, e assim por diante. Raciocinando desse modo, cada ramo da árvore é coerente com 
os demais ramos naquele nível, e sempre se opera sobre o escopo completo do projeto, 
seja em níveis mais ou menos detalhados.
Em qualquer dos níveis o projeto pode ser repartido de diferentes modos:
• Fases cronológicas, datas-marco relevantes ou etapas de execução;
• Macrocomponentes ou entregáveis principais;
• Função da organização (Operações, RH, Marketing, Finanças etc.);
• Executores;
• Unidade organizacional ou área geográfica;
• Natureza das atividades (gestão, operação, suprimentos, testes, etc.);
• Plano de Contas, que é uma Estrutura Analítica adotada para o controle 
financeiro.
A Figura 2 apresenta um exemplo de EAP na forma de árvore (pictórica). Note 
que, em cada ramo, a última etiqueta envolve o gerenciamento do projeto. Poderíamos 
fazer diferente? Sim, sempre julgo útil criar um ramo (à esquerda) que reúne todas as 
atividades de gestão do projeto, porque, com isso, valorizamos a função do Gerenciamento 
de Projetos e facilitamos a elaboração de cronograma e controle.
É notável quando a EAP, na forma de árvore, é elegante em termos estéticos, ou 
na forma enumerada, é homogênea, está bem feita. Foi possível representar todo o escopo 
do projeto em poucos itens (até 60 considero adequado para o nível de detalhe requerido 
para o controle do projeto).
35UNIDADE II Definição e Planejamento
Seja na forma pictórica ou em lista, a EAP complementa a Declaração de Escopo 
do Projeto. Uma EAP sintética terá como consequência um cronograma sintético, uma 
matriz de responsabilidades legível etc.
Figura 2 - EAP - Complemento de Escopo do Projeto
Fonte: o autor.
36UNIDADE II Definição e Planejamento
5. VALIDAR E CONTROLAR O ESCOPO
Ações de monitoramento e validação do escopo são aquelas que exigem o 
acompanhamento e certificação das condições e dos resultados que são obtidos durante a 
execução do projeto, bem como a sua comparação com o que foi, anteriormente, planejado. 
O enfoque dado a essas ações é sobre o resultado obtido durante a execução do projeto.
É importante ressaltar que a validação do escopo difere do controle de qualidade, 
uma vez que a validação do escopo tem foco principal na aceitação das entregas, enquanto 
o controle da qualidade se interessa pela precisão e pelo alcance dos requisitos de qualidade 
especificados para elas.
As atividades de monitoramento e validação são de responsabilidade direta do 
gerente de Escopo, ou do gerente de projetos, caso não tenha um gerente específico para 
coordenar está área.
As ações de monitoramento e validação ocorrem em qualquer momento, quando 
existe o desenvolvimento de uma ação planejada previamente.
Durante a execução, as atividades do projeto são desenvolvidas e muitos profissionais 
e empresas se relacionam para que os resultados pretendidos para o projeto possam ser 
obtidos. Isso não ocorre única e exclusivamente por algum traço da personalidade ou falta 
de motivação das pessoas, mas, sim, pela dificuldade em:
• Ter uma visão maior do projeto;
• Entender a sua participação no todo do projeto;
37UNIDADE II Definição e Planejamento
• Saber as consequências de suas ações para o projeto;
• Compreender os reais requisitos e necessidades explicitados pelo cliente no 
início do projeto.
Além disso, todo o projeto existe para garantir que uma oportunidade seja 
aproveitada ou que uma necessidade seja atendida. Tais oportunidades ou necessidades 
traduzem o ponto focal da relação entre o projeto e o seu cliente. Assim, a satisfação do 
cliente é a base para o sucesso do projeto. A aceitação dos resultados pelo cliente ocorre 
em momentos que denominamos “momentos da verdade”. Eles podem ser figurados por 
um relacionamento direto entre o projeto, via de regra, representado pelo seu gerente e um 
representante dos clientes.
Um dos mecanismos para que isso possa ser mais bem conduzido, ainda na fase 
de planejamento, são os termos de aceite dos entregáveis, que são entregas parciais do 
projeto e o aceite final do projeto, sendo este um dos grandes desafios do GP.
Além do produto e da documentação técnica, o gerente do projeto deve providenciar 
um termo de recebimento para que, em conjunto com o cliente, ele possa assinar e atestar 
a aprovação do que está sendo entregue. Essas formalidades ajudarão a garantir que as 
entregas do projeto estejam prontas para ser apresentadas ao paciente e que sejam aceitas 
por ele. O documento de entrega pode ser bastante simples, como mostra a Figura 3.
Figura 3 - Exemplo de um Termo de Recebimento
Fonte: o autor.
38UNIDADE II Definição e Planejamento
Além dos termos de aceite, é necessário controlar o escopo. Para isso existem 
várias técnicas e ferramentas que podem ser empregadas no controle das mudanças de 
escopo de um projeto. Toda a atividade de controle passa por um ciclo de controle, como 
é apresentado na Figura 4.
O controle de escopo exige alguns cuidados especiais. A definição de marcos por 
meio de resultados das entregas do projeto auxilia a pontuar o controle do escopo do pro-
jeto. A frequência de controle nem sempre cobre toda a geração do produto e nem sempre 
é igualmente distante. Vale lembrar que os marcos não aparecem na EAP.
Olhando a Figura 4 percebemos que a principal entrada é uma adequada linha de 
base. Assim, aproveitamos o momento para definir que linha de base é o conjunto de todos 
os entregáveis do projeto, representados pelas “caixas” exibidas na EAP.
Figura 4 - Ciclo de controle em um projeto
Fonte: o autor.
Já a comparação entre o previsto e o realizado consiste em ações de análise, que 
exigem conhecimento técnico no entendimento da situação e na avaliação das diferenças 
encontradas. A análise dessas diferenças permitirá que alternativas de solução possam ser 
geradas e que sejam tomadas decisões que, quando implementadas, levem o projeto ao 
seucurso normal, previsto originalmente.
O próximo passo nesse ciclo de controle é o de executar a mudança, que deve 
ser previamente definida na área de conhecimento Integração. O fluxo de mudanças pode 
39UNIDADE II Definição e Planejamento
envolver um comitê com vários integrantes ou somente a análise técnica dos impactos e 
a formalização via e-mail da aprovação das alterações pelo cliente. Com a confirmação 
realizada, as ações devem ser tomadas para sua implementação e entrada dentro do ciclo 
de desenvolvimento.
40UNIDADE II Definição e Planejamento
6. DEFINIÇÃO DAS ATIVIDADES
A definição das atividades tem papel fundamental no planejamento, execução e 
controle de um projeto. É por meio das atividades que se delegam as ações para as pessoas 
envolvidas no projeto que se define o trabalho necessário para o cumprimento das entregas 
prometidas ao cliente, e que determina o caminho crítico do projeto e ainda servirá de base 
para o cálculo do custo do trabalho para a montagem do orçamento do projeto.
Os atrasos ou antecipações durante a execução também acontecerão nas 
atividades. É aí que podem ocorrer possíveis variações de custo e qualidade que deverão 
receber ação gerencial corretiva dos gerentes do projeto, se necessário, como veremos 
mais à frente.
Além disso, somente após as atividades definidas podemos executar os processos 
seguintes do gerenciamento do cronograma, fazendo o sequenciamento das atividades e 
as estimativas de duração das atividades.
Não somente o gerenciamento de cronograma, mas todas as áreas do gerencia-
mento de projetos têm no escopo a base para seu planejamento, mas no caso específico do 
gerenciamento do cronograma e, principalmente, no momento de definição das atividades, 
a influência do escopo toma maior proporção.
Através da EAP e, mais precisamente, dos entregáveis (deliverables) é que as 
atividades surgiram. Levando como base a EAP da Figura 2, podemos ver caixas em azul 
e vermelho, que representam os entregáveis do projeto, isto é o escopo do projeto, as 
41UNIDADE II Definição e Planejamento
atividades serão tudo o que deve ser realizado para que cada caixa seja entregue. Desse 
modo, as atividades estão intrinsecamente ligadas ao escopo e a EAP, porém são definidas 
pela área de CRONOGRAMA. É estranho, a princípio, imaginar isso, porém as atividades 
são de responsabilidade de quem controla o Cronograma e assim todas as tarefas surgem 
a partir dessa definição.
6.1 A Utilização de Marcos (Milestones)
Os marcos são atividades especiais constantes do cronograma, com função não de 
exprimir uma ação, mas sim um evento pontual no tempo. Um marco é uma atividade sem 
duração e, consequentemente, sem trabalho e custo, não tendo um recurso com a função 
de executar uma ação.
São, na verdade, datas no cronograma representativas de eventos importantes 
para o projeto, também conhecidos como milestones. Esse tipo de cronograma tem, muitas 
vezes, uma função de posicionar a alta gestão sobre o andamento do projeto através de 
marcos importantes de entregas durante o projeto.
42UNIDADE II Definição e Planejamento
7. SEQUENCIAMENTO DAS ATIVIDADES
Por meio do processo de sequenciamento passa a ser viável a identificação dos 
diversos relacionamentos lógicos entre atividades, em função das relações de precedências 
adequadas. É preciso não só representar, mas documentar todos os tipos de relacionamento, 
suas eventuais exigências de antecipações ou atrasos, e tudo que se faça necessário para 
que o desenvolvimento do cronograma seja feito da maneira mais realista possível.
O objetivo final do sequenciamento das atividades é a obtenção de um diagrama 
de rede completo, compreendendo todas as atividades do projeto e suas diversas inter-
relações. Para tanto, segundo Barcaui (2010), o método de diagramação mais conhecido e 
utilizado é o diagrama de precedências (PDM – Precedence Diagramming Method) que foi 
criado entre 1962 e 1964 pela Stanford University, por meio do dr. John Fondahl.
Esse tipo de método oferece uma clara vantagem pois as atividades estão 
representadas nos nós e as relações nas setas, conforme a Figura 5. Nesse método existem 
quatro tipos de relações possíveis:
• Início-Início: O início da atividade seguinte somente pode começar quando a 
atividade anterior começar (Figura 8);
• Final-Final: O final da atividade seguinte somente pode terminar quando a 
atividade anterior finalizar (Figura 7);
• Início-Final: O final da atividade seguinte somente pode terminar quando a 
atividade anterior iniciar (Figura 9);
• Final-Início: O início da atividade seguinte somente pode começar quando a 
atividade anterior finalizar (Figura 6).
43UNIDADE II Definição e Planejamento
Figura 5 - Diagrama de Precedência
Fonte: o autor.
Figura 6 - Tipos de Precedência: Final-Início
Fonte: o autor.
Figura 7 - Tipos de Precedência: Final-Final
Fonte: o autor.
Figura 8 - Tipos de Precedência: Início-Início
Fonte: o autor.
Figura 9 - Tipos de Precedência: Início-Final
Fonte: o autor.
44UNIDADE II Definição e Planejamento
8. ESTIMANDO A DURAÇÃO DAS ATIVIDADES
Estimar a duração das atividades é uma das tarefas mais difíceis e complexos do 
planejamento de um projeto. Assim, procuramos explorar ao máximo as etapas necessárias 
para que uma boa estimativa de duração de atividades possa ser realizada. Mas é importante 
lembrar que se trata de uma estimativa e nunca de uma certeza absoluta.
O processo de estimar a duração das atividades de acordo com o PMBOK (2017) 
é “obter avaliações quantitativas do número provável de períodos de trabalho necessários 
para a conclusão de uma atividade do cronograma”. Duas técnicas são bem famosas para 
realizar esse tipo de atividade – além, claro, das técnicas de análise de especialista –, são 
a técnica Delphi e Estimativa de três ponto, ou técnica PERT.
A técnica Delphi deve ser aplicada em grupos de cinco a dez pessoas, com um 
moderador que apresenta o problema e participantes que determinam o prazo para sua 
execução, gravando essa informação em um papel, sem que os demais vejam. Após 
a rodada de estimativa, todos abrem seus valores e o moderador passa a palavra aos 
integrantes que definiram o menor e o maior valor. Dessa forma, todo o grupo pode chegar 
a um número razoável, considerando o pior caso e o melhor caso.
A técnica de três pontos ou PERT consiste em realizar uma previsão para cada 
atividade, seguindo três vertentes: o caso mais otimista, o caso mais pessimista e o caso 
mais provável. Assim, deve-se fazer uma média somando as três vertentes, dando peso 4 
para a mais provável e dividindo por 6.
45UNIDADE II Definição e Planejamento
Figura 10 - Cálculo de Estimativa de Três pontos (PERT)
Fonte: o autor.
46UNIDADE II Definição e Planejamento
9. ELABORAR O CRONOGRAMA DO PROJETO
Determinar a programação de um projeto não é uma atividade simples. Na verdade, 
é uma combinação de arte e ciência. A ciência está em determinar no diagrama de rede 
do projeto onde está o caminho crítico (iremos detalhar melhor esse assunto ainda neste 
tópico) e quanto de folga existe nas atividades não críticas. A questão relativa à arte é 
garantir, com toda a incerteza inerente ao projeto, que o cronograma seja executado dentro 
do prazo. Essa atividade é um grande desafio, visto que existem diversas variáveis que 
podem impactar o planejamento, como a própria ausência de recursos para realizar as 
atividades.
Um erro muito comum é quanto à percepção de que os recursos estarão sempre 
100% focados na atividade. Em média, as pessoas trabalham na ordem de 60% a 75%, 
mas isso depende da área de especialização e do grau de atividades paralelas que esse 
recurso poderá estar participando. Esse tipo de situação pode ser exemplificado por uma 
equipe de desenvolvimento que deve implementar um conjunto de novas funcionalidades 
no sistema, porém essa mesma equipe é responsável por auxiliar o cliente no processo de 
homologação da versãoanteriormente entregue e promover correção no sistema quando 
houver.
Elaborar um cronograma requer o uso de uma análise do diagrama de rede criado 
anteriormente no processo de sequenciamento das atividades. Essa análise faz uso de 
uma diversidade de técnicas analíticas, que têm como objetivo principal obter as datas mais 
47UNIDADE II Definição e Planejamento
cedo e mais tarde de cada atividade, identificando as folgas e qual o conjunto ou caminho, 
dentro do diagrama, que determina a duração total do projeto. Apesar da existência de 
outros métodos, o caminho crítico é a base para o cálculo da maioria dos cronogramas de 
projeto.
Para determinar isso, é necessário duas análises após o diagrama de rede pronto: 
uma para frente – feita nos caminhos de ida (do começo para o final) – e outra para trás 
– feita no caminho de volta (do final para o começo). Com essas análises teremos o início 
mais cedo das atividades e o início mais tarde, a diferença entre essas datas é a folga total. 
Dessa forma, o caminho mais longo entre o início e o final do projeto, sem folga, é definido 
como caminho crítico (Figura 11).
Figura 11 - Diagrama de Rede: Caminho Crítico
Fonte: o autor.
 
Na Figura 11, FT = Folga Total, IMT = Início Mais Tarde, IMC = Início Mais Cedo, 
TMT = Término mais Tarde, TMC = Término mais Cedo. 
Além disso, temos o conceito de folga livre, o tempo que é possível atrasar o início 
de uma atividade sem adiar o início das atividades sucessoras. Essa folga livre é calculada 
fazendo a diferença entre o IMT da atividade sucessora menos o TMC da própria atividade.
Porém, imprevistos podem acontecer e, antes de agir de forma mais enérgica no 
projeto, existem algumas técnicas que podem ser aplicadas no próprio cronograma. É o 
caso da compressão (crashing) e o paralelismo (fast tracking):
• Compressão: uma das maneiras é a adição de mais recursos à atividade, 
porém deve ser feita com muito cuidado, porque à medida que novos recursos 
são adicionados é possível ter o efeito contrário, ou seja, aumentar o tempo da 
48UNIDADE II Definição e Planejamento
atividade, pois esse novo recurso deverá ser treinado para a atividade e outros 
recursos poderão ter que parar suas atividades para ensiná-lo ou revisar suas 
atividades.
• Paralelismo: permitir que atividades que sejam sequenciais sejam desenvolvidas 
de certa forma em paralelo. Para esse tipo de ação é necessário um grande 
envolvimento entre os recursos das atividades em questão, pois o risco de 
retrabalho é considerável.
49UNIDADE II Definição e Planejamento
10. CONTROLAR O CRONOGRAMA
Entende-se que, na verdade, não controlamos a variável tempo, mas sim os 
fatores de produção e seu comportamento em termos de oferta e demanda ao longo do 
desenvolvimento do projeto. Entre os itens relevantes desse comportamento pode- se listar:
• Se os fatores de produção, especialmente os recursos humanos, serão 
ofertados em quantidades suficientes por todo o período de produção, sem 
descontinuidade;
• Se as demandas por recursos entre atividades simultâneas não comprometerão 
a estimativa final do prazo do projeto, obtido por meio do desenvolvimento do 
cronograma;
• Se os níveis de produtividade que serviram de base para estimativa das durações 
estão sofrendo variações relevantes que necessitem de ações corretivas para 
recuperar ou minimizar possíveis impactos no prazo do projeto.
O controle de prazos pode ser visto como um processo de monitoramento contínuo, 
envolvendo a análise das causas, seus efeitos sobre as durações do projeto e se esses 
desvios estão dentro das margens estabelecidas. Para o efetivo controle, é necessário um 
processo de monitoramento que envolve a coleta e recebimento de informações relevantes 
e suficientes de muitas fontes, como relatórios periódicos com progresso físico das tarefas 
executadas e reuniões de avaliação e revisão.
50UNIDADE II Definição e Planejamento
11. ESTIMATIVAS DE CUSTO
O processo de estimar os custos está vinculado a uma projeção de futuro daquilo 
que será gasto em cada um das atividades do projeto, portanto trabalha com dados que 
dependem dos valores que serão gastos no projeto e não na construção do preço do 
produto do projeto. Assim, para poder construir um bom preço é necessário ter uma boa 
assertividade na estimativa e, assim, usar técnicas disciplinares e científicas para sua 
aplicação.
11.1. Estimativa de Ordem de Grandeza
Normalmente, empregada no estágio inicial do projeto ou em sua concepção, ela 
usa como base dados históricos, experiência e fatores de escala. Essa estimativa ainda 
suporta uma variação de 25% para menos e 75% para mais.
11.2. Estimativa Análoga
Usada quando temos dados sobre projetos já executados anteriormente, 
semelhantes em escopo e tamanho. Tem custo baixo, pois usa dados históricos e precisão 
também baixa, visto que cada projeto é diferente e pode sofrer alterações não consideradas 
inicialmente.
51UNIDADE II Definição e Planejamento
11.3. Estimativa Paramétrica
Essa estimativa usa técnicas estatísticas que utilizam dados históricos e fórmulas 
matemáticas para sua definição. Esse tipo de técnica gera um valor base para o cálculo 
do projeto que se deseja conduzir. Exemplo, custo da construção civil por metro quadrado 
determinado pelo Índice Nacional da Construção Civil calculado pelo IBGE em convênio 
com o Caixa Econômico Federal.
11.4. Estimativa PERT
A estimativa PERT (Program Evaluation and Review Technique) - Programa de 
avaliação e Técnica de revisão, também conhecida como técnica de três pontos, é aplicada 
quando não existe histórico de atividades próximas a esta que será realizada, e não temos 
especialista para ajudar na estimativa. Essa técnica define três opiniões para cada atividade, 
a opinião pessimista, otimista e a mais provável, conforme a Figura 12.
Figura 12 - Gráfico PERT por atividade
Fonte: o autor.
11.5. Estimativa Delphi
Essa técnica consiste em uma estimativa em grupo em que um integrante explica 
para os demais tudo aquilo que deve ser feito para a conclusão da atividade e, assim, cada 
integrante do grupo escreve o tempo necessário para realizar a atividade em um papel 
(estimativa individual). Após essa rodada de estimativas, todos abrem o valor que foi escrito 
por cada elemento do grupo e os autores do maior valor e do menor valor são convidados a 
defender seus valores. Ao final dessa rodada, o grupo entra em consenso sobre qual será 
a estimativa para a atividade em questão e a rodada recomeça para a próxima atividade.
52UNIDADE II Definição e Planejamento
11.6. Estimativa de Especialista
Envolve a experiência de um determinado profissional sobre a atividade que deve-
rá ser realizada. Esse profissional busca informações sobre a atividade, como tecnologia 
empregada, tópicos de regras de negócio envolvidas, análise de impacto, casos de uso e 
planos de teste (se existir). Essa estimativa tem custo direto baixo, porém difícil de manter, 
pois profissionais com essa característica têm muita experiência e normalmente custam 
caro para a organização.
53UNIDADE II Definição e Planejamento
12. ANÁLISE E GESTÃO DE RISCO
A análise de riscos considera os processos necessários para analisar a severidade 
dos riscos identificados pela equipe para um projeto específico e depois priorizá-los. Tais 
processos envolvem o tratamento qualitativo e/ou quantitativo desses riscos, de modo a 
tornar clara ao gerente do projeto e aos stakeholders a importância do tratamento prévio 
e da prevenção de alguns deles, em prol do alcance dos objetivos do projeto. Estaremos, 
portanto, abordando os seguintes passos na promoção de uma análise adequada dos riscos 
identificados, em que a decisão do método a ser utilizado (qualificação/quantificação) será 
estrategicamente estudado:
Qualificação:
• atribuição de um grau da probabilidade da ocorrência de riscos;
• atribuição de um grau no impacto da ocorrência de riscos;
• cálculodo determinante geral de riscos do projeto;
• priorização de riscos.
Quantificação:
• estimativa numérica da probabilidade da ocorrência de riscos;
• determinação numérica do impacto da ocorrência de riscos;
• cálculo do valor monetário esperada;
• priorização de riscos.
 
54UNIDADE II Definição e Planejamento
Estes dois processos (qualificação e quantificação) podem ser usados individualmente 
ou em conjunto: utilizamos a qualificação para fazer uma pré- seleção dos riscos, para 
depois quantificarmos apenas os riscos selecionados no processo de qualificação.
As informações geradas a partir da análise dos riscos priorizados fundamentarão 
o desenvolvimento de estratégias de resposta a riscos apropriadas ao caso específico, 
objetivando a redução do impacto negativo e o aumento potencial dos benefícios decorrentes 
nos riscos positivos (oportunidades) do projeto.
 
12.1. Qualificação
A abordagem qualitativa nos dá uma primeira dimensão do peso dos riscos, 
classificando as variáveis probabilidade e impacto, em escalas ordinais, variando, 
por exemplo, de “muito baixo” até “muito alto”. Para tal, podemos usar ferramentas 
computacionais que irão facilitar o trabalho que será conduzido pela equipe do projeto. A 
partir dos riscos listados, vamos analisá-los quanto à probabilidade e ao impacto, conforme 
ilustrado na Figura 13, registrando na ferramenta nossa percepção do peso da variável. 
Note que, ao se registrarem os pesos para o impacto, um índice de impacto geral para 
aquele risco pode ser gerado.
Figura 13 - Matriz de Vulnerabilidade (Probabilidade x Impacto)
 
Fonte: o autor.
 
 Como dito, a organização que autoriza o projeto é que geralmente oferece os 
critérios de avaliação das probabilidades dos riscos identificados, que podem ser estimados 
55UNIDADE II Definição e Planejamento
segundo padrões qualitativos ordinais ou quantitativos. Cabe ainda à organização oferecer 
subsídios norteadores, de modo que o nível de subjetividade intrínseca do trabalho passe 
a ser mantido dentro de padrões adequados. No caso de usar a matriz de vulnerabilidade 
seria possível estabelecer, por exemplo, que todos os riscos classificados nos quadrantes 
amarelo e vermelho seriam utilizados para serem analisados pela técnica de quantificação.
Tal como adotado na estimativa da probabilidade, a organização que autoriza 
o projeto é que geralmente oferece os critérios de avaliação dos impactos dos riscos 
identificados, que também podem ser estimados segundo padrões qualitativos ordinais 
ou quantitativos. O impacto é definido como o valor da consequência do risco sobre os 
objetivos do projeto: uma estimativa do ganho ou perda caso o risco aconteça.
Entretanto o parâmetro “impacto do risco” deve ainda ser avaliado segundo 
um critério adicional que aponte qual objetivo do projeto sofrerá as consequências da 
ocorrência do risco. Desse modo, recomenda-se que essa avaliação seja feita à luz dos 
condicionantes típicos do sucesso de um projeto, ou seja, do impacto do risco sobre o 
escopo, o cronograma, o orçamento ou a nível de qualidade da projeto.
 Essa análise pode oferecer complicações decorrentes de vários fatores:
• riscos podem interagir de modos inesperados;
• um único evento de risco pode causar eleitos múltiplos;
• oportunidade para um stakeholder (exemplo: custo reduzido) pode ser 
considerada ameaça para outro (exemplo: lucro reduzido).
Ao usarmos o processo de qualificação estamos atribuindo um grau a cada risco, 
independentemente de sua natureza. Estamos, com isso, afirmando que os pesos dos dois 
riscos de naturezas diferentes são iguais? A importância que devemos dar ao tratamento 
dos dois riscos é, necessariamente, a mesma? Não necessariamente! Isso começa a 
apontar que a qualificação, certamente, é excelente ferramenta se a compararmos com 
o que fazemos hoje, isto é, apenas colocar um percentual de segurança. Porém, se 
quisermos um efetivo gerenciamento dos riscos, a qualificação nos dá apenas uma breve 
ideia dos pesos e importância dos riscos. Precisamos de algo mais intenso, de forma a 
melhorar o nosso processo decisório. Não podemos gerenciar aquilo que não podemos 
medir. Consequentemente, se medirmos timidamente, gerenciaremos timidamente
56UNIDADE II Definição e Planejamento
12.2. Quantificação
Se comparada com o não fazer o gerenciamento dos riscos, a análise qualitativa dos 
riscos oferece benefícios consideráveis no entendimento do projeto e de suas incertezas 
futuras.
A análise quantitativa dos riscos, entretanto, fornece informações mais precisas para 
uma avaliação mais adequada do projeto. Afinal, as decisões de maior impacto costumam 
ser tomadas logo no início do ciclo de vida do projeto, durante sua concepção. Assim, a 
despeito das dificuldades encontradas na materialização desse intento, estimativas as mais 
precisas e o mais cedo possível são consideradas fundamentais.
Como vimos, devemos dimensionar a probabilidade e o impacto de cada risco. A 
probabilidade será sempre um percentual, e o impacto poderá ser medido em termos de 
diversas unidades, tais como aumento de custo ou dias de atraso no cronograma.
Porém, diferentes unidades de impacto tornam difícil, se não impossível, a 
comparação dos riscos de categorias diferentes entre si. Os riscos são do projeto, e devemos 
gerenciá-los, independentemente da categoria a que pertençam. Portanto, devemos levar 
todos os impactos para a mesma unidade, de forma a podermos comparar os riscos entre si. 
E a única unidade comum a todos os riscos é a financeira. Podemos transformar qualquer 
unidade de efeito em dinheiro, isso fará com que possamos comparar os riscos entre si.
Uma nova reflexão: só existem dois setores da economia que são essencialmente 
gestores de riscos e, curiosamente, estes dois setores apresentam resultados de negócio 
acima da média — setores financeiro e seguradora. Nesles nenhuma decisão de negócio é 
tomada sem que o gerenciamento de riscos seja feito. E, fundamentalmente, a análise dos 
riscos é sempre quantitativa. Ora, se esses dois setores apresentam excelentes resultados 
de negócio, possuem larga experiência no gerenciamento de riscos e somente usam a 
quantificação. Será que isso não nos sinaliza algo? Devemos nos esforçar para fazer a 
análise quantitativa, de forma a tentar obter para os nossos projetos, os mesmos benefícios 
que o preciso gerenciamento de risco traz para os dois setores citados.
Ao estimarmos probabilidade e impacto para cada risco, geramos o que é a medida 
da exposição ao risco, chamada de valor esperado ou VME - Valor Monetário Esperado 
(EMV — Expected Monetary Value):
valor Monetário Esperado = probabilidade x impacto 
 
O nome está dizendo: valor esperado é o que se espera que aconteça! Se temos 
uma probabilidade e um impacto para cada risco, temos também um valor esperado para 
57UNIDADE II Definição e Planejamento
cada um deles. E o risco total do projeto é a soma algébrica dos valores esperados de todos 
os riscos.
Como é que a seguradora calcula o prêmio de um seguro? Como um banco calcula 
a taxa de juros que você deve pagar em um empréstimo? Sempre por meio do valor 
esperado!
Imaginemos que você comprou um carro no valor de R$ 50 mil (impacto total 
possível) e vai colocá-lo no seguro. Você provavelmente respondeu a um questionário em 
que a seguradora avaliou a sua taxa de risco ao perguntar quantos quilômetros você roda 
por mês, quantas pessoas dirigem o carro, se você tem filho adolescente que dirige o 
carro, se o carro pernoita em garagem etc. Isso aponta que seu carro tem vários riscos 
associados ao uso. Vamos considerar, para efeito de entendimento da mecânica da análise 
dos riscos, apenas o risco de roubo e que a taxa histórica de roubo de carros iguais ao seu, 
na sua cidade, seja, por exemplo, de 2%.
Portanto o valor esperado será 2% x R$ 50mil= R$ 1 mil. Esse valor é o que a 
seguradora espera desembolsar por carro segurado casoocorra um sinistro.
O valor esperado dos riscos do projeto será o somatório dos valores esperados de 
todos os riscos:
valor esperado do projeto = valor Base + Σ valores esperados dos riscos
 Nesse momento, para podermos fazer a análise, precisamos de mais um valor: o 
valor base.
Valor base é o último valor que temos antes de iniciarmos o processo de 
gerenciamento de riscos. Já calculamos todo o projeto, já temos o escopo, o cronograma 
e o custo ou resultado projetado; portanto, já temos o valor base. Este seria, por exemplo, 
o valor da proposta a ser apresentada ao cliente. O valor esperado do projeto será o valor 
base acrescido do somatório dos valores esperados dos riscos do projeto:
valor esperado dos riscos do projeto = Σ valores esperados de todos os riscos
Esses dois valores são fundamentais, porém não suficientes. Precisamos de mais 
dois valores:
58UNIDADE II Definição e Planejamento
• pior caso: consideramos que todos os riscos de ameaça poderiam se materializar 
pelo total e que nenhum risco de oportunidade se materializar: valor esperado 
do pior caso = valor base + Σ impacto das riscos de ameaça;
• melhor caso: consideramos que todos os riscos de oportunidade poderiam se 
materializar pelo total e que nenhum risco de ameaça se materializaria: valor 
esperado do melhor caso = valor base + Σ impacto dos riscos de oportunidade.
 
12.3. O Planejamento de Respostas
O planejamento de resposta aos riscos é um processo que visa a elaboração de um 
plano de ação voltado para o aproveitamento das oportunidades, bem como para a redução 
das ameaças aos objetivos do projeto.
A decisão da reação deve ser iniciada analisando-se o texto do risco e seu valor 
esperado (exposição, no caso de riscos de ameaça ou alavancagem, em caso de riscos de 
oportunidade).
A reação que adotamos para enfrentar um risco pode decorrer em dois diferentes 
momentos, como veremos a seguir.
12.4. Prevenção ou Contingência?
Ao analisarmos os riscos, podemos decidir por reações imediatas ou posteriores, 
no momento em que há risco ocorrer. É mandatória a identificação do momento da reação 
ao risco, pois isso provocará condições diferentes para o desenvolvimento do projeto. 
Às reações adotadas antes da ocorrência dos riscos, no momento do planejamento, 
chamamos de reações de prevenção ou de contenção, no caso de ameaças, ou reações 
de alavancagem, no caso de oportunidades. No planejamento, essas reações acontecem 
antes da decisão final sobre o projeto, alterando potencialmente as principais variáveis de 
impacto, tais como escopo, qualidade, tempo ou as condições financeiras. Isso se deve a 
essas reações significarem custos imediatos e/ou negociação com a contratante, alterando 
as condições de desenvolvimento e de análise de viabilidade do projeto, pois vão reduzir 
exposições ou alavancar resultados nos valores totais do projeto, antes da decisão final de 
go/no-go do projeto, conforme Figura 14.
Um exemplo claro para nós, de reação de prevenção ou contenção é o seguro que 
fazemos para o nosso carro. O preço total de posse de um carro normalmente é calculado 
como sendo o preço do carro mais o preço do seguro, e toda essa despesa é feita no início 
do “projeto carro”. As reações de prevenção/contenção ou alavancagem são, na realidade, 
reações a serem adotadas antes de o risco acontecer. Apesar de focarmos nessas ações 
59UNIDADE II Definição e Planejamento
no momento do planejamento, nada impede que, durante o desenvolvimento do projeto, 
tenhamos novas ações de prevenção/contenção ou alavancagem, desde que antes dos 
riscos correspondentes se materializarem.
Figura 14 - Momento de reação ao risco
Fonte: o autor.
 Além das reações em tempo de prevenção/contenção, podemos também ter reações 
de contingência (no caso de ameaças ou aproveitamento no caso de oportunidades). Essas 
são ações planejadas agora, mas que serão efetuadas no momento em que o risco ocorrer, 
e que significarão custos futuros que precisam ser planejados em reservas financeiras.
Esses dois momentos de reações podem ser complementares, o que poderá 
provocar dois tipos de reação para um mesmo risco, sendo uma ou mais reações de 
prevenção/contenção e uma ou mais reações de contingência, ou, ainda, poderemos ter 
riscos em relação aos quais não temos o que fazer agora (prevenção/contenção), mas que 
podemos contingenciar no futuro.
Se não entendermos a diferença entre esses dois momentos de reações aos riscos, 
não conseguiremos definir custos imediatos que influenciarão o valor do projeto agora, nem 
custos futuros que direcionarão possíveis reservas financeiras a serem feitas.
Após selecionamos a reação devemos entender o que ela provoca na probabilidade 
ou no impacto do risco. Descreveremos, a seguir, o que chamamos de estratégias de 
reação aos riscos. Segundo o Guia PMBOK (2017), existem varias estratégias possíveis de 
resposta aos riscos do projeto, como ilustra a Tabela 1.
60UNIDADE II Definição e Planejamento
Tabela 1 – Tipos de estratégia de resposta aos riscos 
 
Fonte: o autor.
Quatro estratégias estão associadas aos riscos que, se ocorrerem, podem ter im-
pactos negativos ou positivos nos objetivos do projeto.
 
12.5. Riscos de Ameaças - Evitar
A estratégia de evitar riscos envolve mudanças no plano de gerenciamento do projeto 
para eliminar a ameaça apresentada para um risco adverso, visando isolar os objetivos do 
projeto dos possíveis impactos. Muitas das ações podem estar relacionadas diretamente 
com o gerenciamento de projetos, como, por exemplo, extensão do cronograma e redução 
do escopo.
Mas prevenir riscos pode estar relacionado com novas formas de abordar, 
tecnicamente, a solução proposta pelo projeto. Nesses casos, uma reformulação gerencial 
deve ser considerada. De qualquer forma, a estratégia de prevenir o risco tem como objetivo 
modificar o plano do projeto para eliminar a causa raiz do risco em questão.
O uso exagerado dessa estratégia, contudo, pode levar o projeto como um todo para 
uma posição conservadora, em que se evita utilizar novas tecnologias, novos fornecedores 
etc.
Evitar, na prática, significa tomar ações para levar a probabilidade do risco a zero, 
atuando-se obrigatoriamente na causa raiz do risco.
Essa estratégia aplica-se apenas em tempo de contenção/prevenção, pois, como 
atua na probabilidade, em tempo de contingência não é possível.
 
12.6. Riscos de Ameaças - Transferir
A transferência de riscos corresponde à mudança, para terceiros, da responsabilidade 
— e da propriedade da resposta — sobre um impacto negativo de uma ameaça. Ela confere 
à outra parte a responsabilidade pelo gerenciamento dos riscos, embora esse ato não os 
elimine. A transferência da responsabilidade pelo risco é mais eficaz quando relacionada 
61UNIDADE II Definição e Planejamento
à exposição aos riscos financeiros. A transferência de riscos pode envolver o pagamento 
de um prêmio à parte que as assume, como no caso de um seguro. As ferramentas de 
transferência podem ser bem diferentes e incluem, entre outras, cláusulas contratuais, 
garantias, seguros, limites de responsabilidade etc.
Os contratos podem ser usados para transferir responsabilidades por riscos 
especificados para uma outra parte. A inclusão de cláusulas contratuais ou limites de 
responsabilidade em um contrato/proposta pode especificar qual das partes ficará com 
determinado risco.
 Na prática, a transferência de um risco não o elimina, apenas discute quem ficará 
com o ônus do risco. A probabilidade do risco ocorrer continua existindo e seu impacto 
potencial também, só que com outro responsável. Essa estratégia também só se aplica em 
tempo de contenção/prevenção, pois não é possível transferir algo que já ocorreu.
 
12.7. Riscos de Ameaças - Mitigar
A mitigação de riscos em projetos visa a redução da probabilidade ou do impacto de 
um evento de risco adverso até um limite em que o valor esperado resultante seja aceitável. 
Em