102 - Apostila - Gerência de Projetos em Ti

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
UNIFATECIE Unidade 1
Rua Getúlio Vargas, 333,
Secretário Acadêmico Centro, Paranavaí-PR
Tiago Pereira da Silva (44) 3045 9898
Projeto Gráfico e Editoração UNIFATECIE Unidade 2

André Oliveira Vaz Rua Candido Berthier
Fortes, 2177, Centro
Revisão Textual Paranavaí-PR
Kauê Berto (44) 3045 9898
Web Designer Rua Pernambuco, 1.169,
Thiago Azenha Centro, Paranavaí-PR
(44) 3045 9898
BR-376 , km 102,
Saída para Nova Londrina
Paranavaí-PR
FICHA CATALOGRÁFICA (44) 3045 9898
FACULDADE DE TECNOLOGIA E
CIÊNCIAS DO NORTE DO PARANÁ.
Núcleo de Educação a Distância; www.fatecie.edu.br
MARTINS, André Dias.
Gerência de Projetos em TI. André. Dias Martins.

Paranavaí - PR.: Fatecie, 2020. 112 p.
As imagens utilizadas neste
Ficha catalográfica elaborada pela bibliotecária livro foram obtidas a partir
Zineide Pereira dos Santos. do site ShutterStock
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
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
UNIDADE I
Introdução à Gerência de Projetos
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.
7
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.
UNIDADE I Introdução à Gerência de Projetos 8

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.

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).

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.

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.

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 que o 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

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.

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

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

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.

Figura 2 - Distribuição dos Processos do PMBOK por grupo de Processos
Fonte: Beware (2000).

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ábitos diá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 inﬂuenciar 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

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 inﬁnitas.
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/

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.

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.

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

UNIDADE II
Definição e Planejamento
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.
• 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.
24
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.
UNIDADE II Definição e Planejamento 25

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

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.

Figura 1 - Distribuição dos Processos do PMBOK por grupo de Processos
Fonte: Vargas (2017).

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).

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.

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

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.

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 simples lista 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

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).

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.

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;

• 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.

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
seu curso 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

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.

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

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.

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).

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.

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.

Figura 10 - Cálculo de Estimativa de Três pontos (PERT)
Fonte: o autor.

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ão anteriormente 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

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

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.

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.

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.

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.

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.

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álculo do 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.

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

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

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

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 caso ocorra 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:

• 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

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.

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

à 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 geral, a mitigação no início do projeto (prevenção) é certamente mais eficaz do que a
tentativa de reparar os danos após a ocorrência do risco (contingência). Quando adotados,
processos menos complexos, como, por exemplo, a realização de testes ou a escolha de
um fornecedor mais estável, constituem alguns tipos de ação eficaz de mitigação.
Quando não for possível reduzir a probabilidade, o gerente de projetos e sua
equipe podem adotar a redução do impacto do risco concentrando-se no efeito deste. Por
exemplo, o projeto de redundância em um subsistema pode reduzir o impacto de uma
falha do componente original. Alguns exemplos de mitigação dos riscos, independentes de
prevenção ou de contingência, são apresentados na Tabela 2.
Tabela 2 - Exemplos de ações de mitigação
Fonte: o autor.

Essa estratégia pode ser aplicada tanto em tempo de contenção/prevenção quanto
em tempo de contingência. No entanto em tempo de contenção/prevenção é possível mexer
na probabilidade ou no impacto, mas em tempo de contingência é possível mexer apenas
no impacto (o risco já aconteceu, então a probabilidade já está em 100%).
12.8. Riscos de Ameaças - Aceitar

Os riscos nas quais a probabilidade de ocorrência é baixa, bem como é baixo seu
impacto nos objetivos do projeto, ou os riscos nos quais não há o que fazer, o gerente
de projetos e sua equipe podem, simplesmente, aceitar. Nesses casos, os objetivos do
projeto estão, de certa forma, desprotegidos, mas, caso os riscos ocorram, estes podem
ser contingenciados.
Em alguns casos, o gerente de projetos pode tomar a decisão de aceitar apenas
no âmbito da gestão interna do projeto, mas em outros essa decisão deve ser levada aos
clientes e patrocinadores. Certamente essa estratégia é mais arriscada.
A aceitação do risco pode ser de dois tipos: passiva ou ativa. A passiva não exige
nenhuma providência, deixa a equipe do projeto lidar com o risco quando ele ocorre, de
forma reativa. A aceitação ativa não inclui ação de prevenção, mas nela existe um plano de
contingência para ser executado no caso de o risco ocorrer. Nesse caso também só agimos
a posteriori.
Na prática, a aceitação do risco, seja ativa ou passiva, não mexe na probabilidade
nem no impacto do risco agora (tempo de contenção/prevenção), nem significa custos
imediatos.
A moderna visão do gerenciamento de riscos em projetos também envolve a
determinação de estratégias para aproveitamento de oportunidades de eventos incertos
em relação aos objetivos do projeto, que podem ser definidas por meio de quatro respostas:
provocar, compartilhar, melhorar ou ignorar, com o objetivo de alavancar seus resultados.
Veremos essas respostas a seguir.
12.9. Riscos de Oportunidades - Provocar

Essa estratégia pode ser selecionada para riscos com impactos positivos e nos
pontos em que a organização deseja garantir que a oportunidade seja concretizada; tenta
eliminar a incerteza associada a um risco positivo específico, fazendo com que a oportuni-
dade definitivamente aconteça.

Na prática, provocar significa mexer apenas na probabilidade do risco, gerando a
causa raiz deste, transformando a incerteza em fato e levando-a a 100%.
A exemplo da estratégia de evitar, esta existe tão somente em tempo de alavancagem.
12.10. Riscos de Oportunidades - Compartilhar

O compartilhamento de um risco positivo envolve a atribuição da propriedade a
terceiros que possam capturar melhor a oportunidade em benefício do projeto. Os exemplos
de ações compartilhadas incluem a formação de parcerias, equipes, empresas de propósito
específico ou joint ventures para compartilhamento de riscos, que podem ser estabelecidas
com o objetivo expresso de gerenciar oportunidades. Nesse tipo de estratégia é possível
fazer com que as organizações do projeto estabeleçam alianças, de tal forma que suas
atuações individuais resultem em oportunidades mais eficazes.
A exemplo da estratégia de transferir, esta também só existe em tempo de alavan-
cagem.
12.11. Riscos de Oportunidades - Melhorar

Essa estratégia visa alterar o “tamanho” de uma oportunidade por meio do aumento
da probabilidade e/ou dos impactos positivos e pela identificação e maximização dos
principais acionadores desses riscos de impacto positivo. Procurar facilitar ou fortalecer
a causa da oportunidade e direcionar e reforçar, de forma proativa, suas condições de
acionamento pode aumentar sua probabilidade. Os acionadores de impacto também podem
ser direcionados, tentando aumentar a suscetibilidade do projeto à oportunidade.
Essa estratégia pode ser aplicada tanto em tempo de alavancagem como em
tempo de aproveitamento. No entanto em tempo de alavancagem é possível mexer tanto na
probabilidade quanto no impacto, já em tempo de aproveitamento é possível mexer apenas
no impacto (como o risco já aconteceu, a probabilidade já está em 100%).
12.12. Riscos de Oportunidades - Ignorar

No caso de riscos de oportunidades, ignorar funciona exatamente da mesma forma
do explicitado anteriormente para a estratégia de aceitar, na seção “Riscos de ameaças”.
Os riscos nos quais a probabilidade de ocorrência é baixa, bem como é baixo seu
impacto nos objetivos do projeto, ou os riscos nos quais não há o que fazer, o gerente
de projetos e sua equipe podem, simplesmente, ignorar no âmbito da gestão interna, da
mesma forma que nos riscos de ameaças. Ou seja, nada a fazer.

12.13. O Plano de Resposta
O plano de resposta ao risco corresponde ao seu registro, elaborado de forma
detalhada, incorporando, para cada risco, as seguintes informações: a descrição completa
do risco, sua categoria, a data de identificação, a probabilidade e o impacto — que geram,
consequentemente, o valor esperado do risco, a estratégia de resposta selecionada e suas
respectivas ações e custos —, quem será o responsável pelo acompanhamento/ação, a
data planejada da reação ao risco, o nível de risco residual esperado (caso exista, é o novo
valor esperado). Isto se aplica tanto no caso de reações de prevenção/contenção quanto
no de reações de contingência.
12.14. As Reservas
Aqui necessitaremos quebrar mais alguns paradigmas. O conceito de reservas sofre
grandes mudanças com a aplicação dos processos de gerenciamento de riscos. Como
visto, no delineamento das estratégias de respostas ao risco um dos conceitos bastante
explorados no ambiente de projetos é o de reservas, o que, no senso comum, significa
guardar uma reserva financeira (ou de prazo), que poderá ser usada no futuro, ou não.
As Reservas podem ser de dois grandes tipos: reserva gerencial e reserva de
contingência. Por definição, a reserva gerencial destina-se a cobrir os riscos desconhecidos,
incertezas não identificadas previamente, desconhecidas: aquilo que não sabemos que
não sabemos. Essa é o antigo x% que colocávamos no projeto, ao final do planejamento.
Naquele momento, como não estávamos fazendo a gerência de riscos, todos os riscos
eram desconhecidos e, aí, culturalmente colocávamos os 10%. Aqui vale uma reflexão: se
agora fazemos a gerência de riscos, identificamos, analisamos e respondemos aos riscos
do projeto; se fazemos projetos cíclicos, repetitivos, de mesma natureza, e a grande maioria
dos riscos está associada ao tipo de projeto que fazemos, a tendência é que os riscos
desconhecidos (não identificados), conforme se ganha experiência em um determinado tipo
de Projeto, tendam a zero ou algo muito próximo disso. Tal fato elimina ou reduz a quase
zero a reserva gerencial, pois, para os riscos identificados, já calculamos o valor esperado.
Quanto à reserva de contingência, vamos refletir sobre alguns conceitos:
• contingência, por definição, é o que faremos (ação) quando o risco acontecer;
• já calculamos o valor esperado de todos os riscos do projeto; portanto, a “reserva”
financeira para cobrir o impacto dos riscos já está contemplada. Nesse caso,
se estamos fazendo a gerência de riscos, a reserva de contingência deverá

contemplar apenas a verba para podermos fazer frente ao custo projetado das
ações planejadas de contingência.
Quando estamos falando de riscos, os tipos de reserva mais utilizados pelos gerentes
de projetos são valores monetários ou prazo.
Aqui devemos decidir se vamos alocar reservas no cronograma (apenas para os
riscos cujo impacto seja em cronograma) ou se vamos calcular e considerar o valor esperado
dos riscos que afetam o cronograma. Não podemos fazer os dois, senão estaremos
reservando duas vezes a mesma coisa!
Quando fazemos o cronograma, podemos incluir reservas de prazo, o que quer
dizer: incorporar tempo adicional ao projeto. Estas são também chamadas, segundo o
Guia PMBOK (2017) , reservas de tempo ou buffers no cronograma total do projeto, como
reconhecimento do risco do cronograma. O gerente, junto com sua equipe, deverá, a partir
da análise de risco, considerar um percentual da duração total da atividade/projeto para
efeito de contingências. Nesse sentido, pode ser um percentual da estimativa de duração
da atividade ou um número fixo de períodos de trabalho.
A contingência de prazo pode ser calculada multiplicando-se a probabilidade de
ocorrência de um evento de risco pelo tempo adicional, caso o risco ocorra. Dessa forma,
se um evento com 40% de probabilidade de ocorrência gerar impacto em torno de 20 dias
de duração num determinado evento ou conjunto de atividades, será prudente fazer uma
reserva de oito dias (ou seja 40% x 20 dias = 8 dias).
Se decidirmos, em tempo de planejamento, incluir reservas de tempo no cronograma,
como explicitado anteriormente, e acrescentarmos o custo correspondente ao valor base
do projeto, isso deverá deixar de ser tratado como uma reserva, pois passará a ser custo
efetivo do projeto (novo cronograma, gerando novo custo). Esse valor poderá até não ser
utilizado, mas não é uma reserva em sua essência — reserva significa algo que é, inclusive,
contabilizado e controlado à parte.
A reserva para contingências pode ser usada total ou parcialmente, ou pode ser
reduzida ou eliminada posteriormente, conforme informações mais precisas sobre o projeto
se tomam disponíveis. Muitos projetos, com o aparecimento de uma nova tecnologia, por
exemplo, ou feito com um novo processo para realizar uma determinada tarefa, poderão
ter seu tempo de execução reduzido. Neste sentido, as reservas podem ser eliminadas ou
reduzidas, o que, certamente, dará mais folego ao projeto.
As reservas de contingência também podem ser relacionadas aos custos de um
projeto, situação em que, normalmente, são chamadas de provisões para contingências.

As reservas de contingências são custos estimados que devem ser provisionados,
entre outros motivos, visando criar as condições para que atividades futuras incertas
(reações para os riscos, planejadas para a momento em que eles ocorrerem) possam ser
executadas. Esses casos são eventos que, por alguma razão (aqui entram as incertezas)
precisam ter seus gastos provisionados. A utilização das reservas pelo gerente deverá
ocorrer no momento em que ele achar adequado para o bom andamento das contas do
projeto.
Em termos práticos, a gerência das reservas financeiras do projeto pode se
dar por meio da agregação das reservas de várias atividades relacionadas numa única
tarefa/atividade do cronograma, com duração nula. Na medida em que as atividades do
cronograma estão gerando consumo, a reserva deverá ser, concomitantemente, gerenciada
de acordo com as necessidades do projeto. Em muitos casos o fato de essa administração
ser realizada próxima das atividades do projeto, de forma mais exata, faz com que as
reservas sejam utilizadas de forma mais otimizada.
Alternativamente podem-se agrupar as reservas numa só atividade buffer e,
considerando-se o método da cadeia crítica, posicioná-la no final do caminho de um conjunto
de atividades do projeto. Da mesma forma que ocorre nas atividades de reserva com
duração nula, essas atividades de buffer também devem ser administradas estreitamente
conforme o projeto vai sendo desenvolvido. Espera-se, como resultado, que as variações
de custos do conjunto de atividades do projeto relacionadas com aquelas que contêm as
reservas sejam mais exatas.
Caso os riscos não ocorram, tanto as reservas de prazo quanto as de custos
podem ser, evidentemente, liberadas. No caso das reservas de custos, isso pode significar
diminuição do volume financeiro necessário para o projeto.
No Brasil esta prática ainda é incipiente e nota-se que é mais comum em setores
nos quais o gerenciamento de projetos está presente há mais tempo, como, por exemplo,
na engenharia da construção pesada.

SAIBA MAIS
Leia o texto escrito por Manuel M. Benitez Codas, publicado na Revista de Administração
de Empresas na edição 27, em 1987, acessando link: http://dx.doi.org/10.1590/S0034-
75901987000100004.
Nesse texto, Manuel faz um recorte sobre o Histórico do gerenciamento de projetos
passando por Henry L. Gantt e sua representação gráfica do desenvolvimento esperado
dos projetos e descrevendo o surgimento de grandes métodos, como CPM (Critical Path
Method), Pert (Program Evolution and Review Technique) e a EAP (Estrutura Analítica
de Projetos). Além disso, conta a história do surgimento de associações voltadas para
a discussão, disseminação e padronização, métodos para o gerenciamento de projetos,
citando o PMI e o IMSA (International Management Systems Association).
SAIBA MAIS
Descubra quem te inspira e por quê

Novamente apresentamos a você uma reflexão sobre o mundo empreendedor, com
nossa autora Bel Pesce. Nesse artigo ela escreve sobre a necessidade de sair do
mundo racional, parar de ver as coisas com um olhar lógico de 0’s e 1’s e procurar a
nossa inspiração, aquilo que nos motivou a seguir em frente, e não somente isso, seguir
em frente com o olhar fixo em nossos objetivos. Essa busca pela inspiração e a reflexão
sobre o que podemos aprender neste caminho é o que descreve o trecho a seguir.
“Sonhar faz muito bem. Você provavelmente possui uma lista de coisas que deseja
conquistar nos próximos meses, anos, décadas. Mas achar por onde começar pode ser
um grande desafio. E manter-se comprometido pode ser ainda mais difícil.
Se você não tomar cuidado, corre o risco de se prender demais aos projetos do dia a
dia e se esquecer de quais são seus planos a longo prazo. Sem contar que você pode
acabar limitando-se por não sonhar grande o suficiente.
Ao longo da sua vida, ter a quem admirar ajuda a se manter focado nas conquistas
que realmente importam. Além disso, pessoas admiráveis em geral mostram horizontes
muito amplos e fazem com que você não limite as suas ambições.
Uma das pessoas que admiro é Richard Branson, conhecido principalmente por fundar

o Virgin Group: um conglomerado de mais de 400 empresas, abrangendo produtos dos
mais diferentes mercados, de refrigerantes a voos. Eu admiro o fato de ele ter um senso
muito aguçado para negócios e confiar na sua intuição. Ele não tem medo de tomar
decisões diante de informações incertas ou de cometer erros. Ele realmente faz o que
ama e, ao mesmo tempo, proporciona serviços excelentes para os seus clientes, porque
de fato se importa com isso.
Também admiro o Steve Jobs, fundador da Apple. É extremamente surpreendente que
ele conciliasse o fato de ser um visionário e pensar décadas à frente com o cuidado de
ter uma atenção imensa para os mínimos detalhes. Algumas pessoas acreditam que o
Steve tinha um campo de distorção da realidade ao redor dele. Ele acreditava que coisas
impossíveis eram possíveis e fazia com que todas as outras pessoas acreditassem
também. No final, o impossível tornava-se possível.
Outra pessoa que admiro muito é o Ayrton Senna. Admiro a determinação que tinha
em ser o melhor piloto que poderia ser e o quanto trabalhou para isso. Sua ambição e
amor pelo esporte eram gigantes, mas seu coração era ainda maior. Apesar de viver em
um ambiente ultracompetitivo e muitas vezes ser prejudicado por decisões injustas, ele
sempre se manteve fiel ao seus valores.
Mais um exemplo admirável é o Sílvio Santos, empresário e apresentador. Ele tem uma
habilidade genial de lidar com pessoas e move multidões com esse seu dom. E, acima
de tudo, continua sendo um homem extremamente humilde, mesmo depois de tudo que
construiu.
Richard Branson, Steve Jobs, Ayrton Senna, Sílvio Santos e outras pessoas que admiro
me ajudam a ver que posso e devo sonhar alto. Ao entender o que eu admiro nelas, eu
acabo conhecendo-me muito melhor e entendendo o que realmente importa para mim”.
Fonte: http://lelivros.love/book/download-a-menina-do-vale-bel-pesce-em-epub-mobi-ou-pdf/

REFLITA
“Toda organização precisa de resultados. Para gerá-los precisamos ter um objetivo, que
foi traçado a partir de uma ideia. Para que possamos alcançar o que determinamos,
precisamos desenhar os caminhos que vamos fazer, ou seja, planejar o nosso trabalho.
Dentro dessa roda, temos a Gestão de projetos, que é o ato de tomar decisões para
realizar atividades temporárias, em outras palavras, que possuem início, meio e fim.
Especialistas do mercado financeiro estão otimistas quanto à economia brasileira para
o próximo ano, com juros e inflação controlados, bem como crescimento em vários
setores. Essa análise positiva é um incentivo para investir. Para sua empresa voltar
a crescer, é essencial planejar a forma que esse progresso vai acontecer. Por isso é
essencial investir também em gestão de projetos”.
Fonte: Terra (2017).
REFLITA
Publicado pelo UniDBSCO, Universidade Dom Bosco EAD, no dia 22/03/2018, pelo
professor Sandro Andriow, a matéria POR DENTRO DOS FATOS – A Importância da
Gestão do Tempo em um Projeto trata sobre a gestão de tempo dentro do projeto e qual
a importância e influência que o tempo tem em nossas vidas.
Leia acessando o link:

https://www.domboscoead.com.br/pos-graduacao/noticias/a-importancia-da-gestao-do-tempo-em-um-
projeto/20

INTRODUÇÃO
Tivemos a oportunidade de conhecer um pouco do que é a área de conhecimento

Escopo e seus processos e a relevância de sua gerência para o projeto. Além disso,
mostramos duas formas de gerenciar e manipular a EAP, a forma pictórica ou em árvore e
a forma lista enumerada, devendo escolher a que você melhor se adapta.
Na sequência aprendemos como a área de conhecimento Cronograma funciona
e como ela se integra aos processos produzidos pelo Escopo e como suas atividades são
criadas e gerenciadas ao longo do projeto.
Nesta unidade foi apresentada a área de conhecimento do PMBOK, chamada de
cronograma. Nessa área de gestão do projeto trabalhamos com atividades e seu vínculo
com a EAP, sequenciamento de atividades, estimativas de duração, criação do cronograma,
método de diagrama de precedência e análise de caminho crítico.
Vimos também como controlar esse cronograma e custos durante a execução do
projeto e como promover ações para ajustar o projeto real com aquele que foi planejado.

LIVRO
Título: Gerenciamento do escopo em projetos
Autor: FGV
Editora: IDE
Sinopse: O objetivo deste livro é apresentar referencial teórico
necessário para aprimorar os conhecimentos no gerenciamento
do escopo em projetos, incluindo conceitos e princípios do
gerenciamento e a indicação de meios adequados para pôr
em prática as informações aqui transmitidas. Os processos
descritos neste livro podem ser aplicados a qualquer projeto,
independentemente do negócio, cliente, solução ou abordagem.
É um guia para o gerenciamento do escopo, não uma prescrição.
FILME/VÍDEO
Título: Escopo de Projetos
Ano: 2018
Sinopse: Nessa videoaula abordamos o tema: escopo de um
projeto, passando pelas definições sobre o que é o escopo, as
etapas que fazem parte do seu planejamento e definição, EAP,
além dos impactos das mudanças no escopo ao longo do projeto.
Link: https://www.youtube.com/watch?v=HAqrNIpeDyM

UNIDADE III
Execução, Controle e Finalização
Plano de Estudo:
• Fundamentos do Gerenciamento da Comunicação.
• Planejar as comunicações.
• Acompanhamento e Avaliação do Progresso.
• Engenharia de Requisitos e Controle de Mudanças.
• Conhecer a origem dos Fundamentos do Gerenciamento da Comunicação.
• Conceituar sobre Planejamento, canais de contato e desafios da comunicação.
72
INTRODUÇÃO
Esta unidade dá continuidade às demais vistas sobre o PMBOK, aos estudos sobre
gerenciamento de projetos, tratando das grandes áreas do conhecimento: COMUNICAÇÃO,
AQUISIÇÕES, RISCOS, PARTES INTERESSADAS e INTEGRAÇÃO.
Dentro da gestão de projetos, segundo o PMBOK, essas áreas são propostas para
serem acompanhadas, planejadas e controladas. Por isso, para cada área proposta nesta
apostila iremos tratá-la em todos os grandes grupos de processo – Iniciação, Planejamento,
Execução, Monitoramento e Controle e Encerramento.
Portanto, não fique de 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 COMUNICAÇÃO.
UNIDADE III Execução, Controle e Finalização 73

1. FUNDAMENTOS DA COMUNICAÇÃO
Existem muitas técnicas, métodos e guias para conduzir de forma satisfatória um

projeto. Nesta unidade, que é continuidade da Unidade I, irei continuar seguindo o guia de
boas práticas de gerenciamento de projetos conhecido como PMBOK® (Project Management
Body Of Knowledge) produzido pelo PMI (Project Management Institute). Esse 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 nesta 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.
A partir dessa introdução, temos o alinhar necessário para dar continuidade aos
estudos entre os dois módulos, e concluir a elaboração do plano do projeto, introduzindo o
plano de gerenciamento da comunicação a você. Porém, antes de falar sobre o plano em
si, vou apresentar os fundamentos da comunicação.
Nossas sociedades primitivas desenvolveram a fala por necessidade de comunicação
e troca de informações. Mas não tinham como registrar o que era falado, o que limitava as

possibilidades de deixar um registro dessas informações, que eram transmitidas apenas
por via oral. Desenvolveram, então, para deixar registro de suas informações e experiência,
símbolos e desenhos que podem ser encontrados até hoje em sítios arqueológicos, dando,
assim, origem as primeiras formas escritas de comunicação.
Figura 1 – Distribuição dos Processos do PMBOK por grupo de Processos
Fonte: Vargas (2017).

Para o Guia PMBOK® (2017), “a maioria das habilidades de comunicação é comum
para o gerenciamento geral e o gerenciamento do projeto”. Assim, compreender e utilizar
corretamente o processo de comunicação é fundamental para o bom gerenciamento de
projetos.
1.1. O Processo de Comunicação

Aristóteles foi o primeiro a citar um modelo de comunicação, ao dizer que o processo
necessita de três elementos: aquele que fala, o que essa pessoa tentou dizer e aquele que
escuta, criando assim a base dos modelos de comunicação de hoje, pois deixou clara a
existência de um emissor, de uma mensagem e de um receptor.
Palavra de origem latina (comunicare), comunicação significa “ação de partilhar, de
dividir”. A comunicação pode ser definida como o processo que envolve a transmissão e a
recepção de mensagens entre uma fonte emissora e um destinatário receptor, no qual as
informações são codificadas na fonte e decodificadas no destino, com o uso de sistemas
convencionados de signos ou símbolos sonoros, escritos, iconográficos, gestuais etc.
Conforme Mendes (1999), “a comunicação significa tornar comum, trocar
informações, partilhar ideias, sentimentos, experiências, crenças e valores por meio de
gestos, atos, palavras, figuras, imagens, símbolos etc.”.
O emissor é o componente que emite uma mensagem para o receptor. Por dar
origem à comunicação, o emissor conhece o significado pretendido dessa mensagem
e deve codificá-la para que seja transmitida pelo canal de comunicação escolhido. Sua
comunicação será eficaz quando atingir seu objetivo e produzir a resposta desejada do
receptor.
Mensagem significa conteúdo, aquilo que é dito, escrito ou transmitido por símbolos
ou sinais, e seu objetivo é gerar reações e comportamentos. Ela pode ser transmitida pela
voz, por um texto, por meio de um desenho, por gestos, movimentos expressões faciais ou
por meios eletrônicos.
A codificação é a tradução da mensagem ou ideia para uma linguagem que seja
entendida pelas outras pessoas.
O receptor é o destinatário da mensagem, que recebe a informação e a interpreta.
Se a percepção e compreensão da mensagem que lhe foi transmitida acontecerem como
o emissor pretendia, o processo de comunicação alcançará seu objetivo e terá sucesso.
Contribuem para melhor compreensão a familiaridade do receptor com os tópicos da
mensagem, sua receptividade, a relação de confiança entre emissor e receptor, a clareza e

precisão daquilo que é emitido e a necessidade que o receptor tem de dispor do conteúdo
da mensagem emitida.
O ruído é tudo aquilo que afeta e interfere na transmissão de uma mensagem. São
exemplos de ruídos as distorções em sinais eletrônicos, erros de escrita e de interpretação,
uma voz baixa ou rouca durante uma conversa, a distância e a falta de atenção do receptor,
o uso de jargões, siglas e códigos não familiares a todos.
O feedback ou realimentação é a informação que o emissor obtém da reação do
receptor a sua mensagem. Serve para avaliar os resultados da emissão, para que se possa
estar certo de que a interação está sendo mantida no momento em que ela está sendo
processada; ajuda no processo de saber se e como a mensagem enviada foi recebida e
se foi compreendida ou não. Sem feedback, o emissor não sabe se sua mensagem foi
recebida e compreendida.
Entre os diversos componentes descritos, os canais de comunicação se destacam
pela sua importância e complexidade de utilização.
1.2. Canais de Comunicação

A comunicação se utiliza de vários canais, cada um deles apresentando vantagens
e desvantagens em seu uso. Entre os canais utilizados podem ser citados os orais, os
escritos, os eletrônicos e os digitais.
A comunicação oral acontece numa entrevista face a face, com uma reunião em
torno de uma mesa, em um telefonema ou durante uma apresentação, conferência ou aula.
Nela a interação entre as partes é grande, o feedback é imediato e há ótimas possibilidades
de expor, debater e convencer. Mas, geralmente, não existe registro do que foi dito, as
emoções podem aflorar e frases podem ser ditas sem que haja reflexão e avaliação prévias.
A comunicação escrita é a que aparece em qualquer texto impresso, como
documentos, livros, manuais, cartazes e folhetos. Foi escrita e revisada antes de publicada,
pode ser armazenada para consulta posterior e seu conteúdo não varia: é o mesmo para
todos os receptores. Mas não há controle total de quem a recebeu, como leu e interpretou,
e não permite feedback imediato ou consulta em caso de dúvida de interpretação.
A comunicação por meios eletrônicos e digitais permite a transmissão de um grande
volume de informações de maneira veloz e precisa. A internet, o correio eletrônico e a
telefonia celular são exemplos dessa forma de comunicação, que se vale da tecnologia
dos computadores e das telecomunicações para se concretizar. Permite desde o simples
envio de uma mensagem de texto a transmissão de grandes arquivos de dados ou uma

videoconferência, com imagens dos emissores e receptores interagindo, conversando e
debatendo ao vivo. No entanto, necessita da existência e correto funcionamento de uma
infraestrutura tecnológica e de apoio que lhe dê suporte. Diversos desafios, entretanto,
precisam ser enfrentados pelo gerente, seja no seu papel e responsabilidades de emissor,
seja no de receptor no processo, e podem dificultar a eficácia e os resultados esperados da
comunicação.
1.3. Uma Palavra sobre Empatia

A empatia é a capacidade de se colocar no lugar do outro, de entendê-lo, de tentar
compreender o que passa em sua mente, como e por que se sente de determinada maneira,
porém não a partir da nossa perspectiva, mas tentando pensar como ele, com as suas
crenças e valores. A empatia parte da aceitação, de compreender que os sentimentos de
uma pessoa são possíveis na situação em que ela se encontra, mesmo que se fôssemos
nós na mesma situação tivéssemos outro tipo de atitude.
Dito em palavras mais simples e como um exemplo, para nós pode não ser muito
importante o fato de não termos irmãos, mas para outra pessoa pode ser. Nesta situação, a
pessoa empática colocaria de lado a sua “escala de importância” para entender o sofrimento
do outro a partir da “escala de importância” dele.
Podemos ser muito empáticos, mas se não demonstrarmos e se não colocarmos
em prática, isso não serve para nada. Dito isto, vamos enumerar algumas ocasiões em que
podemos utilizar a empatia:
• Quando sabemos ouvir e compreender os sentimentos do outro sem estar tão
dependentes de nós mesmos e das nossas próprias palavras.
• Quando não usamos apenas palavras para consolar. Um abraço, um tapinha no
ombro, um beijo e uma carícia nos fazem ser mais empáticos.
• Quando estamos com alguém que tem um problema e o ajudamos, por exemplo,
com o nosso senso de humor.
• Quando nos expressamos com delicadeza e cortesia.
• Quando não mostramos atitudes de aborrecimento, irritação e cansaço diante
daquilo que os outros nos contam.
• Quando não fazemos um comentário, uma piada ou uma brincadeira que
sabemos que vai chatear o outro.
• Quando fazemos, por exemplo, um idoso ou uma criança compreenderem que
os entendemos.
• Quando ajudamos a resolver problemas e somos capazes de acalmar os outros.

2. PLANEJAR AS COMUNICAÇÕES
Projetos bem-sucedidos são obtidos por meio de uma combinação de decisão,

ações e estratégias eficazes. Eles raramente são executados por um indivíduo trabalhando
num vácuo, mas por equipes de indivíduos com vários papéis e responsabilidades, que se
relacionam com vários grupos ou pessoas interessadas nos resultados do projeto (stakehol-
ders), pertencentes a diversas áreas da própria empresa ou a diferentes organizações.
Manter esses indivíduos ou grupos totalmente informados e alinhados com o projeto
é um desafio que somente pode ser superado com o uso de um conjunto de estratégias de
comunicação definidas e estruturadas em um plano de comunicações do projeto.
O desenvolvimento de um plano de comunicação eficaz deve ter como objetivo
atingir os seguintes propósitos:
• assegurar que as informações importantes cheguem às partes corretas nos
prazos adequados;
• apontar e identificar problemas potenciais, por meio de reportes de andamento
programados e consistentes;
• gerar entusiasmo e empolgação para com o projeto;
• facilitar a tomada de decisão e o controle de mudanças;
• oferecer um processo específico para feedback e resolução de conflitos;
• melhorar e facilitar o trabalho em equipe, a cooperação e colaboração.

Ainda que os detalhes de um plano de comunicação possam variar de acordo com
a complexidade, tamanho e duração do projeto, qualquer plano deve observar os seguintes
aspectos básicos:
• o propósito: os objetivos da comunicação do projeto, seja ela formal ou informal;
• o métodos: os mecanismos e formatos da comunicação no projeto;
• a frequência: o momento (data e evento) e a frequência das atividades formais
de comunicação.
A comunicação no projeto não deve ser apenas resultado natural das ações
durante a sua realização; ao contrário, deve ser planejada. Considerando que a base do
gerenciamento de projetos é a formalização de processos, com o objetivo de melhorar
o desempenho, a informação e a comunicação, não podemos relegar esta gestão tão
importante ao improviso e à intuição.
A definição da estratégia e do plano de comunicação dela decorrente depende do
entendimento da natureza do projeto e dos seus requisitos de comunicação. O enfoque
do plano de comunicação deve variar em função das necessidades, complexidade e porte
do projeto. As atividades formais de comunicação terão importância maior em grandes
projetos no plano corporativo do que em projetos internos departamentais, que têm foco
mais limitado e um número muito menor de participantes.
Conforme o Guia PMBOK® (2017), “o Planejamento das Comunicações e o
processo de determinar as necessidades de informação das partes interessadas no projeto
e definir uma abordagem de comunicação”.
Entretanto o gerente de projetos não deve impor aos interessados as informações
que estes devem receber; ao contrário, deve planejar a comunicação levando em conta o
que os interessados desejam receber. Ao planejar as comunicações, deve identificar as
necessidades de informações e discutir o plano de comunicação com os interessados, de
forma que este seja o mais aderente possível as suas necessidades no que se refere ao
nível de detalhamento de informações, mídia, periodicidade etc.
Como esse processo está situado no planejamento do projeto, sua consecução
deve estar sincronizada com a preparação do plano de gerenciamento e, sendo parte
integrante dele, não pode ser negligenciada e deixada para ser desenvolvida durante a
execução do projeto.

2.1. Componentes do Plano de Comunicação
Esse plano constituirá uma seção do plano de gerenciamento do projeto, definindo
todo o gerenciamento da comunicação por meio de um documento de fácil entendimento
que inclua:
• Procedimentos para coleta de informações do projeto;
• Descrição do livro de controle do projeto, que mais do que um único livro,
representa, na prática, uma biblioteca, que será o ponto central de coleta e
compartilhamento das informações, definindo como estas serão atualizadas;
• Uma lista de distribuição de informações estabelecendo se foram fornecidas,
por quem, para qual parte interessada, em que formato e com que frequência;
• Uma descrição do formato e conteúdo de cada informação que é distribuída
regularmente, usando-se, sempre que possível, formulários padronizados e
templates (modelos);
• Um cronograma apresentando a periodicidade de cada informação distribuída
regularmente e a pessoa responsável pela sua geração;
• Um cronograma de reuniões definidas de forma sincronizada — reuniões com
fornecedores antes das reuniões internas, reuniões de nível gerencial ou tático
antes das reuniões executivas ou estratégicas, enfatizando-se as reuniões
obrigatórias por contrato.
O gerente de projeto está no centro de toda a comunicação. Obter a informação

certa na hora certa é fundamental para o seu sucesso. Com informação atualizada na ponta
dos dedos, no formato correto pode-se preparar relatórios quase que automaticamente.
Boa documentação, por outro lado, significa menos discussões e conflitos. Assim, o fato de
ter-se preparado o plano de comunicação compreensível no momento do kick-off (reunião
de abertura do projeto) pode trazer muita economia de tempo, energia e preocupação.
A estrutura básica de um plano de comunicação é composta de linhas que
contenham, no mínimo, os seguintes componentes:
• Partes interessadas-alvo;
• Mensagens customizadas;
• Método adequado de comunicar cada mensagem:
• Pessoa responsável pela comunicação;
• Esquema de tempo da comunicação.

2.2. Requisitos de Comunicação
Na primeira fase deve-se levar em consideração que cada projeto tem sua própria
“personalidade”, formada pela combinação de diversos fatores-chave, os quais, por sua
vez, definem as necessidades que devem ser consideradas num plano de comunicação
eficaz. Os fatores-chave são:
• Tipo de projeto: desenvolvimento de produto, implementação de sistemas,
modificação de processos, reorganização administrativa;
• Duração da estimada: dias, meses, anos;
• Porte do projeto: subprojetos, fases, número de atividades, recursos envolvidos,
abrangência (corporativa/departamental);
• Organização do projeto: níveis executivos participantes, departamentos
envolvidos, estrutura da equipe de projeto, usuários, clientes, fornecedores.
O gerenciamento de projetos requer um considerável grau de integração e um
controle das interfaces com muitos grupos e pessoas. Os gerentes de projeto usam diferentes
chapéus e assumem diversos papéis, precisando interagir com um grande número de partes
interessadas (stakeholders) que podem representar um papel significativo no alcance dos
objetivos do projeto. De acordo com o Guia PMBOK® (2017), partes interessadas são
“pessoas ou organizações ativamente envolvidas no projeto ou cujos interesses podem
ser positiva ou negativamente afetados pela execução ou término do projeto”. Partindo-se
desse princípio, as interfaces com elas precisam ser eficazes para ganhar a sua confiança
e garantir a sua cooperação.
Assim pode-se criar um verdadeiro espírito de equipe, em que cada um ajuda a
otimizar a contribuição dos outros para o sucesso do projeto.
A menos que identifiquemos as partes interessadas principais (indivíduos ou
grupos) e seja estabelecido seu interesse específico no projeto, é muito difícil preparar uma
boa estratégia e um bom plano de comunicação.
O processo de comunicação é o principal recurso que o gerente de projeto utiliza
para gerenciar o seu relacionamento com as partes interessadas. Para garantir a eficácia
do processo, deve-se estabelecer, de forma específica, os requisitos de informação que
atenderão as expectativas das partes interessadas, alinhados com suas características.
A avaliação dos requisitos citados envolve as seguintes questões:

Tabela 1 – Fatores de Sucesso da Comunicação
A quem se destina a sua Quem é o seu público-alvo

informação?
Qual é o seu objetivo? O objetivo a ser alcançado
Qual é a informação que O que quer que as pessoas saibam,
quer passar? sintam ou realizem
Como a comunicação está A forma como ela é
elaborada? apresentada
Fonte: o autor.
Cada projeto exigirá um nível de detalhamento maior ou menor, dependendo das

características. O gerente de projetos pode utilizar esses questionamentos para identificar
essa necessidade.

3. ACOMPANHAMENTO E AVALIAÇÃO DO PROGRESSO
A medida que ocorre a fase de execução do projeto, está sendo realizada a

implementação do gerenciamento das comunicações, por meio das ações previstas no
plano de comunicação.
Conforme definido no Guia PMBOK® (2017), nessa fase de execução da
comunicação ocorre, na prática, a distribuição da informação que envolve “colocar as
informações necessárias a disposição das partes interessadas no projeto conforme
planejado”. Isso significa também fazê-lo no momento oportuno e, claro, responder às
solicitações de informações não previstas no planejamento.
As informações dos projetos devem estar disponíveis no momento certo, no formato
correto e consistente. Com o uso de metodologia apropriada e a criação de um bom plano,
os gerentes podem dar um grande salto rumo à eficiência na comunicação.
O compromisso dos envolvidos em adequar-se ao modelo, utilizar efetivamente as
ferramentas e manter as informações atualizadas é imprescindível ao sucesso de qualquer
plano de comunicação. Atualmente, existem soluções tecnológicas abundantes e baratas
que auxiliam na comunicação.
O processo de distribuição para os participantes pode utilizar-se de aplicativos de
uso geral, tais como MS-Office ou OpenOffice, ou de aplicativos especializados para suporte
ao gerenciamento de projetos, tanto com o emprego de papel quanto de mídia eletrônica.

Caso os aplicativos em uso ou que possam ser adquiridos pela organização não
implementem todas as funcionalidades desejadas, podem-se desenvolver, nas empresas,
aplicações internas que permitam a criação e uso de bancos de dados.
Ninguém consegue imaginar a execução do seu trabalho nem a disseminação das
informações necessárias, hoje em dia, sem o uso da tecnologia. Sem dúvida, ela influencia
a maioria das nossas atividades relacionadas ao plano de comunicação do projeto.
Por causa disso, um mito difícil de derrubar é o de que a equipe que tem as melhores
ferramentas eletrônicas do mercado, para documentar o projeto além de ter também a
melhor comunicação.
Tal raciocínio é baseado na ideia de que a tecnologia sozinha é suficiente para
realizar a melhor opção de coleta, armazenagem e distribuição das informações do projeto.
Entretanto, apesar de ter uma enorme importância, a tecnologia não é capaz de sintonizar a
comunicação do projeto aos seus objetivos e, assim, fazer com que suas atividades sejam
desenvolvidas por meio das melhores técnicas e com a máxima cooperação entre as partes
interessadas. É necessário muito mais que só a tecnologia.
É muito comum observar empresas a procura do melhor software para dar conta
do gerenciamento da documentação de um projeto, sem ao menos entender qual o melhor
processo de comunicação para ele. Muitas vezes tal processo nem está definido e a expec-
tativa é a de que o próprio software desempenhe esse papel.
Em primeiro lugar, para se implantar uma solução eletrônica eficaz, que realmente
contribua para a comunicação entre as diversas pessoas envolvidas com o projeto, é
preciso entender como se quer implementar os seus processos. Para isso, pode-se partir
da identificação do tipo de processo que será utilizado na comunicação do projeto. Por
exemplo:
• Sob demanda (ad hoc): pouco padronizado, em que cada membro da equipe
tem liberdade para definir o formato da documentação;
• Centralizado: documentação padronizada e níveis de visibilidade bem definidos;
• Colaborativo: processo voltado para o trabalho em equipe, no qual a
interdependência das atividades são características cruciais do projeto.
Entendido o primeiro aspecto, é possível passar ao segundo passo. Quais os

tipos de objeto serão armazenados e disseminados? Por exemplo: a comunicação será
apenas por meio de formulários eletrônicos ou usará imagens, arquivos de algum software
específico, planilhas, voz e apresentações?

A escolha do software que será utilizado sofre grande influência do tipo de objeto. É
importante ficar alerta quanto a isso, pois um software de grande funcionalidade pode não
ser o mais adequado ao seu projeto por não incluir exatamente aquilo de que você precisa.
3.1. Reuniões em Projetos

Dentro de um plano de comunicação existem vários tipos de comunicação que
podem e devem ser estabelecidas para cada tipo de informação e/ou efeito que se deseja
transmitir para os stakeholders. Porém a mais direta é a conversa face a face. Nessa linha
vamos dedicar uma parte de nosso estudo sobre comunicação para dar a você uma visão
melhor sobre as famigeradas reuniões.
Uma reunião é um encontro entre pessoas, organizado e dirigido segundo regras de
participação conhecidas por todos, e que visa, por meio de troca de ideias e opiniões, coletar
subsídios, apresentar ideias, definir novos métodos ou propor soluções para problemas,
para que se formulem alternativas e se tomem decisões a respeito desses problemas.
Com que objetivos são feitas reuniões em projetos?
• Integração das pessoas para formar uma equipe de trabalho;
• Estabelecimento e classificação do que é causa e do que é efeito, ajudando,
assim, a definição mais precisa dos problemas e identificação de caminhos que
levam a sua solução;
• Partida, acompanhamento e finalização de projetos, com a análise de todas as
contribuições dadas e avaliação dos resultados.
Numa reunião, os participantes são submetidos a estímulos coletivos, sendo
chamados a toda hora para participar, opinar debater e agir. Emitem conceitos e opiniões e
ouvem ideias dos outros, participam de um ambiente de troca de experiências extremamente
fértil e propício ao bom andamento do projeto. Uma reunião é composta por três fases:
• fase I: planejamento;
• fase II: realização;
• fase III: acompanhamento.
Na fase I questiona-se a realização da reunião e, sendo realmente necessária, ela
é preparada e planejada para que atinja os resultados pretendidos. Para a fase I funcionar
é preciso:
• estabelecer objetivos;
• selecionar os tópicos a serem discutidos;
• escolher os participantes;

• planejar e divulgar a agenda de convocação;
• preparar-se para a reunião.
Na fase Il acontece a reunião propriamente dita, que obedece a preparação feita
na fase I e deve ser conduzida com objetividade e firmeza, para que sejam alcançados os
resultados pretendidos. Aqui é importante definir:
• quem conduz a reunião;
• quais os outros papéis na reunião;
• processo de realização;
• critérios de participação e tomada de decisão;
• confecção da ata e atribuição das responsabilidades;
• responsabilidades para a fase III.
Na fase III é verificado o andamento das decisões tomadas e são feitas as correções
julgadas necessárias. Devem acontecer nessa fase:
• acompanhamento das decisões tomadas na fase II;
• comunicação e correção de desvios relatados ou verificados;
• avaliação da necessidade de nova reunião.
Uma reunião pode ser uma boa ideia quando:
• há necessidade de uma resposta rápida de várias pessoas sobre um determinado
assunto;
• existem problemas ou questões a serem esclarecidas, compartilhadas, expostas
ou resolvidas com os demais participantes;
• deseja-se envolver o grupo na tomada de decisão, reconciliação de situações
de conflito ou na busca de consenso;
• deseja-se trocar informações e experiências com o grupo,;
• pretende-se analisar, avaliar e resolver problemas que envolvam pessoas de
áreas ou empresas distintas;
• existem exigências legais a serem implantadas.
Por outro lado, não é conveniente realizar uma reunião quando:
• outra forma de comunicação se mostrar mais rápida ou adequada, como
telefone, e-mail ou um papo no corredor;
• o grupo não houver se preparado adequadamente para a reunião, seja por falta
de tempo, atraso na comunicação, escassez de dados ou fatos semelhantes;
• não puderem estar presentes as pessoas que realmente tomarão decisões
sobre os assuntos a discutir;

• existirem posições irreconciliáveis já conhecidas de antemão, o que pode gerar
agressividade, hostilidade e ausência de resultados concretos;
• as decisões já tiverem sido tomadas e o grupo não souber disso ou, simplesmente,
quando o assunto for ato trivial que não mereça que se gaste tempo com ele.
É bom lembrar que nem sempre as reuniões ocorrem dentro dos padrões
recomendáveis, mas podem ser consideradas eficazes se gerarem resultados. É possível
também que, em situações de crise, de pressão externa forte ou de mudança de regras ou
especificações o número de reuniões aumente consideravelmente. Cuidado nessas horas,
para não se perder num emaranhado de reuniões.
Em projetos ocorrem reuniões em momentos determinados, associadas ao seu
ciclo de vida. Entre as mais importantes pode-se citar:
• reunião de partida (kick-off meeting);
• reunião de acompanhamento (follow-up meeting);
• reuniões para registro e acompanhamento de problemas;
• reuniões para registro de lições aprendidas;
• reuniões para registro e acompanhamento de mudanças;
• reuniões para registro e acompanhamento de ações corretivas e preventivas;
• reunião de encerramento ou de entrega do projeto (close out meeting).
As reuniões de partida e entrega ocorrem uma única vez no início e término do

projeto. Elas formalizam o início e o fim do envolvimento do gerente e sua equipe naquele
projeto e tratam, respectivamente, de como o projeto será realizado e dos resultados obtidos.
Podem ocorrer solenidades, como lançamentos, festas e inaugurações, mas são
reuniões diferentes daquelas mais específicas e ligadas ao gerenciamento de projetos.

4. ENGENHARIA DE REQUISITOS E CONTROLE DE MUDANÇAS
O gerenciamento das comunicações também está relacionado com o processo de

controle e monitoramento do projeto por meio das ações vinculadas ao reporte do seu
desempenho. Segundo o Guia PMBOK® (2017), “os Relatórios de Desempenho são usados
para distribuir informações sobre o andamento e o desempenho do projeto, deve estar
disponíveis antes das reuniões do projeto e devem ter o máximo de precisão e atualização
possível”.
O fato é que só a partir de uma visão clara do comportamento das variáveis críticas
do projeto existem condições de propor mudanças e corrigir os rumos para que os objetivos
possam ser alcançados. Assim, com essa finalidade são apresentadas três exemplos de
relatórios. O primeiro é o relatório de análise de valor agregado, muito utilizado hoje em dia
em projetos de engenharia, que relaciona custo, prazo e trabalho efetivamente realizado
pelo projeto. O segundo é o relatório de desempenho de atendimento a produtos do projeto,
confere uma estimativa da qualidade do projeto de ponto de vista do cliente. Por último, o
relatório de scorecard do projeto faz um balanceamento das quantidades relevantes que
precisam ser alcançadas para que o projeto obtenha sucesso.
A maneira mais eficiente de organizar as informações relevantes para o
gerenciamento do projeto é fazê-lo por meio de relatórios de controle do desempenho.
Esses relatórios têm o propósito de mapear no tempo as variáveis importantes e fornecer

previsões quantitativas e concretas sobre sua evolução. O segredo de um bom relatório é
que ele seja elaborado com finalidades específicas, visando a sua imediata utilização.
É importante frisar que a qualidade dos dados é diretamente dependente de quanto
essas finalidades são explícitas e entendidas pela equipe. Antes de iniciar o processo de
criação de um relatório, é importante listar algumas perguntas, cujas respostas irão servir
como um guia para a sua elaboração. Por exemplo:
• qual seu objetivo ao criar o relatório;
• que informação é requerida prioritariamente para alcançarmos o objetivo citados;
• quais os tipos de informações necessárias;
• com que frequência os dados precisam ser coletados e o relatório criado;
• qual método será usado na sua preparação;
• qual método será usado na sua distribuição;
• qual a necessidade de consolidação dos dados:
• que feedback formal será realizado após a avaliação do relatório;
• como esses relatórios serão integrados com outros elementos de comunicação.
Ainda com relação às informações que irão compor os relatórios de desempenho,
dois assuntos são importantes. O primeiro deles é que em alguns projetos é crucial fornecer
também informações de risco nos relatórios de progresso. Só assim pode-se quantificar
o impacto dos problemas enfrentados no decorrer da execução do projeto e, com isso,
estabelecer as condições para que os estes possam ser monitorados. Por último, alguns
relatórios podem ser baseados em exceções. Esses acontecimentos eventuais podem ser
críticos e afetar uma área vital de projeto.
SAIBA MAIS
Leia o texto escrito por Dr. Bezerra, publicado no site BSBr em 17 de abril de 2018,
acessando o link: https://bsbr.com.br/gerenciamento-das-comunicacoes-projeto/.
Nesse texto Bezerra faz uma discussão sobre a importância da comunicação, começando
com uma célebre frase do Chacrinha “Quem não se comunica, se trumbica”. É um texto
leve e interessante que traz ensinamentos sobre sua carreira e os erros aprendidos
dentro dessa área de conhecimento do gerenciamento de projetos.

SAIBA MAIS
POR DENTRO DOS FATOS – Leia o texto apresentado no link a seguir com o título
Gestão de riscos: O que é e qual a finalidade do gerenciamento de riscos? e saiba mais
sobre Gerenciamento de Riscos. Boa leitura!
Disponível em: https://www.venki.com.br/blog/o-que-e-gerenciamento-de-riscos/
REFLITA
Poder do stakeholder — origem e consequências que o poder da parte interessada

pode ter sobre o projeto:
poder decorrente de posição hierárquica, de carisma ou liderança pessoal;
forças, fraquezas e alianças com outros stakeholders poderosos;
impactos positivos ou negativos do uso desse poder nos objetivos do projeto;
Influência do stakeholder — como ela é exercida pela parte interessada:
em tomadas de decisão;
na administração de processos - controlando, por exemplo, “gargalos” nas processos;
atuando como formador de opinião.

Até aqui tivemos a oportunidade de conhecer um pouco do que é a área de

conhecimento Comunicação e seus fundamentos e a relevância de sua gerência para o
projeto. Além disso, utilizamos cases para comprovar os fatores positivos que uma gestão
focada em comunicação pode trazer para o projeto.
Falamos também sobre o planejamento das comunicações e dentre outros tópicos
os requisitos da comunicação que irão nos ajudar a montar o plano de comunicações do
projeto.
Na próxima unidade aprenderemos como a área de conhecimento Riscos funciona
e como ela fornece subsídios para a gestão do custo. Além disso, vamos discutir, dentro do
espectro da incerteza, qual é a faixa de trabalho de um gerente de riscos.

LIVRO
Título: Gerenciamento de Projetos e Empreendedorismo
Autor: Paulo Yazigi Sabbag
Editora: Saraiva
Sinopse: Esta nova edição traz capítulos que conceituam e
contextualizam os projetos nas organizações, além de explorar as
competências requeridas para o sucesso. O livro também explora
as competências de empreendedores e gerenciadores de projetos
e discute as melhores práticas de gestão, tendo como referência
as normas do Project Management Institute (PMI). Compatível
com as normas do guia PMBOK 5ª edição.
FILME/VÍDEO
Título: Comunicação e Stakeholders em Projetos - Gestão de
Projetos
Ano: 2019
Sinopse: Entendendo os obstáculos à comunicação - Ruídos
externos. Gestão de Projetos.
Link: https://www.youtube.com/watch?v=r99OYrx1D6Y

UNIDADE IV
Metodologias de Gerência
de Projetos de TI
Plano de Estudo:
• O que são os stakeholders.
• Visão geral e processos de gestão dos stakeholders.
• Gerenciamento e controle do engajamento dos stakeholders.
• Conhecer o que são os stakeholders.
• Discutir ferramentas e técnicas de gestão de stakeholders.
• Estudar os processos da área de conhecimento dos stakeholders.
• Monitoramento do engajamento, ética dos stakeholders.
• Conhecer e Discutir o papel do stakeholders utilizando o Project Management Body Of
Knowledgement (Pmbok) e suas metodologias:
• Pmi;
• Pmp;
• Pmbok;
• Áreas De Conhecimento.
94
INTRODUÇÃO
A palavra inglesa stakeholder é formada pela junção da palavra stake com a palavra
holder. Segundo o dicionário Michaelis (2016), a palavra stake tem vários significados em
português, como “estaca”, “poste” ou “mourão”. Mas essa palavra também significa “aposta”,
“dinheiro apostado”, “prêmio”, “risco”, “interesse” ou “parte”. Já a palavra holder, segundo
esse dicionário, é o mesmo que “proprietário”; “dano” ou “arrendatário”. A junção dessas
duas palavras resulta em algo similar a “alguém que possui interesse” em algo.
A expressão “parte interessada” é uma das possíveis traduções para a palavra
stakeholder em português. Essa é a expressão que consta no guia PMBOK (2017) em sua
versão na língua portuguesa. No Brasil, é comum também o uso de outras palavras para a
tradução de stakeholders: “intervenientes”, “afetados” ou “impactados”.
No guia PMBOK, a palavra stakeholder se refere a todas as pessoas ou organizações
envolvidas diretamente ou indiretamente no projeto e impactadas positivamente ou
negativamente por ele.
Vamos juntos neste universo e ter a visão geral dos processos de gestão dos
stakeholders?
UNIDADE IV Metodologias de Gerência de Projetos de TI 95

1. VISÃO GERAL DOS PROCESSOS DE GESTÃO DAS PARTES INTERESSADAS
É o momento de identificar pessoas e organizações ativamente envolvidas no

projeto e analisar seus interesses e seu efetivo envolvimento. Elas podem ser afetadas
positiva ou negativamente pela execução do projeto. Stakeholders estão em diversos níveis
da organização ou podem ser externos ao projeto ou à própria organização. As informações
coletadas, devidamente documentadas e organizadas, servirão de base para o processo
de planejamento das comunicações e de guia durante os processos de distribuição das
informações e de controle das comunicações.
Do ponto de vista prático, uma identificação dos stakeholders que tenham
implicações positivas para o projeto consiste na criação de um registro de partes
interessadas (stakeholders) que tenham informações relevantes e necessárias para o
projeto. Essas informações podem variar de projeto para projeto, porém alguns exemplos de
informações podem ser considerados: nome, código, objetivo, interesse, influência, poder
responsabilidade e disponibilidade para o projeto, conforme pode ser visto no Quadro 01.

Quadro 1 - Exemplo de registro de partes interessadas
Nome Objetivo/ Interesse Influência Poder Responsabilidade Disponibilidade
Gerente de Conclusão do Alta Alto Coordenação Total

Projetos projeto dentro do projeto
do prazo e custo.
Equipe de D e s e n v o l v e r Alta Baixo Execução Total
Projetos as atividades do
projeto
Governo Garantir Impos- Baixa Alto Avaliação Mínima
tos e cumpri-
mento das leis
Patrocina- Retorno do In- Média Alto Financiamento Reduzida
dor vestimeto do projeto
Fonte: o autor.
1.1. Avaliação da Importância e Influência dos Stakeholders

As pessoas ou organizações que podem afetar ou ser afetadas pelo projeto
devem ser identificadas com suas respectivas responsabilidades, em particular aquelas
com envolvimento direto na alocação de recursos (patrocinador e gerentes funcionais),
no recebimento das principais entregas (cliente) e na própria condução dos trabalhos
(equipe de projeto). Informações relevantes relacionadas a seus interesses, envolvimentos
e impactos no sucesso do projeto devem ser documentadas.
A equipe do projeto deve detalhar e validar progressivamente a lista de stakeholders
ao longo da vida do projeto, especialmente em seu processo de planejamento. É necessário
segmentar e decompor vários desses grupos para uma interação mais eficiente com seus
participantes. O objetivo é identificar os stakeholders, avaliar sua influência e seus interesses
no projeto, documentar suas necessidades, desejos e expectativas e orientar as ações e
respostas visando à ampliação de sua cooperação para o sucesso do projeto.
Além disso, a equipe terá de lidar com acréscimos e reduções da lista inicial, pro-
vocados por saídas de membros da equipe e substituição de fornecedores, entre outros.
Os esforços no âmbito de gerenciamento da comunicação e dos recursos humanos de
projeto estão intensamente conectados a essa análise, com destaque para a definição dos
papéis e responsabilidades, com as respectivas habilidades demandadas e a definição da
sistemática de comunicação do projeto.
Dessa forma, avalia-se, para cada stakeholder identificado, o impacto que ele pode
exercer e sua capacidade de influenciar os objetivos do projeto. É claro que os impactos

variam de stakeholder para stakeholder. Alguns podem controlar recursos críticos necessá-
rios ao projeto, enquanto outros podem ter poder de facilitar, transformar ou bloquear uma
implantação.
Geralmente, os que patrocinam um projeto ou fornecem os principais recursos
são os stakeholders mais importantes. Entretanto outros stakeholders, que apoiam ou
cooperam, ainda que indiretamente, podem ser relevantes em certos estágios. Esses dois
aspectos podem ser avaliados considerando:
a. poder do stakeholder: origem e consequências que o poder da parte
interessada pode ter sobre o projeto:
• poder decorrente de posição hierárquica ou de carisma ou liderança pessoal;
• forças, fraquezas e alianças com outros stakeholders poderosos;
• impactos positivos ou negativos do uso desse poder nos objetivos do projeto;
b. influência do stakeholder: como ela é exercida pela parte interessada:

• em tomadas de decisão;
• na administração de processos – controlando, por exemplo, “gargalos” nas
processos;
• atuando como formador de opinião.
É fundamental uma etapa de análise específica dos aspectos comportamentais

associados a cada stakeholder; certo que esses pontos podem afetar seu relacionamento
com o projeto. Identificando o comportamento atual e seus efeitos potenciais positivos ou
negativos para o projeto, pode-se planejar uma comunicação com cada stakeholder que
permita atingir uma condição mais favorável.
O grau de interesse, ainda que pessoal ou político, pode se sobrepor aos interesses
do projeto e seus efeitos podem afetar o grau de apoio e colaboração obtida. A dependência
do projeto com relação ao stakeholder pode estar relacionada ao grau de poder deste sobre
os recursos. Tal dependência varia de baixa a alta, com o interesse do indivíduo ou grupo
situando-se num espectro de interesse mútuo (totalmente a favor) até interesse conflitante
(totalmente contra), o que confere a esses stakeholders uma posição de aliados ou membros
da rede (no primeiro caso) ou de bloqueadores ou desaceleradores (no segundo caso).
Esses espectros podem ser visualizados e melhor gerenciados através de um gráfico em
formato de plano cartesiano, mostrado na Figura 1.

Figura 1 - Gráfico de mapeamento dos Stakeholders
Fonte: o autor.
Como resultado prático da identificação dos stakeholders, é obtido um registro

contendo todos os detalhes relativos a sua identificação, avaliação e classificação, como foi
visto no Quadro 1. Detalhes comuns se referem a nomes, cargos, posição no organograma,
expectativas em relação ao projeto, capacidade de influência e outros.

2. FERRAMENTAS E TÉCNICAS
Com base na estratégia para engajamento de cada stakeholder, um plano de ge-

renciamento de stakeholders deve ser desenvolvido. Esse plano deve conter:
● Reciprocidade:
▪▪ como o stakeholder é importante para a atividade;
▪▪ expectativas e apostas feitas pelas stakeholders.
● Categorização de stakeholder - posicionamento do stakeholder quando compa-

rado ao gerente do projeto:
▪▪ acima do gerente do projeto (gerência sênior, diretoria);
▪▪ par do gerente do projeto (outros gerentes de projetos);
▪▪ abaixo do gerente do projeto (equipe);
▪▪ externo ao projeto (fornecedores, acionistas, mídia etc).
● Perfil de engajamento, demonstrado e ilustrado na Figura 2:

▪▪ nível de apoio à atividade;
▪▪ nível de receptividade à informação sobre a atividade;
▪▪ engajamento-alvo: os níveis-alvo de apoio e receptividade.
Figura 2 - Tipos de perfil de Stakeholders
Fonte: o autor.

Uma outra ferramenta que pode ser utilizada é a Matriz de Avaliação do Nível
de Engajamento (MANÉ), conforme exemplo na Figura 3. Esta matriz pode ser utilizada
a partir do levantamento do perfil dos stakeholder e, assim, traçar metas para levar um
determinado stakeholder até o nível de engajamento desejado ou esperado. Essa Matriz
pode ser utilizada durante a etapa de monitoramento e controle para avaliar a evolução dos
nossos stakeholder.
Figura 3 - Matriz de Avaliação de Nível de Engajamento
Fonte: o autor.
Depois de montado o MANÉ, é possível traçar planos de ação para cada stakeholder
e mudar esses planos de ação à medida que o projeto se desenvolve.
Figura 4 – Exemplos de Ações com base nas estratégias para cada stakeholder
Ações
1. Convidá-los para participarem do processo de gerenciamento dos
riscos.
2. Assegurar que os requisitos sejam claros. Enviar relatórios.
3. Envolvê-los nas reuniões da equipe, reportar a essas pessoas e incluir
informações solicitadas.
4. Convidá-los para ingressarem oficialmente na equipe de gerenciamento
de projetos.
5. Planejar reuniões periódicas durante o projeto para verificar se

identificaram mais riscos.
Fonte: o autor.

3. GERENCIAR E CONTROLAR O ENGAJAMENTO DE STAKEHOLDERS
Para obter sucesso no gerenciamento de projetos, é fundamental gerenciar os

stakeholders e suas expectativas. Inicialmente, é preciso conhecer e manter expectativas
claras e alinhadas, sejam elas as do projeto com relação à participação do stakeholder,
sejam elas as dos próprios stakeholders. Esse ponto é fundamental para que todos estejam
em condições de trabalhar e se comprometer com uma direção e propósito comuns, os
quais estejam mutuamente entendidos e acordados. Quando isso acontece, os stakehol-
ders também são capazes de avaliar e reportar quando o projeto está alcançando o que
é esperado dele. Os stakeholders devem ter, ainda, uma percepção clara de como estará
o negócio, a instituição e sua própria função quando o projeto for concluído. Essa visão
comum deve ser estabelecida pelo patrocinador com os stakeholders, o mais cedo possível
no ciclo do projeto, devendo ser monitorada pelo gerente como parte do gerenciamento da
comunicação.
É fundamental que saibamos se estamos lidando com uma expectativa ou um requi-
sito. Uma expectativa é uma perspectiva direcionada que um cliente, fornecedor, membro
do time do projeto ou qualquer outra pessoa pode ter.
O ideal é que pudéssemos conhecer e documentar expectativas como requisitos
formais. Isso, entretanto, apesar de não ser impossível, é bastante difícil, porque desco-
bri-las já é um desafio, devido a inúmeras razões, como preocupações políticas, falta de
tempo, falhas de organização, deficiência de foco estratégico e assim por diante. Todavia,

ainda que as expectativas sejam identificadas, a dificuldade passa a ser obter as definições
formais dos requisitos que atendem a esses desejos, para que possamos tomar as decisões
apropriadas.
Outra questão-chave é que as expectativas podem correr em várias direções e
estar em vários lugares, pois qualquer stakeholder pode ter uma expectativa.
O ideal seria que a equipe do projeto conseguisse documentar todas as expectativas
como requisitos potenciais e trabalhasse com os vários stakeholders para priorizá-los e
identificar como podem ser incluídas no produto final do projeto, criando-se, então, um
verdadeiro processo de gerenciamento das expectativas, que será visto mais adiante.
Apesar de complexo, isso pode e deve ser feito, ainda que não o consigamos em sua
totalidade.
Um dos problemas comuns é que, com a passagem do tempo e de outros eventos
que vão ocorrendo ao longo da execução do projeto, como conversas, esquecimentos,
novas ideias, as expectativas mudam de maneira imprevisível, estabelecendo barreiras ao
seu entendimento. Quando isso ocorre, as expectativas dos stakeholders se desviam dos
requisitos documentados pela equipe do projeto.
Sem um gerenciamento ativo de toda a equipe por meio de uma comunicação
efetiva que quebre essa barreira de entendimento, o grau dessas variações será crescente,
e o alinhamento do projeto com as expectativas ficará gravemente prejudicado.
Além de esforço, essa tarefa exigirá o uso de ferramentas e técnicas apropriadas
para sua realização, bem como capacidades adicionais relativas a:
• como definir a natureza das expectativas dos stakeholders;
• como entender o impacto das expectativas não conhecidas e escondidas e
como descobri-las;
• como ouvir os desejos e crenças dos stakeholders;
• o que fazer quando as expectativas não estão alinhadas com o plano do projeto;
• o que fazer quando as expectativas não são realistas.
Um bom gerente de projeto, entendendo suas responsabilidades com os

stakeholders, deve ir além e construir um bom relacionamento com eles, por meio de uma
rede que estabeleça um feedback informal mais sincero e pessoal do que o obtido nos
relatórios escritos ou no que é reportado nas reuniões. Isso vai proporcionar ao gerente
dados valiosos que o auxiliarão a conduzir o projeto de maneira mais efetiva e harmoniosa,

bem como será de especial ajuda para enfrentar as constantes tomadas de decisão dentro
da organização.
3.1. Controlar o engajamento dos stakeholders

O processo de controle do engajamento envolve o monitoramento da eficácia da
comunicação por meio dos seguintes passos:
• análise da comunidade de stakeholders para garantir conhecimento do nível de
adesão — os atores certos para a fase atual ou momento do projeto;
• análise do perfil de engajamento dos stakeholders.
O processo de identificação, priorização e engajamento dos stakeholders não pode

ser um evento único. O trabalho de gerenciamento do relacionamento com os stakeholders
não pode parar com o planejamento. A natureza e a adesão da comunidade de stakeholders
muda conforme haja redirecionamento dentro da organização ou até mesmo com a saída
dessa organização, podendo assumir diferentes níveis de importância para o projeto,
passando por alterações de poder, interesse ou influência.
A chave para o gerenciamento do relacionamento com os stakeholders é o
entendimento de que a comunidade de participantes é uma rede de pessoas. Não é possível
desenvolver relacionamentos que nunca mudarão, assim como não é possível tomar
decisões objetivas sobre as pessoas. Na melhor das hipóteses, a metodologia aplicada
deve visar reduzir a subjetividade inerente às pessoas que tomam decisões sobre como
desenvolver e manter relacionamentos sólidos com outras pessoas.
As relações interpessoais não são fixas. É necessário rever a adesão da comunidade
de stakeholders regular e continuamente. Revisões regulares devem ser programadas
quando o trabalho da atividade se move de um estágio de sua implantação para a seguinte,
isto é, do planejar para construir, ou do construir para implantar, com intervalos regulares
dentro de uma fase particular. Um intervalo típico para esse tipo de análise seria três meses.
A equipe do projeto precisa analisar continuamente sua comunidade de stakeholders
para ocorrências não planejadas que podem desencadear uma revisão quando a atividade
se move de um estágio de implantação para o próximo, ou quando novas pessoas se
juntam à equipe. Cada vez que a dinâmica da mudança da comunidade de interessados
muda, a adesão deve ser reavaliada.

SAIBA MAIS
1 CONSELHO DO GERENTE DE PROJETOS – O stakeholder esquecido

O início da minha trajetória em gerenciamento de projetos foi bem rápido. Por minha
formação em arquitetura, comecei a trabalhar em uma empresa de gerenciamento fa-
zendo projetos arquitetônicos de adaptações para troca de marca de uma grande rede
bancária. Menos de um ano depois esse projeto acabou e um novo, do mesmo cliente,
iniciou. Desta vez trataríamos de adequar um lote de mais de 100 agências às normas
de acessibilidade. Fui alçado a coordenador da equipe e logo assumi como gerente.
Nesse projeto, recebíamos um briefing do cliente, íamos a campo para conferência,
traçávamos um estudo de viabilidade técnica, financeira e legal, e alinhávamos todas
essas diretrizes em projetos arquitetônicos, que eram então quantificados e enviados
a empresas em pacotes de licitação. Após a contratação das construtoras, as obras
iniciavam e passávamos a acompanhá-las, informando o cliente e demais partes inte-
ressadas. O trabalho se findava com relatórios de encerramento e checklists diversos de
conformidades aos padrões e normas específicos.
Especialmente durante a execução, diversas vezes cometi o erro de descer à operação.
Era para mim um respiro dos enormes, e então desconhecidos, desafios da gestão do
projeto, do cliente e da equipe. A operação me era mais confortável.
Pois bem, uma semana acertamos a implantação de uma das maiores obras daquele
lote. Tratava-se de um grande desafio, pois iríamos fazer uma série de modificações
em uma agência grande, que não poderia deixar de funcionar em nenhum momento.
De segunda a quinta-feira ficamos tomando as últimas providências para poder fazer a
obra de sexta-feira às 18 horas até segunda-feira às 5 horas da manhã. Entregaríamos
o local pronto e limpo para a operação antes das 8 horas, quando os funcionários come-
çaram a retornar para o trabalho.
As providências citadas eram muitas. Uma agência bancária é um lugar complexo para
trabalhar: deve-se pedir autorização da rede para pegar as chaves, solicitar formalmente
que o gerente desabasteça os caixas e o autoatendimento, aloque o dinheiro em malo-
tes e que documente tudo nos mínimos detalhes. A equipe interna também precisa estar
ciente, pois seus pertences devem ser acomodados em caixas, separados, para não se
perderem ou quebrarem. E se alguma mesa mudar de lugar? Por exemplo, alguém que
ficava na janela agora vai para o lado da parede, onde o ar é mais forte. É um campo

fértil para testar resiliência, habilidades de gestão de pessoas e conflitos.
Além dos stakeholders mais diretos, também é preciso acionar uma empresa específica
para recolher os malotes, conferindo o montante. Muitos papéis são assinados para que
os valores retornem ao local antes da reabertura. E os alarmes? Sísmicos, de presen-
ça, na porta principal, na porta giratória, nos caixas... cada um deles operado por uma
empresa diferente, todas precisando chegar ao local antes de o gerente ir embora, para
que se confiram todos os desacionamentos. E ainda restam os fornecedores. Materiais
de construção, móveis, comunicação visual... uma loucura.
Precisamente às 19 horas da sexta-feira tudo isso tinha sido superado. Eu tinha passa-
do as últimas duas horas correndo (e pendurado ao telefone) para garantir que todos
os agendamentos fossem cumpridos. E foram, apesar de alguns sustos e mudanças
de última hora. Construtora a postos, material à disposição, cronograma alinhado, tudo
tranquilo. Despedi-me do engenheiro da construtora, deixei meus contatos à disposição,
desejei boa sorte e fui aproveitar a noite de sexta-feira.
No meio da madrugada. toca o telefone e acordo sobressaltado: era o engenheiro. Nada
de piadas com a rivalidade com arquitetos, mas telefonema àquela hora só poderia ser
problema. Sem controlar os pensamentos, mil teorias se formaram na minha cabeça:
“esqueci de solicitar o desligamento de algum alarme”, “houve um acidente”, “faltou
material”, “o gerente fez uma visita surpresa e não gostou de alguma coisa”... alguns
segundos depois, lembrei de falar:
Alô.
Boa noite, Fernando, desculpe a hora. Temos um problema.
Mas isso é óbvio, fala logo, pensei eu. Mas me contive. E retruquei, meio calmo:
Boa noite. Pode falar.
Pois então, a obra parou.
Mais uma obviedade. Respirei fundo e perguntei, já não mais calmo:
O que houve, homem??
Está todo mundo rendido com as mãos na parede. Sorte que eu saí para fumar um pou-
co antes da brigada chegar, então me escondi atrás da árvore e te liguei.
É, teria sido uma boa ideia ter lembrado que estávamos fazendo uma obra no meio da
madrugada, em uma agência bancária, e que havia um prédio residencial bem em cima
dela. Eu certamente teria entrado em contato com o síndico e ele não teria chamado

a polícia para denunciar uma quadrilha de assalto a bancos. E eu não teria passado a
madrugada pendurado no telefone.
Fernando Bartelle
Fonte: Vignochi et al.(2017, p. 78).
2 Faça uma pesquisa sobre cases de projetos que não fizeram a gestão correta dos
stakeholders e, por isso, alguma situação não esperada ocorreu.
REFLITA
1 Assista ao vídeo produzido por Luciano Salamacha e José Finocchio Junior, que
apresenta, de forma divertida, uma situação do dia a dia quando falamos de stakeholders,
acessando o link: https://www.youtube.com/watch?v=p5UyOfINdqQ&t=9s
Após assistir o vídeo, reflita como é ser um stakeholder na situação do dia a dia de uma
Empresa.
2 Faça uma pesquisa na internet e reflita sobre métodos para a gestão das partes
interessadas. Existem técnicas e métodos novos surgindo e, por isso, é importante que
você tenha o maior número possível de conhecimento nessa área.
Fonte: o autor.

Nesta unidade foi apresentada a área de conhecimento do PMBOK chamada de

partes interessadas. Nessa área de gestão do projeto identificamos as partes interessadas
e estudamos sobre engajamento destas partes.
Vimos também como classificar os stakeholders e como gerenciar e controlar o
engajamento destes no projeto.

LIVRO
Título: Gestão de stakeholders
Autor: Thelma Rocha e Andrea Goldschimidt
Editora: Saraiva
Sinopse: Aqui está uma importante obra, que se tornará referência
e enriquecerá o aprofundamento das discussões sobre a profissão
e a atividade do administrador, por reunir o pensamento de quem
tem na bagagem conhecimento teórico e experiência prática da
comunicação empresarial aplicada hoje pelas empresas, que
estão, a cada dia, mais conscientes da importância de criar
e manter relacionamentos duradouros e positivos com seus
diferentes públicos. Temos dito, com frequência, que o modelo
de desenvolvimento para a sociedade deve prever a construção
conjunta. Os casos expostos nesta obra deixam isso evidente.
Engajamento de stakeholders, colocado de maneira simples,
é poder fazer, com a ajuda de muitos, o que não se consegue
fazer sozinho. A leitura deste livro ajudará a encontrar modelos de
relacionamento sólidos e produtivos, entre empresas e sociedade,
com vistas ao bem comum. Este é o caminho.
FILME/VÍDEO
Título: Partes Interessadas Stakeholders
Ano: 2016
Sinopse: Gestão das partes interessadas, vídeo realizado para
explicar os conceitos básicos estabelecidos por uma estrutura de
alto nível de normas ISO, referente aos Stakeholders.
Link: https://www.youtube.com/watch?v=9AtaIAZEu0c

REFERÊNCIAS
BARCAUI, A. B. Gerenciamento do tempo em projetos. Rio de Janeiro: Editora FGV, 2015.
GADDIS, P. O. THE PROJECT MANAGER. Harvard Business Review, 37(3), 89-97, 1959.
GANTT, H. L. Organizing for work. New York: Harcourt, Brace and Howe, 1919.
GIBBON, E. The history of the decline and fall of the Roman Empire. New York: Penguim Clas-
sics, 1996.
KEZSBOM, D.; EDWARD, K. The new dynamics Project management: winning through the
competitive advantage. 2. ed. Hoboken: John Wiley & Sons, 2001.
MENDES, Eunice; JUNQUEIRA, L. A. C. Comunicação sem medo. São Paulo: Editora Gente,
1999.
Michaelis. Dicionário Escolar - Língua Portuguesa. São Paulo: Melhoramentos, 2016.
PMI - PROJECT MANAGEMENT INSTITUTE. A Guide to the Project Management Body of

Knowledge (PMBOK Guide). 6. ed. Newtown Square: PMI, 2017.
TAYLOR, F. W. The principles of scientific management. New York: W. W. Norton & Company,
1911.
TERRA. Por que investir em gerenciamento de projetos em 2018? 2017. Disponível em:
https://www.terra.com.br/noticias/dino/por-que-investir-em-gerenciamento-de-projetos-em-
-2018,606280fa012c6ab580a50470e623731619tvlhfv.html. Acesso em: fev. 2020.
VARGAS, R. V. Manual prático do plano do projeto. Rio de Janeiro: Brasport, 2017.
VARGAS, R. V. Manual prático do plano do projeto. Rio de Janeiro: Brasport, 2017.
VIGNOCHI, L. et al. Lições aprendidas em Projetos: depoimentos de quem aprendeu com os

próprios erros. Rio de Janeiro: Brasport, 2017a.

CONCLUSÃO
Chegamos ao final do estudo sobre Gerência de Projetos em TI seguindo o PMBOK.

Foi possível entender os conceitos principais sobre as áreas de conhecimento, expandindo
os conceitos sobre ESCOPO, CRONOGRAMA, CUSTOS, QUALIDADE e RECURSOS.
Estudamos a forma de organização do escopo através da declaração do escopo,
e a construção da EAP. Além disso, falamos sobre gestão de cronograma, orçamento, esti-
mativa e gestão de recursos e a influência da qualidade tanto no produto como no projeto.
Vimos também sobre as áreas de conhecimento do PMBOK, ou seja, COMUNICA-
ÇÃO, AQUISIÇÕES, RISCOS, PARTES INTERESSADAS e INTEGRAÇÃO.
Perceba que agora você está munido(a) de conceitos valiosos para o mercado,
capaz de revolucionar o dia a dia das empresa e promover inovação. O poder deste conhe-
cimento já é visto e explorado pelas empresas que possuem uma demanda muito grande
por projetos e investem em evolução contínua.
E não é somente isso, a demanda extrapola o conceito de produtividade e atinge
até as áreas principais da empresa, podendo focar em redução de custos, visualização da
marca e aumento de lucratividade, tornando realidade as estratégias empresariais estabe-
lecidas.
Então, uma dica é: nunca parar de estudar o assunto e transformar os novos conhe-
cimentos adquiridos em práticas do dia a dia. Assim, terá a chance de alcançar o sucesso
tão almejado. O primeiro passo já foi dado, agora é com você.
Um abraço e até a próxima!
Prof. André Dias Martins

102 - Apostila - Gerência de Projetos em Ti

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

102 - Apostila - Gerência de Projetos em Ti

Enviado por

Direitos autorais:

Formatos disponíveis

Gerência de

Diretor de Ensino e Pós-graduação

Coordenador NEAD - Núcleo

Coordenador do Núcleo de Pesquisa

Projeto Gráfico e Editoração UNIFATECIE Unidade 2

Gerência de Projetos em TI. André. Dias Martins.

Prof. Me. André Dias Martins

Olá, prezado(a) aluno(a), seja bem-vindo(a) à apostila de Gerenciamento de Projeto

Esta unidade inicia os estudos sobre gerenciamento de projetos, tratando de temas

UNIDADE I Introdução à Gerência de Projetos 8

O conceito de gerenciamento de projetos não tinha sido utilizado de forma isolada

UNIDADE I Introdução à Gerência de Projetos 9

1.1. Fatores Influenciadores

Quadro 1 - Fatores influenciadores

1.2. Projetos da Antiguidade

UNIDADE I Introdução à Gerência de Projetos 10

1.3. Gerenciamento de Projetos Contemporâneos

UNIDADE I Introdução à Gerência de Projetos 11

O conhecimento sobre projetos, acumulado até o presente momento, permite notar

2.1. Singularidade dos Projetos

UNIDADE I Introdução à Gerência de Projetos 12

2.3. O que É Gerenciamento de Projetos

2.4. Teoria da Tripla Restrição

UNIDADE I Introdução à Gerência de Projetos 13

Figura 1 - Tríplice Restrição

UNIDADE I Introdução à Gerência de Projetos 14

3.1. Aprendizado por meio dos Erros

UNIDADE I Introdução à Gerência de Projetos 15

3.2. Progressividade dos Projetos

3.3. Diferença entre Projetos e Processos

UNIDADE I Introdução à Gerência de Projetos 16

3.4. Organizações de Gerenciamento de Projetos

3.5. Project Management Body Of Knowledge (PMBOK)

3.6. Stakeholders, Variáves e Etapas do Projeto

UNIDADE I Introdução à Gerência de Projetos 17

Fonte: Beware (2000).

UNIDADE I Introdução à Gerência de Projetos 18

Saia da sua zona de conforto!

UNIDADE I Introdução à Gerência de Projetos 19

UNIDADE I Introdução à Gerência de Projetos 20

UNIDADE I Introdução à Gerência de Projetos 21

Até aqui tivemos a oportunidade de conhecer um pouco do que é um projeto e o

Até a próxima unidade.

UNIDADE I Introdução à Gerência de Projetos 22

UNIDADE I Introdução à Gerência de Projetos 23

Esta unidade inicia os estudos sobre gerenciamento de projetos, segundo o PMBOK,

UNIDADE II Definição e Planejamento 25

Existem muitas técnicas, métodos e guias para conduzir de forma satisfatório um

UNIDADE II Definição e Planejamento 26

UNIDADE II Definição e Planejamento 27

Fonte: Vargas (2017).

UNIDADE II Definição e Planejamento 28

UNIDADE II Definição e Planejamento 29

O Escopo do Projeto é uma lista completa, mas não detalhada, de atividades e

UNIDADE II Definição e Planejamento 30

O Escopo do Projeto contém, sem se limitar, as seguintes macroatividades:

É fácil perceber se os responsáveis pelo projeto dominam a metodologia gerencial:

UNIDADE II Definição e Planejamento 31

UNIDADE II Definição e Planejamento 32

Muitos empreendedores têm dificuldade em definir o escopo do projeto nessa fase

UNIDADE II Definição e Planejamento 33

A Figura 2 apresenta um exemplo de EAP na forma de árvore (pictórica). Note

UNIDADE II Definição e Planejamento 34