Gestão de Projetos

Gestão de Projetos
Prof. Rogério Lacerda
2018
Copyright © UNIASSELVI 2018
Elaboração:
Prof. Rogério Lacerda
Revisão, Diagramação e Produção:

Centro Universitário Leonardo da Vinci – UNIASSELVI
Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

UNIASSELVI – Indaial.
L131g
Lacerda, Rogério
Gestão de projetos. / Rogério Lacerda. – Indaial: UNIASSELVI, 2018.
191 p.; il.
ISBN 978-85-515-0219-8
1.Administração de projetos. – Brasil. II. Centro Universitário
Leonardo Da Vinci.
CDD 658.404
Impresso por:
Apresentação
Olá, acadêmico, seja bem-vindo à disciplina de Gestão de Projetos!
A Gestão de Projetos é muito relevante nas organizações atuais,

dado que esta disciplina possibilita colocar planejamentos estratégicos de
uma forma mais prática e operacional no dia a dia das empresas e demais
instituições.
A disciplina foi disposta em três unidades, a primeira possibilita

uma compreensão da necessidade de projetos e seu relacionamento com
os processos de execução estratégica, desde indicadores até a gestão de um
portfólio ou programas de projeto.
Outro ponto interessante da Unidade 1 é a conceituação de projetos e

seus variados tipos, bem como o aprofundamento das áreas de conhecimento
e grupo de processos que compõem a base de conhecimentos de gestão de
projetos.
Na Unidade 2, nós faremos com detalhes a exposição de conteúdos de

como realizar um planejamento de projeto, desde a definição do seu escopo,
o planejamento de tempo e custo, bem como demais aspectos importantes
do planejamento de projetos como a gestão da comunicação, qualidade de
projetos e identificação e avaliação de riscos.
A Unidade 3 se destina à exposição de conteúdos a respeito da

execução e controle de projetos que perpassam em assuntos de alta
relevância, como a gestão de equipes, liderança, comunicação, controle da
qualidade de projetos, como criar os relatórios de acompanhamento e termo
de encerramento do projeto.
Esperamos que o conteúdo atenda não só a sua necessidade acadêmica,

mas também possibilite no aperfeiçoamento da sua vida profissional e
prática.
Desejo ótimos estudos!
Professor Rogério Lacerda
III
NOTA
Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto

para você que está chegando agora à UNIASSELVI quanto para você que já é
veterano, há novidades em nosso material.
Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

o material base da disciplina. A partir de 2017, nossos livros estão de visual novo, com um
formato mais prático, que cabe na bolsa e facilita a leitura.
O conteúdo continua na íntegra, mas a estrutura interna foi aperfeiçoada com nova
diagramação no texto, aproveitando ao máximo o espaço da página, o que também
contribui para diminuir a extração de árvores para produção de folhas de papel, por exemplo.
Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

apresenta também este livro no formato digital. Assim, você, acadêmico, tem a possibilidade
de estudá-lo com versatilidade nas telas do celular, tablet ou computador.

Eu mesmo, UNI, ganhei um novo layout, você me verá frequentemente e surgirei para
apresentar dicas de vídeos e outras fontes de conhecimento que complementam o assunto
em questão.
Todos esses ajustes foram pensados a partir de relatos que recebemos nas pesquisas
institucionais sobre os materiais impressos, para que você, nossa maior prioridade, possa
continuar seus estudos com um material de qualidade.
Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

Desempenho de Estudantes – ENADE.

Bons estudos!
IV
V
VI
Sumário
UNIDADE 1 – INTRODUÇÃO À GESTÃO DE PROJETOS........................................................... 1
TÓPICO 1 – DE ONDE VÊM OS PROJETOS?................................................................................... 3

1 INTRODUÇÃO...................................................................................................................................... 3
2 FORMAS DE EXECUÇÃO DA ESTRATÉGIA: PROCESSOS E PROJETOS............................ 4
3 GESTÃO DE PORTFÓLIO E PROGRAMAS.................................................................................. 13
RESUMO DO TÓPICO 1........................................................................................................................ 19
AUTOATIVIDADE.................................................................................................................................. 20
TÓPICO 2 – DEFINIÇÃO E TIPOS DE PROJETOS.......................................................................... 21

1 INTRODUÇÃO...................................................................................................................................... 21
2 TIPOS DE PROJETOS.......................................................................................................................... 21
3 CICLOS DE VIDA DE UM PROJETO............................................................................................... 29
4 ESTRUTURAS ORGANIZACIONAIS............................................................................................. 36
RESUMO DO TÓPICO 2........................................................................................................................ 41
AUTOATIVIDADE.................................................................................................................................. 42
TÓPICO 3 – GESTÃO DE PROJETOS................................................................................................. 43

1 INTRODUÇÃO...................................................................................................................................... 43
2 ÁREAS DE CONHECIMENTO E GRUPOS DE PROCESSOS.................................................... 45
3 ABERTURA DE PROJETOS: CONSTRUINDO O TERMO DE ABERTURA DE
PROJETOS.............................................................................................................................................. 50
LEITURA COMPLEMENTAR................................................................................................................ 60
RESUMO DO TÓPICO 3........................................................................................................................ 61
AUTOATIVIDADE.................................................................................................................................. 62
UNIDADE 2 – PLANEJAMENTO DE PROJETOS............................................................................ 63
TÓPICO 1 – COMO DEFINIR O ESCOPO DO PROJETO?............................................................ 65

1 INTRODUÇÃO...................................................................................................................................... 65
2 INTERPRETANDO UM TERMO DE ABERTURA DE PROJETOS............................................ 65
3 ANÁLISE DO GERENTE DE PROJETO........................................................................................... 67
4 ESTRUTURA ANALÍTICA DE PROJETO....................................................................................... 70
RESUMO DO TÓPICO 1........................................................................................................................ 81
AUTOATIVIDADE.................................................................................................................................. 82
TÓPICO 2 – COMO PLANEJAR O TEMPO E O CUSTO DO PROJETO?................................... 83

1 INTRODUÇÃO...................................................................................................................................... 83
2 SEQUENCIAMENTO DE ATIVIDADES......................................................................................... 83
3 ESTIMATIVAS DE PROJETO............................................................................................................. 89
3.1 TRABALHO/ ESFORÇO OU DURAÇÃO DA ATIVIDADE?.................................................... 97
4 PLANEJANDO A EQUIPE DO PROJETO........................................................................................ 97
5 CRONOGRAMA E ORÇAMENTO................................................................................................... 101
VII
RESUMO DO TÓPICO 2........................................................................................................................ 110
AUTOATIVIDADE.................................................................................................................................. 111
TÓPICO 3 – PREPARANDO PARA A EXECUÇÃO.......................................................................... 113

1 INTRODUÇÃO...................................................................................................................................... 113
2 PLANEJAMENTO DE COMUNICAÇÃO........................................................................................ 114
3 PLANEJANDO A QUALIDADE........................................................................................................ 117
RESUMO DO TÓPICO 3........................................................................................................................ 122
AUTOATIVIDADE.................................................................................................................................. 123
UNIDADE 3 – EXECUÇÃO E CONTROLE DE PROJETOS............................................................ 125
TÓPICO 1 – E SE ALGO SAIR DO PLANEJAMENTO?.................................................................. 127

1 INTRODUÇÃO...................................................................................................................................... 127
2 IDENTIFICAÇÃO E AVALIAÇÃO DE RISCOS DE PROJETO................................................... 127
3 PLANO DE RESPOSTA AOS RISCOS............................................................................................. 130
RESUMO DO TÓPICO 1........................................................................................................................ 140
AUTOATIVIDADE.................................................................................................................................. 141
TÓPICO 2 – MOBILIZAÇÃO DA EQUIPE......................................................................................... 143

1 INTRODUÇÃO...................................................................................................................................... 143
2 HABILIDADES INTERPESSOAIS.................................................................................................... 147
3 LIDERANÇA.......................................................................................................................................... 151
RESUMO DO TÓPICO 2........................................................................................................................ 158
AUTOATIVIDADE.................................................................................................................................. 159
TÓPICO 3 – COMUNICAÇÃO DO PROJETO.................................................................................. 161

1 INTRODUÇÃO...................................................................................................................................... 161
2 SISTEMAS DE COMUNICAÇÃO DE PROJETOS........................................................................ 161
RESUMO DO TÓPICO 3........................................................................................................................ 166
AUTOATIVIDADE.................................................................................................................................. 167
TÓPICO 4 – GARANTINDO E CONTROLANDO A QUALIDADE DO PROJETO................. 169

1 INTRODUÇÃO...................................................................................................................................... 169
2 AUDITORIAS......................................................................................................................................... 169
3 CONTROLE DO PROJETO................................................................................................................. 171
3.1 ELABORANDO O RELATÓRIO DE DESEMPENHO DO PROJETO...................................... 171
3.2 MONITORANDO INDICADORES DO PROJETO..................................................................... 181
4 ENCERRAMENTO DO PROJETO..................................................................................................... 183
RESUMO DO TÓPICO 4........................................................................................................................ 186
AUTOATIVIDADE.................................................................................................................................. 187
REFERÊNCIAS.......................................................................................................................................... 189
VIII
UNIDADE 1
INTRODUÇÃO À GESTÃO DE
PROJETOS
OBJETIVOS DE APRENDIZAGEM
A partir desta unidade, você será capaz de:
• compreender os conceitos sobre a gestão de projetos.
• entender a gestão de projetos como parte da gestão estratégica;
• compreender os conceitos de gestão de portfólio de projetos.
PLANO DE ESTUDOS
Esta unidade está dividida em três tópicos. No decorrer da unidade,
você encontrará autoatividades com o objetivo de reforçar o conteúdo
apresentado.
TÓPICO 1– DE ONDE VÊM OS PROJETOS?
TÓPICO 2 – DEFINIÇÃO E TIPOS DE PROJETOS
TÓPICO 3 – GESTÃO DE PROJETOS
1
2
UNIDADE 1
TÓPICO 1
DE ONDE VÊM OS PROJETOS?
1 INTRODUÇÃO
Uma empresa, sendo instituída, necessita de um nível de organização
para alcançar os seus objetivos. E, para que estes objetivos sejam alcançados, a
utilização da técnica de planejamento estratégico, fundamentada em métodos
analíticos, auxilia a compor um conjunto de objetivos e ações que impactarão em
curto, médio e longo prazo a empresa.
Existem várias técnicas e abordagens utilizadas na realização de um

planejamento estratégico. Este pode ser realizado por meio de ferramentas
analíticas que, analisam de modo racionalista o contexto, propõe objetivos e de
forma lógica, ações que irão atender aos objetivos.
A estratégia também pode ser vista como um posicionamento, e com

o uso de ferramentas analíticas. Realiza-se uma análise detalhada do contexto
competitivo em que a empresa está inserida. Com essa análise, principalmente
em relação a concorrentes, novos entrantes, barreiras de entrada, entre outros,
há uma determinação do posicionamento estratégico da organização. Este
posicionamento, pode se dar por meio de competição por preço, competição
por características de produtos e/ou serviços superiores a concorrência ou, até
mesmo, trabalhar em ações que visam à ampliação de atuação da empresa em
nichos restritos de mercado (MINTZBERG; QUINN, 2001).
Outra forma de visão da estratégia é como um padrão. Ou seja, a estratégia

não é vista como um plano com o posicionamento deliberado pelo gerente, mas
sim, como fruto de um comportamento recorrente de ações passadas e ao traçar
um modus operandi da organização, propõe-se então ações de acordo com esse
padrão (MINTZBERG; QUINN, 2001).
Por último, a quarta forma de entender a estratégia é por meio da estratégia

como uma perspectiva de visão de mundo dos gestores. Uma organização não
pode ser entendida como um mecanismo das ciências naturais, e sim fruto de um
contexto social. Deste modo, as visões, preferências e valores pessoais devem ser
levadas em consideração durante a elaboração de planos (OLIVEIRA et al., 2016).
Nesta ótica de estratégia como perspectiva do gestor, é necessário fazer o

uso de ferramentas analíticas e também cognitivas com o objetivo de ampliar a
visão do contexto em que a organização está inserida e assim, auxiliar o gerente
a compor as ações conforme a sua visão de mundo e visão de futuro para a
organização (ENSSLIN et al., 2001).
3
UNIDADE 1 | INTRODUÇÃO À GESTÃO DE PROJETOS
Essas quatro visões estratégias são de suma importância para a

composição de um conjunto de ações estratégicas para a melhoria do desempenho
organizacional, pois, dependendo do mercado onde a organização está inserida,
ela pode ter repercussões operacionais importantes.
Por exemplo, uma organização industrial que fabrica bens de consumo

em grande escala de produção geralmente possui como fator competitivo o
menor preço. Neste sentido, as ações estratégicas, sempre ou quase sempre, estão
associadas a redução de custo operacionais e ampliação de mercado (PORTER,
1992).
Já, empresas de produtos tecnológicos dependem fundamentalmente da

constante melhoria de seus produtos atuais e também de um portfólio de produtos
equilibrado, em que se faz necessário o entendimento do futuro para determinar
as oportunidades de mercado e, principalmente, investir em ações estratégicas.
Para isso, o capital intelectual é importante para a inovação e melhoria de seus
produtos.
Capital intelectual, neste exemplo, pode ser explicado por um quadro de

funcionários com competências técnicas e intelectuais acima da média, de forma
a tornar as ações estratégicas um investimento importante e com repercussões de
longo prazo e duradouras.
A partir do conhecimento sobre os tipos de estratégia organizacional,

vamos agora aprofundar um pouco mais os conhecimentos sobre as formas de
execução da estratégia. Vamos lá!
2 FORMAS DE EXECUÇÃO DA ESTRATÉGIA: PROCESSOS E

PROJETOS
Uma vez estabelecido e entendido, os conceitos e abordagens de estratégia,
é então necessário entender como a estratégia se operacionaliza dentro das
organizações.
Uma estratégia, como vimos na seção anterior, se trata de intenções

desejadas por um corpo executivo de gestores. Todavia, se uma estratégia não
for bem executada, se torna apenas boas intenções e vontades. Desse modo, ela
sendo operacionalizada de forma caótica, o acaso se torna o fator preponderante
para a execução dos objetivos organizacionais.
Sem o norte estratégico, a organização não passará de pessoas e

profissionais que não sabem para onde ir, e nem sabem comparar sua situação
atual com os desejos futuros. Portanto, o alinhamento entre as intenções futuras
e o que é efetivamente executado no dia a dia das organizações é um fator chave
para o sucesso.
4
TÓPICO 1 | DE ONDE VÊM OS PROJETOS?
Existem basicamente duas formas de operacionalizar a estratégia e

fazer com que esta seja executada de forma alinhada estrategicamente no dia
a dia organizacional. As estratégias podem ser operacionalizadas por meio de
processos e por meio de projetos (PMI, 2013).
Processos recebem uma entrada e, a partir da execução de suas atividades,

transformam essas entradas em saídas. Deste modo, processos são um conjunto
de atividades que são executadas, de forma mais ou menos repetitiva, e seguem
um fluxo básico de sequência, conforme apresentado na Figura 1, podendo ser
mensurado o seu resultado ao longo do tempo (SORDI, 2005).
FIGURA 1 – ELEMENTOS DE UM PROCESSO
FONTE: O autor (2018)
Como exemplo de um processo, podemos analisar o processo de montagem

de um carro em uma fábrica, conforme Figura 2. O fluxo de montagem segue uma
rígida e controlada sequência de atividades, em que as pessoas sabem exatamente
quais peças devem ser encaixadas em determinado local e quanto tempo levará
para executar cada atividade. Para esses tipos de processos, as ferramentas de
gestão mais apropriadas e adequadas são as técnicas de otimização, como PERT/
CPM, 6-sigma e controles estatísticos de processos (ANDRADE, 1998).
FIGURA 2 – PROCESSO DE MONTAGEM DE UM AUTOMÓVEL
FONTE: <http://m.diarioonline.com.br/noticias/veiculos/noticia-410988-como-funciona-uma-
linha-de montagem-de-automoveis.html>. Acesso em: 10 set. 2018.
5
No entanto, outros tipos de processo não são tão determinísticos, pois

as informações e orientação para o desempenho da atividade não podem ser
determinados previamente e assim, são basicamente executados por pessoas
e com o uso de seu intelecto. Para estes tipos de atividades, a robotização e a
informatização ainda são limitadas. Podemos citar, como exemplo, o atendimento
ao cliente em um pós-venda.
Por mais que haja um esforço das organizações em padronizar esses

atendimentos, a interlocução entre duas pessoas – o cliente e o funcionário da
empresa – não se pode determinar exatamente quanto tempo o processo irá durar.
Deste modo, pode haver vários desdobramentos em um único atendimento,
a partir de uma pergunta, vários tipos de ações são possíveis, por exemplo: a
consulta de uma base de conhecimento (respostas a perguntas frequentes –
FAQs), a abertura de um chamado para manutenção de um serviço ou produto,
entre outros.
Esse segundo tipo de processo tem como principal característica que não
se pode determinar com precisão a duração de sua atividade, o que torna o uso de
ferramentas estatísticas limitadas a este contexto. Porém, outras análises podem
ser muito importantes a serem realizadas na gestão desse processo, por exemplo,
a natureza da abertura de chamados do help desk ou quais atendentes têm o maior
número de reabertura de chamados. Essas análises e reflexões podem sugerir
uma necessidade de capacitação e averiguação dos motivos que levaram a um
desempenho indesejado pelos gestores.
Em suma, o primeiro tipo de processo é bem mecanicista, executado

basicamente por softwares e automatizado por robôs ou máquinas. Já, o outro tipo
de processo é intensamente executado por pessoas, em que o conhecimento é
um indicador chave de sucesso. As alterações de ação estratégica por meio de
processos se dão pela execução da Gestão de Processos de Negócio – BPM, mas
não será abordado neste livro.
A outra forma de execução de estratégias é por meio de projetos.

Projetos são ações pontuais com começo, meio e fim claros, com um conjunto de
atividades coordenadas que utilizam recursos organizacionais a fim de alcançar
um determinado objetivo. Ao contrário de processos, nos quais o ponto de partida
é uma solicitação (entrada), o projeto é executado a partir de uma deliberação
executiva, geralmente, de cunho estratégico.
Neste sentido, é possível observar, no Quadro 1, as principais diferenças

entre o gerenciamento de projetos tradicional e o gerenciamento de projetos
estratégico.
6
QUADRO 1 – GERENCIAMENTO ESTRATÉGICO DE PROJETOS
Gerenciamento de Gerenciamento de
projetos tradicional projetos estratégico
Atingir prazo, custo e Atingir os objetivos de
Paradigma central
escopo prometido negócio
Foco Eficiência Eficácia e eficiência
Papel do gerente de Terminar o trabalho Ampliar mercado e
projetos prometido resultados da empresa
Estilo do gerente de
“Um tamanho veste todos” Adaptativo
projetos
Como atingir a vantagem
Definição do projeto O que precisa ser feito?
competitiva?
Equipes e resolução de Liderança, visão,
Lado humano
conflitos significado e motivação
FONTE: Adaptado de: Shenhar (2004)
Retomando, pode-se dizer então que projetos são únicos por natureza e
processos são repetitivos por natureza. Projetos precisam de um objetivo claro
para que se haja um planejamento operacional e que todos os recursos necessários
sejam mobilizados em uma ordem do tempo para que o objetivo seja alcançado.
Processos enquanto projetos têm em comum a melhoria ou uma

determinada ação estratégica. Em processos, por exemplo, uma ação estratégica
seria diminuir o tempo de resposta a um cliente. Portanto, é necessário que
seja continuamente averiguado quais são os “gargalos” do processo, ou seja,
processos que estão tomando maior parte do tempo. Desse modo, por meio de
controle estatístico e a ampliação do conhecimento gerencial, pode-se diminuir
esse tempo.
Como exemplos de projetos, podemos citar a abertura de mais pontos

de venda de uma rede de varejo. Dessa forma, projetos não são rotineiros, ou
seja, não há uma demanda contínua de abertura de lojas, mas sim, uma ação
estratégica com impacto organizacional.
A Figura 3 apresenta um esquema resumido de como projetos e processos

podem ser identificados no contexto organizacional.
7
FIGURA 3 – ABERTURA DE UMA NOVA FILIAL DE UMA LOJA
Conforme visto anteriormente, a ação estratégica de uma empresa para

(de) abrir uma nova filial é um projeto pois, possui início, meio e fim. Ou seja,
a partir do objetivo estratégico traçado, o projeto é iniciado por um Termo de
Abertura do Projeto – TAP, passa-se para a execução do projeto e este é finalizado
a partir da entrega de seu resultado final. Já os processos podem ser observados no
dia a dia de funcionamento dessa loja, a entrada recorrente de cliente, a realização
de pedidos e a consolidação de vendas.
Entretanto, processos quanto projetos precisam ser averiguados

constantemente para avaliação do alcance dos objetivos estratégicos. Então, faz-
se necessária uma mensuração dos resultados, surge então o terceiro elemento
importante para a execução da estratégia, a avaliação de desempenho.
Todavia, um grande equívoco realizado pelas organizações e profissionais

é entender que a avaliação de desempenho só é útil após a execução de determinada
situação. Na verdade, a avaliação de desempenho é um desdobramento de anseios
e expectativas organizacionais em relação aos objetivos traçados, e estes objetivos
devem ser mensurados por indicadores de desempenho expressados em uma
escala de preferência.
Neste sentido, a Figura 4 busca exemplificar o processo de formulação

desses indicadores:
8
FIGURA 4 – PLANO ESTRATÉGICO E PROJETOS
FONTE: Adaptado de Norton e Kaplan (2004)
Como visto, a partir dos objetivos estratégicos é possível identificar

indicadores de desempenho que auxiliarão na tradução da estratégia em ações
práticas. Ou seja, a partir desses indicadores de desempenho, a organização
poderá identificar sua situação atual e assim poderá realizar uma análise de que
projetos serão necessários para que o objetivo estratégico seja atingido.
Ao realizar o projeto, é necessária a análise dos resultados alcançados, e

assim uma nova avaliação e atualização dos indicadores de desempenho. Uma vez
realizado, este deve ser um processo recursivo da organização para avaliação de
seus resultados perante seus indicadores de desempenho e objetivos estratégicos.
Com essa visualização e reflexão, os gerentes podem formar opinião com base em
fatos e dados e propor metas de desempenho. A partir dessas metas, surge então
a necessidade de melhoria de processos ou a criação de projetos para elevar o
desempenho de cada objetivo que está sendo focado no momento.
EXEMPLO
Uma organização ao traçar um objetivo, deve identificar quais são as áreas
de gestão que impactam o alcance deste. Neste exemplo é possível observar que o
objetivo estratégico pode ser desdobrado pelos resultados das áreas de mercado,
produção, pessoas e financeiro, conforme apresentado na Figura 5.
9
FIGURA 5 – OBJETIVOS ESTRATÉGICOS E ÁREAS DE GESTÃO
Ao identificar estas áreas de gestão, passa-se a definição de indicadores e

metas de desempenho, conforme apresentado na Figura 6. No exemplo, o comitê
executivo coloca como um dos objetivos a ampliação da presença geográfica e
com o indicador diretamente relacionado.
FIGURA 6 – INDICADORES E METAS DE DESEMPENHO
10
Neste ponto, observa-se o uso da ciência de avaliação de desempenho

como forma de expressar um anseio dos executivos em métricas para realizar
uma gestão eficaz (Figura 7).
FIGURA 7 – AVALIAÇÃO DE DESEMPENHO E OBJETIVOS ESTRATÉGICOS
Na Figura 8 a seguir, observa-se a relação dos indicadores com gestão

de projetos. É a partir dos indicadores de desempenho que os projetos são
concebidos. E no caso do exemplo, talvez necessite um programa de projetos para
alcançar a meta estratégica.
11
FIGURA 8 – RELAÇÃO ENTRE INDICADORES, PROJETO E PROGRAMAS
É importante notar que no exemplo foram explorados apenas um

indicador e um projeto, mas para a execução de um planejamento estratégico,
esse procedimento de relação entre indicadores e projetos deve realizar todas as
áreas da organização, conforme apresentado na Figura 9.
FIGURA 9 – IDENTIFICAÇÃO DE INDICADORES
12
Como observado na Figura 10, a organização deseja também ampliar o

número de vendedores treinados.
FIGURA 10 – EXEMPLO DE PAINEL DE INDICADORES PARA UMA ORGANIZAÇÃO DE

DEPARTAMENTOS
Dessa forma, a avaliação de desempenho tem que ser realizada antes

da execução de melhorias, tanto para processos quanto em relação à gestão de
projetos.
3 GESTÃO DE PORTFÓLIO E PROGRAMAS

Após esclarecer o que é e como ocorre a gestão estratégica, é necessário
identificar como essas ações são operacionalizadas, principalmente, em relação a
projetos, foco central desse texto.
Gerenciar um projeto de uma maneira individual requer certas

habilidades e técnicas, que veremos mais à frente. Porém, veremos a seguir que
o gerenciamento de um conjunto de projetos requer outro tipo de abordagem e
métodos, como a gestão de portfólio e programas.
13
a. Portfólio
Quando na gestão estratégica, selecionamos um conjunto de ações e de

projetos o denominamos de portfólio de projetos. Portfólio de projetos é um
conjunto de projetos que necessitam um contínuo alinhamento com a estratégia
organizacional e estes devem ser gerenciados de forma coordenada e visando
alcançar os objetivos organizacionais. Portfólio de projetos trata da formulação,
seleção, priorização e implementação de projetos e sobre a operacionalização da
estratégia organizacional (LACERDA et al., 2010).
A gestão de portfólio é uma área de conhecimento bastante estudada

nas últimas décadas, mas, ostensivamente analisada com vistas à rentabilidade
financeira de projetos, muito comum em empresas industriais de manufatura,
por exemplo.
Projetos organizacionais não podem ser avaliados somente quanto ao

seu retorno de investimento, pois muitos, principalmente os mais estratégicos,
têm impactos indiretos ou estruturantes nos objetivos organizacionais e no
faturamento. Por exemplo, em um projeto de capacitação, não se pode obter o
retorno de investimento imediato, pois estimulando o conhecimento das pessoas,
subentende-se que teremos também uma melhoria das operações.
Seja qual for o método utilizado para avaliar o portfólio de projetos, se

usado apenas o retorno financeiro, o gestor correrá um sério risco de priorização
de ações que somente tem impacto direto na redução de custos e aumento de
faturamento no curto prazo. Deste modo, pode-se resultar em uma série de
problemas estratégicos, em que a estrutura organizacional não foi preparada
para o crescimento sustentável e para a melhoria contínua de longo prazo.
Dessa maneira, o portfólio de projetos tem que ser avaliado não só em

aspectos financeiros, mas também sobre os impactos indiretos sobre seus clientes,
impactos organizacionais em termos de processos internos, inovação e gestão
de pessoas, que se tornam preponderantes nos dias atuais, principalmente nos
projetos de base tecnológica e de inovação.
Na área de conhecimento da gestão de portfólio, podem-se observar

vários métodos e abordagens para esse tipo de ação, porém, podemos generalizar
quatro grandes etapas na gestão de portfólio, conforme apresentado na Figura 11.
14
FIGURA 11 – GERENCIAMENTO DO PORTFÓLIO
FONTE: Lacerda (2009)
A primeira etapa é definir o que os executivos e gestores da organização

desejam. Ou seja, quais são os objetivos estratégicos e quais são os indicadores de
desempenho que irão mensurar os projetos que precisam ser criados, priorizados
e executados.
No segundo momento são criadas alternativas de ação que visarão impactar

positivamente nos objetivos e indicadores de desempenho, determinados na
etapa anterior.
A seguir, é necessária uma decisão, que é a comparação entre o “desejo”

e “as alternativas de ação”. Existem vários métodos para realizar essa atividade,
em que a avaliação multicritério de apoio à decisão é a principal técnica. Mas
também, caso o gestor de portfólio esteja em contextos mais simples, pode-se
usar uma matriz ponderada de critérios.
A partir da avaliação de desempenho, que confronta um modelo de

avaliação com as ideias de projetos, surge então um ranking, que é uma ordenação
de projetos dos mais atrativos até os menos atrativos. Desse modo, a organização
pode categorizar seus projetos para que haja uma lista de ordenação por
categorias. Por exemplo, poderia existir uma categoria somente de projetos de
desenvolvimento de produtos e uma outra categoria só de melhoria e capacitação
de colaboradores.
Essa divisão em categorias é interessante para quando os gestores da

organização têm orçamentos definidos para cada tipo de categoria e garante,
desse modo, que todas as categorias tenham um conjunto de projetos, gerando
15
então um equilíbrio entre o portfólio de projetos. Sendo assim, previne-se, por

exemplo, de se investir todo o orçamento em desenvolvimento de tecnologia ou
aquisição de software esquecendo outros aspectos estruturantes da organização.
Uma vez que estabelecemos essas categorias, em gestão de portfólio, chamamos
de balanceamento do portfólio, e desse modo, é possível então começar o
financiamento dos projetos.
O financiamento do projeto ocorre pelo projeto mais atrativo e quanto

é o seu orçamento previsto, então parte-se para o segundo projeto, caso haja
orçamento e assim sucessivamente até que o orçamento de uma determinada
categoria seja exaurido. E, dessa forma, os projetos que são financiados têm a
sua prioridade de execução. Após essa decisão, dada pela ordem de execução de
projetos, existe também a necessidade de monitoramento contínuo do portfólio.
A etapa de decisão dos projetos, os planos, cronogramas e orçamentos

são realizados em alto nível e com uma margem de risco e incerteza alta, dado
que as estimativas foram executadas sem informações e que precisam de mais
tempo (e recursos) para obtenção. Assim, esses projetos devem ser de tempos
em tempos (a cada fase do projeto) monitorados para que haja garantia que os
projetos financiados continuem sendo os mais atrativos para organização.
Como exemplo desse monitoramento, pode ser citado um projeto de

ampliação de pontos de vendas de uma empresa de cosméticos. Na etapa de
estruturação do projeto, o gestor supôs que poderia criar cinco filiais com um
orçamento de R$200.000.
O projeto foi financiado e iniciado, porém ao longo da execução do projeto,

o gestor percebe que cinco filiais ficariam inviáveis em virtude de algumas
imprecisões nos orçamentos. O gerente de projeto então pede uma redução da
meta de cinco para três filiais.
Esse constante monitoramento de atratividade e atualização do ranking

de prioridades de projetos geram então as solicitações de mudança. A gestão
de solicitações de mudanças é fator crítico para as organizações em termos
estratégicos, pois auxiliam a determinar se um projeto continua a ser executado ou
se este deve ser suspenso por conta de metas irreais ou subestimação de recursos.
Em algumas situações, durante a execução do projeto, percebe-se que a

atratividade dele não passou de uma especulação no momento do financiamento.
Em princípio, isso pode suscitar uma falha de planejamento, mas gerentes
experientes entendem que é inviável no momento de o financiamento arcar
com altos custos de orçamentos e dispêndio de tempo de pessoas para planejar
detalhadamente cada etapa do projeto. Isso seria mais prejudicial, pois a fase de
avaliação poderia levar meses e perder oportunidades estratégicas importantes.
Em suma: a gestão de mudanças e o monitoramento contínuo de portfólio é
fundamental e aceitar essas imprecisões faz parte do cotidiano de qualquer
gerente de projeto.
16
Como veremos nos tópicos posteriores, a gestão de projetos não é

uma ciência determinística, pois os projetos de maior impacto estratégico e
principalmente os projetos de inovação ou projetos estruturantes que visam dar
consistência para a organização crescer continuamente, tem em sua natureza um
alto grau de incerteza.
Dessa forma, esse exercício contínuo de planejar, executar e avaliar os

objetivos e estimativas, e também o que o gerente de projeto e seu time aprenderam
ao longo da execução é um exercício contínuo da gestão de portfólio e, como
veremos nas seções subsequentes, um exercício contínuo na gestão de projetos.
b. Programas
No conceito de gestão de operações, existe um outro conceito importante

que é o conceito de programa. Um programa, nada mais é do que a gestão do
portfólio de projetos em conjunto com a gestão de processos, com rumo à um
objetivo em comum (PMI, 2013).
Muitas vezes, as organizações se deparam com situações em que

determinado objetivo precisa de vários projetos para sua execução, o que se
caracteriza a gestão de portfólio. Porém, esses projetos são alinhados de uma
maneira temporal, ou seja, projetos são encerrados e seus resultados já são utilizados
pelos usuários. Com esse uso, algumas demandas recorrentes podem ocorrer,
gerando a necessidade de lidar com processos.
Dessa forma, existe a necessidade de gerenciar projetos de uma maneira

coordenada, mas também gerenciar os ativos desses projetos que já estão sendo
gerados e usados. Pode-se imaginar essa questão com o exemplo da empresa que
precisa construir cinco filiais, compondo dessa forma, sua rede de vendas.
Supondo que essas filiais serão construídas de maneira progressiva, ou

seja, um projeto para cada filial, tem-se então cinco projetos diferentes. Mas, estes
devem ser construídos de uma maneira coordenada, pois a mesma equipe irá
fazer cada projeto e, deste modo, surge o conceito de gestão de portfólio.
Porém, essas filiais são construídas de uma maneira temporal, ou seja, uma
primeira filial é entregue e já entra em operação, vendendo e atendendo ao cliente.
Enquanto isso, o projeto da segunda filial inicia, e esse mesmo gestor de portfólio
tem que dar assistência. Ou seja, duas iniciativas coordenadas estão em andamento:
o projeto da segunda filial e o processo de atendimento da primeira filial.
Assim, se há problemas na primeira filial, como uma falha no software de

emissão de nota fiscal, essas manutenções não são previsíveis e não estão dentro
de escopo do projeto. Então essas demandas entram numa rotina de gestão de
processos que é um processo de atendimento ao gerente da filial.
Em resumo, a Figura 12 apresenta as principais características e como a

gestão de projetos, portfólio e projetos estão relacionadas:
17
FIGURA 12 – GERENCIAMENTO DE PORTFÓLIO, PROGRAMA E PROJETO
18
RESUMO DO TÓPICO 1
Neste tópico, você aprendeu que:
• Existem várias técnicas e abordagens que sustentam o planejamento estratégico

organizacional.
• As estratégias podem ser operacionalizadas por meio de processos e por meio

de projetos.
• Processos são, basicamente, um conjunto de atividades que são executadas,

de forma mais ou menos repetitiva, e seguem um fluxo básico de sequência,
podendo ser mensurado o seu resultado ao longo do tempo.
• Projetos são ações pontuais com começo, meio e fim claros, com um conjunto
de atividades coordenadas, que utilizam recursos organizacionais a fim de
alcançar um determinado objetivo.
• Processos e projetos precisam ser averiguados se estão conseguindo alcançar os

objetivos estratégicos. Então, faz-se necessária uma mensuração dos resultados,
surgindo então o terceiro elemento importante para a execução da estratégia, a
avaliação de desempenho.
• Portfólio de projetos é um conjunto de projetos que necessitam um contínuo

alinhamento com a estratégia organizacional e estes devem ser gerenciados de
forma coordenada.
• Um programa é a gestão do portfólio de projetos em conjunto com a gestão de

processos rumando a um objetivo em comum.
19
AUTOATIVIDADE
1 Preencha as frases a seguir a partir dos conceitos apresentados neste tópico:
a) ___________ são um conjunto de atividades que são executadas, de forma

repetitiva, e seguem um fluxo básico de sequência.
b) ___________ são ações pontuais com começo, meio e fim claros, com um
conjunto de atividades coordenadas que utilizam recursos organizacionais a
fim de alcançar um determinado objetivo.
c) ___________ é um conjunto de ___________ que necessitam um contínuo
alinhamento com a estratégia organizacional e estes devem ser gerenciados
de forma coordenada e visando alcançar os objetivos organizacionais.
d) Um ___________, caracteriza-se como a gestão de ___________ de
___________ em conjunto com a gestão de ___________, com rumo a um
objetivo em comum.
20
UNIDADE 1
TÓPICO 2
DEFINIÇÃO E TIPOS DE PROJETOS
1 INTRODUÇÃO
Após contextualizar o panorama de origem dos projetos dentro de
uma organização e também como os projetos são coordenados para constante
alinhamento com a estratégia, podemos agora analisar e conceituar mais
profundamente o que é um projeto.
Um projeto se caracteriza por um conjunto de atividades que usam

recursos organizacionais, que podem ser financeiros, humanos ou materiais, para
o alcance de um objetivo determinado. Projetos então se caracterizam por ser
uma iniciativa temporária da organização, e tem pela sua natureza um começo,
meio e fim (KERZNER, 2016).
Com a definição de que projeto é uma iniciativa temporária, o projeto

carrega um conjunto de métodos e técnicas específicos para trabalhar com esse
tipo de contexto, porém, esses métodos e abordagens podem ser explicados
conforme a natureza e tipo do projeto e quais são as suas características.
Dessa forma, tais métodos e abordagens são explicitados nos subtópicos

seguintes.
2 TIPOS DE PROJETOS
Existem várias tipologias e taxonomias para caracterizar projetos e
determinar quais instrumentos gerenciais são adequados para quais contextos.
Um dos principais elementos de determinação do tipo de projeto e futura escolha
das técnicas é o grau de conhecimento que temos do projeto.
Existem projetos que possuem uma ampla base histórica e é possível

determinar de forma análoga e comparativa quais foram os principais fatores
críticos de sucesso dos projetos anteriores, bem como conseguir parâmetros para
estimar prazo e custo. Muitas vezes, esses já possuem um checklist, ou seja, já
possuem uma estrutura e um conjunto de atividades pré-formatadas em que o
gestor já parte de uma base sólida de conhecimento.
Nessa categoria de projetos com ampla base histórica, pode-se exemplificar

com projetos de construção civil. Uma construtora, que constrói usualmente
o mesmo padrão de edifício, já tem conhecimento dos itens que geram maior
21
esforço, quais itens que tipicamente geram atrasos, quais fornecedores que
atendem a sua necessidade, ou quais variáveis ambientais afetam determinada
atividade, como a chuva.
Assim, a partir desse conhecimento prévio, algumas etapas do projeto já

são previamente conhecidas uma vez que já foram desempenhadas em projetos
anteriores. E, é a partir dessa base histórica, que muitos gerentes de projetos
podem iniciar seu planejamento.
No caso da construtora, por exemplo, já fazem parte da base de

conhecimento da empresa as etapas básicas para a construção de um prédio,
conforme apresentado na Figura 13:
FIGURA 13 - ETAPAS PARA A CONSTRUÇÃO DE UM PRÉDIO
FONTE: Adaptado de: <https://www.aarquiteta.com.br/blog/engenharia-e-construcao-civil/10-

etapas-de-uma-obra/>. Acesso em: 10 set. 2018.
Assim como a partir da base histórica é possível determinar as principais

etapas de construção, ainda é possível identificar cada atividade inerente às
etapas, e assim por diante (Figura 14).
22
TÓPICO 2 | DEFINIÇÃO E TIPOS DE PROJETOS
FIGURA 14 – ETAPAS E ATIVIDADES PARA CONSTRUÇÃO DE UM PRÉDIO
Pilares
Paredes
Vigas
Baldrame Torre caixa
d'água
Vigas
Radier
Lages
FONTE: Adaptado de: <https://www.aarquiteta.com.br/blog/engenharia-e-construcao-civil/10-

etapas-de-uma-obra/>. Acesso em: 10 set. 2018.
Outro exemplo que pode ser citado é o cálculo de estimativa da utilização

de tijolos em uma determinada obra. A partir de uma base histórica, para a
construção de um novo prédio, uma construtora pode estimar a quantidade
necessária de tijolos que utilizará.
Deste modo, ao consultar a base histórica da empresa, é possível identificar

orientações para a estimativa de tijolos necessários para a obra, conforme
apresentado na Figura 15:
FIGURA 15 – ORIENTAÇÕES PARA ESTIMATIVA DE TIJOLOS
FONTE: Adaptado de: <https://www.aarquiteta.com.br/blog/engenharia-e-construcao-civil/

como-calcular-consumo-de-blocos-ou-tijolos-por-metro-quadrado/>. Acesso em: 10 set. 2018.
23
Deste modo, ao consultar as orientações disponibilizadas pela empresa,

com base nas experiências anteriores na realização de projetos similares, as
estimativas podem ser feitas de forma mais assertiva.
Retomando ao exemplo, a partir da base histórica, é possível que a equipe

do projeto possa determinar com maior facilidade a estimativa de tijolos a serem
utilizados, conforme a Figura 16, Figura 17 e Figura 18.
FIGURA 16 – ESTIMATIVA DE TIJOLOS (1)
FONTE: Adaptado de: <http://ew7.com.br/projeto-arquitetonico-com-autocad/index.php/

tutoriais-e-dicas/97-como-representar-a-espessura-das-paredes-em-desenho-tecnico.html>.
Acesso em: 11 set. 2018.
24
FONTE: Adaptado de: <http://www.mfrural.com.br/busca.aspx?palavras=fabrica+blocos>.

Acesso em: 11 set. 2018.
FONTE: Adaptado de: <https://www.dicascasa.com.br/quanto-tempo-para-construir-uma-

casa/>. Acesso em: 11 set. 2018.
25
Importante salientar que não é o setor de construção civil que tem projetos
com base histórica, pois podem existir muitos projetos de construção civil que são
singulares, sem comparação com outros, não se caracterizando então esse tipo de
projeto.
Nesses projetos em que existe uma grande base histórica, o gerente de

projeto já parte de uma base de conhecimento importante para sua execução. Por
essa natureza de alguma previsibilidade, a escolha de instrumentos gerenciais
é baseada normalmente no controle. O controle em administração geral ocorre
pela tentativa contínua de minimização de desvios, basicamente de prazo, custo
e progresso físico do projeto, que chamaremos de escopo.
Por outro lado, existem projetos em que não há uma base histórica pela
qual a organização possa se comparar. Geralmente isso ocorre onde as metas
e o escopo do projeto se tornam incertos ou imprecisos, fruto da limitação de
conhecimento da equipe naquele tipo de projeto, típico de projetos de inovação.
Para esse tipo de projeto, pode-se exemplificar os projetos de

desenvolvimento de novos produtos ou na arquitetura tecnológica de uma
linha de produtos. Nesses tipos de projetos, geralmente não existe uma base
histórica para estimar quanto tempo demora uma atividade e, muitas vezes,
essa incerteza não permite ao gestor uma diretiva sobre o que de fato tem que
ser feito no projeto (escopo). Para esses projetos sem base histórica, o escopo é
incerto e indeterminado no início do projeto. A incerteza advém da limitação de
conhecimento, e conhecimento não é um ativo que pode ser assimilado de forma
rápida e barata, por isso o conhecimento é um diferencial competitivo importante
em qualquer organização moderna.
EXEMPLO
Para exemplificar as diferenças entre projetos, imaginemos o projeto de
um novo produto, uma barraca de camping, conforme ilustrado na Figura 19.
Obviamente, barraca é um produto clássico, composto de hastes e tecido protetor.
Porém, a empresa em questão quer inovar, desenvolvendo a barraca com

ar condicionado, composto dos elementos apresentados na Figura 19.
26
FIGURA 19 – PROJETOS DE INOVAÇÃO
FONTE: O autor
Apesar da demanda por uma barraca que deixe também o mochileiro

tranquilo em momentos quentes do dia, a questão do peso das unidades
condensadora e evaporadora é um problema, conforme ilustrado na Figura 20.
FIGURA 20 – PROBLEMÁTICA DA BARRACA COM AR CONDICIONADO, UM PROJETO

INOVADOR
Dessa forma, existe a necessidade de um processo criativo para resolver

esse problema do peso. Na Figura 21 são apresentados dois exemplos. Um
diretamente relacionado com o desenvolvimento tecnológico de uma unidade
condensadora mais leve para o ar condicionado.
Porém, existe outra possibilidade, a realização de parcerias com hostels,

que ficariam com as unidades condensadoras e o mochileiro só precisaria obter
na recepção por aluguel.
27
Nesse exemplo deixa claro que para resolver problemas, não é somente
uma questão de engenharia ou tecnologia, mas focar no problema e endereçar
necessidades dos usuários.
FIGURA 21 – DECISÕES PARA A SOLUÇÃO DE PROBLEMAS
Projetos que envolvem incertezas são os grandes desafios e oportunidades

das organizações nos tempos atuais. Assim, os gerentes de projetos precisam
adequar seus instrumentos gerenciais, uma vez que os instrumentos baseados
no controle precisam basicamente ter uma estimativa concreta e propositiva do
tempo, custo e o que tem que ser feito.
Todavia, projetos sem base histórica não têm essa determinação, ou se há,
existe uma insegurança quanto a sua precisão. O que se tem no início de projetos
dessa natureza são palpites e opiniões, que chamaremos aqui de uma hipótese
ou premissa de projeto, que somente após a execução se pode aferir se estavam
corretas ou não.
Instrumentos gerenciais baseados em controle não são adequados para

contextos incertos, pois se focam no controle de variáveis que impactam no
resultado desejado. Para contextos de projetos de inovação devem-se usar técnicas
de expansão de conhecimento na equipe e criar condições para que as pessoas
consigam de uma maneira progressiva e por ciclos de aprendizagem, entender
o projeto e assim propor estimativas factíveis. Isso ocorre devido a pequenos e
sucessivos experimentos que se focam na aprendizagem.
28
Vale reiterar que somente existe incerteza pela limitação de conhecimento.

Assim, a aprendizagem visa ampliar o conhecimento e, consequentemente,
minimizar a incerteza.
Outra variável em que podemos categorizar os projetos é o nível de

complexidade. A complexidade aqui nesse contexto não se caracteriza pelo que
é fácil ou difícil de executar, pois a facilidade ou dificuldade se relaciona com
o grau de conhecimento e experiência de uma determinada equipe. Para uma
equipe experiente, uma atividade pode se caracterizar como fácil e a mesma
atividade executada por uma equipe inexperiente pode se configurar uma
atividade complicada.
Assim, o termo complexidade em contexto de projetos se refere à

quantidade de componentes e pessoas envolvidas com o projeto e, principalmente,
como essas pessoas e componentes devem ser integrados no projeto, ou seja,
quantos stakeholders farão parte desse contexto.
Após categorizar o projeto, pela magnitude da base histórica do projeto e

pela sua complexidade, o gerente de projetos pode avaliar qual é o ciclo de vida
pelo qual será executado o projeto, assunto que será abordado na próxima seção.
UNI
O termo stakeholder (partes interessadas, em português) se refere às pessoas e

às organizações que podem ser afetadas pelo projeto, de forma direta ou indireta.
3 CICLOS DE VIDA DE UM PROJETO

Ciclo de vida se refere à abordagem de como será a sequência de eventos
que ocorrerá no projeto para que esse alcance os resultados esperados.
O ciclo de vida clássico é o executado em fases, em que o projeto é

dividido em intervalos de tempo e cada intervalo, chamado fase, tem um produto
de trabalho importante para a conclusão do projeto. Toda fase é encerrada com
um marco do projeto. Alguns exemplos típicos de marcos de projeto são entrega
do termo de abertura do projeto, estabilização dos requisitos de projeto, acordo
preliminares de planos de projeto, implementação, entrega e encerramento do
projeto (PMI, 2013).
O ciclo de vida por fases é indicado em projetos em que haja uma base
histórica adequada para determinar os marcos do projeto e confiabilidade nas
estimativas para conseguir determinar a grandeza de cada fase, mesmo que
29
em forma de proporção, como “estima-se que a implementação durará 50% do

projeto todo”. A Figura 22 apresenta uma exemplificação desses tipos de ciclo de
vida:
FIGURA 22 – MODELO DE CICLO DE VIDA: CASCATA
Uma opção ao ciclo de vida por fases é o ciclo de vida iterativo. Uma
iteração é um conjunto de atividades que são realizadas com vistas a dissipar
dúvidas e riscos de projeto de forma progressiva (PEREIRA et al., 2007).
Esse ciclo de vida é indicado para projetos com base histórica limitada
ou inexistente, sendo necessário evoluir o projeto gradativamente para entender
seus requisitos e ter bases de estimativas mais confiáveis. Em uma iteração, há
um foco de curto prazo de entrega de um conjunto restrito de requisitos que seja
operacional, ou seja, seja útil para o usuário e a equipe de projeto observar se
estão no caminho correto.
Para tal intento, realiza-se um ciclo de levantamento de requisitos,

implementação e teste de uma parte relevante do escopo. Como se fosse o ciclo
de vida de fases do projeto, mas com duração curta, geralmente entre uma a três
semanas cada iteração, conforme a Figura 23.
30
FIGURA 23 – CICLO ITERATIVO
Em um projeto de inovação, é típico não saber com precisão quais os

requisitos do projeto e quantas iterações (tempo) serão necessárias para sua
conclusão, conforme Figura 24.
FIGURA 24 – LINHA DO TEMPO (1)
31
Nas primeiras iterações, geralmente se destina a identificar quais são os

requisitos de projeto, assim como na Figura 25.
Os requisitos de maior risco ou de maior utilidade ao usuário são

formalmente especificados e classificados por ordem de criticidade, ou seja,
aqueles que serão implementados primeiro, conforme a Figura 26.
32
Com o escopo clarificado, foca-se em dividir o projeto em iterações, assim

como demonstrado na Figura 27.
33
Muitas vezes, em projetos de muita incerteza, só existe um plano das

próximas iterações, e não do projeto como um todo, conforme Figura 28.
34
Ao avançar na execução do projeto, pode-se dividir as atividades de cada

requisito ao longo das iterações, surgindo a ordem das versões de produto e quais
requisitos cada versão contemplará, assim como na Figura 29.
35
4 ESTRUTURAS ORGANIZACIONAIS
Como observado nas seções anteriores, as organizações podem executar
sua estratégia por meio de processos ou por projetos. Dessa forma, a disposição dos
recursos humanos, financeiros e de infraestrutura são estruturados e organizados
para atender a essa tipologia de execução estratégica (MINTZBERG, 1995).
Deste modo, por questões históricas e principalmente pelo anseio

primário em desenvolver o lucro em detrimento ao desenvolvimento da estrutura
organizacional com rentabilidade e lucratividade em amplos horizontes de tempo,
as estruturas organizacionais foram tradicionalmente desenhadas para atender
aos processos críticos, ou seja, aqueles processos que são vetores fundamentais
para o sucesso da empresa.
Dessa maneira, para potencializar a especialização em detrimento de uma

visão abrangente dos objetivos organizacionais, as estruturas organizacionais
foram historicamente contaminadas por estruturas funcionais, ou seja, estruturas
sobre as quais as organizações são divididas em áreas de conhecimento ou
departamentos.
Por exemplo, uma empresa privada típica pode ser entendida como um
conjunto de processos financeiros, de operações, recursos humanos, logística,
vendas e atendimento ao cliente. Por trás dessa tipologia, em que chamamos de
36
estruturas funcionais, está o anseio de organizar as áreas de conhecimento a fim

de otimizar os recursos disponíveis. Essa visão de estruturas organizacionais teve
início na era da administração científica, e se perpetuou durante décadas como
modelo típico em que observamos nas empresas atualmente.
Porém, por trás dessa tipologia, existe a premissa de que os objetivos

organizacionais são atendidos por essas unidades organizacionais de uma maneira
que cada unidade contribua de forma alinhada com os objetivos da empresa.
Todavia, observa-se uma disfunção que é o foco exacerbado da utilização dos
recursos disponíveis, ou seja, privilegiar a eficiência (“fazer bem feito”) e não se
atentar à eficácia (“fazer o que deve ser feito”), deixando o alcance dos objetivos
da organização em segundo plano.
As estruturas funcionais apresentam dificuldades para orquestrar os

recursos interdepartamentais, que são típicos nas organizações modernas. Pode-
se citar, como exemplo, o desenvolvimento de um produto em uma estrutura
funcional.
O desenvolvimento de um produto geralmente fica com a competência

e responsabilidade da área de operações. Portanto, as outras unidades não se
sentem responsáveis por aquela iniciativa, dado que são responsáveis por
otimizar seus recursos e seus próprios processos. Um esquema de organização
funcional é apresentado na Figura 30.
FIGURA 30 – ORGANIZAÇÃO FUNCIONAL
FONTE: Adaptado de PMI (2013)
37
Como exemplo de disfunção desse tipo de estrutura pode ser citado

quando o setor de recursos humanos desenvolve um plano de cargos e salários e
um plano de remuneração variável para os seus colaboradores. Porém, quando
se pensa em desenvolver um produto não é só a questão física ou a questão do
produto em si que precisa de gerenciamento. O desenvolvimento de produto
necessita uma equipe bem capacitada e selecionada para que se possa ter alto
desempenho nesse produto.
Portanto, para desenvolver um produto, seja ele tecnológico ou não, a

área de recursos humanos deve pensar de forma estratégica e alinhada com a
área de operações para que consiga suprir a necessidade estratégica. A gestão de
pessoas, por meio de motivação, seleção e desenvolvimento de pessoas contribui
com o desenvolvimento das competências críticas para o alto desempenho do
projeto e o desenvolvimento de produto. Existe uma relação indireta, mas de
extrema importância nessas unidades.
Outro exemplo, ainda no desenvolvimento de um produto. No momento

em que o produto está em sua fase final de testes, já deve ser iniciado, ou até
avançado, a elaboração de um plano de marketing, um plano de divulgação e
um plano de estratégia de vendas, capacitando todo o canal de distribuição e de
vendas para que os representantes possam lidar com esse novo produto que está
sendo disponibilizado para o mercado.
Deste modo, área de vendas, que antes era só responsável por atingir
uma meta de vendas, precisa também estar alinhada com o desenvolvimento do
produto para que a força de vendas possa ter pessoas e um discurso alinhado com
a proposta de valor e modelos de precificação adequado para o novo produto que
se está disponibilizando.
Com esses exemplos, pode-se observar a dificuldade que um diretor-

geral ou um executivo tem em orquestrar todos esses departamentos de forma
que garanta não só um desempenho departamental de excelência, mas também
garantir que os objetivos organizacionais sejam prioritários, até mesmo em
detrimento de alguns objetivos departamentais isolados, pela sua contribuição
estruturante e estratégica para a organização. Muitas vezes, para que o coletivo
possa alcançar seus resultados, o individual deve ser preterido.
Em contraponto às estruturas funcionais, existe outra forma de estrutura

organizacional que endereça a questão de alinhamento de objetivos e alinhamento
de todas as unidades de negócio para um fim específico. Os departamentos, em
vez de serem organizados por áreas de conhecimento, devem ser dispostos por
projetos (PMI, 2013).
Assim, não existem vários gerentes e vários departamentos para compor

um conjunto de recursos para o cumprimento de um objetivo, mas sim, um gerente
de projeto e uma equipe multidisciplinar alocada para que consiga atender a esse
objetivo.
38
Os departamentos em estruturas projetizadas não são unidades primárias

para a consecução de objetivos. Mas sim, o projeto passa a ser um conjunto de
recursos multidisciplinares, com competências de operações de finanças, de
recursos humanos, marketing e venda, assim por diante.
Os departamentos do modelo funcional continuam existindo, porém são

responsáveis por prover recursos, pessoas e competências alinhados ao que os
projetos precisam e não rivalizando os seus objetivos e recursos em detrimento
de objetivos organizacionais globais.
Nessa configuração projetizada, os gerentes do projeto têm autoridade

superior a chefia de departamento, e podem solicitar alocação de recursos para o
cumprimento de objetivos organizacionais. Deste modo, os processos isolados não
são mais relevantes que os objetivos globais de uma organização. Um esquema de
organização projetizada é apresentado na Figura 31.
FIGURA 31 – ORGANIZAÇÃO PROJETIZADA
FONTE: Adaptado de: PMI (2013)
Todavia, a estrutura projetizada também carrega alguns desafios

gerenciais de longo prazo. Por exemplo, a equipe de um projeto é transiente, ou
seja, ela é arregimentada e disponibilizada às unidades de negócio assim que o
projeto se inicia e se encerra.
Dessa maneira, os profissionais precisam compreender não só a sua função

em uma unidade de negócio isolada. Mas sim, a equipe precisa entender que cada
dia do seu trabalho é como um passo para o alcance dos objetivos estratégicos de
uma organização.
Outro desafio dessa configuração é que em um determinado momento

a empresa pode não ter à disposição e nem terá atividades suficientes para
alocar profissionais dedicados exclusivamente, como um contabilista ou um
39
auditor. Esses profissionais podem trabalhar em um determinado momento em

um projeto, mas não de uma forma dedicada. Surge, então, uma importante e
complexa necessidade de gerenciar recursos compartilhados.
Esses recursos compartilhados, como pessoas, orçamento e infraestrutura,

podem também ser motivo de disputas e priorização. Deste modo, é necessário a
intervenção executiva para que os recursos compartilhados também sejam usados
de forma alinhada aos objetivos estratégicos da organização.
Pode-se ainda citar outra forma de estrutura, a híbrida. A estrutura híbrida

contempla características das duas estruturas funcionais e projetizadas. Nessa
estrutura de organização continuam existindo os departamentos funcionais,
porém, há também o departamento de projetos. Assim, as operações ou processos
isolados que não têm relação ou tem baixa relação com outros departamentos são
tratados dentro de cada departamento.
Porém, projetos estratégicos são alocados para a área de projetos que se

denomina em algumas organizações como escritório de projetos ou PMO (em
inglês Project Management Office). Esse escritório de projetos contempla a alocação
de profissionais capacitados em gestão de projetos, assim como define e mantém
uma metodologia de gestão de projetos para toda a organização (BARCAUÍ, 2012).
Dessa maneira, quando um projeto estratégico é iniciado, um profissional

da gestão de projetos do escritório de projetos é alocado para sua gerência e
as demais pessoas de forma compartilhada são disponibilizados pelas áreas
funcionais. Apesar de parecer uma vantagem de alinhamento estratégico, bem
como garantir a identificação de um profissional em relação ao seu departamento,
essa estrutura organizacional também oferece desvantagens.
A principal desvantagem é a equipe que está alocada no projeto e muitas

vezes se reporta de uma forma duplicada para o gerente funcional e o gerente
de projeto. Ou seja, em termos de sua carreira e objetivos de longo prazo, ele
se reporta para o gerente funcional, porém, no dia a dia do projeto e no alcance
os objetivos da organização, ele se reporta ao gerente de projeto, o que pode
acarretar uma disputa de prioridades entre as unidades, uma vez que há uma
complexidade em determinar essa prioridade.
Como se observa nesta unidade, não há uma estrutura funcional perfeita,

muito menos a melhor. A decisão dessa estrutura organizacional é dependente
do contexto, do tipo de empresa, tamanho e segmento que ela atua.
Como critério básico e fundamental para a escolha dessas tipologias, pode-

se recorrer ao critério de ciclo de vida de produto. Por exemplo, organizações que
têm ciclo de vida de produtos longos, ou seja, produtos que ficam muito tempo
no mercado, dando manutenções e melhorias graduais incrementais, podem se
beneficiar das estruturas funcionais clássicas, porém organizações de ciclo de vida
de um produto curto, que são típicos em organizações de tecnologia e inovação,
se beneficiam mais de estruturas organizacionais projetizadas.
40
RESUMO DO TÓPICO 2
• Um projeto se caracteriza por um conjunto de atividades que usam recursos

organizacionais, que podem ser financeiros, humanos ou materiais, para o
alcance de um objetivo determinado.
• Existem projetos que possuem uma ampla base histórica e é possível determinar
de forma análoga e comparativa, quais foram os principais fatores críticos de
sucesso dos projetos anteriores, bem como conseguir parâmetros para estimar
prazo e custo.
• Existem projetos em que não há uma base histórica pela qual a organização
possa se comparar. Geralmente isso ocorre quando as metas e o escopo do
projeto se tornam incertos ou imprecisos, fruto da limitação de conhecimento
da equipe naquele tipo de projeto, típico de projetos de inovação.
• Projetos que envolvem incerteza são os grandes desafios e oportunidades das

organizações nos tempos atuais.
• Instrumentos gerenciais baseados em controle não são adequados para

contextos incertos, pois se focam no controle de variáveis que impactam no
resultado desejado.
• Ciclo de vida se refere à abordagem de como será a sequência de eventos que

ocorrerá no projeto para que esse alcance os resultados esperados.
• O ciclo de vida clássico é o executado em fases, quando o projeto é dividido

em intervalos de tempo e cada intervalo, chamado fase, tem um produto de
trabalho importante para a conclusão do projeto.
• Uma iteração é um conjunto de atividades que são realizadas com vistas a

dissipar dúvidas e riscos de projeto de forma progressiva.
• As estruturas funcionais apresentam dificuldades para orquestrar os recursos

interdepartamentais, que são típicos nas organizações modernas.
41
AUTOATIVIDADE
1 Qual é o tipo de ciclo de vida indicado para um projeto de desenvolvimento

de um novo celular que controla os dispositivos eletrônicos da sua casa,
como luzes, TVs, geladeira etc.? Justifique sua resposta.
2 Proponha um ciclo de vida para a construção de uma nova praça em seu

bairro. Como seriam as fases? Justifique sua resposta.
42
UNIDADE 1
TÓPICO 3
GESTÃO DE PROJETOS
1 INTRODUÇÃO
Uma vez contextualizado como as organizações executam a sua estratégia
e como são estruturadas as pessoas, recursos financeiros e de infraestrutura para
execução dessas ações, passa-se agora a abordar o tema central da gestão de
projetos.
A gestão de projetos é um conjunto de ações gerenciais, que coordenam

um esforço temporário para que se possa entregar um resultado tangível ou
intangível a um conjunto de interessados. Um projeto pode criar um produto
físico, como um motor, ou um produto intangível, como um aplicativo de celular.
Um projeto também pode ter no seu objetivo a criação ou implantação de

um serviço, por exemplo, a implementação de uma área de assistência técnica
de uma fábrica. Uma melhoria de processo também pode ser considerada um
projeto, sendo esse, uma melhoria organizacional (PMI, 2013).
O termo “projeto”, na língua portuguesa, apresenta duas conotações,

usaremos nesta disciplina a de execução de processos gerenciais a fim de alcançar
um resultado. A outra conotação se refere ao sinônimo de um determinado projeto
de produto, como se fosse uma maquete ou uma simulação de um produto. As
duas conotações se diferenciam na língua inglesa, sendo o primeiro “project” e
o segundo “design”. Portanto, um gerente de projeto no contexto de gestão de
projetos, deve dominar as práticas gerenciais (“Project”) e não necessariamente
ser expert na área de negócio envolvendo “design”.
Obviamente, um gerente de projeto sem nenhum conhecimento na área de

conhecimento do projeto fica fragilizado, pois terá dificuldade de ser reconhecido
pela equipe técnica como líder. Entretanto, pessoas com alto conhecimento técnico
terão muito mais valor na linha de frente da empresa e não na área gerencial.
Desta maneira, o gerente de projeto tem que ser um expert nas práticas gerenciais,
mas também, tem que possuir conhecimentos básicos para entender das situações
da área de domínio do problema do projeto.
Por exemplo, dificilmente um gerente de projetos em uma indústria

automobilística terá o respeito dos engenheiros mecânicos sem entender os
elementos básicos do processo de desenvolvimento e montagem de um carro.
43
Todavia, é possível que um gerente de projetos com habilidades interpessoais,

possa superar essa lacuna técnica de engenharia, mas não superar a defasagem
de conhecimentos gerenciais e interpessoais.
Com essa exposição, pode-se perceber que um gerente de projetos para

execução de suas funções, precisa de três elementos inter-relacionados, que são:
(i) conhecimento nas práticas gerenciais de gestão de projetos; (ii) conhecimento
elementar na área de domínio do problema; e, (iii) habilidades interpessoais.
Assim, o PMBOK (Project Management Body of Knowledge) institui que um

projeto é um esforço temporário, empreendido para criar um produto, serviço
ou resultado exclusivo. O PMBOK define um conjunto de práticas, técnicas
e processos para que os profissionais de gestão de projetos possam ter um
vocabulário comum dessa área de conhecimento, bem como institui um conjunto
de ações tidas como “boas práticas” da área.
Muito se discute na literatura o tema de gestão de projetos, que pode se dar

do entendimento do projeto como um elemento racional e extremamente lógico
para alcançar o resultado. Também pode ser entendido como uma estrutura de
processos para que o gerente e sua equipe possa entender mais de seus objetivos
e ações, e de que forma consigam aprender sobre projeto e melhorar os objetivos
pelos quais eles foram financiados.
Apesar do PMBOK citar os processos como um conjunto de “boas

práticas”, esse termo não pode ser levado de uma maneira universal, pois o que
é relevante para um projeto pode não ser relevante para o outro, dado que um
projeto é uma ação temporária e única.
Portanto, cada projeto tem que ter um gestor de projeto para que possa
observar e analisar o contexto de forma singular e específica, entender quais
práticas descritas no conjunto de base de conhecimentos de gestão de projetos
possam ser úteis para aquele determinado momento do projeto, formando então
uma metodologia de gestão de projetos.
Com essa assertiva, podemos afirmar que o PMBOK não se constitui em

uma metodologia de gestão de projetos, mas sim uma base de conhecimento
comum. Refere-se a uma metodologia, quando um subconjunto dessas práticas é
implementado e utilizado para um projeto em específico ou para uma organização
em um dado instante.
Apesar do esforço e da contribuição do PMBOK para gestão de projetos,

não se pode dizer que ela é exaustiva, dado que para cada tipo de produto de
trabalho pode ser interessante e relevante usar ferramentas de outras áreas de
conhecimento ou áreas técnicas mais específicas para lidar com determinado
problema.
44
TÓPICO 3 | GESTÃO DE PROJETOS
Os processos gerenciais que compõem a base de conhecimento em gestão

de projetos podem ser classificados de duas formas, e no cruzamento dessas
categorias, estão os processos de gestão de projetos. Então, os processos de gestão
de projetos podem ser organizados por áreas de conhecimento e por grupos de
processos.
2 ÁREAS DE CONHECIMENTO E GRUPOS DE PROCESSOS

As áreas de conhecimento em gestão de projetos são um conjunto de
conceitos, termos e atividades que compõem o campo profissional de gestão de
projetos, ou seja, são áreas de especialização. A gestão de projetos possui dez
áreas de conhecimento, sendo elas: integração, escopo, tempo, custos, qualidade,
recursos humanos, comunicações, riscos, aquisições e gerenciamento de partes
interessadas (stakeholders).
Já, os grupos de processos se destinam a elaborar um conjunto de processos

gerenciais que ocorrem em determinado momento do projeto. Os grupos de
processos são: iniciação, planejamento, execução, monitoramento, controle e
encerramento.
Os grupos de processos, muitas vezes, são confundidos como fases do

projeto. Porém, planejamento, execução e controle não são fases de um projeto,
uma vez que o planejamento é um ato contínuo do gerente de projeto e não
somente em um determinado ponto do projeto.
Pela sua origem mecanicista e de racionalidade perfeita, o grupo de

processos de planejamento do PMBOK congrega o maior número de processos
gerenciais, sendo o único grupo de processos em que todas as áreas de
conhecimento têm ao menos um processo.
De forma inversa, a área de conhecimento de gerenciamento de integração

do projeto, está relacionada com processos de todos os grupos de processos do
PMBOK, sendo a única área de conhecimento que tem processo para todos os
grupos de processos. Isso ocorre porque a área de conhecimento de integração
do projeto na verdade não congrega um conteúdo específico, mas reflete uma
compilação final do conhecimento gerado naquele momento. A integração então
se destina a equilibrar todas as dimensões de sucesso do projeto, que podem
possuir vários critérios de sucesso e não apenas prazo e custo.
Por exemplo, quanto mais escopo o gerente inclua no projeto, geralmente,

maior é o tempo necessário para execução do projeto. Muitas vezes, então, a área
de conhecimento de integração serve para equilibrar escopo e tempo. Percebe-
se que ao remover certas características do projeto (escopo) pode acelerar ou
abreviar o encerramento do projeto. Essa atividade de equilíbrio entre as áreas de
conhecimento se dá pela área de conhecimento de integração, se tornando então
uma área de conhecimento que observa o projeto de forma integrada e global.
45
No grupo de processo de execução, por exemplo, não existem processos

gerenciais para a área de conhecimento de escopo. Já na área de conhecimento
de gestão de riscos, os processos gerenciais se concentram somente no grupo de
processos de planejamento, monitoramento e controle.
O Quadro 2 apresenta as áreas de conhecimento e os grupos de processos

identificados pelo PMBOK.
QUADRO 2 – GRUPO DE PROCESSOS DE GERENCIAMENTO DE PROJETOS E MAPEAMENTO

DAS ÁREAS DE CONHECIMENTO
Grupo de
Grupo de Grupo de Grupo de Grupo de
processos de
Áreas de processos de processos de processos de processos de
monitoramento
conhecimento iniciação planejamento execução encerramento
e controle
4.4. Monitorar
e controlar o
trabalho do
4. 4.1. Desenvolver 4.2. Desenvolver 4.3. Orientar
projeto
Gerenciamento o termo de o plano de e gerenciar o 4.6 Encerrar o
da integração abertura do gerenciamento do trabalho do projeto ou fase
4.5. Realizar
do projeto projeto projeto projeto
o controle
integrado de
mudanças
5.1. Planejar o
gerenciamento do
escopo
5.2. Coletar os
5.5. Validar o
5. requisitos
escopo
Gerenciamento
do escopo do 5.3. Definir o
5.6. Controlar o
projeto escopo
escopo
5.4. Criar a
estrutura analítica
do projeto
(EAP)
6.1. Planejar o
gerenciamento do
cronograma
6.2. Definir as
atividades
6.3. Sequenciar as
6. atividades
Gerenciamento 6.7. Controlar o
do tempo do 6.4. Estimar os cronograma
projeto recursos das
atividades
6.5. Estimar as
durações das
atividades
6.6. Desenvolver o
cronograma
46
7.1. Planejar o
gerenciamento dos
custos
7.
Gerenciamento 7.4. Controlar os
7.2. Estimar os
dos custos do custos
custos
projeto
7.3. Determinar o
orçamento
8.
8.1. Planejar o 8.2. Realizar
Gerenciamento 8.3. Controlar a
gerenciamento da a garantia da
da qualidade do qualidade
qualidade qualidade
projeto
9.2. Mobilizar
a equipe do
projeto
9.
9.3.
Gerenciamento 9.1. Planejar o
Desenvolver
dos recursos gerenciamento dos
a equipe do
humanos do recursos humanos
projeto
projeto
9.4. Gerenciar
a equipe do
projeto
10.
Gerenciamento 10.1. Planejar o 10.2.
10.3. Controlar
dos recursos de gerenciamento das Gerenciar as
as comunicações
comunicações comunicações comunicações
do projeto
11.1. Planejar o
gerenciamento dos
riscos
11.2. Identificar os
riscos
11.3. Realizar a
11.
análise qualitativa
Gerenciamento 11.6. Controlar
dos riscos
dos riscos do os riscos
projeto
11.4. Realizar
a análise
quantitativa dos
riscos
11.5. Planejar as
respostas aos
riscos
12.
12.1. Planejar o 12.2.
Gerenciamento 12.3. Controlar 12.4. Encerrar as
gerenciamento das Conduzir as
das aquisições as aquisições aquisições
aquisições aquisições
do projeto
13. 13.3.
13.4. Controlar
Gerenciamento 13.1. Identificar 13.2. Planejar o Gerenciar o
o engajamento
das partes as partes gerenciamento das engajamento
das partes
interessadas no interessadas partes interessadas das partes
interessadas
projeto interessadas
47
No grupo de processo de iniciação se encontram os processos gerenciais

que irão legitimar o projeto junto às partes interessadas que originaram o
projeto. De forma típica, na iniciação do projeto, primeiramente se identificam
os stakeholders e então denomina-se um rótulo do problema que se quer resolver
com o projeto.
Na iniciação, também se encontram as premissas de projeto, que são

suposições feitas pela equipe gerencial e equipe interna, e também se encontram as
restrições, que são imposições realizadas pelo ambiente externo e patrocinadores.
Geralmente, a iniciação ocorre somente no início do projeto, porém,

caso aconteça durante a execução uma grande alteração no projeto em relação a
stakeholders ou nos objetivos do projeto, a iniciação pode ser novamente acionada.
Entretanto, isso é atípico, uma vez que se o objetivo de projeto for alterado
muitas vezes, é mais interessante encerrar o projeto antigo do que tentar aprovar
solicitações de mudança em relação a um projeto que não tem mais sentido de
existir.
O grupo de processos de planejamento, como vimos anteriormente, é

o maior em termos de número de processos e se destina um esforço cognitivo
para entender o projeto e propor planos que corroboram com a execução das
atividades que levarão ao resultado desejado.
Existem várias maneiras e abordagens de planejamento de projetos,

neste sentido retoma-se a discussão da seção anterior sobre os tipos de projeto.
Projetos com ampla base histórica remetem a um planejamento racional, em que
se procura otimizar ao máximo os recursos alocados no projeto para que esses
sejam usados de uma forma eficiente, ou seja, com menor número de desperdício
e desvios em relação ao plano.
De outra forma, os projetos sem base histórica, ou seja, os projetos

em que há muita incerteza, típicos de projetos de inovação e transformação
organizacional, o planejamento por ondas sucessivas ou até por iterações se
tornam mais adequados.
Portanto, apesar do número de processos ser o maior do PMBOK, no

grupo de processos de planejamento a quantidade de esforço que será destinada
a cada processo depende do projeto em específico. Projetos com ampla base
histórica terão um grande esforço de planejamento. Já projetos sem base histórica
e ampla incerteza, é necessário que haja um breve esforço de planejamento, indo
o mais brevemente para a execução, aferindo o que se aprendeu e repetindo esse
ciclo para que se possa aprender e descobrir outras partes do projeto escondidas
pela incerteza e falta de conhecimento.
No grupo de processos de execução é onde os pacotes de trabalho serão

executados pelas pessoas designadas, sendo então fundamental o papel do
gerente de projetos na liderança dessas pessoas para o contínuo alinhamento
48
com os propósitos do projeto, bem como, manter um sistema de informações

gerenciais, controlando o progresso do projeto e antevendo problemas de forma
proativa.
Já o grupo de processos de controle, se destina à averiguação e comparação

dos parâmetros do planejado versus os parâmetros obtidos pela execução. À
diferença entre esses dois parâmetros tem-se o nome de desvio.
Importante salientar, nesse momento, que o desvio do planejado versus

o executado é uma questão corriqueira em projetos. Muitas vezes, quando o
planejado é executado exatamente conforme o planejado, pode ser indício de que
os dados não estão sendo obtidos de uma maneira adequada, pois a natureza do
trabalho humano não permite uma variação ou desvio zero. Já uma máquina ou
computador pode terminar o trabalho precisamente como o planejado.
Assim, é de atribuição do gerente de projetos analisar o desvio do

projeto e formar juízo. Se esse merece uma ação corretiva ou não. Muitas vezes,
os desvios são mínimos e não merecem uma ação corretiva formal, pois fazem
parte da natureza da execução humana, porém os desvios que ultrapassam
significantemente os limites desejados precisam ter ações corretivas para que
o projeto consiga recuperar aquela dimensão deficitária, como um atraso de
atividades ou padrões de qualidade aquém do permitido.
Muitas vezes, essas ações corretivas precisam ser submetidas novamente

ao novo planejamento, caracterizando uma ação corretiva que propõe uma
solicitação de mudanças que deve ser incorporada, novos planejamentos com
a devida análise de impacto e depois alterações dos planos para uma nova
legitimação de stakeholders.
O grupo de processos de encerramento, bem como a iniciação, são

grupos de processos executados apenas uma vez durante o projeto. Este grupo
de processos é basicamente a documentação das lições aprendidas de projeto,
bem como o repasse dos ativos gerados pelo projeto para os responsáveis que
irão usufruir ou utilizar daquele produto final. Nessa fase, também ocorre o
encerramento e liquidação dos contratos de terceiros. Neste sentido, é possível
verificar na Figura 32 a interação entre os grupos de processos a cada fase do
projeto.
49
FIGURA 32 – INTERAÇÃO ENTRE OS GRUPOS DE PROCESSOS EM UMA FASE OU EM UM

PROJETO
FONTE: PMI (2013)
3 ABERTURA DE PROJETOS: CONSTRUINDO O TERMO DE

ABERTURA DE PROJETOS
Uma vez contextualizadas todas as áreas de conhecimento e grupo de
processos que compõem a base de conhecimento em gestão de projetos, precisa-
se entender qual processo ocorre no início de um projeto.
O processo que aborda essa questão de abertura de projetos está no grupo

de processos de iniciação e presente na área de conhecimento de integração, este
denominado desenvolver o termo de abertura do projeto. O termo de abertura
de projeto (TAP) pode ser composto por um documento, ou um conjunto de
documentos, apesar do termo usado no singular.

A Figura 33 apresenta as principais entradas, ferramentas e técnicas para
a construção do termo de abertura.
50
FIGURA 33 – ENTRADAS, TÉCNICAS E SAÍDAS DO DESENVOLVIMENTO DO TERMO DE

ABERTURA DO PROJETO
Importante citar, nessa jornada em gerenciamento de projetos, que se deve

entender cada processo da base de conhecimento em gestão de projetos como
uma atividade cognitiva para entender cada passo um pouco mais do nosso
projeto e para se tomar decisões adequadas para cada contexto.
De forma objetiva, o que se quer dizer é que a gestão de projetos não se trata
de gerar documentos. Isso torna a gestão de projetos uma atividade burocrática
de simples formalização, comprometendo os objetivos organizacionais e
distanciando o gerente da sua equipe.
Em suma, apesar do nome, é necessário entrar no verbo que inicia o

processo que é, desenvolver o termo de abertura de projeto, ou seja, o ato de
desenvolver é muito mais rico de conhecimento para o gerente de projetos do que
simplesmente preencher documentos.
Dessa forma, vamos abordar cada ponto e cada perspectiva do tema de

abertura de projeto não como seções de um documento, mas sim, como uma
atividade dentro dessa jornada de desenvolvimento de conhecimento do projeto.
É no início do projeto que todos os stakeholders podem agir de forma criativa, pois,
ainda não há muito comprometimento de investimento no projeto.
Os modelos de documentos devem ser criados e adaptados a cada projeto

e a cada organização. Portanto, evite nesse momento utilizar modelos padrões de
documentos (templates), pois estes limitam muitas vezes sua criatividade e não é
fator crítico de sucesso para o seu projeto. Pelo contrário, adotar metodologias
prontas e que deram certo em outras empresas pode ser um caminho aberto para
o fracasso de seu projeto.
51
O início de um projeto, conforme destacado nas seções anteriores, ocorre

pela insatisfação de uma pessoa, ou um conjunto de pessoas, perante a situação
atual que ela se encontra. Pode-se dar também pela perspectiva do aproveitamento
de uma oportunidade de negócios. Ambas são faces da mesma moeda em que o
projeto se concebe.
Assim, um projeto não é criado de uma maneira objetiva, mas sim, se inicia
a partir de uma pessoa, ou um conjunto de pessoas, com recursos financeiros ou
econômicos para financiar o projeto e iniciar o estudo e execução da eliminação
ou a melhoria do contexto em que ele se encontra.
Como exemplos, pode-se citar o diretor comercial de uma empresa, este

está insatisfeito com o número de cidades atendidas pelos seus vendedores,
então, precisa de um projeto para a ampliação do número de cidades atendidas.
Nesse ponto, é importante destacar a importância da avaliação de

desempenho como instrumento gerencial. Reflita que esse diretor comercial
percebe dois pontos, o primeiro sobre a situação que ele está, com 20 cidades
atendidas pela sua área comercial. Também existe o desejo de ampliar para 35
cidades atendidas. A diferença entre a situação atual e o ponto desejado (meta),
chama-se problema. Dessa forma, um problema se caracteriza pela distância
entre a situação atual e onde os financiados querem estar (ENSSLIN et al., 2001).
Obviamente, esse exemplo apresenta somente um critério de sucesso do

projeto e vai desencadear todo um desenvolvimento de pessoas, seleção, processos
de recrutamento, divulgação, capacitação, treinamento em campo e assim por
diante para elevar esse número de cidades, porém, dificilmente um projeto no
mundo real vai ser dependente apenas de uma métrica ou de um indicador de
desempenho. Mas sim, haverá múltiplos critérios de sucesso em projetos e nem
sempre o gerente de projetos conseguirá atender a todos os critérios de uma
forma plena.
Dessa forma, com essa estrutura de pensamento ao desenvolver o termo

de abertura de projeto, o gerente de projeto já tem que se preocupar em identificar
essa pessoa, ou grupo de pessoas, que estão insatisfeitas e qual o critério de
sucesso que o projeto será avaliado.
Importante também destacar que a avaliação de desempenho em um

contexto estratégico e proativo se destina a explicar de uma forma antecipada
quais os critérios pelo qual o projeto vai ser avaliado durante a sua execução e,
principalmente no seu encerramento, o uso do produto final de trabalho.
A essa pessoa insatisfeita que quer aproveitar uma oportunidade ou tem

um problema, chama-se patrocinador do projeto. O patrocinador então é um tipo
de stakeholder e, pela sua responsabilidade e autoridade sobre os recursos, pode
alterar a situação atual adversa para uma situação mais adequada pelo que ele
52
deseja, porém, geralmente, o patrocinador do projeto, de uma forma prática, não

tem tempo para trabalhar operacionalmente no projeto, delegando essa atividade
a um gerente de projeto.
Deste modo, surge então um segundo tipo de stakeholder, que se chama

gestor de projetos. Este tem o papel de gerar conhecimento sobre o projeto
e organizar os recursos disponibilizados pelo patrocinador para o alcance
equilibrado dos objetivos propostos. Assim, o papel do gerente de projetos é de
facilitador do processo de uma construção coletiva de entendimento para o que
é melhor para a situação.
A palavra facilitador é apropriada uma vez que em projetos, como vimos

na seção anterior, o gerente não precisa ter pleno conhecimento da área de atuação,
nem ser um expert no domínio do problema. Apesar de que, o conhecimento
básico se faz necessário para que ele adquira respeito pelos seus pares.
O terceiro tipo de stakeholder pode-se chamar de intervenientes. Estes

são o conjunto de pessoas que não tomam decisões diretas sobre o projeto,
nem propõem objetivos, dado que essa atribuição é do patrocinador, porém,
os intervenientes têm papel importante em projetos, uma vez que eles podem
influenciar positivamente ou negativamente no projeto, e interferem na formação
do juízo de valor do patrocinador. Ou seja, o patrocinador aprecia o ponto de
vista dos intervenientes, mas não delega a eles a decisão.
Como exemplo, pode-se citar a figura do diretor comercial que deseja

ampliar a sua rede de vendas de 20 vendedores para 35 vendedores, caracterizando
um projeto. Esse diretor comercial leva em conta a opinião de um outro diretor,
que é o diretor financeiro da organização, pessoa essa que não está sobre a sua
alçada hierárquica. Então, é importante para o diretor comercial que o diretor
financeiro que estabelece os orçamentos anuais da empresa, consiga entender
os impactos indiretos da formação da força de vendas no alcance de objetivos
de vendas e, consequentemente, de faturamento que é o objetivo do diretor
financeiro.
Outro típico interveniente de projetos se caracteriza pela própria equipe de

execução. Em muitos casos, principalmente em produtos tecnológicos intensivos
em conhecimento e inovação, a equipe de execução do projeto se caracteriza
por pessoas que podem contribuir para o entendimento do problema e propor
soluções criativas, muitas vezes, mais baratas, para que o projeto consiga alcançar
os seus resultados utilizando menos recursos.
O gerente de projetos experiente é perspicaz, entende que ele precisa de

uma equipe comprometida para que os seus resultados sejam alcançados. Dessa
forma, a equipe do projeto também é mapeada como um stakeholder interveniente
do projeto, para que ele consiga criar um clima organizacional que não só alcance
os objetivos do patrocinador, mas também, que a equipe tenha um significado
sobre o trabalho de cada membro, gerando motivação e visão do projeto.
53
A quarta categoria de stakeholders se materializa na figura dos agidos,

pessoas que são afetadas pelos resultados do projeto, porém, não terão uma
voz ativa dentro das atividades de planejamento, execução e controle. Pode-
se caracterizar essas pessoas como passivas no sucesso do projeto e na sua
gestão. Um exemplo típico de agido é o cliente.
Sem dúvida alguma, um dos objetivos de uma empresa é o lucro. Desse

modo, o cliente precisa ser plenamente atendido para que ele volte a consumir
produtos e serviços de uma determinada empresa. Porém, o cliente geralmente
está preocupado com o seu próprio problema, e não com problema da organização.
Dessa maneira, é um grave erro em gestão de projetos, e na administração em
geral, fazer tudo o que o cliente quer, pois, o cliente não está preocupado com
critérios de sucessos empresariais.
O lucro é tão óbvio, que uma organização e um projeto tem que ser
orientado aos seus clientes, porém, não se pode fazer tudo o que o cliente
deseja, pois, o principal stakeholder continua sendo o patrocinador do projeto. O
patrocinador possui dimensões de sucesso do projeto diferentes do cliente e, é o
patrocinador que em caso de conflito de interesses precisa ser ouvido para saber
se uma demanda de clientes é incorporada no projeto ou não.
Uma vez categorizados os tipos de stakeholders, é necessário formalizar

todos que deverão ser contemplados e observados durante a gestão do projeto.
Geralmente, existe uma avaliação do grau de influência do stakeholder para o
projeto, esse grau de influência é utilizado em caso de conflitos de pontos de
vistas do que deve ser feito no projeto.
Por exemplo, o diretor comercial quer uma entrega que impacta

negativamente nos objetivos do diretor de produção e vice-versa. Existe uma
dificuldade em encontrar uma solução negociada. Dessa maneira, o grau de
influência auxilia de uma forma antecipada ao gestor de projetos, de modo a
esclarecer qual a pessoa que deve ser ouvida para tomar a decisão ou realizar a
arbitragem das partes por meio de autoridade hierárquica.
O grau de influência pode ser de uma forma simples e categorizada, como

a escala de likert de 1 a 5. Deste modo, é possível categorizar, por exemplo, o grau
5 como de maior influência, geralmente reservado ao patrocinador.
Importante destacar que, em alguns projetos, podem ter mais de um

patrocinador, ou seja, mais de um stakeholder de nível 5, sendo o nível grau máximo
de influência nesses casos. Caso existam conflitos de perspectivas e conflitos
de interesse no projeto para com os objetivos de cada stakeholder, é necessário
então a habilidade de negociação e arbitragem por parte do gestor de projetos.
Estas habilidades, muitas vezes, são inevitáveis, pois projetos com múltiplos
patrocinadores são mais complexos e precisam de gerentes mais experientes para
mediar as situações que serão frequentes de divergências de pontos de vista.

54
Outro ponto importante, no termo de abertura de projeto, é caracterizar

o nome e sobrenome de cada stakeholder, porém, alguns casos, principalmente de
agidos, fica inviável citar o nome de todos, dado número de pessoas envolvidas,
como clientes e equipe do projeto.
Além do nome e sobrenome e o grau de influência do stakeholder, destaca-

se a importância de clarificar o seu cargo dentro da organização e, principalmente,
qual é o seu papel e ambição dentro do projeto.
Como exemplo foi citado acima que o patrocinador tem duas grandes
responsabilidades no projeto. A primeira é determinar de forma antecipada,
os objetivos e métricas de sucesso do projeto, bem como em segundo lugar,
disponibilizar os recursos necessários para a execução.
Essas duas atribuições são típicas do patrocinador, porém, não devem ser
usadas de forma exaustiva ou genéricas a qualquer contexto. É importante sempre
o diálogo e reuniões com patrocinadores, necessários para determinar de uma
forma clara e acordada a responsabilidade de cada uma das partes interessadas.
Após a identificação, avaliação elementar dos stakeholders, e como eles irão

contribuir, cada um com seu papel dentro do projeto, o gerente de projeto agora
precisa criar um rótulo do problema. O rótulo do problema se caracteriza por
uma breve descrição estruturada do problema que o projeto visa resolver.

Outra forma de rotular um problema é criando um modelo multicritério
de apoio à decisão. Isso se faz ao identificar os critérios da avaliação do projeto,
em qual nível está cada critério nesse momento e em qual nível se deseja estar
depois da conclusão do projeto (LACERDA et al., 2012). Ou seja, para projetos
mais simples, um rótulo apenas é o suficiente para iniciar o processo do
desenvolvimento do termo de abertura de projeto, porém para projetos mais
complexos, se faz necessário uma mensuração e identificação da situação atual
bem como as metas desejadas.
Nesse momento, o gerente de projeto pode se valer tanto de entrevistas

com os stakeholders, para identificar o problema, bem como, realizar uma
triangulação de evidências com documentações da empresa, que poderia ser um
plano de negócios, um planejamento operacional, um planejamento de vendas,
um planejamento de um produto ou até o planejamento estratégico da empresa
para entender o contexto que o projeto irá se desenvolver.
No contexto de desenvolvimento de um produto, é comum ter um

plano de negócios, documento que identifica uma oportunidade de mercado,
a necessidade organizacional, por exemplo, em corte de custos, uma demanda
pontual de um cliente ou, até mesmo, um marco legal imposto pelo governo
(ROZENFELD et al., 2000).
55
Os fatores ambientais da empresa também são fundamentais para

o desenvolvimento do termo de abertura de projeto, uma vez que a cultura
organizacional e os processos internos muitas vezes normatizados criam restrições
importantes que precisam ser identificadas pelo gerente de projeto.
Além de reuniões e entrevistas com os stakeholders, bem como uma análise

documental da empresa e do contexto competitivo que ela se situa, o gerente
de projeto também pode observar a necessidade de uma opinião especializada.
Por exemplo, consultores da área, consultas a equipe técnica de engenheiros ou
programadores, clientes, patrocinadores e demais especialistas no domínio do
problema. É necessário entender o “estado da arte” daquela problemática em que
se pretende atuar, também se pode consultar universidades e pesquisadores do
ramo para identificar formas inovadoras de lidar com o problema.

Obviamente, depois de fazer um levantamento de informações primárias
e secundárias, muitos pontos serão excluídos e outros serão incorporados dentro
do projeto. Portanto, é muito comum que o gerente de projetos dedique horas ou
dias em reuniões de brainstorming, resolução de conflitos e solução de problemas
pontuais para o entendimento não só seu, como da equipe de projetos que ele
pretende trabalhar.
UNI
Brainstorming é um tipo de dinâmica de grupo utilizada como técnica para

resolução de problemas específicos, para desenvolvimento de novas ideias ou projetos, para
debates de informações e para estímulo do pensamento criativo dos participantes.
Com essas informações, além da lista das partes interessadas e um rótulo

do problema que poderá ser desdobrado em indicadores de desempenho e
critérios de sucesso do projeto, poderá se identificar premissas e restrições do
projeto.
As premissas de projeto são suposições em que o gerente se baseia

para que consiga traçar os seus primeiros planos de ação. Em administração,
principalmente em contextos de projetos, trabalhamos em situações em que não
se possui todo o conhecimento necessário para o desenvolvimento de ações. Até
porque, se o conhecimento já existisse, o próprio patrocinador delegaria isso a uma
pessoa operacional. Mas, na ausência desse conhecimento, delega-se o problema
a um gerente de projeto. Todavia, por mais que o gerente de projeto entreviste
pessoas e analise meticulosamente a documentação existente, dificilmente ele terá
todas as informações para uma tomada de decisão precisa. Dessa forma, alguma
suposição deverá ser colocada para que ele avance para as primeiras atividades
de execução de projeto (VARGAS, 2005).
56
Outra situação, na qual a premissa é relevante, é em situações em que o

tempo e custo para a obtenção do dado são maiores do que o benefício de possuir
tal informação. Lembrando que é um momento inicial do projeto, no qual não tem
muito tempo e dinheiro investido ainda e existem muitas incertezas e perguntas
a serem respondidas. Em suma: ficar vasculhando dados e informações de cada
incerteza no início de um projeto pode significar o seu fracasso como gerente de
projetos, pois a equipe e stakeholders terão a sensação que nada está avançando,
afetando a moral do time e expectativas dos stakeholders. Algum risco o gerente
de projeto deverá sempre assumir para si e tomar algumas decisões baseadas em
premissas, sem a certeza que aquele fato é verdadeiro ou não.
Como exemplo, no caso da expansão da força de vendas de uma empresa,

o gerente de projeto poderia realizar uma pesquisa para saber se a faixa de
remuneração da empresa é atraente para atração de talentos comerciais, ou seja,
vendedores. Porém, essa pesquisa pode levar um certo período de tempo, bem
como pode ter custos. O gerente de projeto poderá optar por realizar essa pesquisa,
investir recursos financeiros e econômicos além do tempo, mas deixando de lado
outros aspectos necessários no início do projeto. Poderá investir muito tempo e
dinheiro com pesquisa de salários, não sabendo ao certo quais os outros aspectos
que fariam os profissionais trabalharem na empresa.
Como o termo de abertura de projeto se destina a realizar um panorama

geral do problema do projeto, essa decisão de pesquisa de salários poderia ser
gerenciada usando uma premissa a ser validada (ou não) durante a execução do
projeto.
Nesse exemplo, o gerente poderia optar por uma visão otimista por criar
uma premissa como “a remuneração da empresa é compatível para atrair pessoas
qualificadas para o cargo”. Mas também, o gerente de projeto com mais cautela
poderia assumir uma premissa mais conservadora, como “será necessário uma
adequação do plano de cargos e salários da organização para que o projeto consiga atrair
talentos compatíveis com os anseios comerciais da empresa”.
Repare que, independentemente de a premissa ser pessimista ou otimista,

a premissa não é um fato validado, mas sim uma suposição que auxilia a traçar os
primeiros planos do projeto. É um instrumento gerencial importante e legítimo.
O erro é não assumir premissas, tornando o projeto muito lento para obter cada
fato e dado, ou não formalizar as premissas, tornando elas não gerenciáveis e não
transparentes aos stakeholders.
Mais adiante, será observado que é durante o planejamento e execução do

projeto que as premissas devem ser constantemente revistas e catalogadas como
riscos de projeto, pois não são informações dadas como fato para a execução,
porém não passam de uma suposição.
57
A suposição é um artifício gerencial fundamental para que o projeto não

fique moroso. O gerente de projeto terá que tomar decisões com informações
incompletas e, as partes faltantes da informação se tornam premissas que devem
ser gerenciadas de acordo com o seu impacto, como veremos na unidade a seguir.
Outro elemento importante no termo de abertura de projeto é identificar

as restrições. Ao contrário das premissas de projeto, que são suposições realizadas
pelo gerente de projeto sendo uma ação interna da equipe de projeto, a restrição
é uma imposição dada pelo contexto externo.
As restrições podem vir, na maioria das vezes, do próprio patrocinador.

Além de determinar os objetos e os recursos necessários para a execução do
projeto, o patrocinador pode determinar também limites de prazo para a entrega
de resultados.
Restrições clássicas em projeto são, um orçamento finito, um número de

recursos disponibilizados ao projeto, que podem ser financeiros ou econômicos.
A diferença entre recursos financeiros e econômicos ocorre pelo fato do recurso
financeiro ser disponibilizado em termos monetários ao gestor (dinheiro) e os
recursos econômicos são recursos que são cedidos, mas não podem ser convertidos
em outros bens. Como exemplo, o patrocinador pode ceder uma equipe de
15 engenheiros para o projeto, sendo essa equipe um recurso econômico, mas
não financeiro. Laboratórios, salas de reuniões, computadores e outros itens
de infraestrutura também são tidos como recursos econômicos passiveis de
restrições.
Porém, outros tipos de restrições são típicos em projetos, por exemplo,

restrições legais. Alguns setores, como o alimentício e a saúde, são regulados por
órgãos governamentais. Podem existir restrições tecnológicas, ou seja, o ambiente
de que a empresa, ou não permite ou limita certas ações de melhoria, podem
apresentar restrição de capacidade e assim em diante.
Um equívoco comum, que se observa em determinados projetos, é o

próprio gerente de projetos criando restrições. Destaca-se aqui que a restrição de
projeto não deve ser criada e sim identificada ou imposta por uma pessoa externa
ao contexto do projeto. Isso ocorre porque quanto menos restrições o projeto
apresentar, mais opções de criação de soluções será possível. Se o gerente de
projetos, de uma forma ingênua, criar restrições, estará ele mesmo criando alguns
limites desnecessários que podem impactar seu escopo durante as atividades
de planejamento. Dessa maneira, como dica prática, se não foram identificadas
restrições, é interessante que não se crie, pois isso será uma oportunidade durante
o planejamento e execução do projeto.
Com essas informações, o gerente de projeto pode então compilar esses

resultados em um documento, que pode ser chamado termo de abertura de
projeto, project charter ou visão do projeto. O nome do documento não é relevante,
mas sim o conteúdo compatível com o que foi discutido até agora.
58
Nesse momento, o gerente de projeto deve legitimar os resultados finais

com o principal stakeholder do projeto. Essa legitimação, de forma preferencial,
deve ocorrer por meio de uma reunião de ordem pessoal, para que o gerente de
projeto explane cada item do projeto e explique para o patrocinador os elementos
que compõem e formalizam a abertura de projeto.
A legitimação de um documento gerencial se refere ao ato do executivo

perceber no documento todos os elementos que ele acredita ser importante dentro
de sua estrutura de preferências e valores. A legitimação precisa ser realizada para
que o patrocinador acredite que aquilo representa os seus valores e preferências.
Dessa forma, a legitimação é o momento em que, caso haja qualquer ambiguidade
ou dúvida, essa deve ser eliminada, mesmo que o documento tenha redundância
de informações.
Em um termo de abertura de projetos, é preferencial a redundância de

informações do que a omissão de certas informações. Pode parecer um detalhe
nesse momento, mas durante a execução fará uma diferença crucial entre o
fracasso e o sucesso.
Apesar da reunião presencial ser um meio preferencial para essa

legitimação, com o comprometimento do stakeholder do patrocinador, pode ser
que, seja inviável devido a agenda dos patrocinadores. Vale ressaltar que, caso
o patrocinador ou algum stakeholder, não possuir agenda para uma reunião tão
importante, o gerente de projeto deve realizar a reflexão de avaliar se o projeto
é realmente a prioridade destes. Se não for prioridade, ele poderá vir a ter
problemas sérios durante a execução do projeto por falta de comprometimento
das partes interessadas, como veremos na unidade a seguir.
Outras formas de legitimação seriam as videoconferências, que são muito

poderosas, porém, perde-se um pouco da leitura corporal, que pode ser importante
para a identificação de ambiguidades. Por fim, a pior de todas, que seria o último
recurso a legitimação, o e-mail. Por e-mail, a oportunidade de explicação é nula
por parte do gerente de projetos e deve ser somente usada como último recurso.
59
LEITURA COMPLEMENTAR
CRITÉRIOS SUGERIDOS PARA PRIORIZAÇÃO DE PROJETOS

ESTRATÉGICOS
Na seleção de projetos estratégicos, são aplicados diversos critérios com a

finalidade de priorizar os projetos mais adequados e supostamente necessários e
suficientes para atingir os objetivos estratégicos propostos.
Pode ser utilizada uma escala de avaliação distribuída em 6 pontos, sem

centro, de 0 a 5.
Complexidade – Analisa a abrangência do escopo do projeto, o custo benefício

e o esforço alocado para a sua implementação: quanto menor a complexidade,
maior a pontuação.
Custo – Avalia o investimento necessário em termos de orçamento para a

operacionalização da iniciativa: quanto menor o custo, maior a pontuação.
Determinação legal ou da Administração – Pontua as iniciativas em função de

cumprimento de lei ou de determinação da Administração da Organização. O
projeto recebe pontuação máxima ou mínima nesse critério, não há pontuação
intermediária.
Impacto na meta – Mede a relevância estratégica, ou seja, a contribuição do

projeto para o alcance da meta estratégica à qual ele se relaciona: quanto maior o
impacto, maior a pontuação.
Prazo – Avalia a duração, o cronograma de implementação, bem como o prazo

final de conclusão do projeto: quanto menor esse prazo, maior a pontuação.
Probabilidade de sucesso – Considera os riscos envolvidos no projeto para o

alcance dos resultados esperados: quanto menores os riscos, maior a pontuação.
Resultados a curto e médio prazo – Examina o tempo necessário para que o

projeto comece a gerar os resultados esperados: quanto menor o tempo, maior a
pontuação.
Situação de implementação – Investiga a situação atual do projeto, ou seja, o

seu percentual de implementação à época da definição e priorização dos projetos
estratégicos: quanto maior o percentual, maior a pontuação. Os projetos não
iniciados recebem pontuação zero.
FONTE: <http://www.cnj.jus.br/gestao-e-planejamento/492-gestao-planejamento-e-pesquisa/
gestao-e-planejamento/gestao-e-planejamento-do-judiciario/metodologia-de-gestao-de-
projetos/13735-criterios-sugeridos-para-priorizacao-de-projetos-estrategicos>. Acesso em: 3 out.
2018.
60
RESUMO DO TÓPICO 3
• O PMBOK define um conjunto de práticas, técnicas e processos para que os

profissionais de gestão de projetos possam ter um vocabulário comum dessa
área de conhecimento, bem como institui um conjunto de ações tidas como
“boas práticas” da área.
• O PMBOK não se constitui uma metodologia de gestão de projetos, mas sim

uma base de conhecimento comum.
• As áreas de conhecimento em gestão de projetos são um conjunto de conceitos,

termos e atividades que compõe o campo profissional de gestão de projetos, ou
seja, são áreas de especialização.
• O termo de abertura de projeto pode ser composto por um documento, ou um

conjunto de documentos.
• O início de um projeto ocorre pela insatisfação de uma pessoa, ou um conjunto

de pessoas, perante a situação atual que ela se encontra.
61
AUTOATIVIDADE
1 Preencha as frases a seguir a partir dos conceitos apresentados neste tópico:
No grupo de processo de __________ se encontram os processos

gerenciais que irão legitimar o projeto junto às partes interessadas que
originaram o projeto.
No grupo de processos de __________ é onde os pacotes de trabalho
serão executados pelas pessoas designadas.
O grupo de processos de __________ é o maior em termos de número
de processos e se destina a um esforço cognitivo para entender o projeto e
propor planos que corroboram com a execução das atividades que levarão ao
resultado desejado.
Já o grupo de processos de __________, se destina a averiguação e
comparação dos parâmetros do planejado versus os parâmetros obtidos pela
execução. A diferença entre esses dois parâmetros tem-se o nome de desvio.
O grupo de processos de __________ é basicamente a documentação
das lições aprendidas de projeto, bem como o repasse dos ativos gerados pelo
projeto para os responsáveis que irão usufruir ou utilizar daquele produto
final.
62
UNIDADE 2
PLANEJAMENTO DE PROJETOS
• elaborar cronogramas e estimativas de projeto;
• preparar a execução de um projeto;
• realizar a análise de riscos de projeto.
PLANO DE ESTUDOS
Esta unidade está dividida em três tópicos. No decorrer da unidade,
você encontrará autoatividades com o objetivo de reforçar o conteúdo
apresentado.
TÓPICO 1 – COMO DEFINIR O ESCOPO DO PROJETO?
TÓPICO 2 – COMO PLANEJAR O TEMPO E CUSTO DO PROJETO?
TÓPICO 3 – PREPARANDO PARA A EXECUÇÃO
63
64
UNIDADE 2
TÓPICO 1
COMO DEFINIR O ESCOPO DO PROJETO?
1 INTRODUÇÃO
O desenvolvimento do TAP – termo de abertura do projeto – é o primeiro
processo do ciclo de vida do projeto. Este é considerado o pontapé oficial,
confirmando que o projeto deve iniciar.
O termo de abertura do projeto, ao formalizar o início do projeto, concede

ao gerente de projetos a autoridade para aplicar os recursos organizacionais nas
atividades de desenvolvimento (PMI, 2013). Deste modo, o PMI (2013) elenca
alguns pontos que devem estar exemplificados no TAP:
a) Propósito e justificativa do projeto.

b) Objetivos mensuráveis do projeto.
c) Lista geral dos requisitos.
d) Descrição geral do projeto.
e) Lista geral do nível de riscos.
f) Resumo do cronograma de marcos.
g) Resumo do orçamento.
Na sequência é exemplificada a elaboração do TAP, assim como o processo

de entendimento desse documento pelo gerente de projeto.
2 INTERPRETANDO UM TERMO DE ABERTURA DE PROJETOS

Para um melhor entendimento da atividade de interpretação um termo
de abertura de projeto, será utilizado um exemplo prático desta situação.
Neste exemplo foi traçado como ação estratégica a abertura de novas filiais de
determinada loja, afim de aumentar a presença de mercado da empresa em
questão.
Neste sentido, o gerente de projetos recebe a demanda de uma equipe

estratégica. Essa equipe analisou toda a organização e seu contexto competitivo,
gerando um termo de abertura de projeto para cada ação estratégica que será
patrocinada, neste exemplo, a abertura de nova lojas, conforme a figura a seguir:
65
UNIDADE 2 | PLANEJAMENTO DE PROJETOS
FIGURA 1 – EXEMPLO DE TAP ELABORADA PELA EQUIPE DE PLANEJAMENTO ESTRATÉGICO
A partir deste TAP, é necessário que o gerente faça as análises necessárias

a partir de sua experiência em gerenciamento de projetos.
66
TÓPICO 1 | COMO DEFINIR O ESCOPO DO PROJETO?
3 ANÁLISE DO GERENTE DE PROJETO

Percebe-se que, apesar do bom trabalho executado em alto nível
estratégico, o TAP apresentado precisa ainda de uma análise do ponto de vista de
gerenciamento de projetos.
O primeiro ponto é a análise de stakeholders. Há uma lista de stakeholders,

mas não uma hierarquização de quais que devem ser levados em conta e em qual
nível de autoridade. Assim, o gerente de projeto pode usar um quadro, conforme
exemplo apresentado a seguir, e assim, esclarecer o nível de influência e interesse
de cada stakeholder.
QUADRO 1 – NÍVEL DE INFLUÊNCIA E INTERESSE DE STAKEHOLDERS

Nome do
Influência Cargo Interesse no projeto
stakeholder
5 Mário Silva Diretor comercial Alcançar suas metas de vendas
4 Vinicius Amaral Acionistas da Melhorar a competitividade da
Marcos Silveira empresa empresa
3 Evandro Menezes Diretor financeiro Observar retorno do

investimento
3 Thiago Magalhães Diretor de pessoas Melhorar o clima organizacional
1 Vitor Hugo Pessoas contratadas Ter ascensão na carreira
Carla Silva
Maria Moreira
2 Luiz Gustavo Fornecedores Ampliar seu mercado
Armando Souza
Vivian Amorim
1 Felipe Silva Clientes Conseguir comprar produtos de
Fernando Costa qualidade sem se deslocar
FONTE: O autor
Pontos de ambiguidades podem ser anotados como premissas de projeto

para posterior averiguação. Sempre que houver dúvidas, o gerente de projeto
deve anotar e formalizar. Seguem alguns exemplos:
1. Premissas:
• P1- Diretor comercial irá participar de reuniões de estruturação do plano de
projeto ao menos 2h por semana de reunião presencial ou videoconferência.
• P2- Apenas UMA loja será escopo desse projeto e as demais lojas terão projetos
específicos, dado que a meta é 20 lojas.
• P3- O recrutamento e seleção de pessoas não será escopo desse projeto, sendo
responsabilidade do diretor de pessoas.
• P4- O orçamento estará à disposição do gerente de projeto de forma integral no
início do projeto.
67
• P5- Existe um manual de padronização de lojas e o projeto não precisará criar

ou discutir essas normas.
• P6- A empresa está sem qualquer pendência jurídica e tributária para a emissão
do alvará na prefeitura.
• P7- O projeto não incluirá gerenciamento dos primeiros dias de vendas e
inauguração. A loja será entregue para a equipe comercial que imediatamente
gerenciará a inauguração e operação da loja.
Com essas premissas em vista, o gerente de projeto constrói uma estrutura

de escopo de alto nível de forma visual, apresentado na figura a seguir:
FIGURA 2 – ESCOPO – ALTO NÍVEL
Repare que as premissas acima são expostas de forma afirmativa, sempre

em favor de um projeto mais rápido e de baixo custo. Essas premissas devem ser
incorporadas no TAP e legitimadas pelo patrocinador do projeto. Caso ele não
concorde com alguma afirmação, deve editá-la de forma mais otimista ou mais
pessimista.
Exemplo 1:
Quando o gerente de projeto (GP) inicia o processo de legitimação do TAP,

o patrocinador não sabe se a diretoria de pessoas tem ciência dessa demanda de
novas contratações e nem sabe a prioridade disso na diretoria de pessoas. Assim,
solicita ao GP para alterar a premissa P3 para:
68
UNI
“O recrutamento e seleção de pessoas será o escopo desse projeto, sendo

responsabilidade do GP contatar o diretor de pessoas para averiguar como eles querem e
podem se envolver com o projeto”.
Reparem que o patrocinador quer adotar uma postura conservadora e

garantir que isso não seja um entrave para sua loja nova.
Exemplo 2:
Ainda durante a legitimação do TAP, o patrocinador entende que o

repasse da loja para a equipe comercial é sempre um processo tenso e gostaria
que a premissa P7 fosse alterada para:
“O projeto incluirá o gerenciamento dos primeiros dias de vendas e

inauguração”.
Com essas duas alterações, o GP também atualiza a estrutura visual de

escopo de alto nível do TAP, conforme a figura a seguir:
FIGURA 3 – ESTRUTURA DE ESCOPO ATUALIZADA
69
Como se pode observar nos exemplos acima, mesmo que a equipe de

estratégia tenha feito um bom trabalho, essas ambiguidades são naturais quando
chegam ao operacional do gerenciamento de projetos. Também se pode observar
a importância das premissas para esclarecer ambiguidades e discutir de forma
franca com o patrocinador do projeto, pois houve uma alteração substancial do
escopo do projeto com essas aparentes simples alterações.
O patrocinador poderia requerer mais tempo para a legitimação do

TAP, mas importante destacar que durante o gerenciamento de projetos haverá
inúmeras situações como essas e a cada caso de nova situação se o projeto entra
em stand-by, para termos certeza de uma informação, poderá postergar muito as
decisões e tornar o processo demorado.
Assim, recomenda-se assumir uma postura mais ou menos otimista

de projeto, documentar bem as premissas e seguir o processo. Até porque as
premissas serão gerenciadas como riscos de projetos e incorporadas nos planos.
4 ESTRUTURA ANALÍTICA DE PROJETO

O planejamento do projeto se inicia a partir da decomposição do seu
escopo em partes menores, que chamamos de pacote de trabalho. Estas partes
menores são ordenadas, quando possível, a fim de paralelizar estas atividades
para que seja possível estimar suas durações e custos (DINSMORE, 1999).
Apesar da aparente simplicidade dessa questão, muitos detalhes e

variáveis impactam positiva e negativamente na qualidade do planejamento.
Um ponto importante antes de esclarecer os procedimentos para realizar um
planejamento de projeto é ter em mente que um plano está sempre suscetível a
mudanças e a oportunidades de melhoria, uma vez que o plano é elaborado e está
proporcionalmente relacionado ao conhecimento que o gerente de projetos tem,
naquele momento, do projeto.
Costuma-se dizer, então, que o plano representa apenas um retrato

momentâneo das ações que serão realizadas, e que o ato de planejar é contínuo e
não somente em um determinado ponto do projeto.
O planejamento do projeto então, tipicamente, se inicia com a elaboração

da estrutura analítica de projeto, denominada EAP. A EAP, conforme a figura a
seguir, é a representação gráfica do projeto e apresenta a hierarquia de entregas,
sendo que no menor nível está o pacote de trabalho (PMI, 2013).
70
FIGURA 4 – EXEMPLO DE EAP
Essa decomposição em partes menores pode ser obtida de várias

maneiras, mas, geralmente, é decomposta com profissionais especialistas no
domínio do problema. Neste ponto, destaca-se que o gerente de projetos tem a
função de facilitador do projeto na decomposição e não necessariamente é dele a
responsabilidade de liderar o movimento.
Neste sentido, o gerente de projetos não tem a responsabilidade de

determinar qual é a melhor decomposição para as atividades de um projeto. Por
exemplo, caso seja realizado um projeto para a construção de um hospital, é de
suma importância que o gerente de projetos reúna engenheiros e profissionais
da área da saúde e outros especialistas para que consiga decompor o hospital em
suas partes constituintes.
Neste exemplo, o gerente de projetos não é responsável por determinar

toda a logística na gestão de um hospital, mas é dele a responsabilidade de
determinar quem são as pessoas que irão compor a equipe do projeto e quais as
técnicas que serão utilizadas para a elaboração desta atividade de criar a EAP.
A estruturação da EAP poderá durar muitas horas de esforço, ou até

mesmo meses, para sua conclusão, dependendo da complexidade do projeto. As
reuniões então são frequentes na vida do gerente de projeto para que ele consiga
apoiar os especialistas e chegar a uma estrutura analítica de projeto condizente
71
com os objetivos definidos, uma vez que a EAP serve de insumo para a elaboração
dos cronogramas, orçamentos e demais artefatos que compõe um planejamento
de projeto.
Há de se destacar então que a estrutura analítica de projeto é, depois do

termo de abertura de projeto, a mais importante entrega na gestão de projeto,
uma vez que todos os documentos de planejamento serão derivados da estrutura
analítica de projeto.
Outra forma de obter a estrutura analítica de projeto seria pela elaboração

do fluxo de processos de negócio que, uma vez estruturados e decompostos
serviram de base para a elaboração da EAP, conforme apresentado na figura a
seguir.
FIGURA 5 – EXEMPLO DE FLUXO DE PROCESSOS - 1
O mais importante na escolha das técnicas de construção da EAP é

justamente a sua associação aos objetivos de projeto. Muitas vezes, a equipe
de projeto decompõe a entrega em partes menores e tecnicamente adequadas,
porém, estas não estão associadas, suficientemente detalhadas ou não consideram
as características do projeto que interessaram os objetivos pelos quais o projeto
foi financiado.
Dessa forma, a principal missão do gerente de projeto é extrair

conhecimento técnico da equipe e manter o alinhamento com os objetivos pelos
quais o projeto foi financiado. Uma das formas práticas de não perder esse
72
alinhamento é se valer dos indicadores de desempenho explicitados no termo

de abertura de projeto e, realizar os fluxos de processos de negócios que tenham
saídas alinhadas e que sejam impactados nos indicadores de desempenho.
Então, se um dos objetivos do projeto é atender a uma comunidade para

alfabetizar 1000 adultos, o gerente de projeto terá que definir qual entrega que
aumentará o desempenho do projeto e alcançará o desempenho de alfabetização de
adultos. Nesse exemplo, seria a execução de aulas ou disciplinas de alfabetização
e, a principal saída seria o adulto alfabetizado. A figura a seguir apresenta o
exemplo em questão:
FIGURA 6 – EXEMPLO DE FLUXO DE PROCESSOS - 2
Nesse momento, o gerente de projeto deve definir qual a área de

conhecimento necessária para chegar ao resultado esperado e assim, poderá
definir um conjunto de pedagogos e representantes da comunidade para que
juntos definam a estrutura analítica de projeto.
Durante a reunião conjunta, os pedagogos podem argumentar ao gerente

de projeto que para alfabetizar alunos não basta simplesmente uma sala de aula.
Para o professor é importante ter infraestrutura, uma metodologia de ensino, a
sensibilização sobre importância da alfabetização para o desenvolvimento social
e, principalmente, uma divulgação do programa e do projeto para que consigam
alcançar seu objetivo.
Essas ações, então, podem ser ordenadas de forma sequencial para que
se consiga obter o conhecimento necessário para o desenvolvimento da estrutura
73
analítica de projeto, porém, as atividades não estarão no nível adequado para um

pacote de trabalho, por exemplo, a etapa de atividade de divulgação do projeto.
A etapa de divulgação do projeto pode ser também decomposta em

partes menores, sendo uma operação mais complexa com várias horas de
esforço, envolver várias pessoas e sistemas de informações. Nesse momento,
existe a necessidade de desdobrar essa atividade em partes menores, porém a
equipe do projeto alfabetização (pedagogos) que participaram do primeiro nível
de decomposição da EAP talvez, nesse quesito de divulgação do projeto, não
tenham conhecimentos e habilidades suficientes para detalhar o projeto de uma
forma precisa.
O gerente de projeto deve então observar que podem existir outras áreas
de conhecimento que irão contribuir na decomposição. Dessa forma, poderá
então definir profissionais de marketing digital e de associações de bairro
da comunidade para que consigam juntos compor uma divulgação virtual e
presencial de forma efetiva.
Todavia, o desdobramento em partes menores pode durar várias horas,

várias reuniões com áreas de conhecimento distintas. É de suma importância
determinar quando esse desdobramento irá se encerrar.
Não existe uma maneira objetiva de determinar a granularidade quando

um pacote de trabalho irá ser desdobrado, pois este depende da percepção do
gerente do projeto e, principalmente, do conhecimento adquirido para que ele
consiga elaborar os seus planos de trabalho em conjunto com a equipe. No entanto,
existe uma premissa de mercado em que os pacotes de trabalho não podem ser
inferiores a quatro horas e superiores a quarente horas.
Se o pacote de trabalho foi desdobrado em partes menores do que quatro

horas, existirão muitas atividades de projetos a serem controladas e gerenciadas,
o que torna o trabalho do gerente de projeto bastante desgastante e árduo. Outro
ponto importante é referente a pessoa que está executando o pacote de trabalho,
talvez ela levará muito mais tempo reportando quanto custou cada atividade,
qual a duração e quais são as próximas atividades a serem realizadas, perdendo
assim autonomia profissional. Ou seja, pacotes de trabalho menores do que
quatro horas geram um desgaste gerencial desnecessário e não trazem benefícios
para o projeto.
Já pacotes de trabalho acima de quarente horas dão autonomia para a

equipe, porém, o gerente de projeto pode levar muito tempo para detectar que
um determinado profissional ou a equipe está com problemas ou com falta de
entendimento sobre a atividade que está sendo executada. Com isso, o gerente
pode perder o controle sobre o projeto, ter retrabalhos ou detectar problemas de
uma forma tardia.
74
Por causa dessas condições é que existe essa heurística de pacote de

trabalho entre quatro e quarente horas. Obviamente que nesse momento ainda
não temos o processo de estimativa, então por isso é uma heurística.
A regra de 4-40 poderá ser aplicada para 8-80. Ou seja, o pacote de trabalho
é definido entre 8 e 80 horas, porém cabe destacar que esses números, tanto de
4-40 como de 8-80, não são números científicos, simplesmente são palpites iniciais
para que o gerente do projeto consiga determinar qual é o valor a ser usado para
seu projeto em específico.
Em geral, para projetos de muito risco e incertezas, o ideal é o pacote de

trabalho de pouco esforço (4-40 horas), tendo ciclos mais curtos de iterações. Em
projetos com ampla base histórica, usam-se pacotes de trabalho maiores, dando
mais autonomia à equipe, uma vez que já se sabe o que deve ser feito e quais as
formas de contornar certas situações.
Desse modo, uma vez determinada a estrutura analítica de projeto,

o gerente de projeto ganha mais confiança para iniciar os demais planos. É de
se destacar, que a primeira versão da EAP não precisa ser a versão totalmente
detalhada e nem com todos os seus pacotes de trabalho, pois certas entregas da
EAP podem necessitar de experimentações para saber a melhor forma da sua
decomposição.
Esses experimentos são típicos de projetos de inovação, em que há muita

incerteza e ausência de conhecimento suficiente para saber a melhor forma ou
pelo menos uma forma factível de executar uma determinada atividade, portanto,
para aqueles ciclos de vida iterativos, é normal que certas partes da EAP estejam
detalhadas e outras partes ainda com grandes blocos de resultados de projeto que
serão decompostos futuramente.
Dessa maneira, o gerente de projeto pode iniciar uma iteração para que
consiga realizar experimentos e pesquisas de campo com o objetivo de decompor
o projeto e, com mais brevidade possível, conseguir minimizar os riscos da
incerteza de um projeto.
Para a atividade de decomposição do escopo em pacotes de trabalho, o

GP pode iniciar com a decomposição da estrutura legitimada pelo patrocinador e
realizar reuniões com especialistas ou análise de documentação.
75
EXEMPLO
Retomando o exemplo da construção de uma nova filial de uma loja, o
gerente de projetos inicia então a construção da EAP. A partir do TAP e da base
histórica que a empresa possui, o gerente de projetos identifica as principais etapas
do projeto e solicita a ajuda de alguns especialistas em cada área de conhecimento
para a definição dos pacotes de trabalho.
FIGURA 7 – EXEMPLO EAP – ALTO NÍVEL
Para a estrutura física, foram selecionados arquitetos e engenheiros

civis (especialistas). Deste modo, foram identificados os pacotes de trabalho
apresentados na figura a seguir.
76
FIGURA 8 – ESTRUTURA FÍSICA: PACOTES DE TRABALHO
77
Para o layout da loja, será seguido o manual de lojas, com ampla base
histórica (documental), apresentados na figura a seguir:
FIGURA 9 – LAYOUT: PACOTES DE TRABALHO
Para a parte jurídica, serão usados os procedimentos descritos no site da

prefeitura e site de bombeiros (documental), conforme figura que segue:
FIGURA 10 – JURÍDICO: PACOTES DE TRABALHO
78
Por fim, para as atividades relacionadas às pessoas foram selecionados

dois profissionais da área da empresa (especialistas), que identificaram os pacotes
de trabalho demonstrados na figura a seguir:
FIGURA 11 – PESSOAS: PACOTES DE TRABALHO
79
Desta forma, a partir do auxílio de especialistas e da documentação

disponibilizada pela empresa, o gerente de projetos pôde identificar de forma
assertiva as etapas, pacotes de trabalho e entregas que serão realizadas ao longo
do projeto.

A partir dessa definição, passa-se, então, ao sequenciamento de atividades
e às estimativas de projeto, assuntos estes abordados no tópico subsequente.
80
RESUMO DO TÓPICO 1
• A partir da elaboração do TAP, o gerente de projetos se dedica à análise deste

documento, identificando o nível de influência de stakeholders, ambiguidades
e premissas acerca do projeto.
• As premissas do projeto devem ser incorporadas no TAP e legitimadas pelo

patrocinador do projeto. Caso ele não concorde com alguma afirmação, deve
editá-la de forma mais otimista ou mais pessimista.
• O planejamento do projeto se inicia a partir da decomposição do seu escopo

em partes menores, que chamamos de pacote de trabalho.
• A EAP é a representação gráfica do projeto, apresenta a hierarquia de entregas,

sendo que no menor nível está o pacote de trabalho.
• A estrutura analítica de projeto é, depois do termo de abertura de projeto, a mais

importante entrega na gestão de projeto, uma vez que todos os documentos de
planejamento serão derivados da estrutura analítica de projeto.
81
AUTOATIVIDADE
1 Você foi designado como gerente de projetos para a realização de uma festa
de formatura. Faça a proposição de um TAP para esse projeto.
2 Construa uma EAP do projeto da festa, com mínimo de três níveis

hierárquicos e no mínimo dez pacotes de trabalho.
82
UNIDADE 2 TÓPICO 2
COMO PLANEJAR O TEMPO E O CUSTO DO PROJETO?
1 INTRODUÇÃO
Uma vez estabelecidos os componentes que formarão o escopo do projeto,
passa-se então à atividade de organização desses componentes de uma forma
lógica.
O próximo passo é a ordenação dos pacotes de trabalho, em que se

procura identificar as atividades que serão realizadas primeiro e aquelas que
serão deixadas mais para o final do projeto, o que chamamos de sequenciamento
de atividades (PMI, 2013).
Logo depois são realizadas as estimativas de projeto, que na verdade, são

estimativas do conjunto de atividades identificadas como pacotes de trabalho
dentro da etapa de estrutura analítica de projeto. Estes assuntos serão abordados
nas seções subsequentes.
2 SEQUENCIAMENTO DE ATIVIDADES
Existem muitas maneiras de realizar o sequenciamento de atividades,
mas essa ordenação dependerá do ciclo de vida adotado no projeto, conforme
se observou na Unidade 1. Como método básico de priorização, utilizam-se
dependência lógica, valor agregado aos objetivos do projeto e risco.
FIGURA 12 – FATORES DE INFLUÊNCIA NA PRIORIDADE DE ATIVIDADES
FONTE: Adaptado de Cruz (2017)
83
No tocante de precedência, as atividades podem ser organizadas pelas

atividades que têm uma dependência entre si, por exemplo, para se contratar
professores para o projeto educacional é necessário, como atividade anterior,
descrever o perfil desse profissional, as habilidades, competências e atitudes
desejadas.
Desse modo existem quatro formas de identificar dependência de

atividades (CUKIERMAN, 1977), porém a maioria dos casos recai sobre a
dependência do tipo “terminar para iniciar” (FTS – Finish to Start), que se baseia
no sentido de que uma atividade tem que ser encerrada para que a subsequente
possa ser iniciada.
FIGURA 13 – DEPENDÊNCIA "TERMINAR PARA COMEÇAR"
Essa é a dependência mais clássica e mais utilizada no gerenciamento de

projetos. Pode-se dizer até que, para projetos de baixa e média complexidade,
somente esse tipo de dependência é suficiente.
Existem ainda outros três tipos de dependências que podem ser utilizadas
pelo gerente de projetos em casos específicos. Em casos em que uma atividade tem
que ser encerrada obrigatoriamente junto com a outra, ou seja, uma dependência
de duas atividades em que uma deve ser concluída com a outra (FTF – Finish to
Finish).
FIGURA 14 – DEPENDÊNCIA "TERMINAR PARA TERMINAR"
O terceiro tipo de dependência se caracteriza em uma atividade que deve

ser obrigatoriamente iniciada junto com outra atividade, ou seja, quando uma
começa a ser executada, a outra também obrigatoriamente tem que ser executada
(STS – Start to Start).
84
TÓPICO 2 | COMO PLANEJAR O TEMPO E O CUSTO DO PROJETO?
FIGURA 15 – DEPENDÊNCIA "COMEÇAR PARA COMEÇAR"
Por fim, o quarto tipo de dependência se refere à atividade que precisa ser
iniciada para que a outra seja encerrada (STF – Start to Finish).
FIGURA 16 – DEPENDÊNCIA "COMEÇAR PARA TERMINAR"
Conforme observado, os três últimos casos de dependência entre as

atividades são até difíceis para se dar exemplos. Lembramos que um gerente de
projeto pode usar durante sua vida profissional somente a dependência “encerrar
para iniciar” como dependência que resolverá com certeza a maioria dos seus
problemas práticos.
Outro ponto a se destacar é: dependências devem ser utilizadas quando

existe uma obrigatoriedade entre as atividades e não como forma de melhorar o
entendimento do projeto ou otimizar o uso de um determinado recurso, seja esse
humano ou material.
Por exemplo, um erro comum é que as dependências sejam determinadas

a partir de uma visão de equipe como, criar dependência de atividades que serão
executadas supostamente por um mesmo membro da equipe. Essa prática não é
recomendável uma vez que não há uma dependência entre as atividades e sim
uma limitação de recursos, neste caso, humano. Caso o gerente de projetos consiga
mais pessoas para trabalhar no projeto, as atividades poderiam ser executadas
em paralelo, deixando claro que a dependência não está nas atividades, mas sim
em função de uma lógica que o gerente de projeto adota para seu projeto.
O segundo critério para priorização de atividades é a agregação de valor

para os objetivos do projeto de um conjunto de atividades. A melhor forma de
entender esse tipo de critério é por meio de, primeiramente, a determinação dos
marcos do projeto. Ou seja, os pontos de relevância na linha do tempo do projeto,
em que se observa uma entrega relevante para o alcance dos seus objetivos.
85
Isso ocorre por meio do entendimento dos objetivos de projeto e como

esses agregam valor. Os marcos do projeto podem ser determinados de uma
forma genérica, mas, é de suma importância que o gerente de projeto também
construa marcos de projetos específicos ao projeto em questão e ao seu contexto
organizacional e não somente replicar marcos de modelos já existentes que
poderão fracassar para o seu projeto.
Alguns exemplos de marcos relevantes e específicos de um determinado

projeto são: quando a fundação de um prédio é realizada, quando o acabamento
de uma obra é executado, quando o chassi e o motor do carro estão acoplados,
quando são executados os testes funcionais de um sistema e quando uma versão
importante de um produto é entregue ao cliente.
Apesar dos exemplos acima, em contextos genéricos ou específicos de cada

projeto, geralmente, os marcos são determinados pelo conjunto de atividades que
deixarão os usuários e stakeholders mais contentes com o avanço do projeto. Este
fator é de suma importância, não só pela felicidade do patrocinador, mas também
pela moral da equipe.
Caso a equipe não sinta que esteja contribuindo para a melhora de um

determinado contexto, poderá perder a motivação e gerar insatisfação de não
der parte do seu tempo para algo útil, gerando, desta forma, certa indiferença da
equipe e um distanciamento do usuário.
Diante disso é importante que o gerente de projetos consiga elaborar uma

linha do tempo de entregas que sua equipe possa observar por si só quão relevante
o projeto é para seus usuários e stakeholders. Manter também uma relação contínua
e estreita com os usuários é fator crítico de sucesso para qualquer projeto.
As definições de marcos relevantes contribuem para que o projeto tenha

uma constante relação de comunicação com os usuários, gerando então um
processo positivo de entregas e feedbacks com a finalidade de constantemente
identificar formas de aperfeiçoar a gestão do projeto. Esta composição de marcos
é subdividida em iterações ou sprints de projetos. Estas iterações são fragmentos
do tempo, mais curtos que os macros de projetos, mas que trazem uma entrega
representativa para equipe e para os usuários (COHN, 2000).
Não existe um prazo exato para determinação das iterações, recomenda-

se algo em torno de duas semanas, ou seja, a cada duas semanas a equipe irá
apresentar aos usuários uma entrega parcial do projeto, que representa um avanço
contínuo rumo ao final bem-sucedido. Essa organização pode ser obtida pelo uso
de uma linha do tempo em que se dispõe os marcos do projeto, as iterações e as
entregas das atividades. Ressalta-se que o mais importante são os marcos. Após
esses marcos as iterações e somente com a determinação desses elementos de
progresso é que se buscam as atividades que farão que essa entrega seja positiva.
86
Neste sentido, busca-se primeiro o que precisa ser feito e depois, como
esse objetivo será alcançado. Os objetivos são representados por perguntas ou
indicadores, e os meios indicados pelas atividades de projeto.
O terceiro elemento de priorização de atividades de projeto é o fator de

risco do projeto e de suas atividades. Quando conseguimos estimar o esforço
de uma atividade, seu tempo e como ela deve ser executada, estamos pensando
em atividades de baixo risco e podem ser executadas o mais tarde possível no
cronograma (SALLES, 2006).
Por outro lado, as atividades em que as estimativas da equipe de projeto

não estão seguras e não há um consenso de como aquela atividade será executada,
essas atividades devem ser controladas, e identificadas como de alto risco.
Assim as atividades de alto risco devem ser geralmente executadas mais

próximas do ponto inicial do projeto e por consequência as atividades de baixo
risco podem ser executadas mais próximas do final, pois existe pouca chance de
surpresas indesejáveis.
Uma vez detalhados os três aspectos que levaram à priorização das

atividades humanas, o gerente de projetos deve tomar uma decisão importante,
harmonizar o critério de valor ao cliente e objetivo do projeto com os critérios de
dependência e fator risco.
Essa decisão não é adequada por meios estatísticos e precisarão ser

avaliadas segundo os valores e preferências do gerente. É nesse momento que
a experiência faz diferença ao gerente de projetos, bem como o conhecimento e
domínio do problema, seja ele tecnológico ou um negócio.
Como dica geral, recomendam-se primeiro as atividades de maior risco,

depois as de alto valor agregado e por fim, adequar as dependências lógicas. Mas
cada projeto, é um projeto diferente e essa ordem pode ser alterada.
EXEMPLO
Dada a lista de pacotes de trabalho exposta no tópico anterior (Figura 7),
podemos organizar os pacotes de trabalho usando primeiramente o critério de
dependência. Após essa análise, podemos aperfeiçoar a priorização, acrescentando
os critérios de riscos e agregação de valor ao projeto.
Sob a ótima apenas da dependência, o projeto poderia ser organizado

conforme a figura a seguir.
87
FIGURA 17 – SEQUENCIAMENTO DE ATIVIDADES - 1
Todavia, o gerente de projetos observa que para iniciar a seleção de

fornecedores e firmar os contratos que estão presentes dentro do escopo de layout,
esta atividade deve ser executada antes do prédio da loja física estar pronto. Essa
análise também pode ser observada sob a ótica de riscos, pois terminar a parte
física e só a partir desse momento, procurar por fornecedores pode aumentar os
riscos do projeto.
O gerente de projetos decide então definir que a atividade de construção do

prédio da loja deve iniciar juntamente com a atividade de seleção de fornecedores
que estão presentes dentro do escopo de Layout. Deste modo, as atividades têm
a relação de INICIAR para INICIAR. Ou seja, assim que iniciar o prédio da loja
física, pode-se executar a parte de fornecedores e contratos do layout da loja.
Assim, o gerente de projetos estabelece um novo diagrama de

sequenciamento de atividades do projeto, conforme observa-se na figura a seguir.
FIGURA 18 – SEQUENCIAMENTO DE ATIVIDADES - 2
88
Com essa linha geral, pode-se criar diagrama de precedência detalhados

para cada item da figura anterior. Na figura a seguir está o diagrama de
precedência da loja física.
FIGURA 19 – DIAGRAMA DE PRECEDÊNCIAS: PRÉDIO LOJA
3 ESTIMATIVAS DE PROJETO
As estimativas de projeto são, na verdade, as estimativas do conjunto de
atividades identificadas como pacotes de trabalho dentro da etapa de estrutura
Existem muitas técnicas para estimar o esforço e o tempo de projetos,

porém é importante mencionar que nenhuma técnica é definitiva. Ou seja, as
estimativas de projeto são suposições que o gerente de projeto realiza para que
consiga elaborar um plano e acompanhar a execução.
Um erro comum de gerentes de projetos iniciantes é o esquecimento de

que essa estimativa é uma suposição. Assim, após as estimativas, elaborados
planos de trabalho, cronograma e atualizados os softwares de apoio à decisão, as
estimativas são tidas pelos stakeholders, e pelo próprio gerente de projeto, como
verdades absolutas. Ou seja, caso haja um desvio dessas estimativas durante a
execução, logo se deduz que o problema está na execução, porém essa premissa é
um erro clássico em gerenciamento de projetos.
Muitas vezes, o gerente e a equipe de projeto precisam estimar os projetos

sem todas as informações possíveis. Na verdade, essa situação de trabalhar com
informações incompletas é quase regra em projetos, pois os stakeholders querem
o mais brevemente possível um plano fechado para conseguir tomar a decisão do
seu financiamento ou não.
89
Assim, elaborando um pensamento que a estimativa é uma suposição e

que existe a certeza de uma pressão para entregar os planos o mais brevemente
possível, é importante mencionar que, caso haja um desvio do planejado, esse
pode ser um problema de execução sim, mas também pode ser um problema de
estimativas com um processo sem um aprofundamento ideal.
Obviamente, um gerente de projeto solicita aos stakeholders um prazo

adequado para o planejamento, mas essa tensão entre stakeholders e gerente de
projeto deve ser entendida como uma certeza e o gerente precisa lidar com essa
situação que é real, e o ideal quase nunca acontecerá.
Dessa maneira, é importante no início do planejamento, durante as

estimativas e principalmente na formalização de cronograma, orçamento e demais
planos de trabalho, que os stakeholders sejam ostensivamente comunicados que as
estimativas são baseadas em pressupostos.
Alguns pacotes de trabalho possuirão um nível de certeza maior, e outros

pacotes de trabalho possuirão o nível de incerteza bastante elevado, pois existirá a
ausência ou limitação do conhecimento da equipe e do gerente em como resolver
essa situação, enquanto existe a pressão dos stakeholders para ter um plano fechado
com estimativas bem precisas.
Como podemos observar ao longo desse livro, é importante destacar que
o planejamento é um contínuo exercício de expansão de conhecimento no gerente
de projeto e na sua equipe sobre os objetivos e alternativas possíveis para sua
execução. Obviamente, se deseja trabalhar com certezas para que consigamos
elaborar planos com nível de desvio bem baixo, o que é muito comum em projetos
que tenham ampla base histórica.
Na execução de projetos com ampla base histórica, o gerente de projeto

obviamente pode fazer uma estimativa baseada no passado, ou seja, identificar
quanto levou cada um desses projetos já realizados em termos de prazo e custo.
Essas estimativas são confiáveis e terão desvios baixos devido à eventos pouco
prováveis.
Esse tipo de estimativa é chamado de estimativa paramétrica, que são

esforços estimados pela sua relação de uma entrega física, como o metro quadrado
numa construção civil, o metro linear na construção de um muro. Deste modo,
ressalta-se que estimativas paramétricas são confiáveis desde que exista um
conjunto de eventos passados em que se possa tomar uma decisão.
Como podemos observar, esses exemplos são factíveis desde que você
consiga traçar uma relação paramétrica entre o tamanho do projeto mensurado
por um indicador físico, como metro quadrado, e funcionalidades de um produto
com a relação de esforço obtido em situações passadas.
90
Existem outras variáveis que podem compor o processo de estimativas

de projeto como variáveis ambientais e variáveis técnicas. Por exemplo, uma
equipe recém-treinada sem muita experiência ou a construção de uma casa que
está em uma inclinação relevante e que não foi realizada no passado. Esses tipos
de variáveis podem tornar o projeto mais complexo ou podem tornar o projeto
mais simples, sendo então variáveis técnicas ou variáveis ambientais, que são
multiplicadores do resultado final de estimativa.
Já em projetos em que não dê para fazer essas relações de entrega física

versus o esforço obtido no passado, a abordagem paramétrica perde sua utilidade.
Por exemplo, em situações nas quais não há base histórica confiável, ou seja, os
projetos passados não foram encerrados com um relatório de lições aprendidas
sobre o que foi entregue e ou quanto esforço foi despendido para as atividades
desenvolvidas.
Isso é muito comum em organizações que não têm a visão da importância

de gestão de projetos. Pode até planejar, porém a execução é realizada de uma
maneira muito artesanal, sem a coleta de dados de apontamentos diários ou
semanais da equipe sobre quanto tempo foi gasto para cada pacote de trabalho.
Sem essas informações, se torna impossível o uso de técnicas paramétricas, pois
não haverá base histórica.
Já no contexto de projetos de desenvolvimento de produtos, principalmente

os que tenham alto índice de inovação, não é possível o uso de base histórica, uma
vez que o produto será realizado pela primeira vez e talvez a única. Uma técnica
bastante difundida no mercado de trabalho é a consulta por especialistas.
Esta técnica se caracteriza pela apresentação dos pacotes de trabalho

a uma pessoa com grande experiência no domínio do problema do projeto, e
neste caso, este especialista pode votar em quanto tempo durará cada pacote de
trabalho.
Obviamente, esse tipo de estimativa dependerá não só do grau de

experiência da pessoa, mas também do quanto aquele pacote de trabalho está
especificado. A especificação de um pacote de trabalho é necessária para saber se
a estimativa será mais conservadora ou mais arriscada.
Imagine um pacote de trabalho de uma simples colocação de um piso

cerâmico. Para esse pacote de trabalho, um profissional júnior poderia supor
que a distância chamada “fuga” entre as peças cerâmicas pode ser executada por
separadores de piso cerâmico, ou seja, a forma mais usual de colocação de um
piso o que demoraria um valor x de tempo para sua colocação. Porém, depois
da estimativa e durante a execução percebe-se que na verdade o stakeholder não
gostaria daquele piso cerâmico, mas sim de um piso de porcelanato, que exige
instrumentos e cuidados maiores que o piso cerâmico tradicional, demandando
mais tempo do que o previsto para sua colocação.
91
Dessa maneira, sem uma especificação adequada, somente com o título

do pacote de trabalho, o especialista que realiza a estimativa pode ser levado
a suposições sem uma explicitação do que caracteriza aquela sua estimativa.
Usando essa abordagem sem uma especificação minimamente adequada, é quase
certo que o gerente de projeto e sua equipe enfrentarão grandes dificuldades e
desvios de projeto. Deste modo, gera-se uma insatisfação no stakeholder, uma vez
que as estimativas já foram formalizadas e não houve o cuidado de explicitar as
especificações ou a suposição por trás daquela estimativa.
Assim, o uso de especialistas para estimativas pode ser usado em projetos,

porém, é importante que o gerente de projeto faça questionamento ao especialista
a cada pacote de trabalho: “Qual é a suposição que deve ser verdade para que aquela
estimativa possa ser honrada?”
Ou seja, no caso da colocação de piso, o gerente de projeto poderá falar

que levará uma hora para cada 3m² de pisos colocados, desde que este seja do
tipo x, y ou z. Assim, no momento da formalização das estimativas, o stakeholder
pode aprovar não só a duração, o esforço e o custo daquelas atividades do pacote
de trabalho, mas também identificar se realmente as premissas estão corretas. No
futuro, caso o stakeholder queira mudar as especificações, não será tratado como
um desvio das estimativas, mas sim, uma solicitação de mudança de projeto.
Outra alternativa que dê mais confiabilidade ao processo de estimativas

de projeto é o uso da técnica Delphi. A técnica Delphi consiste em usar não
somente um especialista, mas um conjunto de especialistas para que consiga
gerar um entendimento maior, não só na atividade de estimativas, mas também
nas especificações do projeto (MORICOCHI et al., 1995).
Essa técnica é bastante poderosa para a elucidação de incertezas e pontos

obscuros do projeto que precisam ser especificados melhor. A técnica se baseia em
uma lista de pacotes de trabalho e, com suas especificações disponíveis naquele
momento, o gerente de projeto distribui uma lista de pacotes de trabalho aos
especialistas de forma individual a cada especialista.
Então, de uma forma isolada, o especialista é solicitado a gerar o esforço

para cada pacote de trabalho, porém, é de suma importância que o especialista
também consiga elaborar uma proposta de especificação. Ou seja, o especialista
tem que ser proativo em explicitar o racional que ele usou por trás daquele valor
de esforço.
Por exemplo, em um pacote de trabalho para instalar o sistema de alarme

em uma casa, o especialista poderá estimar oito horas de trabalho, com a premissa
de que as instalações elétricas e telefônicas já estejam previamente prontas e
todos os fios passados pelas tubulações para tal fim. Já um outro especialista
poderá estimar quarente horas de esforço para essa mesma atividade, porém,
ele assumiu a premissa de que também vai ter que passar todos os fios elétricos e
telefônicos até cada ponto de câmeras e sensores de alarme, bem como a central
de alarme da casa.
92
Desta forma, qual o especialista tem razão nessa situação? Neste sentido,
o próximo passo da técnica Delphi é o confronto das estimativas, o gerente de
projeto faz de maneira isolada uma comparação do nível de esforço de cada pacote
de trabalho. Obviamente, para aqueles pacotes de trabalho em que não existam
uma grande dispersão dos valores de esforço, o gerente de projetos pode arbitrar
o valor de esforço do seu projeto, podendo ser mais otimista ou pessimista.
Porém, no exemplo de instalação do sistema de alarme da casa existe

uma grande dispersão entre 8 e 40 horas de trabalho, um especialista afirma que
é possível terminar em um dia e outro especialista informando ao gerente do
projeto que precisa de uma semana para executar aquele pacote de trabalho.
Nas situações em que haja uma grande dispersão entre as estimativas, o

gerente do projeto convoca para uma reunião, agora sim presencial e com todos
os especialistas, para que estes consigam defender o seu ponto de vista usando as
premissas de trabalho. Então, nesse momento, o gerente do projeto informará aos
stakeholders que a estimativa se baseia em uma premissa e estes poderão assumir
essa premissa como verdade.
FIGURA 20 – EXEMPLO TÉCNICA DELPHI
Nesta situação, o gerente de projeto poderá então criar um novo pacote

de trabalho com a atividade de passar todos os fios telefônicos e elétricos na
casa e, um outro pacote de trabalho, somente para a instalação e configuração
dos alarmes. Dessa maneira, e nesse exemplo simples, pode-se observar o poder
de esclarecimento que tem a técnica Delphi desde que haja pacote de trabalho
especificado.
Nos casos em que haja uma grande dispersão dos esforços entre os
especialistas, o gerente de projeto poderá fazer novas rodadas de estimativas.
Essas rodadas de estimativas e de novos pressupostos feitos pelos especialistas
é realizada a cada pacote de trabalho e até que o gerente de projeto tenha a sua
confiança em elaborar um plano com aquelas informações dos especialistas.
93
Apesar das vantagens presentes na técnica Delphi, a questão do tempo

para realizar as reuniões com os especialistas se torna uma desvantagem para a
aplicação da técnica. Ou seja, o tempo de planejamento é obviamente superior ao
da técnica paramétrica ou da consulta de um especialista somente.
Assim, o gerente do projeto pode compor um determinado conjunto

de pacotes de trabalho onde utilizar a técnica, ou seja, para aqueles pacotes de
trabalho em que haja base histórica, ele poderá se valer da técnica paramétrica.
Quando não existe base histórica, pode-se optar para a técnica Delphi nos pacotes
de trabalho críticos e de alta relevância para o projeto. Já para pacotes de trabalho
de menor importância, podem ser utilizadas estimativas mais rápidas, como a de
um especialista.
Gerentes de projeto em formação ou iniciantes podem supor que a técnica

Delphi deve ser usada para todos os pacotes de trabalho, porém, no dia a dia a
pressão para elaborar planos de cronogramas é alta, e, muitas vezes, a equipe
já está alocada. A equipe do projeto precisa trabalhar, então é importante que
os jovens gerentes de projeto entendam que o ótimo é inimigo do bom, e que
muitas vezes não será possível alcançar a excelência e o ideal dentro de cada
planejamento.
Então, se faz necessário lembrar sempre de separar poucas atividades de

muita relevância, em que terão um planejamento mais elaborado e ostensivo.
Já nas atividades de baixo risco e que não impactam drasticamente no projeto
podem ser utilizadas técnicas menos elaboradas e com menos precisão.
EXEMPLO
O gerente do projeto precisa estimar o esforço envolvido com o projeto,
porém diferentes pacotes de trabalho podem requerer diferentes métodos de
estimativa.
Por exemplo, para os pacotes de trabalho relativos à colocação de piso,

pode-se usar um método paramétrico. O gerente busca na base histórica e
encontra documentação de um projeto encerrado de uma loja física de 100m². Na
documentação desse projeto passado, essa etapa consumiu 5 pessoas 8 horas por
dia durante 10 dias de trabalho. Assim, observa-se um esforço de 400 horas de
trabalho para 100m². Por dedução, precisa-se 4h por m² para concluir os pacotes
de trabalho de piso.
Dado que a loja do projeto atual é maior e tem 300m2, o gerente de projeto
estimou então 1200 horas de trabalho para os pacotes de medições do piso,
colocação do piso e ajustes dos recortes.
94
Essa estimativa foi possível, pois existia base histórica e um parâmetro

replicável (m² com o mesmo piso). Todavia, caso não haja base histórica ou
critérios replicáveis, o método paramétrico não fará sentido.
Um exemplo sem base histórica é a parte do projeto que contempla como

é a formação da equipe (pessoas) que vai fazer parte da loja. Apesar da empresa
ter uma base histórica de contratações passadas, elas foram realizadas em capitais
e cidades grandes, o que não é realidade nessa cidade. Nesse contexto, o gerente
do projeto prefere usar a técnica Delphi com o departamento de gestão de pessoas
para estimar o esforço envolvido.
Após realizada a primeira rodada, os resultados são apresentados no

quadro a seguir:
QUADRO 2 - APLICAÇÃO DA TÉCNICA DELPHI 1° RODADA
A primeira rodada da técnica Delphi apresentou a estimativa dos três

especialistas em RH da empresa. Eles foram obtidos de forma individual, ou seja,
não houve reunião para que eles conversassem ou tirassem dúvidas entre si.
Analisando os dados obtidos na primeira rodada de estimativas, reparou-

se que três pacotes de trabalho tinham uma divergência que mereciam uma nova
rodada: definição de papéis, banco interno e agendamento de entrevistas. Repare
que outros pacotes tinham divergência, mas o gerente de projeto entendeu que
a dispersão não compensaria outra rodada. Assim, o gerente de projeto assumiu
uma estimativa mais pessimista e passou adiante os três pacotes de trabalho que
poderiam apresentar algum aspecto novo que interferisse na gestão do projeto.
Neste sentido foi realizada a segunda rodada, com os resultados conforme

o quadro a seguir:
95
QUADRO 3 – APLICAÇÃO DA TÉCNICA DELPHI 2° RODADA
Com a reunião de avaliação dos motivos das dispersões o GP descobriu

alguns fatos novos, como as premissas de cada especialista apresentadas no
quadro que segue:
QUADRO 4 – PREMISSAS DOS ESPECIALISTAS
Na definição de papéis, o gerente descobriu que o pacote de trabalho

nem sequer é um pacote de trabalho, pois provavelmente se resolva em troca
de e-mails. No banco interno, não precisará abrir edital interno de vagas, uma
vez que os colaboradores já manifestam sua intenção em aceitar progressão por
transferência. E no agendamento de visita, o gerente de projeto propôs uma
solução intermediaria.
Dessa maneira, os resultados da segunda rodada ficaram como no quadro

que segue:
96
QUADRO 5 – TÉCNICA DELPHI: RESULTADO FINAL
3.1 TRABALHO/ ESFORÇO OU DURAÇÃO DA ATIVIDADE?

No tópico de estimativas, observaram-se três técnicas muito utilizadas pelo
mercado de trabalho para a composição de planejamento. Foi destacado que os
valores arbitrados nesse ponto das estimativas são esforços ou valores de trabalho
que deverão ser dispensados para a conclusão de uma atividade. Todavia, esses
valores não indicam a duração da atividade, pois a duração é uma resultante do
esforço com a agenda de trabalho de um profissional que irá executar a atividade.
Como exemplo vamos supor que um pacote de trabalho pode dispensar 8

horas de esforço para sua conclusão. Alguns podem supor que 8 horas é um dia
de trabalho, porém, apesar de existir a simplificação da jornada de trabalho de
um profissional em 8 horas diárias, essa informação não se aplica a todos.
Esse profissional, com esse pacote de trabalho, pode ter um acordo com a
empresa de só trabalhar de manhã, por exemplo. Deste modo, perfazendo 4 horas
diárias, assim esse pacote de trabalho de 8 horas de esforço durará na verdade,
em termos de tempo, dois dias de trabalho.
Também é importante identificar os dias de folga da equipe, geralmente

sábado e domingo. Então imaginamos esse mesmo pacote de 8 horas, e que o
profissional só trabalha uma hora por dia. Desse modo, este pacote de trabalho
levará 10 dias corridos para sua conclusão, sendo 8 dias úteis e dois dias de folga.
Nesse exemplo podemos observar que um pacote de trabalho de 8 horas

pode ser estimado em termos de prazo, em um dia, dois dias ou até 10 dias,
dependendo da jornada de trabalho daquele profissional que irá executar.
4 PLANEJANDO A EQUIPE DO PROJETO

A gestão de projetos é uma atividade basicamente social, ou seja, é uma
atividade executada por pessoas e, dessa maneira, a gestão e elaboração da
equipe são pontos fundamentais na execução e no sucesso da gestão de projetos
no mundo atual (CHIAVENATO, 2008).
97
Obviamente, muitas vezes, o gerente de projeto é incumbido de executar

e gerenciar um projeto já com uma equipe previamente definida. Esse caso é
tipicamente real quando se fala em projetos dentro de uma organização maior ou
até mesmo em uma startup, onde as equipes são bastante reduzidas e já existe o
deslocamento de certos profissionais para uma empreitada.
Todavia, é relevante também nesses casos identificar a disparidade entre

o desejado e o conhecimento atual. O primeiro ponto relevante na elaboração
de planejamentos, e especificamente na elaboração da equipe, é não usar nomes
próprios para identificação de cada membro da equipe e sim usar os papéis
desempenhados pelas pessoas. Ou seja, no caso de um projeto de desenvolvimento
de software existem os papéis de gerente de projeto, de arquiteto de softwares,
programador e o papel de testador, por exemplo. Esses papéis poderão ser
executados todos pela mesma pessoa, porém, é importante que o gerente saiba
que para cada atividade ele estará assumindo um papel diferente e que irá
necessitar de conhecimentos e habilidades distintas para cada pacote de trabalho.
Em uma empresa, apesar de ser desejado ter profissionais polivalentes,

devemos aceitar que em alguns papéis aquele profissional irá exercer a sua
atividade com os conhecimentos necessários e em outros papéis, ele fará de uma
maneira marginal e suscetível a mais erros.
Dessa maneira, um dos primeiros procedimentos a realizar quanto

à composição da equipe é a identificação dos papéis. Cada papel deverá ser
especificado com um nível de detalhamento para que se consiga identificar, por
exemplo, qual é a formação necessária para executar aquela atividade, quais
as certificações que são interessantes para aquele papel, o nível de experiência
desejado para o projeto e quais são as outras habilidades técnicas desejáveis.
Também se pode documentar quais as capacitações desejadas e obrigatórias que
aquele profissional precisa realizar para executar determinado pacote de trabalho.
Ao realizar essa atividade, o gerente de projetos tem então a sua equipe

ideal, quase que perfeita na execução de projetos, porém, sabemos que o ideal,
apesar de ser perseguido, ele nunca é alcançado. E deste modo, o gerente de
projeto consegue mapear a distância entre a sua equipe e o papel que ela vai
executar, essa distância é chamada de análise de GAP.
Esse GAP precisa ser explicitado aos stakeholders para que o financiador
do projeto consiga observar se ele deseja pessoas de maior senioridade para o
projeto ou aceita os níveis de diferença atual entre a equipe e o desejado.
Caso a pressão dos stakeholders seja demasiadamente alta, o gerente de

projetos tem que ser rígido e profissional para apresentar os gastos e solicitar
mais recursos e pessoas para suprir essa disparidade. Ou, se o tempo e prazo do
projeto permitirem, o gerente de projeto poderá elaborar um plano de formação da
sua equipe para a diminuição dessa diferença. Algumas técnicas e conhecimentos
podem ser eliminados com cursos de curta duração ou até mesmo com um estudo
autodirigido, muito utilizado nas organizações.
98
Desse modo, o uso de papéis de projeto dará uma flexibilidade na alocação

de pessoas na sua equipe, assim como ao explicitar quais são as competências
necessárias para a execução de determinados papéis.
Caso o papel identificado necessite de mais de uma pessoa para sua

execução, é importante a atribuição de um identificador numérico, por exemplo,
“programador 1”, “programador 2” e “programador 3”. Com isso o gerente de
projeto poderá elaborar cenários de custo benefício ao stakeholders, ou seja, mais
profissionais significa mais custos e até certo ponto pode diminuir o prazo de
execução do projeto.
Esse custo benefício deve ser objeto de contínua negociação do gerente

de projeto com os stakeholders. Caso a equipe seja enxuta e pequena, com poucas
pessoas assumindo múltiplos papéis, obviamente o projeto tenderá a ser mais
longo e essa decisão não pode ser exclusiva do gerente de projeto, mas sim fruto
de uma negociação com os stakeholders.
EXEMPLO
Para planejar as pessoas que irão compor a equipe de projeto, o gerente
de projeto deve avaliar cada pacote de trabalho e saber as competências e
habilidades necessárias para cada uma delas. No quadro a seguir há um exemplo
dessa avaliação.
QUADRO 6 – COMPETÊNCIAS REQUERIDAS POR CADA ATIVIDADE
Atividade Competência requerida

 Formação em arquitetura.
Projeto  Ter experiência de no mínimo um ano com contextos empresariais.
arquitetônico  Um projeto realizado com a prefeitura local da loja.
 Ter ao menos um curso de aperfeiçoamento nos últimos 12 meses.
 Formação em engenharia civil.
Projeto
 Ter experiência de no mínimo três anos com contextos empresariais.
estrutural
 Três projetos realizados com a prefeitura local da loja.
Projeto  Formação em engenharia civil.
hidráulico  Ter experiência de um ano com aproveitamento sustentável de água.
Projeto  Formação em eletrotécnica.
elétrico  Ter experiência de um ano com projetos empresariais.
Projeto  Formação em arquitetura.
iluminação  Ter experiência de um ano com projetos empresariais.
Projeto  Formação em engenharia mecânica.
sonoro  Ter experiência de um ano com projetos empresariais.
 Formação em segurança empresarial.
Projeto
 Ter experiência de um ano com projetos empresariais.
segurança
 Experiência de um ano em pessoal e TI de segurança.
99
Aparentemente, o gerente de projeto poderia indicar um profissional para

cada pacote de trabalho, porém, com uma análise mais aprofundada, temos sete
pacotes de trabalho e cinco perfis:
a) Engenheiro civil.
b) Arquiteto.
c) Engenheiro mecânico.
d) Eletrotécnico.
e) Profissional de segurança.
O gerente de projeto, caso opte, poderia se valer do engenheiro civil para

suprir a demanda de arquitetos, desde que ele tivesse experiência em iluminação
e fachadas. Haveria uma diferença do plano de competências, mas com menos
pessoas, a chances de incompatibilização de projetos é menor, bem como a
quantidade de comunicação e esforço gerencial em lidar com mais pessoas.
Também poderia haver o critério de valor-hora para compor essa decisão.
Essa decisão de composição de equipe poderia ser ilustrada na figura a

seguir. Pode-se observar que a alternativa de manter duas pessoas para os dois
papéis de arquiteto e engenharia teria benefícios em atender aos dois papéis sem
GAPs, ou seja, com competências ideais.
Porém, se assumir um engenheiro para o seu papel e também o de

arquitetura, perde-se em competências claramente, mas há aspectos positivos em
risco de incompatibilidade de projetos, comunicação e custo, uma vez que com
mais carga horária envolvida, o valor-hora pode ser negociado. Essa é uma típica
decisão que poderia usar tomada de decisão multicritério.
FIGURA 21 – COMPOSIÇÃO DE EQUIPE
100
5 CRONOGRAMA E ORÇAMENTO
Uma vez que identificamos os objetivos do projeto, construímos a estrutura
analítica de projeto, identificando assim os pacotes de trabalho e posteriormente
realizando uma estimativa de nível de esforço e equipe envolvidos com o projeto,
é possível a construção de cenários de cronogramas e orçamentos para o projeto
(PMI, 2013).
Um primeiro ponto importante a ser destacado é a questão de cenários

que devem ser legitimados junto ao stakeholder e também o entendimento de
que o cronograma e o orçamento na verdade são resultantes de vários fatores do
projeto.
No tocante, para a questão de cenários, é importante que o gerente de

projetos entenda que suas decisões são baseadas em uma visão parcial e incompleta
da realidade, uma vez que existem incertezas do que deve ser feito dentro do
projeto. Essas incertezas não podem ser dissipadas por conta da pressão e tensão
existentes entre os stakeholders, a priori essa pressão e tensão pode aparecer um
fator negativo, mas devemos entender isso como uma realidade presente em
gestão de projetos. Ou seja, é da natureza do projeto que existam essas tensões,
assim o gerente de projeto deve elaborar planos baseados em pressupostos de
cronograma e orçamento final, que devem ser frutos de uma negociação constante
com o patrocinador do projeto, apresentando os principais cenários sugeridos
e as premissas envolvidas. Esses cenários podem ser múltiplos, e não somente
otimista ou pessimista, podem ser vários caminhos a serem trilhados, descobertos
e negociados com o stakeholder.
Em projetos inovadores, nos quais exista uma grande incerteza ou até

pacotes de trabalho que não possam ser especificados e estimados, muitas vezes,
o patrocinador e o gerente de projetos podem tomar a decisão de somente aprovar
um cronograma inicial dos primeiros marcos do projeto para depois, com mais
informações e conhecimento, poder elaborar o cronograma completo do projeto.
O gerente de projetos apesar de apresentar múltiplos cenários deve

sempre emitir a sua opinião sobre qual a proposta que ele e sua equipe entendem
como a melhor para o projeto. Isso é um compromisso ético e profissional do
gerente de projetos uma vez que premissas estão por trás daqueles valores de
esforço, prazos e custos do projeto.
Outro ponto a se destacar é, cronogramas e orçamentos são resultantes de

uma combinação de fatores e decisões dentro do projeto. Essas decisões podem
ser melhor entendidas pelas áreas de conhecimento da gestão de projetos, ou
seja, o cronograma e o orçamento na verdade são resultantes das decisões da
composição da equipe de projeto.
101
Vale lembrar que todas as atividades de planejamento são direcionadas

para o alcance de objetivos de um grupo de pessoas. Caso haja uma alteração,
tanto de pessoas e patrocinadores intervenientes, bem como os seus interesses,
estas alterações podem afetar o cronograma e o orçamento.
Outra variável relevante que pode afetar os cenários de cronograma e

orçamento é a área de conhecimento de qualidade. Esta pode demandar um maior
nível de testes de um determinado produto, gerando o maior esforço de pessoal
para internamente testar ostensivamente o produto antes de liberar o mercado.
Quanto maior o nível de qualidade, seja no ponto de vista de ações

corretivas, preventivas ou de auditoria, pode-se demandar mais esforços e
prazos, envolvendo contratos de terceiros, ou seja, parte da estrutura analítica de
projeto, que são realizados por terceiros por meio de contratos e licitações, podem
impactar a forma que o cronograma e o orçamento serão realizados, pois apesar
de ter contratos firmados, esses pacotes de trabalho realizados por terceiros não
estão sob a gestão direta do gerente de projetos. Dessa forma, pode haver certa
morosidade e burocracia envolvida, dependendo do nível de atividade e níveis
contratuais.
Como pode-se observar, apesar de que para um gerente de projeto

iniciante o cronograma é uma questão simples de ser resolvida, o cronograma e o
orçamento resultam de uma relação complexa de múltiplos fatores, alternativas
infinitas e que precisam ser entendidos e apresentados aos stakeholders de uma
maneira franca, para junto destes tomar as decisões dentro de um planejado.
Existem muitas formas de apresentação de cronograma, a mais clássica

em gestão de projetos é por meio de gráficos de Gantt, onde visualmente cada
atividade do projeto é apresentada por meio de quadrados e, cada quadrado,
representa um período de tempo (PRADO, 1998). Estes períodos de tempo
geralmente são representados por dia, então uma atividade planejada para
execução em três dias será representada em três quadrados, um ao lado do outro,
e assim sucessivamente para cada atividade. As dependências são apresentadas
por meio de setas e os losangos representam os marcos do projeto, um exemplo
de gráfico é apresentado na figura a seguir.
102
FIGURA 22 – EXEMPLO DE DIAGRAMA DE GANTT
Vale lembrar que a simplicidade na apresentação ao stakeholder deve ser

sempre um vetor importante, pois um cronograma e toda sua complexidade
precisam ser explicados pelo gerente de projetos. Lembrando que os stakeholders
contrataram justamente o gerente de projeto, pois não possuem e não querem,
nesse momento, se aperfeiçoar na técnica de projetos. Os stakeholders querem
somente entender um cronograma e tomar as decisões adequadas.
Pensando nessa simplicidade, um cronograma pode ser apresentado

em forma gráfica de linha do tempo em que se apresenta um quadro de linhas
e colunas. Neste quadro, as colunas representam os sprints ou iterações, que
representam um fragmento fixo de tempo que geralmente é definido em uma
ou duas semanas. As linhas apresentam os pacotes de trabalho, ou caso existam
muitos pacotes de trabalho, poderão representar as principais entregas que fazem
sentido para o stakeholders.
Apesar de tecnicamente isso não chamar cronograma, por não ter detalhes
de quando cada pacote de trabalho será encerrado, deixa aos stakeholders, gerente
de projeto, e, principalmente, a equipe do projeto uma clara noção de quais são
as prioridades em um dado momento. Dessa forma, esse tipo de apresentação
de compromissos de tempo é muito útil pois, simplifica a forma de gerenciar o
projeto.
Uma vez que não interessa em qual dia precisamente um pacote de trabalho
será encerrado, mas um conjunto de pacote de trabalho tem que ser encerrado
naquela iteração, deixando as decisões de menor nível de responsabilidade para
equipe que pode, dentro de uma interação tomar as decisões para contornar
problemas, premissas e riscos que constantemente vêm à tona na execução.
103
Esse tipo de apresentação gráfica pode ser materializado em softwares

de uma forma colaborativa para todos os membros da equipe e stakeholders, mas
também é usualmente representada em quadros físicos na sala do projeto, onde
todos conseguem mover os pacotes de trabalho caso eles sejam alterados.
Já os orçamentos, a representação é a clássica gestão orçamentária em

que as rubricas de custos estão representadas pelos pacotes de trabalho e uma
multiplicação entre as horas de trabalho pelo valor unitário da hora do profissional
que está executando aquela atividade.
Indo para o ponto mais prático em projetos de uma organização, muitas

vezes, a questão orçamentária é somente uma ordem de magnitude uma vez que
poucas organizações têm os seus orçamentos controlados por meio de projeto.
A maioria das organizações atualmente controlam o seu orçamento de

uma forma corporativa global e os projetos são ações estratégicas, mas o controle
orçamentário fica a cargo do departamento ou da unidade administrativa que
conduz um determinado projeto.
As organizações que possuem a questão orçamentária controlada por

projetos são organizações que vivem de projetos de terceiros, muito comum em
projetos de construção civil, prestadores de serviço ou organizações, que têm alta
maturidade em gestão de projetos, com anos de execução, experiências e lições
aprendidas.
Todavia, de uma forma geral, atualmente, as organizações usam os

orçamentos de projeto para saber somente uma ordem de magnitude do
investimento, de uma forma prática. Isso quer dizer que os valores unitários das
horas dos profissionais não precisam ser fielmente representados pelo custo que
está representado na folha de pagamentos. Se essa gestão precisasse ser igual,
resultaria a gestão de projeto de uma complexidade extremamente alta, uma
vez que os custos dos profissionais podem variar mês a mês, como encargos e
gratificações.
Também precisamos pensar que o custo da má organização de um projeto

não é somente o valor da hora do profissional, mas também toda a infraestrutura
física como, por exemplo, salas e mobiliários, conta de luz, telecomunicações e
todas as unidades administrativas de apoio.
Uma organização que está iniciando a gestão de projetos que quer fazer
esse controle no nível orçamentário, ou seja, fazer com que a conta do orçamento
da empresa “feche” com a soma de todos os projetos, pode ser tornar uma
atividade árdua e burocrática, tirando o foco do projeto e ao que ele se destinou
para dar foco a uma questão burocrática.
104
Assim, os orçamentos de projetos trabalhados por ordem de magnitude

são importantes para saber a grandeza de um projeto em relação aos outros, como
volume de horas e o nível de profissionais seniores e, então, algumas simplificações
são realizadas. Por exemplo, o valor hora de um determinado papel de projeto
de um membro é padronizado para todos, um programador Júnior pode ter
um custo padronizado para todos os projetos de R$ 15,00 a hora. Obviamente
esse valor pode variar mês a mês e pode variar de acordo com profissional, mas
essa padronização dá uma simplificação necessária para que se consiga saber,
não só a ordem de magnitude do orçamento, mas também, tornando a questão
orçamentária de uma forma mais prática e menos burocrática.
Assim, uma vez que se consiga a linha do tempo de projeto, com as

entregas que podem ser representadas por uma linha do tempo ou um gráfico de
Gantt, pode-se então calcular o nível de esforço ao longo do tempo. Por exemplo,
toma-se por base o total de horas trabalhadas de cada papel na primeira semana,
multiplica-se pelo valor hora e faz-se o somatório e assim sucessivamente para
segunda semana e terceira semana.
Esse somatório de custos por semana pode ser representado por um

gráfico de duas dimensões, sendo a dimensão das abscissas a linha do tempo
e das ordenadas o total de custo do projeto acumulado. Esse gráfico, de uma
forma clássica é nomeado curva S, pois o seu formato se assemelha a essa letra.
Isso ocorre porque no início do projeto poucas pessoas são alocadas e a equipe é
pequena.
Assim, de posse dos cenários de cronograma e orçamento, inicia-se uma

negociação com os stakeholders e uma deliberação de qual cenário será adotado
como decisão definitiva do projeto para formar a linha de base do projeto.
A linha de base de projeto é um termo usado em gestão de projetos para

representar uma versão de um conjunto de artefatos gerenciais que compõe
o plano. Geralmente, a linha de base representa o cronograma e o orçamento,
mas também todos os documentos em sua última versão que originaram esses
orçamentos e cronogramas, a citar termo de abertura de projeto, estrutura analítica
de projeto, estimativas, premissas e sequenciamento das atividades, entre outros
que possam surgir a cada caso de uma maneira particular.
Então, a linha de base é na verdade uma fotografia de todos os documentos

gerenciais que foram escolhidos para tomada de decisão e assim, caminha-se para
a execução do projeto. Essa fotografia é importante para que, durante a execução
do projeto, desvios possam ser identificados e uma decisão possa ser tomada
para uma ação corretiva a fim de recompor a execução mais perto do plano ou
apresentar solicitações de mudanças para que consiga ter uma nova linha de base.
Há de se destacar ainda que, o termo fotografia faz mais sentido do que

o congelamento de um plano. O termo congelamento dá a entender que o plano
está fechado e não pode ser mais alterado, mas isso não é verdade uma vez que
105
todo planejamento foi composto de premissas, suposições e incertezas, que

podem não ser a realidade da execução. Dessa forma, ajustes tanto no plano como
na execução são factíveis, ou seja, na Unidade 3, veremos que alguns desvios não
são necessariamente falhos na execução, mas podem ser falhas as limitações de
planejamento.
EXEMPLO
No exemplo da loja, o GP elaborou um timeline, deixando claro os marcos
do projeto, conforme ilustrado na figura a seguir.
FIGURA 23 – TIMELINE DO PROJETO
Com base no timeline e seus marcos, o GP inseriu os pacotes de trabalho,

compondo uma primeira versão do cronograma, conforme observado no quadro
a seguir:
106
QUADRO 7 – MARCOS DO PROJETO
Derivado do cronograma, pode-se construir o gráfico de Gantt,

apresentando de forma gráfica o cronograma e as precedências entre suas
atividades.
FIGURA 24 – DIAGRAMA DE GANTT
107
Para cada pacote de trabalho, é inserido o valor de esforço de cada membro

da equipe, fazendo possível a construção do orçamento, conforme ilustrado no
quadro a seguir:
QUADRO 8 – ESTIMATIVA DE RECURSOS (1)
QUADRO 9 – ESTIMATIVA DE RECURSOS (2)
Para o orçamento total do projeto, o custo do valor hora de cada membro

de equipe é apresentado no quadro que segue:
108
QUADRO 10 – ESTIMATIVA E RECURSOS E CUSTOS
109
RESUMO DO TÓPICO 2
• Existem quatro formas de identificar dependência de atividades: “terminar

para iniciar” (FTS – Finish to Start), "terminar para terminar" (FTF – Finish to
Finish), "começar para começar" (STS – Start to Start) e "começar para terminar"
(STF – Start to Finish).
• Dependências devem ser utilizadas quando existe uma obrigatoriedade entre

as atividades.
• Marcos do projeto são os pontos de relevância na linha do tempo do projeto, em

que se observa uma entrega relevante para o alcance dos objetivos do projeto.
• As estimativas de projeto são, na verdade, as estimativas do conjunto de

atividades identificadas como pacotes de trabalho dentro da etapa de estrutura
• É importante no início do planejamento, os stakeholders sejam ostensivamente

comunicados que as estimativas são baseadas em pressupostos.
• A técnica Delphi consiste em usar não somente um especialista, mas um

conjunto de especialistas para que consiga gerar um entendimento maior, não
só na atividade de estimativas, mas também nas especificações do projeto.
• Existem muitas formas de apresentação de cronograma, a mais clássica em

gestão de projetos é por meio de gráficos de Gantt, em que visualmente cada
atividade do projeto é apresentada por meio de quadrados e, cada quadrado,
representa um período de tempo.
• Os orçamentos de projetos trabalhados por ordem de magnitude são

importantes para saber a grandeza de um projeto em relação aos outros,
como volume de horas e o nível de profissionais seniores e então, algumas
simplificações são realizadas.
110
AUTOATIVIDADE
1 Construa uma rede de precedências com os pacotes de trabalho da

autoatividade anterior sobre a festa de formatura.
111
112
UNIDADE 2 TÓPICO 3
PREPARANDO PARA A EXECUÇÃO
1 INTRODUÇÃO
Uma vez determinada a versão dos documentos que irão compor a linha
de base, passa-se a pensar na parte da execução do projeto.
O primeiro fator de importância na execução é que a equipe esteja

comprometida com o planejamento do projeto. Repare que a palavra é
comprometida, uma vez que ela foi envolvida durante o planejamento do projeto.
Essa questão é importante pois, muitas vezes, o gerente de projeto isola

a equipe de determinadas decisões e compõe um planejamento que não é parte
integrante do pensamento da equipe. Esse é um dos principais fatores que podem
complicar a execução de um projeto, um conjunto de planejamentos em que a
equipe não acredita na viabilidade daquele cenário.
Uma vez que essa aceitação formal é sugerida, que seja realizada por meio
de uma reunião e depois um envio de e-mail para que todos consigam responder
ao seu “de acordo”. Caso haja alguma divergência de opinião, o gerente de projeto
precisa iniciar uma negociação e saber se a objeção de um integrante da equipe,
ou mais, ocorre por alguma fragilidade no planejamento ou se trata de um receio
de que o planejamento não esteja ideal.
Nas seções anteriores já discutimos sobre o planejamento ideal e que este

é uma utopia, é um plano no qual não existem certezas. Novamente, esse cenário
ideal não é realidade em gestão de projetos, a realidade trata de uma constante
tensão e pressão com os stakeholders. Desse modo, esse receio, de algum membro
da equipe, precisa ser contornado pelo gerente de projeto por meio de conversas
e argumentações.
O gerente de projeto não deve fazer o uso da sua autoridade para impor
um planejamento, pois, na melhor das hipóteses, criará um conflito no momento
do uso da sua autoridade. Mas, o pior cenário é que o gerente de projeto faça uso
da autoridade e a equipe apenas finja que está aceitando o planejamento, mas no
fundo do seu entendimento, a equipe não acredita naquele plano. Esse é o pior
cenário, pois durante a execução, caso haja qualquer desvio, seja de execução ou
de planejamento, a equipe não irá se comprometer a trabalhar com contingências
que necessitam algum tipo de dedicação e esforço a mais do que o planejado.
Uma vez que aquele plano não foi aceito de uma maneira explícita, mas sim o
113
plano foi imposto pelos stakeholders e pelo gerente de projeto. Dessa maneira,
a obtenção do aceite dos planos validados pelos stakeholders e pela equipe é de
suma importância para a execução do projeto.
2 PLANEJAMENTO DE COMUNICAÇÃO
Um fator importante ao se planejar a execução é a questão da gestão da
comunicação. A gestão da comunicação passa pelo planejamento das informações
que precisam ser trafegadas entre a equipe, entre os stakeholders e, em alguns
casos, com atores externos como clientes sociedade e mídia.
A gestão da comunicação precisa ser planejada e se inicia pela definição

dos elementos que devem ser comunicados e quais os atores participantes. Toda
comunicação também tem um meio e um veículo pelo qual as informações serão
trafegadas, algumas vezes de uma forma unidirecional.
Os elementos de comunicação devem ser identificados para saber quais

são aqueles que irão ter uma comunicação planejada. De uma forma atípica, os
projetos precisam de um repositório de documentos, onde o gerente de projeto
irá dispor os documentos oficiais dos projetos aprovados e aqueles que estão
constantemente sendo digitados e editados.
É importante saber e configurar regras na ferramenta utilizada para que

alguns documentos sejam somente leitura da equipe e algumas outras pastas e
documentos possam ser editados por qualquer membro da equipe.
Outra funcionalidade importante na questão de gestão dos pacotes de

trabalho é ter um status de progresso da atividade. Recomenda-se que use o
sistema Kanban, ou seja, quais atividades que estão esperando a pessoa liberar
para iniciar a execução, quais são as atividades e pacotes de trabalhos que estão
em execução, quais estão aguardando validação e quais estão concluídos. Esses
são os estados típicos de gestão de projetos, mas podem ser customizados para
cada situação.
Neste sentido é importante que a equipe tenha a visualização e

conhecimento de como está o status de cada pacote de trabalho. Existem muitas
ferramentas do mercado atualmente que se destinam a essa ajuda na gestão de
projetos. Não cabe a esse livro recomendar uma ferramenta, mas recomenda-se a
prerrogativa da simplicidade de uso e um sistema que seja aceito por todos.
Além dessas funcionalidades, também é importante definir como o

gerente de projeto irá controlar as horas de projeto. Uma vez que houve um plano
e estimativas, necessita-se saber se o projeto ainda está dentro do planejado e, se
existe um desvio a ser contornado ou um desvio importante que comprometa os
objetivos do projeto.
114
TÓPICO 3 | PREPARANDO PARA A EXECUÇÃO
Essa última funcionalidade talvez seja o elemento mais desgostoso para

a equipe de projetos, pois a cada pacote de trabalho encerrado a pessoa deve
apontar as suas horas e definir quantas horas foram necessárias para concluir
aquela atividade.
Apesar de ser uma atividade desagradável, pois remete a um controle

excessivo, sem esse report de horas o gerente de projeto não consegue saber se
as estimativas de custos do projeto estão adequadas e, mais à frente no projeto,
a organização poderá possuir um banco de dados para identificar o quanto de
desvio houve no projeto em relação ao planejado, auxiliando no planejamento de
projetos futuros.
Novamente, é importante destacar a simplicidade desse elemento. Este

controle pode ser obtido por softwares muito sofisticados ou podem ser feitos
por uma planilha eletrônica, com os pacotes de trabalho e a comparação entre o
planejado e o executado. O uso destes meios deve ser muito bem pensado durante
o projeto.
Também é interessante que o gerente de projetos deixe livre para sua

equipe criar novos pacotes de trabalho, mesmo que estes não estejam planejados.
Isso denotará uma abertura para qualquer membro da equipe propor alternativas
e explicitar suas preocupações com assuntos relacionados ao projeto.
A principal questão em torno desses novos pacotes de trabalho é que esses

devam ser designados para o gerente de projeto, e ele que dará o encaminhamento
necessário. Isso é importante, pois lembramos que existe uma linha de base, e
se todos os membros da equipe criarem novos pacotes de trabalho para outros
membros da equipe, o projeto dificilmente terá um norte dentro do que foi
planejado.
Neste ponto, as reuniões são elementos cruciais de comunicação e de suma

importância para o sucesso dos projetos, uma vez que este trata de pessoas. No
próximo tópico será abordado como conduzir e planejar reuniões, porém, nesse
momento é importante determinar e planejar quais são as reuniões programadas
durante o projeto.
Sempre que um gerente de projeto agenda uma reunião com urgência,

esta precisa ser justificada como um evento catastrófico e imprevisto que precisa
ser gerenciado de uma maneira imediata. Existe também a previsibilidade de
reuniões como, por exemplo, reuniões de encerramento de iterações, reuniões de
entrega de resultados aos stakeholders ou reuniões de comunicação de desempenho
do projeto.
Essas reuniões, apesar de serem fundamentais e de suma importância,

não podem ser encaradas como urgentes, uma vez que podem ser antecipadas.
No caso de projetos em que haja um comprometimento dos stakeholders, é
uma boa prática que após uma primeira versão da linha de base o gerente de
115
projetos convoque todas as reuniões importantes durante o projeto, pois assim os

stakeholders externos, principalmente, consigam reservar espaço nas suas agendas
para a reunião. Isso dará um tom profissional e de experiência ao gerente de
projeto.
Outro tipo de reunião importante e não urgente são as que ocorrem de

forma recorrente com a equipe do projeto, estas podem ser divididas em três
categorias. A primeira categoria são reuniões rápidas e diárias, com o objetivo de
saber sobre elementos que aconteceram desde o dia anterior ou desde a última
reunião, o que se pretende fazer até a próxima reunião e quais elementos podem
dificultar o andamento do trabalho naquele período.
Essa reunião diária, apesar de só possuir três perguntas, é muito positiva

para a equipe uma vez que tem elementos de controle, de planejamento e de
antecipação a riscos ou dificuldades. Entretanto, essa reunião deve ser feita
com todos os membros da equipe, independentemente da sua senioridade ou
complexidade de execução de tarefa. Isso dará um tom de união e transparência
ao projeto, auxiliando para que todos consigam contribuir para o sucesso.
É desejável que essa reunião diária não ultrapasse 15 minutos, quando

cada membro apenas fale de uma maneira bem sintética o que está acontecendo
e, o gerente de projetos coleta as informações. Uma boa prática é que essa reunião
não seja agendada, ela preferencialmente deve ocorrer no mesmo local e no
mesmo horário, e para que a reunião não se estenda, é desejável que esta ocorra 15
minutos antes do almoço ou 15 minutos antes do fim do expediente, provocando
na própria equipe uma necessidade de síntese.
A segunda categoria se refere às reuniões semanais, estas têm a finalidade

de, no meio de uma interação, identificar os pacotes de trabalho de uma maneira
mais global e saber a situação em que se encontram os objetivos de uma
determinada interação. Essa reunião pode ser realizada sempre no mesmo dia
da semana e horário, também com toda a equipe, mas precisa-se de um tempo
maior, uma vez que pode haver deliberações de alternativas e soluções que não
estavam anteriormente pensados.
Por fim, a terceira categoria de reunião são as realizadas sempre nos

marcos do projeto, ou seja, nas entregas importantes do projeto. Uma boa prática
é que o gerente de projeto vá para reunião com stakeholders de resultados ou,
com no mínimo, o principal responsável pela entrega. Isso dará um prestígio ao
membro da equipe em falar diretamente para os stakeholders, e ao mesmo tempo,
faz o empoderamento daquele profissional para que ele entenda como pensam
os stakeholders.
Jamais o gerente de projeto deve realizar reuniões de entregas de

resultados no estilo caixa preta, ou seja, ele somente fala com stakeholders e depois
comunica a equipe. Essa prática não gera comprometimento da equipe para a
causa do projeto.
116
3 PLANEJANDO A QUALIDADE
A gestão da qualidade em projetos é de suma importância para o alcance
dos objetivos pelos quais o projeto existe, porém, a qualidade é uma das áreas de
conhecimento do PMI que deve ser criteriosamente pensada e analisada para que
o nível de formalismo esteja compatível com as necessidades de projeto e com a
maturidade da organização.
Nos tópicos anteriores, nós observamos as práticas em gestão de projetos

que dificilmente um projeto, de qualquer natureza, não realize. Ou seja, a
necessidade do termo de abertura de projeto, estrutura analítica, estimativas,
premissas que suportam aquelas estimativas e elaboração de um cronograma e
orçamento são praticamente fundamentais para qualquer tipo de projeto, salvo
raras exceções.
Entretanto, em alguns projetos há uma necessidade de formalizar as

práticas de qualidade e essa sessão destaca esses pontos. Reitera-se que as práticas
a seguir devem ser criteriosamente adequadas a cada contexto do projeto e da
organização, ou seja, praticar todas as técnicas de qualidade em uma empresa
que está iniciando a sua trajetória em gestão de projetos pode provocar efeitos
colaterais indesejáveis, como lentidão e o excesso de preciosismo acadêmico e
teórico, sem os resultados práticos as quais ela se destina (ANTÓNIO; TEIXEIRA,
2007).
A gestão da qualidade iniciou-se nos estudos organizacionais sendo

basicamente a redução de defeitos, e em um aspecto contemporâneo, a qualidade
passou a significar o mais próximo do desejável pelo usuário final (JURAN,
1997). Dessa forma, a qualidade deixou de ser uma dimensão objetiva, como
simplesmente um indicador de falhas e erros de projeto, para ser um conceito
relacionado à percepção de uma pessoa, com isso existe uma grande carga
subjetiva do que vem a ser qualidade (CARVALHO; PALADINI, 2013).
Além desse aspecto, existe não só a questão da subjetividade, mas a

percepção dos stakeholders específicos de cada projeto, tornando assim a qualidade
um conceito que dificilmente conseguirá ser definido de uma maneira detalhada
de forma universal. A qualidade, então, significa as formas de organização dos
recursos para o alcance dos objetivos estratégicos.
Para ilustrar, de uma maneira simples, essa conceituação da qualidade,

pode-se imaginar uma situação na qual existe um produto de baixo nível de
erros, um produto quase perfeito, porém, o custo dele é muito alto, impossível
até de uma pessoa de classe média alta adquiri-lo. Imagina-se então um outro
produto, que tenha algumas falhas contornáveis em seu uso e com um custo
bastante acessível ao usuário final, podendo assim ser comprado.
117
FIGURA 25 – QUALIDADE X PREÇO
FONTE: <https://bergan.com.br/qualidade-ou-preco-adivinhe-o-que-seu-cliente-prefere/
qualidade-x-preco/>. Acesso em: 12 set. 2018.
A reflexão que fazemos é: Qual é o melhor produto? Qual é o produto

de melhor qualidade? Essa simples exemplificação coloca dentro do conceito da
qualidade múltiplas dimensões, como o preço final.
Iniciantes poderiam dizer que são duas dimensões distintas, que a

qualidade se remete a apenas produzir o produto mais próximo do ideal em termos
de funcionalidades e erros, mas profissionais mais experientes entendem que
um produto de qualidade é um produto melhor avaliado por muitas dimensões,
ou seja, não adianta termos um produto com baixíssimo nível de erros se o seu
custo se torna impeditivo para seu usufruto e que o prazo para sua execução seja
inviável para se colocar no mercado.
Essa definição de qualidade no seu aspecto multicritério é fundamental,

pois a qualidade não se trata apenas dos objetivos a que se propõem o projeto,
mas sim de como os recursos serão dispostos. Não adianta estruturar um
planejamento no qual haja uma busca incessante de testes e correções em busca
do produto perfeito, isso poderia tornar o orçamento e cronograma inviáveis.
Por isso, muitas vezes, a qualidade é deixada de lado, no seu aspecto formal,
pois algumas organizações e gerentes entendem que a qualidade deve estar
desassociada de outras dimensões e que são conflituosos entre si.
Assim, o primeiro passo do planejamento da qualidade é analisar os

objetivos do projeto. Esses objetivos devem ser desdobrados em partes menores,
como se fosse uma estrutura analítica de projeto, mas em busca não dos pacotes
de trabalho, mas sim de pontos de vistas menores que possam ser avaliados por
indicadores de desempenho.
Esses indicadores de desempenho são escalas ordinais que ilustram a

preferência de um decisor em relação ao projeto. Por exemplo, é preferível que o
projeto atrase 5% do que 20%, tendo então uma escala de preferência decrescente,
ou seja, quanto menor, melhor.
118
FIGURA 26 – INDICADORES DE DESEMPENHO
A vantagem de trabalhar com escalas ordinais, é que no aspecto da

qualidade acima exposto, podemos abrir mão de certas dimensões para beneficiar
outras. Vamos imaginar o caso da escala acima, onde é preferível que o projeto
atrase 5% do que 20% de seu prazo, mas também existem outros indicadores, por
exemplo, é preferível possuir cinco falhas de projeto do que 15 falhas.
Dessa maneira o gerente tem que tomar decisões que equilibrem essas
duas dimensões, ou seja, se não conseguir ter as duas dimensões em níveis de
excelência, qual será a dimensão preferível. Com certeza, essa não é uma decisão
das mais fáceis e a complexidade aumenta quando colocamos outros indicadores
de desempenho, uma vez que é comum que um projeto tenha 10, 15 ou até mais
indicadores de sucesso.
Assim, é de fundamental relevância que, para trabalhar no conceito de

qualidade, esses objetivos sejam operacionalizados em escalas de preferência
isoladas, primeiramente, para depois serem comparadas e integradas em um
modelo. Isso facilita o trabalho do gerente de projeto, uma vez que ele vai saber
a priori quais são as dimensões pelas quais o projeto, a equipe e ele mesmo serão
avaliados no final e, geralmente, esses indicadores também são legitimados pelos
patrocinadores do projeto.
119
Após a legitimação desses indicadores de desempenho, que vão

representar de uma forma prática e operacional quais são as dimensões pelos
quais o projeto será avaliado, o próximo passo no planejamento da qualidade
ocorre pela representação de quais processos afetam cada um dos indicadores
ou afetam os indicadores de maior impacto no sucesso do projeto. E, antes de
representar o processo por meio de modelos de processo de negócio, é importante
entender qual artefato resultante será avaliado pelos indicadores.
Ou seja, vamos imaginar um indicador de desempenho, o volume de

horas de capacitação realizadas pela equipe do projeto. Esse indicador do projeto
vai avaliar uma pessoa capacitada ou uma equipe capacitada. Geralmente, esse
resultado se chama saída de processos e é representada por um substantivo e um
verbo no infinitivo.
Com a identificação dos indicadores e quais saídas serão avaliadas, pode-

se então passar a identificar os processos que irão construir as respectivas saídas.
Esses processos são basicamente representados por modelos de processos de
negócio, que explicitam quais atividades são críticas para ter impacto positivo
nas dimensões desejadas.
Essa análise de processos de negócio dentro do projeto pode sugerir

recomendações de mudanças na estrutura analítica de projeto, cronogramas e
qualquer outro elemento de planejamento. Vale ressaltar que, mesmo já definido,
o planejamento não é uma etapa do projeto e sim um processo contínuo de
aperfeiçoamento e geração de conhecimento.
Importante também lembrar que a simplicidade é sempre prerrogativa

máxima para qualquer tipo de projeto, seja ele simples ou complexo, seja ele um
projeto de ampla base histórica ou um projeto de inovação radical. Assim, os
fluxos de processos não precisam e não devem ser complexos com fluxogramas
muito extensos, quando se precisa de especialistas, mas, sim, de fluxos curtos
em que se recomenda de quatro a cinco atividades no máximo para chegar ao
resultado do projeto.
Outra dica prática importante para colocar a gestão da qualidade

facilmente no seu projeto é a premissa de que se não puder fazer essa análise de
indicadores, saídas e processo para todos os objetivos, é indicado que se faça os
principais. Ou seja, se não der para fazer todos, faça pelo menos a metade, mas
sempre buscando a essência daqueles que são os mais importantes.
A gestão da qualidade falha muitas vezes na sua operacionalização, por

tentar fazer muitas coisas, como a análise de muitos processos, quando muitas
vezes, nenhum é realmente feito com a reflexão necessária ou são feitas mais
formalidades do que necessário. Deste modo, essa análise é fundamental para
que o gerente de projeto consiga construir com indicadores de desempenho e
processos de negócios alinhados aos objetivos, que sejam poucos, mas essenciais
ao projeto que está sendo gerenciado.
120
DICAS
Como Leitura Complementar sugerimos a leitura do texto de HELDMAN,

Kim. Gerência de projetos: guia para o exame oficial do PMI. Gulf Professional Publishing,
2006. Você poderá acessá-lo em: <https://pmisp.org.br/document-repository/artigos-e-
news/130-18-aplicando-lean-project-management/file>. Boa leitura!
121
RESUMO DO TÓPICO 3
• O gerente de projeto não deve fazer o uso da sua autoridade para impor um
planejamento, pois, na melhor das hipóteses, criará um conflito no momento
do uso da sua autoridade.
• A gestão da comunicação passa pelo planejamento das informações que

precisam ser trafegadas entre a equipe, entre os stakeholders e, em alguns casos,
com atores externos como clientes sociedade e a mídia.
• A gestão da qualidade em projetos é de suma importância para o alcance dos

objetivos pelos quais o projeto existe.
• A qualidade significa as formas de organização dos recursos para o alcance dos

objetivos estratégicos.
122
AUTOATIVIDADE
1 Quais decisões são inerentes à etapa de planejamento da comunicação do

projeto?
2 Discorra sobre a importância da realização de reuniões para a comunicação

do projeto.
123
124
UNIDADE 3
EXECUÇÃO E CONTROLE DE
PROJETOS
• compreender os conceitos básicos inerentes a atividade de mobilização

da equipe;
• elaborar um plano de comunicação do projeto;
• compreender as ferramentas de controle de qualidade de projetos.
PLANO DE ESTUDOS
Esta unidade está dividida em quatro tópicos. No decorrer da unidade, você
encontrará autoatividades com o objetivo de reforçar o conteúdo apresentado.
TÓPICO 1 – E SE ALGO SAIR DO PLANEJADO?
TÓPICO 2 – MOBILIZAÇÃO DA EQUIPE
TÓPICO 3 – COMUNICAÇÃO DO PROJETO
TÓPICO 4 – GARANTINDO E CONTROLANDO A QUALIDADE DO

PROJETO
125
126
UNIDADE 3
TÓPICO 1
E SE ALGO SAIR DO PLANEJAMENTO?
1 INTRODUÇÃO
Ao realizar o conjunto de práticas, ou algumas das práticas abordadas nos
tópicos anteriores, existe recorrentemente a afirmação de que todo planejamento
é fruto de premissas e suposições. Estas suposições são artifícios necessários do
gerente de projeto, pois, em poucas situações, será possível ter pleno conhecimento
de todas as variáveis para conseguir realizar um planejamento.
Dessa forma, a gestão de projetos precisa gerenciar essas premissas e

suposições, para que assim, consiga antever planos alternativos, que possam
ser acionados, ou planos ostensivos, para em um cenário que algo dê errado ou
alguma premissa não seja confirmada, o gerente de projetos já consiga ter em
mãos alguns planos de ações.
A área de conhecimento na gestão de projetos que cuida dessas situações

é a de conhecimento de riscos, e no âmbito de planejamento de riscos, a primeira
atividade a ser realizada é a identificação dos riscos.
2 IDENTIFICAÇÃO E AVALIAÇÃO DE RISCOS DE PROJETO

A identificação dos riscos pode ser iniciada justamente pelo termo de
abertura de projeto, em específico, as premissas de projeto. As premissas são as
suposições que precisam ser levadas como verdade, para que todas as estimativas
do planejamento sejam válidas. Então, caso uma premissa não venha a ocorrer,
ela representa um risco ao projeto, e dessa forma, todas as premissas vão ser
identificadas como um risco.
Outra forma de identificação de riscos é por meio do processo de

estimativas, como vimos no Tópico 2 da unidade anterior. Todo o processo
de estimativa é baseado em premissas, e novamente, todas as premissas de
estimativas devem ser consideradas como riscos.
Por exemplo, em um processo de estimativas, foi identificado que o índice

pluviométrico para um determinado mês está estimado em 30 milímetros. Caso
haja um fluxo de chuvas maior que esse, representa-se um risco de projeto e então
deve ser gerenciado.
127
UNIDADE 3 | EXECUÇÃO E CONTROLE DE PROJETOS
Como forma complementar, é importante tornar o processo de identificação

de riscos um fluxo contínuo, ou seja, pode-se realizar uma reunião com a equipe,
realizando a técnica Delphi para identificação de riscos, que podem comprometer
o sucesso do projeto. É possível também aproveitar as reuniões diárias, semanais
e de marcos para que novos riscos possam ser identificados e catalogados.
Nas reuniões diárias observamos que três perguntas são realizadas, sendo
o que você fez desde a última reunião, o que que você vai fazer até a próxima
reunião e o que pode o impedir. A terceira pergunta é justamente o processo
contínuo de identificação de riscos e todos esses devem ser identificados e
formalizados.
A identificação dos riscos pode ser realizada de uma forma mais informal,
com simples papéis colados na parede, com sistemas de informações simples, como
bloco de notas ou estruturação de lembretes, mas também podem ter aplicações
mais elaboradas, como uma planilha eletrônica onde haja um identificador para
cada risco.
Os identificadores são interessantes para que não se precise falar o nome

do risco todo, que pode ser composto de várias palavras, tornando a comunicação
mais complexa. Então pode-se dar como identificador, por exemplo, “R1”, “R2”,
“R3”, e assim sucessivamente.
O mais importante na identificação do risco é não se antecipar e

negligenciar algum risco por conta de ele não ser importante no momento da
identificação. A quantidade de riscos é importante para não deixar nada escapar
e, dessa forma, no passo seguinte podemos avaliar estes riscos.
De uma forma prática, os riscos são avaliados por duas dimensões, sendo
a primeira o impacto para o sucesso do projeto e a segunda a probabilidade de que
ele aconteça. Quanto ao impacto no sucesso do projeto, os riscos variam conforme
a sua gravidade. Caso ele aconteça, pode ter um impacto catastrófico no projeto,
por vezes, até impedir ou fazer com que o projeto seja encerrado, ou um impacto
que poderia ser negligenciado e o produto será entregue com algumas limitações.
Por exemplo, em um projeto de construção de software, em que haja o risco

do relatório não poder ser impresso em um determinado tipo de impressora,
esse risco provavelmente tem um impacto baixo, uma vez que a compra de um
outro modelo de impressora pode representar um baixo custo em relação a todo
o esforço que está sendo feito no projeto. Entretanto, caso haja um risco de o
banco de dados não suportar a carga de informações presentes no software, este
pode comprometer todo sistema de informações e assim os riscos são avaliados
conforme o seu impacto.
Neste sentido existem várias formas de ordenar e criar essas escalas

de impacto, mas novamente, para a maioria dos casos de projetos, pode-se
simplesmente classificar como alto, médio ou baixo impacto.
128
TÓPICO 1 | E SE ALGO SAIR DO PLANEJAMENTO?
Os riscos de alto impacto são aqueles riscos que se acontecerem

comprometem o projeto, provocam seu encerramento ou a mudança do termo de
abertura de projeto. Os riscos de médio impacto são aqueles riscos que provocam
alterações em cronogramas, no escopo ou orçamento, por exemplo, mas os itens
contidos no termo de abertura de projeto não são impactados. São riscos que
oferecem uma magnitude menor, apesar de serem importantes. Por fim, pode-
se classificar um risco como baixo impacto quando podem ser contornados com
desvios, geralmente aceitos em projetos, como desvios de até 10% ou 5% do
orçamento e cronogramas.
A questão aqui é, quem vai avaliar se um risco é alto, médio ou baixo?

Uma das técnicas utilizadas em estimativas, também é útil para a gestão de
riscos, que é a técnica Delphi. Novamente uma planilha de riscos é enviada para
toda equipe, de uma maneira isolada e anonimamente, todos votam para saber
o impacto daquele risco perante o projeto e usando as escalas que o gerente de
projeto definiu.
Assim, as divergências podem ser posteriormente discutidas, por exemplo,

um especialista detectar que o risco é alto e outro detectar que o mesmo risco é
de impacto baixo, ou seja, qual é realmente a magnitude de impacto desse risco.
A grande verdade é que esses especialistas estão vendo esse risco de maneiras
diferentes, e essas divergências devem ser negociadas de uma maneira coletiva e
mediadas pelo gerente de projeto até que a determinação do impacto seja comum
a todos, similar ao processo de estimativas.
A outra dimensão de gestão de riscos é a admissão da probabilidade de

ocorrência do risco. Um risco não pode ter 0% de probabilidade, isso quer dizer
que não é possível que aconteça e então não seria um risco, e também não pode
ter 100% de certeza, uma vez que se o risco tem 100% de certeza ele já é um
fato e deve ser gerenciado dentro da estrutura analítica de projeto ou retirado do
escopo do projeto.
Assim, como probabilidade alta entendem-se aqueles riscos que a

organização já sofreu no passado e que nos últimos doze meses teve que realizar
contornos. Os riscos de média probabilidade são aqueles que ocorreram em
situações similares fora da organização. Reserva-se a probabilidade baixa para
aqueles riscos que nunca ocorreram ou que a organização já tenha passado por
situações similares sem maiores complicações.
Mesmo com essas diretivas é fundamental reiterar que a probabilidade e

o impacto quem determina se é alto, médio ou baixo é a equipe, pois o gerente
de projeto precisa dar à equipe empoderamento para que consigam se identificar
como partes fundamentais do sucesso do projeto. Caso o gerente de projetos
tenha uma opinião divergente da equipe, essa sempre deve ser negociada.
129
De posse da probabilidade e o impacto de cada risco, precisamos então

ordenar esses riscos conforme a sua exposição. A exposição do risco ocorre pela
multiplicação de fatores entre a probabilidade e o impacto, criar-se então uma
matriz, na qual as linhas representam o impacto e as colunas a sua probabilidade,
o risco pode ser representado por um ponto ou círculo dentro desta matriz.
Se analisarmos os riscos com alta probabilidade e alto impacto no projeto,

obviamente terão o seu lugar no ranking superior, ou seja, são aqueles riscos
que devem ser gerenciados pelo gerente de projeto e dificilmente podem ser
negligenciados.
Depois, podem-se analisar os riscos que têm uma alta probabilidade e um

médio impacto, ou vice-versa. Esses riscos oferecem então uma exposição média,
e assim sucessivamente fazemos essa análise e ordenamos esses riscos.
Essa análise gráfica também pode ser representada por uma análise
matemática, colocando um fator de alta probabilidade, o alto impacto com valor
de sete pontos, por exemplo, médio cinco pontos e baixo três pontos. Realizando
a multiplicação, um projeto de alto impacto e média probabilidade vai gerar 35
pontos de exposição, depois basta ordenar a planilha eletrônica pela exposição.
Deste modo, torna-se um modelo dinâmico, pois a cada reunião semanal pode-se
alterar o impacto e a probabilidade.
3 PLANO DE RESPOSTA AOS RISCOS

Após a ordenação dos riscos pela sua exposição, inicia-se a análise de
planos de resposta aos riscos. O plano de resposta aos riscos contém ações, que
podem ser categorizadas pelos seguintes tipos: (i) risco evitado; (ii) aceitação do
risco; e, (iii) planos de mitigação ao risco.
Um risco evitado significa alterar parte do escopo para que aquele risco
não aconteça. Por exemplo, imagina-se o risco de não saber se os roteadores
wifi vão conseguir propagar o sinal para todas as salas de um determinado
estabelecimento, então, pode-se negociar que a instalação dos roteadores estejam
fora do escopo do projeto, dessa maneira o risco será eliminado.
Também pode-se ter a aceitação de um risco, geralmente é realizada em

conjunto com o patrocinador do projeto, pois os custos de contingência e prevenção
ao risco são caros ou provocam efeitos colaterais indesejáveis. Dessa maneira, a
aceitação do risco simplesmente é a aceitação do patrocinador, que caso aconteça
aquele fato, existirá uma negociação para que se analisem os impactos do projeto
e depois as alterações necessárias.
130
Geralmente, a terceira categoria é a mais utilizada, que são planos

de mitigação ao risco. Planos de mitigação ao risco são planos proativos que
provocam a diminuição da probabilidade de acontecimentos daquele risco ou
diminuição de seu impacto.
Todo plano de mitigação ao risco significa mais ações do projeto, ou

seja, mais pacotes de trabalho da estrutura analítica, e consequentemente, mais
esforços e duração do projeto. Assim, os planos de mitigação ao risco precisam
ser ordenados pela exposição, pois dificilmente você encontrará um projeto em
que se consiga um plano de mitigação para todos os riscos, o que tornaria ele
inviável.
Dessa maneira, é importante elaborar o plano de mitigação primeiramente

para riscos de exposições altas, em que há alto impacto e alta probabilidade que se
realizem. É necessário ainda que se negocie com os stakeholders e patrocinadores
os planos de mitigação para essas situações, e caso ainda haja possibilidade
orçamentária e de cronograma para novos planos, pode-se partir para as posições
médias e baixas. Mas, geralmente no âmbito prático, os riscos de mitigação alta
já oferecem um grande custo ao projeto, e precisam ser trabalhados com critério.
Dessa maneira, leva-se à tona uma questão prática e importante para o

gerente de projeto, que é manter a lista de riscos de alta exposição numa pequena
fração dos riscos como um todo, ou seja, os riscos de alta exposição não podem
ultrapassar 20% do total de riscos.
Se os riscos identificados como alta exposição ultrapassarem essa fração,

este pode ser um indício de que a equipe esteja extremamente conservadora e
precavida, então cabe ao gerente de projeto apresentar esse fato e tentar extrair
da equipe quais daqueles riscos que realmente são diferenciados e que oferecem
maior exposição. Ainda para essa situação, o gerente de projeto pode criar uma
nova categoria, como a probabilidade e o impacto altíssimo.
Importante destacar que todo o plano de mitigação segue a mesma

máxima que observamos ao longo do planejamento, é necessário fazer planos de
mitigação práticos, reais e factíveis, mesmo que sejam poucos. Ou seja, é melhor
gerenciar com excelência um risco altíssimo do que gerenciar todos os riscos de
uma maneira burocrática e sem efeito.
Para conseguir essa seriedade e profissionalismo, recomenda-se que todo

plano de mitigação gere um item no cronograma e um pacote de trabalho. Ou
seja, se um plano de mitigação é a contratação de mais um profissional a partir
do segundo mês do projeto, no cronograma deve constar quem é que vai fazer a
descrição das atribuições desse profissional, o seu recrutamento e a seleção. Dessa
maneira, não haverá esquecimento e negligência perante esse plano de mitigação,
uma vez que, no cronograma existirá o comprometimento de uma pessoa para se
deslocar do projeto para essa atividade que visa resolver um risco.
131
Os riscos podem, também, ser objeto de atividades que não necessariamente

geram um produto de trabalho, conhecidos como buffers. Os buffers são blocos
de esforço de pessoas, mas que não se tem a certeza, ainda, que irão ocorrer.
Vulgarmente, essas atividades são nomeadas como “gordura”.
Obviamente, por questões éticas, essas gorduras não são bem vistas pelo
patrocinador do projeto, parecendo que o gerente de projeto está muito precavido
ou até mesmo cobrando alguma coisa que não irá realizar. Assim, não seria
ético atribuir ao projeto muitas mais horas que o necessário, simplesmente para
eliminar ou mitigar um desconforto da equipe e uma insegurança do gerente de
projeto.
Todavia, pode-se apresentar ao patrocinador uma atividade com dois

profissionais, contendo um esforço de 30 horas no final de uma iteração, mas
explicando para ele que essa atividade representa a mitigação de risco. Ou seja,
pode acontecer ou não, caso aconteça, já se possui pessoas e recursos provisionados
para a questão e não precisando de negociações com o stakeholder.
EXEMPLO
O gerente de projetos decide realizar uma reunião com alguns especialistas
nos temas do projeto e chegou com uma lista dos riscos conforme o quadro a
seguir:
QUADRO 1 – LISTA DE RISCOS DO PROJETO
Descrição do risco
R1 – Não conseguir contratar vendedores a tempo
R2 – Chuvas atrapalharem a fundação da obra
R3 – Rede de dados da cidade não ter boa qualidade
R4 – População não saber os diferenciais da loja
R5 – Incompatibilização de projetos de construção
R6 – Não conseguir os alvarás em tempo para inauguração
R7 – Rotatividade de pessoal na obra

R8 – Defasagem de conhecimento dos vendedores maior que o esperado
132
Deste modo, para avaliar os riscos, o gerente de projeto decidiu

realizar rodadas de técnica Delphi com os especialistas e não precisou dissipar
divergências relevantes. Ele definiu os seguintes parâmetros para a avaliação de
riscos de projeto, apresentados no quadro a seguir:
QUADRO 2 – PARÂMETROS PARA AVALIAÇÃO DOS RISCOS
Deste modo foi elaborado o seguinte plano de mitigação de risco, e após o

plano de resposta aos riscos, 3 e 4 e Figura 1.
133
QUADRO 3 – PLANO DE MITIGAÇÃO DE RISCOS

Descrição do risco Probabilidade Impacto Observações
O gerente de projeto não tem dados
sobre a oferta de bons quadros de
R1 – Não
pessoas na cidade (probabilidade),
conseguir contratar
Média Alto porém, sem vendedores, a inauguração
vendedores a
terá que ser adiada ou operar com
tempo
qualidade que poderá colocar em risco
o nome da empresa (impacto).
O gerente de projeto buscou dados
pluviométricos da região e a base
históricas dos últimos 15 anos aponta
para 10% de chances em ter índice de
R2 – Chuvas
chuvas que comprometam o trabalho
atrapalharem a Baixa Alto
ao ar livre (probabilidade). Todavia,
fundação da obra
se isso ocorrer, os trabalhadores da
obra são obrigados, por segurança, a
esperarem execução de atividades até a
parada da chuva (impacto).
O gerente de projeto identificou no
histórico de 5 projetos de lojas anteriores,
que a questão de telecomunicações
e sistemas de informações foram
R3 – Rede de dados negligenciados e observou que não há na
da cidade não ter Alta Alto EAP uma devida atenção a essas questões
boa qualidade (probabilidade). Sem telecomunicações
e sistemas de informações, não há
como emitir notas fiscais e ter acesso ao
controle de estoque, não permitindo a
operação da loja (impacto).
A cidade da loja está em uma região
distante da matriz e a marca nunca
R4 – População
fez qualquer campanha publicitária
não saber os Alta Alto
na região (probabilidade). Sem
diferenciais da loja
clientes, os objetivos de negócios estão
comprometidos (impacto).
Nenhum dos projetos anteriores teve
R5 – esse evento (probabilidade) e quando
Incompatibilização houve algum problema, foi facilmente
Baixa Médio
de projetos de contornado pelos técnicos sem qualquer
construção intervenção executiva do gerente de
projeto (impacto).
O gerente de projeto não tem todos
R6 – Não conseguir os procedimentos e exigências que
os alvarás em a prefeitura faz para a abertura
Média Alto
tempo para de um novo comércio na cidade
inauguração (probabilidade). Sem alvará, a loja não
pode funcionar (impacto).
134
Em projetos anteriores, observou-se

que todos (probabilidade) sofrerão
R7 – Rotatividade
Alta Alto impactos superiores a 15% do tempo
de pessoal na obra
(impacto) por conta de rotatividade do
pessoal de construção civil.
A questão da capacitação e orientação
de novos colaboradores em cidades
R8 – Defasagem de fora da matriz foram problemáticos em
conhecimento dos projetos anteriores (probabilidade) e é
Alta Alto
vendedores maior importante que a empresa mantenha
que o esperado o padrão e a cultura organizacional e
consiga chegar nas pessoas que farão o
contato direto ao cliente (impacto).
QUADRO 4 – PLANO DE RESPOSTAS AOS RISCOS

Descrição do risco Probabilidade Impacto Observações Plano de resposta
O gerente de projeto
Probabilidade: elaborar
não tem dados sobre a
plano de divulgação das
oferta de bons quadros
vagas em mídia e escolas
de pessoas na cidade
profissionalizantes.
R1 – Não (probabilidade), porém,
Probabilidade: averiguar
conseguir contratar sem vendedores, a
Média Alto banco de transferência
vendedores a inauguração terá que
interna.
tempo ser adiada ou operar
Plano de contingência:
com qualidade que
formar vendedores a
poderá colocar em risco
partir de pessoas sem
o nome da empresa
experiência.
(impacto).
buscou dados
pluviométricos
da região e a base
históricas dos últimos
15 anos aponta para Probabilidade: aceitar.
10% de chances em Plano de contingência:
ter índice de chuvas se ocorrer, elaborar
R2 – Chuvas
que comprometam o cronograma alternativo
atrapalharem a Baixa Alto
trabalho ao ar livre para antecipar material
fundação da obra
(probabilidade). que possa ser realizado
Todavia, se isso ocorrer, em balcões provisórios.
os trabalhadores da
obra são obrigados, por
segurança, a esperarem
execução de atividades
até a parada da chuva
(impacto).
135
O gerente de projeto Probabilidade: o projeto

identificou no terá que elaborar uma
histórico de 5 projetos alteração da EAP e
de lojas anteriores, planos a partir da
que a questão de segunda iteração para
telecomunicações acomodar as demandas
e sistemas de do departamento
informações foram de TI (tecnologia da
negligenciados e informação). O gerente
R3 – Rede de dados observou que não há de projeto entende para
da cidade não ter Alta Alto na EAP uma devida a primeira iteração, esse
boa qualidade atenção a essas questões risco não trará prejuízos,
(probabilidade). Sem então entende ser melhor
telecomunicações não adiar o início do
e sistemas de projeto por esse risco.
informações, não há Impacto: não há planos
como emitir notas de contingência por
fiscais e ter acesso ao enquanto. Não se sabe
controle de estoque, não se o sistema trabalha em
permitindo a operação forma off-line (sem rede
da loja (impacto). de dados).
Probabilidade: nessa
versão do plano de
projeto, não há um
pacote específico ainda
para lidar com esse risco,
que está dentro do tópico
A cidade da loja está em “PROJETO PILOTO”
uma região distante da da EAP e ainda não tem
matriz e a marca nunca especificações. Reuniões
fez qualquer campanha serão agendadas com os
R4 – População
publicitária na região stakeholders para detalhar
não saber os Alta Alto
(probabilidade). Sem essa questão e trabalhar
diferenciais da loja
clientes, os objetivos com ações de respostas a
de negócios estão esse importante risco ao
comprometidos projeto.
(impacto). Impacto: por enquanto,
não há plano de
contingência. A partir
da segunda iteração
espera-se ter mais dados
para um plano robusto e
austero para esse risco.
136
Probabilidade:
aceitar, pois estamos
trabalhando com
o mesmo líder de
engenharia para
Nenhum dos projetos
discutir os assuntos
anteriores teve esse
com os técnicos dos
evento (probabilidade)
projetos arquitetônicos,
R5 – e quando houve
estruturais, hidráulicos,
Incompatibilização algum problema, foi
Baixa Médio elétricos, iluminação,
de projetos de facilmente contornado
sonoro e segurança.
construção pelos técnicos sem
Impacto: as questões
qualquer intervenção
serão gerenciadas
executiva do gerente de
pontualmente, não
projeto (impacto).
sendo necessário, para
o momento e para
situações passadas
analisadas, uma ação
mais contundente.
Probabilidade: foi feita
uma consulta on-line
no site da prefeitura e
uma ligação telefônica,
dizendo que o processo
de liberação ocorre em
uma semana. Assim,
o canteiro de obras
poderá iniciar com
não tem todos os
licença provisória nesse
procedimentos e
horizonte de tempo.
R6 – Não conseguir exigências que a
Com o protocolo
os alvarás em prefeitura faz para a
Média Alto da documentação
tempo para abertura de um novo
solicitada pela
inauguração comércio na cidade
prefeitura, poderemos
(probabilidade). Sem
ter mais realidade
alvará, a loja não pode
nessas conjecturas.
funcionar (impacto).
Impacto: não há planos
de contingência,
uma vez que não
há disponibilidade
de imóveis com
as características
necessárias para a loja
nessa cidade.
137
Probabilidade: já está
comprovado que
esse risco é iminente.
Mesmo que haja uma
terceirização do serviço
de obras operacionais,
a probabilidade não
se altera e a multa
contratual da empresa
terceirizada não
compensa os impactos
gerados. Assim, o
Em projetos anteriores,
gerente de projetos
observou-se que
sugere o uso de buffer
todos (probabilidade)
de cronograma para
sofrerão impactos
R7 – Rotatividade acomodar esse risco
Alta Alto superiores a 15% do
de pessoal na obra e ir gerenciando esse
tempo (impacto) por
risco de forma semanal.
conta de rotatividade
Também, como ação
do pessoal de
estruturante, analisar
construção civil.
com o departamento
pessoal, técnicas de
melhorias no clima
organizacional
das pessoas que
trabalham nos níveis
mais operacionais,
mitigando a chance de
um desligamento por
questões banais.
Impacto: uso do buffer de
cronograma.
Probabilidade: nessa
versão inicial do plano
há um pacote de trabalho
para divulgação externa
A questão da de vaga. Mas o gerente
capacitação e de projeto irá se reunir
orientação de novos com o departamento
colaboradores em de pessoas para saber o
cidades fora da matriz que pode ser realizado
foram problemáticos a partir da segunda
R8 – Defasagem de em projetos anteriores iteração para mitigar
conhecimento dos (probabilidade) e esse risco.
Alta Alto
vendedores maior é importante que a Impacto: existe um plano
que o esperado empresa mantenha de contingência possível
o padrão e a cultura que é liberar dois
organizacional e vendedores seniores
consiga chegar nas de lojas da matriz,
pessoas que farão o com ampla vivência na
contato direto ao cliente empresa, que poderão
(impacto). ganhar diárias para
trabalhar duas semanas
ou quanto necessário na
cidade em questão para
mitigar impactos.
138
FIGURA 1 – GRÁFICO DE BOLHAS: RISCOS DO PROJETO
Como é observado, no quadro 4 acima, o gerente de projeto entende que a

primeira versão do plano deve ser legitimada pelos patrocinadores, mas de forma
ética, responsável e transparente, aponta as limitações dessa versão do plano.
Essa é uma decisão arrojada, mas importante, pois caso o GP espere para
iniciar o seu trabalho com todas as informações e planos de mitigação em mãos,
pode estender demasiadamente o início do projeto. Muitas vezes, os riscos mais
importantes e impactante em um projeto só pode ser identificado durante a
própria execução. O esforço em catalogar os riscos foi realizado e as limitações do
plano apontadas de forma explícita. Isso é o mais importante.
Neste sentido, ao final do processo de planejamento, os seguintes documentos

de projeto foram elaborados, conforme representado na figura a seguir:
FIGURA 2 – DOCUMENTOS DO PLANEJAMENTO DO PROJETO
139
RESUMO DO TÓPICO 1
• A gestão e riscos buscam antever planos alternativos que possam ser acionados
ou planos ostensivos, que para em um cenário que algo dê errado, ou alguma
premissa não seja confirmada, o gerente de projetos já consiga ter em mãos
alguns planos de ações.
• A identificação dos riscos pode ser realizada de uma forma mais informal, com
simples papéis colados na parede, com sistemas de informações simples, como
bloco de notas ou estruturação de lembretes, mas também podem ter aplicações
mais elaboradas, como uma planilha eletrônica onde haja um identificador
para cada risco.
• Os riscos são avaliados por duas dimensões, sendo a primeira o impacto para
o sucesso do projeto e a segunda a probabilidade de que ele aconteça.
• Após a ordenação dos riscos pela sua exposição, inicia-se a análise de planos
de resposta aos riscos.
140
AUTOATIVIDADE
1 Elabore um plano de resposta aos riscos listados a seguir para a realização

da festa de formatura, identificando sua probabilidade, impacto e um plano
de respostas para cada um.
Descrição do risco Probabilidade Impacto Plano de resposta
R1: Atrasos de um
fornecedor
R2: Falta de recursos
para execução da festa
R3: Local de difícil
acesso para convidados
R4: Qualidade do buffet
e bebidas
141
142
UNIDADE 3
TÓPICO 2
MOBILIZAÇÃO DA EQUIPE
1 INTRODUÇÃO
Uma vez realizado o planejamento do projeto, inicia-se um grupo de novas
atividades para que seja possível materializar o plano em um produto e assim
alcançar os objetivos propostos pelo termo de abertura de projeto. Entretanto,
o principal desafio, nesse momento, para o gerente de projeto é garantir o
alinhamento entre o termo de abertura de projeto e o plano de projeto, com a
execução.
Além disso é fundamental que o gerente do projeto esteja atento para

que durante a execução a equipe possa fornecer oportunidades de melhoria nos
planos. É durante a execução que muitas formas mais simples e fáceis de executar
uma atividade são observadas.
Deste modo, a execução se torna complexa, por justamente possuir duas

vias. Uma via diz respeito ao planejamento, ditando as atividades que devem ser
executadas, já na outra via, o gerente de projeto observando a reação da equipe e
obtendo insumos de melhoria contínua no seu plano.
Entretanto, não existe uma forma matemática exata para que um

determinado desvio possa ser explicado por uma limitação de planejamento ou
uma falha na execução. O importante é que o gerente de projeto tenha em mente
essas duas possibilidades, sempre que houver um desvio do planejado, este pode
ser um problema de execução, mas também pode ser um problema ou limitação
do plano proposto.
A decisão entre essas duas alternativas é feita basicamente pelas pessoas.

A equipe do projeto deve estar arregimentada e alinhada de forma contínua,
e assim, o gerente de projeto deve estar em constante relacionamento com sua
equipe.
Deste modo, para garantir o alinhamento, é desejável que pelo menos

um membro da equipe participe de todo o planejamento do projeto. Com essa
participação, este membro consegue legitimar o plano, tornando assim um senso
de propriedade. O plano não pode ser uma ideia do gerente de projeto e este ser
o detentor da verdade absoluta, mas sim, deve mobilizar a equipe para que ela se
torne a dona do projeto.
143
Assim, uma reunião inicial é fundamental para que se apresentem os

planos e a estratégia para execução das atividades de projeto. As reuniões são um
instrumento poderoso durante a execução do projeto, e elas são necessárias para
avaliar constantemente a necessidade de adequação dos planos ou a necessidade
de melhoria na execução.
Conforme comentado na unidade anterior, boas reuniões se iniciam muito

antes das pessoas entrarem na sala. As reuniões devem ser marcadas o quanto
antes pelo gerente de projeto e, para a categoria de reuniões de acompanhamento
de projeto, o agendamento prévio já é possível ao início do projeto. Ou seja, se o
projeto tiver duração de 6 meses, é possível agendar todas as reuniões de controle
de forma quinzenal, informando assim todos os compromissos agendados para
stakeholders e a equipe com uma previsibilidade bem antecipada.
Ninguém considera adequado um convite de reunião em cima da hora,

principalmente em reuniões de monitoramento e acompanhamento, pois estas
seriam reuniões previsíveis. E, caso deixe para última hora, o gerente de projeto
pode ter dificuldades para que as pessoas tenham agenda livre para realizar uma
reunião importante.
Uma outra categoria de reuniões são as corriqueiras, de esclarecimentos

ou resoluções de problemas. Para este tipo de reunião é fundamental que o
gerente de projeto tenha uma pauta clara, com os itens a serem descritos e
principalmente, com o resultado final bem definido. Por exemplo, “essa reunião
será bem-sucedida se conseguirmos um plano de melhoria dos testes acordado
com os presentes”.
Além da pauta e resultados esperados bem definidos, é importante que

se evitem pautas iniciadas pelas palavras “discutir” ou “negociar”, uma vez que
esses verbos significam os meios, mas não os fins de uma reunião. Ninguém
entra em uma reunião para discutir ou para negociar, mas entra para resolver um
problema ou buscar alternativas de melhoria.
Outro ponto importante a se destacar é a identificação das pessoas

que precisam estar na reunião. Essas pessoas podem ser categorizadas como
obrigatórias ou optativas. Pessoas obrigatórias são aquelas que caso haja ausência,
a reunião deve ser imediatamente cancelada ou sequer iniciada. Já as pessoas
optativas são aquelas pessoas que mesmo sem sua presença a reunião pode
ocorrer. Ou seja, são pessoas que seria interessante que tivessem, mas que não
são obrigatoriamente relevantes para o alcance do resultado da reunião.
Uma dica importante neste ponto é, caso uma pessoa obrigatória não
consiga estar presente, ela possa delegar a sua participação para uma pessoa
indicada, porém essa pessoa delegada deve ter poder decisório, ou seja, a
autoridade e responsabilidade pelas decisões da reunião. Caso um delegado esteja
na reunião em nome de uma pessoa obrigatória, mas essa não conhece o teor da
144
TÓPICO 2 | MOBILIZAÇÃO DA EQUIPE
reunião e também não tem autoridade para tomar as decisões necessárias para
os resultados da reunião, o gerente de projeto deve cancelar o evento, poupando
tempo dos demais colegas presentes.
Essas dicas podem, para um gerente de projeto iniciante, ser um pouco

rigorosas demais, mas o gerente de projetos experiente sabe que reuniões ineficazes
começam onde as pessoas presentes não têm autoridade para mobilização de
recursos para o alcance dos resultados. Em suma, caso haja pessoas obrigatórias
ausentes, ou pessoas substitutas que não têm autoridade, a reunião deverá ser
realizada novamente.
Atualmente existem sistemas de informação colaborativos que podem

propor datas e horários para que se realize uma reunião. Mas, se o gerente de
projeto notar a dificuldade de obter uma agenda de horários para os participantes
obrigatórios, é importante que apresente esta dificuldade ao stakeholder de
influência superior, ou até chegar o patrocinador. E, ainda neste sentido, em um
projeto em que há uma necessidade de uma reunião para determinadas decisões
e as pessoas obrigatórias não conseguem comparecer, pode-se indicar um grave
problema de falta de comprometimento da organização com o projeto e isso deve
ser de conhecimento do patrocinador.
Outro ponto relevante para uma realização de reunião eficaz é a

disposição (layout). É desejável que todas as pessoas presentes possam manter
uma comunicação visual, então geralmente a disposição de cadeiras é realizada
em formato de “U”, conforme a figura a seguir:
FIGURA 3 – LAYOUT DE REUNIÃO "U"
FONTE: <https://pt.dreamstime.com/ilustrao-da-forma-de-u-image55056078>. Acesso em:

14 set. 2018.
145
Além da disposição das cadeiras, reuniões efetivas acontecem quando

existe um responsável por projetar, para visualização de todos, a memória de
reunião. Ou seja, a cada ponto de decisão, o gerente de projeto não anota em seu
caderninho o que foi decidido, mas sim, escreve uma memória de reunião onde
todos possam ver e aprovar o texto que está projetado.
Essa prática pode parecer burocrática, mas pode poupar muito tempo do
gerente de projetos. Caso ele não faça a memória de reunião em tempo real, além
do tempo gasto com a reunião, deverá ainda elaborar a memória e muitas vezes
um gerente pode ter reuniões sucessivas, ocasionando uma lentidão na emissão
destas memórias. Uma reunião efetiva ideal é aquela que quando os participantes
voltam as suas áreas de trabalho já receberam um e-mail com as decisões tomadas
pelo grupo da reunião.
O termo memória de reunião aqui descrito pode, em algumas organizações,

ser conhecido como ata de reunião. Contudo, a ata de reunião, além de se referir a
um documento formal e até legal, geralmente, relata o que aconteceu na reunião.
A memória de reunião não tem esse objetivo, deve ser simples, indicando apenas
o tema e o que o grupo definiu.
Como se pode observar, fazer uma reunião efetiva dá trabalho, portanto,

caso você indique uma reunião de 60 minutos, na verdade, é recomendável que
ocupe 50 minutos para discussão e deliberações e a utilização dos 10 minutos
finais para a apresentação da memória de reunião, identificar objeções, enviar a
memória para os participantes e então o convite para a próxima reunião sobre o
tema, se houver.
Uma reunião efetiva precisa de decisões unânimes, ou seja, em hipótese

alguma se deve criar uma memória de reunião onde a maioria decidiu algo e
explicita-se àquelas pessoas que foram contrárias à decisão da maioria. Essa
prática não apresenta qualquer benefício ao projeto e pode colocar essas pessoas
da minoria como pessoas que não têm mais compromisso com o sucesso do
projeto, uma vez que elas não concordaram com a decisão.
Uma boa prática, caso haja polaridade na decisão, é que o gerente de projeto
possa dar um tempo de alguns dias para que o grupo minoritário possa fazer um
relatório mais aprofundado dos seus argumentos, gerando uma nova reunião,
porém, esses casos devem acontecer para temas complexos e de alto impacto para
a organização ou para o sucesso do projeto e não devem ser executados para
questões onde o custo de uma reunião seja superior ao impacto negativo de uma
decisão “errada”.
Um gerente de projetos experiente jamais impõe a sua opinião, mas está

presente na reunião como um facilitador para que a equipe chegue ao resultado
unânime e que esteja alinhado com os objetivos do projeto. Caso não haja esse
alinhamento, o gerente não deve contrariar a sua equipe, mas sim, apresentar os
riscos e problemas daquela decisão e apresentar o termo de abertura de projeto
146
para a sensibilização das pessoas, demonstrando que aquela decisão é inadequada.

Em outras palavras, jamais o gerente de projeto deve usar a sua autoridade, ele
se impõe pela sua forma de conduzir uma reunião e as divergências da equipe.
Durante a reunião, é importante iniciar com a presença de todos os

obrigatórios, apresentar a pauta já em forma de memória de reunião em um
projetor e colocar para todos o tempo que ele dispõe para que a reunião encerre.
Reuniões sem prazo para terminar também se tornam reuniões ineficientes, pois
abrem discussões e oportunidades para temas informais ou temas fora de foco.
Caso, no meio da reunião, haja uma solicitação de mudança de pauta e

por unanimidade aceita, o gerente de projeto deve encerrar a primeira reunião e
iniciar a nova pauta com os presentes que desejarem e puderem participar. Deve-
se evitar aproveitar uma reunião como “muro de lamentações”, pois discussões
fora de pauta podem gerar impaciência e perda de tempo dos demais colegas
participantes.
Em outras situações, caso o tema seja polêmico ou polarizado, o gerente

de projeto pode designar um timer keeper ou um relógio, quando todos possam
averiguar se o tempo usado está adequado. Por isso, outra dica prática é que
as reuniões, caso sejam muito polêmicas, aconteçam em finais de período, por
exemplo, antes do almoço ou antes de término da jornada diária de trabalho,
provocando nos colegas uma autorregulamentação na reunião para que todos
consigam falar de forma objetiva e sucinta o que pensam e que consiga chegar ao
resultado da reunião com a maior brevidade possível.
2 HABILIDADES INTERPESSOAIS
O gerente de projeto é um profissional polivalente e com características,
às vezes, até mesmo, antagônicas. Podemos categorizar o gerente de projeto com
três habilidades, as habilidades técnicas no escopo do problema do projeto, o
domínio das técnicas de gestão de projeto e habilidades interpessoais.
As habilidades técnicas se referem ao entendimento para desempenhar

tarefas específicas a partir de conhecimento específico. Por exemplo, em um
projeto de desenvolvimento de software, o gerente de projeto deve ao menos
conhecer noções mínimas do que é desenvolver um software. Já em um caso
de um projeto para construção de uma casa, este deve ter noções mínimas de
construção civil.
As habilidades de gestão de projetos dizem respeito às técnicas

apresentadas neste curso, que proporcionam uma noção do passo a passo que
um gerente de projeto deve realizar para que o projeto seja bem executado.
147
Já as habilidades interpessoais são importantes para o relacionamento

com a equipe que compõe o projeto. A maioria dos projetos que encontramos no
mercado envolvem pessoas e dificilmente um gerente de projeto irá conseguir
êxito somente com sua autoridade, com poder de sanção e poder de recompensa.
Este terá que saber o momento de ser um líder mais motivador, quando vai
consolar a sua equipe e dizer o que é possível em certas situações, ou atuará de
uma forma ostensiva, pressionando para que se consigam os resultados de uma
forma efetiva.
As habilidades técnicas de gestão de projetos podem ser adquiridas em

cursos e capacitações contínuas e devem permear toda a trajetória da carreira
de um gerente de projetos, porém as habilidades interpessoais são dependentes
de um conjunto de fatores que somente o tempo e a experiência no papel como
gerente de projetos conseguirão aperfeiçoar.
Existem vários estudos que indicam o comportamento que deve ter um

gerente de projeto no seu nível interpessoal, porém, não será lendo que um gerente
de projeto iniciante irá adquirir essas habilidades interpessoais. Será por meio de
constante envolvimento físico com sua equipe, ou seja, o gerente de projeto deve
evitar o uso excessivo de dispositivos eletrônicos para sua comunicação com a
equipe e deve priorizar o contato presencial.
Neste sentido, vamos estudar adiante os sistemas de informação eletrônicos

de projetos e como esses sistemas auxiliam no controle do projeto de uma maneira
global, mas não pense que você como gerente de projeto irá gerenciar uma equipe
por meio, majoritariamente, de e-mails, mensagens instantâneas ou ordens de
pacotes de trabalho emitidas por um software.
Pelo contrário, as pessoas precisam de contato físico e um contato pessoal,

por isso é desejável que o gerente de projeto imprima versões de cronograma,
ou pelo menos dos pacotes de trabalho, e use esse papel para ir rabiscando e
editando com a sua equipe, assim a equipe ganhará um colega e o gerente de
projeto poderá caminhar em todas as áreas de trabalhos da sua equipe e não
somente sendo um emissor de e-mails.
O uso de dispositivos eletrônicos distancia as pessoas, deste modo, a

recomendação é que no início do dia as ordens de trabalho do dia sejam enviadas,
os e-mails urgentes sejam respondidos e assim o gerente de projeto entre em
contato direto com sua equipe, vendo e discutindo os problemas reais de cada
situação presencialmente.
Nesse ponto é importante o autoconhecimento, pois existem muitos

estudos de autoavaliação, sobre padrões de personalidade e características
pessoais. Alguns estudos criaram estereótipos como tentativas de enquadrar as
pessoas em determinados arquétipos (RIBEIRO FILHO, 2010).
148
Devemos sempre lembrar que a pessoa é singular, ela é complexa por si

mesma e jamais encontraremos mesmo dentro de uma família ou gêmeos, pessoas
com características pessoais idênticas. Os arquétipos, conforme a figura a seguir,
são interessantes para que o gerente de projeto possa primeiro fazer as reflexões
de certos padrões de comportamento que ele tem em relação a determinadas
situações, e então entender o comportamento de cada membro da sua equipe.
FIGURA 4 – ARQUÉTIPOS DE PERSONALIDADE
Existem pessoas mais práticas, sucintas, que gostam de ser diretas e que
não se ofendem facilmente e não levam as críticas como ações pejorativas. Mas
devemos também entender que existem pessoas que precisam do contato mais
humano, que precisam contar as histórias de uma maneira mais elaborada e se
fazer entendido, como também há as pessoas que necessitam de feedback, em
que devem ser meticulosamente medidas as palavras, pois podem ser entendidas
como uma ofensa ou até gerar uma insegurança pessoal naquela pessoa.
Reitera-se que as pessoas são únicas e singulares, mas podemos usar os

arquétipos para conseguir lidar com cada uma, mas jamais rotulá-las de uma
forma estática, até porque as pessoas mudam conforme fatos que acontecem na
sua vida pessoal e profissional.
Em um determinado enquadramento poderíamos apresentar as pessoas

que são mais racionais, pessoas que tomam suas decisões baseadas na lógica
dedutiva e procuram dentro de si e do seu intelecto as melhores decisões. Outro
arquétipo contrário são pessoas mais sociais e que precisam pertencer a um grupo
para tomar a sua decisão, geralmente, esse arquétipo é de pessoas que precisam
conversar com outras para gerar o seu próprio entendimento, que apreciam a
opinião alheia para flexibilizar a sua decisão perante o grupo, assim, muitas
vezes, tomam decisões baseadas nos impactos que podem ter em outra pessoa.
149
O terceiro arquétipo são aquelas pessoas extremamente cautelosas e

procedimentais, são pessoas que precisam ter regras claras e processos explícitos
e documentados para que possam se sentir seguras e executar um bom trabalho.
De modo oposto, existem pessoas cujas decisões são baseadas após a ação, ou seja,
são pessoas experimentais. Possuem um palpite da melhor decisão e começam a
fazer experimentos ou até a executar uma atividade de forma a aprender ao longo
do caminho.
Você pode estar se enquadrando em um desses arquétipos, porém, o

principal equívoco é achar que um gerente de projetos bom é de determinado
arquétipo. O gerente de projetos deve se autoconhecer para que consiga saber
as suas potencialidades e também as suas fraquezas, que consiga lidar com uma
determinada situação e consiga saber se ele vai se importar mais de uma maneira
nativa da sua personalidade ou vai ter que ser desafiado ou auto desafiado para
superar aquela sua forma de agir para que o projeto seja bem-sucedido.
Retomando os arquétipos acima, as pessoas racionais são boas em

planejamentos, em fazer orçamentos, ações e cronogramas, em pensar em cenários
lógicos e pensar em fatos e dados que possam corroborar para uma decisão,
porém, as pessoas que têm um comportamento extremamente racional tendem
a ser mais isolados, não tem muito envolvimento com as pessoas e podem ser
rotulados como pessoas frias.
Por outro lado, as pessoas com a sensibilidade e a socialização como

potencial são verdadeiros integradores de equipe, pois essas pessoas animam o
ambiente de trabalho, conseguem cativar as pessoas para um objetivo comum e
conseguem muitas vezes com um breve papo trazer a equipe de um baixo astral e
de uma dificuldade do projeto para uma situação mais confortável e motivadora,
porém, se essa característica for executada de uma forma exacerbada, o gerente
de projeto pode deixar os objetivos de projetos em segundo plano para que o
clima organizacional da equipe esteja bom e muitas vezes essa equação não é
possível.
As pessoas com características cautelosas ou procedimentais são de

natureza extremamente organizada, que conseguem transmitir segurança
às pessoas, pois conseguem explicitar com cuidado todos os procedimentos
e processos que devem seguir para cada pacote de trabalho do projeto. Essas
pessoas conseguem estruturar modelos organizacionais com regramentos,
conseguem organizar um grande volume de pessoas para um objetivo comum
por meio de processos, modelos de documentos ou sistemas de informação.
Entretanto, de uma forma exacerbada, essa característica pessoal pode

tornar uma dificuldade no projeto, pois impede que melhorias nos processos sejam
realizadas, pois estes toleram pouco a mudança. Em projetos de muita inovação,
onde haja a todo instante novas evidências de premissas e novos conhecimentos
gerados, a aprendizagem pode gerar desconforto pela instabilidade do
planejamento.
150
O gerente de projeto com personalidade experimental tem uma grande

vantagem em projetos em que exista um grau de incerteza muito alto, pois a
incerteza, como observamos nas seções anteriores de planejamento, não são
possíveis de resolver apenas com o pensar, a reflexão e a proposição de planos,
mas sim é necessário à execução de certos elementos e atividades. Para dissipar
essas dúvidas e gerar um planejamento mais próximo da realidade, essas são
pessoas essenciais em momentos de problemas, pois geram oportunidades de
melhoria a todo instante.
Porém, de uma forma exagerada, uma pessoa com essa característica pode
colocar o projeto em risco, pois a ação pode ser muito intensa e com pouca reflexão
aos objetivos do projeto, tornando então o projeto um sucessivo ciclo de refazer
a cada dia, ou a cada iteração, um novo planejamento gerando intermináveis
retrabalhos.
Você pode pensar qual é a melhor característica? Como vimos, não existe
a melhor característica, somente nesses exemplos simples, você pode observar
que as pessoas com essas características têm potencialidades e, principalmente,
são ideais em determinado ponto do projeto, mas também têm fragilidades.
Desse modo, não se pode mudar um gerente de projeto a cada situação ou

cada tipo de projeto, mas o gerente de projetos, sim, pode ter seu autoentendimento
e saber que naquele momento ele pode exagerar nas suas características pessoais,
pois são benéficas ao projeto, porém, em uma situação adversa, é necessário se
desafiar a se comportar de outra maneira, ou se associar com outras pessoas da
equipe para que se possa garantir a integração do projeto.
3 LIDERANÇA
A liderança em projetos, uma das habilidades fundamentais que o gerente
de projetos precisa ter para o sucesso nas suas execuções de projeto, é fundamental
pois impacta no desempenho da equipe e esta é o principal fator para o sucesso
do projeto.
A liderança é um tema bastante debatido nos estudos na área de psicologia

organizacional, existem inúmeros trabalhos de como lidar e trabalhar com esse
tema. O estudo da liderança na área de gestão de projetos diz respeito a como o
gerente gerencia os membros de sua equipe para que consiga um alinhamento com
os objetivos propostos e ainda sim consiga ter a satisfação da execução do projeto.
Como existem vários conceitos e metodologias diferentes sobre liderança

em psicologia organizacional, optou-se neste livro por um de maior cunho
prático e aplicado para os iniciantes. Toda via, vale lembrar que esse tema precisa
ser melhor entendido e aprofundado com leituras especializadas sobre o tema,
principalmente para o entendimento de qual metodologia se encaixa melhor com
o estilo de habilidades pessoais do gerente de projeto em questão.
151
Como vimos na seção anterior, o gerente de projeto precisa ter um alto

conhecimento de suas fragilidades interpessoais e suas potencialidades e, a
partir da análise do contexto, saiba qual é o momento de estar mais perto de
sua realidade nativa de sua característica pessoal ou quando tem que exercitar a
sua capacidade transformadora. Além do seu autoconhecimento, existem alguns
procedimentos básicos, conforme a figura a seguir, para que os mecanismos e
processos de liderança consigam ser operacionalizados durante a execução do
projeto, o primeiro é a seleção da sua equipe.
FIGURA 5 – PROCEDIMENTOS BÁSICOS DE LIDERANÇA
FONTE: Adaptado de: Souza (2015, s.p.)
A seleção das pessoas que irão compor a equipe deve ser criteriosa, pois
muitos problemas de desempenho se dão por uma designação a um pacote de
trabalho a uma pessoa que não tenha habilidade e atitude para executar aquela
tarefa. Dessa forma é importante que o gerente de projetos tenha um maior nível
de autonomia para que ele escolha sua equipe.
Reitera-se que não existe fórmula mágica para trabalhar e regimentar

uma equipe, porém, recomenda-se que uma equipe comprometida pode
superar algumas habilidades técnicas. Entretanto, caso tenha uma equipe
qualificada, tecnicamente superior, mas que não tem as habilidades interpessoais
desenvolvidas e a motivação inerente ao clima organizacional adequado, ele
pode trazer sérios problemas para o projeto.
Assim, a recomendação é que você tenha uma seleção criteriosa de

pessoas, e além do perfil técnico, é indicado que sinalize também a questão
comportamental frente ao modelo de referência, como os arquétipos citados
na seção anterior, quanto mais plural uma equipe mais polivalente ela vai ser.
152
A palavra polivalente significa que uma pessoa, mesmo que seja um exímio
especialista em uma determinada área, em algum instante do projeto pode
precisar assumir outro papel que pode não ser a sua especialidade e nesse
momento a questão de motivação e a relação interpessoal é mais importante que
sua habilidade técnica.
Neste sentido, a recomendação é o equilíbrio entre as habilidades técnicas

da equipe, mas também com as habilidades interpessoais e comportamentais,
assim durante a seleção da equipe de projeto, dependendo da sua formação, o
gerente de projeto poderá solicitar apoio da área ou dos profissionais da psicologia
e de profissionais que sejam experientes no recrutamento e seleção de pessoas.
O segundo elemento de liderança é a clarificação de resultados e a

explicitação formal e escrita do que se espera de cada membro de sua equipe
(SOUZA, 2015). É fundamental para um bom líder que a comunicação consiga
sair da oralidade para a escrita, em que se possa constantemente recorrer para
relembrar e reforçar os objetivos daquela pessoa. Clarificar resultados e explicitar
em forma escrita os objetivos de uma pessoa não é uma tarefa das mais simples.
O gerente de projeto deve garantir que a soma dos objetivos individuais resulte
nos objetivos do projeto. E essa atividade deve ser pensada meticulosamente
pelo gerente, pois caso não faça essa atividade de forma adequada, pode ocorrer
de todos os membros da equipe alcançarem seus resultados individuais, mas os
objetivos coletivos do projeto amargarem o insucesso (BLANCHARD et al., 1986).
Como dica prática, os objetivos devem ter uma entrega clara e uma
meta de prazo para sua conclusão, geralmente, a meta de prazo é estabelecida
ao fim de uma iteração, assim fica simples a sua mensuração. A entrega clara
tradicionalmente é um substantivo sucedido de um verbo no particípio, como
“relatório de testes submetido ao controle de versão” e não somente “elaborar
um plano de teste”.
Com esses objetivos classificados, o segundo ponto é o nível de

acompanhamento que o liderado irá precisar do gerente de projeto. O
acompanhamento pessoal é uma questão fundamental para que as pessoas
consigam suprir as suas necessidades e se sentirem seguras em uma determinada
função. Não é recomendável que o gerente de projeto assuma uma posição
como líder, seja mais delegador ou mais controlador, pois diferentes pessoas em
diferentes atividades podem requerer níveis de acompanhamento diferenciados
e isso pode variar a cada ciclo de objetivos.
Neste sentido, o ciclo de objetivos geralmente remete aos marcos do

projeto, porém, pessoas de baixa maturidade técnica em determinado objetivo ou
para determinados procedimentos inerentes aos objetivos podem requerer um
nível de acompanhamento maior. Por outro lado, a pessoa que tem uma base
histórica qualificada no desempenho daquelas práticas ligadas ao objetivo em
que foi designada, pode necessitar de um acompanhamento menor durante a
execução.
153
Dessa forma, o gerente de projeto deve analisar o perfil da pessoa, fatos,

dados de seu passado e também atividades executadas. Importante lembrar que,
não se pode delegar a uma pessoa uma atividade dando total liberdade, visto que
no passado ela não apresentou experiência naquela execução.
Outro erro comum de liderança é dar autonomia para uma pessoa que
seja experiente profissionalmente. Por exemplo, um desenvolvedor de software
com muita experiência, com mais de 20 anos de execução de diferentes tipos de
projetos, mas somente programando, agora este assume a função de arquiteto
de softwares. Apesar da sua experiência pregressa e de alta maturidade em
programação e desenvolvimento de software, na área de arquitetura de software
ele deve ser tratado com uma pessoa de baixa maturidade técnica. Novamente,
caso a maturidade seja baixa é necessário um maior acompanhamento, caso a
maturidade seja alta, menor o acompanhamento do gerente de projeto.
Todavia, essa definição não é estática. Voltando ao exemplo, o programador

pode nas primeiras semanas ser tratado como uma pessoa de baixa experiência,
mas o gerente de projeto rapidamente a treina, observa e capacita. Já nas primeiras
semanas o gerente de projeto detecta que ele pode ter maior autonomia, e assim
o considera uma pessoa de alta maturidade.
Na mesma situação no pensamento inverso, muitas vezes, um profissional

experiente recebe autonomia, porém ele começa, por fatores externos, a ter um
desempenho baixo. Desse modo, o nível de acompanhamento deve ser maior, até
que ele consiga apresentar um desempenho adequado.
Importante destacar que o nível de acompanhamento não quer dizer

cobrança, pelo contrário, o gerente de projeto ao acompanhar uma pessoa e um
profissional sobre sua liderança deve apoiá-lo na execução do projeto e buscar
suprir as necessidades e transpor os obstáculos que possam advir daquela
insegurança natural de executar uma atividade pela primeira vez. Caso seja uma
habilidade técnica, que o gerente de projeto não consiga suprir, é preciso detectar
essa defasagem e imediatamente deslocar um profissional, seja interno ou externo
ou até mesmo requerer uma capacitação para que aquele liderado consiga suprir
aquela defasagem.
Em suma, o acompanhamento em termos de liderança de projeto é para

a melhoria de desempenho e jamais para ampliar o nível de cobrança que já é
natural das organizações e principalmente na ótica de projetos, com prazos e
orçamentos ostensivos.
Outro elemento importante da liderança é o feedback. O feedback é um

instrumento de melhoria de desempenho, em que o líder, no caso o gerente de
projeto, irá proferir e comparar os resultados obtidos naquele ciclo de objetivos
com os resultados dos fatos e dados do projeto. Um bom feedback é uma reunião
de duas pessoas, evitando então presenças alheias e constrangimentos ao liderado
(HUNTER, 2006).
154
Por ser uma reunião, o feedback então se inicia bem antes, na determinação
de objetivos. Uma vez que há um acordo de objetivos entre o líder e liderado e
do nível de acompanhamento desejado pelo liderado, o gerente de projeto envia
os objetivos, daquele ciclo de avaliação e o convite para uma reunião, com data
horário e local agendados, onde serão dados os feedbacks e a atualização de
objetivos para o próximo ciclo. Ou seja, a atividade de clarificar os resultados,
os objetivos individuais e o agendamento da execução de feedback é uma tarefa
corriqueira e rotineira do gerente de projetos de forma individual.
A frequência dessas reuniões de clarificação e feedback também devem

variar conforme a maturidade do profissional naquela atividade, ou seja, se for
um profissional de ampla maturidade técnica em determinada função, pode-se
sugerir feedbacks a cada três meses, por exemplo, porém, quando se trata de
uma pessoa inexperiente e em formação é possível que sejam necessários ciclos
semanais de clarificação e feedback.
Um bom feedback não pode ser surpresa para o liderado, pois com a
clarificação de resultados e com a explicitação das entregas, o próprio liderado
deve estimar se teve um desempenho bom ou ruim. Por isso é tão importante
uma boa clarificação de resultados, não apenas informar “a minha equipe gostou
do meu trabalho” porque esse tipo de objetivo não traz benefício ao projeto.
Deve-se iniciar o feedback com atenção à duração, que deve ser estimada
de forma a apresentar os resultados e os seus argumentos para o liderado, e caso
algum objetivo não seja alcançado, ou algum desempenho pessoal for inferior a
normalidade, é importante que o gerente de projeto apresente possíveis causas
e o que era esperado de comportamento daquele profissional. Assim, um bom
feedback requer uma coleta de dados de pares e supervisores, de forma a trazer
elementos factuais que consigam convencer e explicar ao liderado os pontos que
ele precisa melhorar no próximo ciclo de avaliação.
Apesar do gerente precisar ser sempre autocrítico, alguns problemas de

desempenho não recaem necessariamente no gerente de projeto, mas no liderado,
que deve sair da reunião de feedback com esse reconhecimento e com o que
deve ser aperfeiçoado. Caso isso não aconteça, o liderado pode sair da reunião
de feedback se sentindo injustiçado, novamente um sintoma de uma falha de
processo de liderança que deve ser corrigido pelo gerente de projetos.
Na reunião de feedback é importante que o liderado saiba ouvir, o gerente

de projeto pode explicar no começo da reunião como funciona o procedimento e
que o importante não são as justificativas nesse momento, mas sim o entendimento
da defasagem de desempenho e como corrigir. Caso o liderado queira se
manifestar em um ponto que ele não concorde, por exemplo, pode haver uma
defasagem no equipamento ou no software que ele precisava usar para executar
uma determinada atividade e não foi disponibilizado pelo gerente.
155
Para executar adequadamente sua tarefa o liderado necessita de uma

balança eletrônica de medição digital, mas este tem disponível apenas uma
balança de medição analógica. Ou seja, esse instrumento dado pelo gerente de
projeto de forma analógica impediu que ele tivesse um desempenho melhor em
suas atividades.
Dessa maneira, o gerente de projeto deve avaliar se a disponibilização de

uma balança eletrônica está dentro do orçamento e especificações do projeto, e caso
esteja, deve ser corrigido esse problema de desempenho com a disponibilização
dos recursos adequados e solicitados pelo liberado, porém, caso não haja essa
possibilidade, o gerente de projeto deve avaliar criteriosamente se a pessoa é
adequada para a função.
Os objetivos do projeto são maiores, e nesse exemplo dado da balança

eletrônica e analógica, o gerente de projeto deve tomar a decisão de continuar
investindo no liderado com mais capacitação, melhorando procedimentos para
que ele consiga usar aquele instrumento disponível, se deve ocorrer uma troca
de pessoas, seja ela dentro da equipe ou dentro dos departamentos, e em última
instância uma demissão. Uma demissão é sempre o resultado de uma admissão
inadequada, por isso existe a máxima em gestão que “deve-se ser rápido para
contratar, mas o mais rápido possível para demitir”.
Com esses ciclos sucessivos de clarificação de resultados e feedback

ocorrendo de uma maneira adequada, onde as partes saibam o que deve ser
melhorado, seja ele o gerente de projeto ou o liderado, existem ainda dois
processos de liderança estratégicos também relevantes, a capacitação continuada
e os mecanismos de recompensa.
Esses dois mecanismos, muitas vezes, não estão sobre a alçada do gerente de
projeto. A capacitação continuada lida com os programas anuais de treinamento,
que normalmente as empresas comprometidas com seus funcionários possuem.
Este planejamento anual apresenta as habilidades técnicas que as pessoas devem
desenvolver em um determinado período, e esses treinamentos são agendados
corporativamente conforme os ciclos de feedback. Ou seja, se existir uma
competência, por exemplo, aprimorar uma linguagem de programação, e um
determinado desenvolvedor está com uma defasagem naquela linguagem, a
organização deve investir em capacitações continuadas a longo prazo naquele
profissional para que ele consiga progredir na sua carreira.
O mecanismo de recompensas é ainda mais delicado do ponto de vista

de projetos, mas vale lembrar que as recompensas necessariamente não precisam
ser financeiras, como participação de lucros e resultados. Muitas vezes, as
recompensas podem ser expressadas em pequenos gestos de reconhecimento
público ou de brindes para a equipe, mesmo que simbólicos representam o apreço
do gerente de projeto para com aquela pessoa que tem alto nível de desempenho.
156
Novamente cabe destacar que, os dois temas são recorrentes em psicologia

organizacional e existem as mais variadas correntes de como resolver tanto a
capacitação continuada com ação de recompensas. Seja ela coletiva ou individual,
é importante que o gerente de projeto seja justo, o equilíbrio das recompensas
individuais e coletivas são importantes e recomenda-se que haja uma parcela das
recompensas que sejam de cunho coletivo.
Conforme vimos, a questão de liderança em projetos talvez seja uma das

mais complexas a executar e requer muita dedicação e, principalmente, o mais
valioso recurso do gerente de projetos que é o seu tempo. Liderar requer tempo e
o desenvolvimento de pessoas também irá requerer.
QUADRO 5 – CLARIFICAÇÃO DE RESULTADOS
157
RESUMO DO TÓPICO 2
• É fundamental que o gerente do projeto esteja atento para que durante a

execução a equipe possa fornecer oportunidades de melhoria nos planos.
• É desejável que pelo menos um membro da equipe participe de todo o

planejamento do projeto.
• Podemos categorizar o gerente de projeto com três habilidades, as habilidades

técnicas no escopo do problema do projeto, o domínio das técnicas de gestão
de projeto e habilidades interpessoais.
• Pessoas são únicas e singulares, mas podemos usar os arquétipos para

conseguir lidar com cada uma, mas jamais rotulá-las de uma forma estática, até
porque as pessoas mudam conforme fatos que acontecem na sua vida pessoal
e profissional.
• A liderança em projetos é uma das habilidades fundamentais que o gerente de

projetos precisa ter. O sucesso nas suas execuções de projeto, é fundamental
pois, impacta no desempenho da equipe e esta é o principal fator para o sucesso
do projeto.
158
AUTOATIVIDADE
1 Liste e descreva as principais habilidades que um gerente de projetos deve

possuir.
2 A partir das afirmações apresentadas, identifique a que aspecto de liderança

esta característica se refere:
Em muitos casos as ___________________ podem ser expressadas em pequenos

gestos de reconhecimento público ou de brindes para a equipe, mesmo que
simbólicos representam o apreço do gerente de projeto para com aquela pessoa
que tem alto nível de desempenho.
A equipe deve ser composta de forma criteriosa, deste modo, para a
_________________ além do perfil técnico, é indicado que se sinalize também a
questão comportamental desejada.
O ____________________ é uma questão fundamental para que os membros
da equipe consigam suprir as suas necessidades e se sentirem seguras em uma
determinada função.
O ____________________ é um instrumento de melhoria de desempenho, onde
o líder, no caso o gerente de projeto, irá proferir e comparar os resultados
obtidos naquele ciclo de objetivos com os resultados dos fatos e dados do
projeto.
A atividade de ________________ deve ser realizada de modo a conceder ao
membro da equipe uma explicação formal dos resultados esperados.
159
160
UNIDADE 3
TÓPICO 3
COMUNICAÇÃO DO PROJETO
1 INTRODUÇÃO
A gestão de comunicação é um elemento importante na execução dos
projetos. Destaca-se que a comunicação, às vezes, é representada por meio de
reuniões, que já foram objeto dos tópicos anteriores. Na verdade, durante vários
momentos do planejamento e execução deste curso, além das reuniões, toda parte
de liderança também pode ser representada como um elemento de constante
comunicação.
Uma comunicação ocorre quando existe um emissor e um receptor, ou

seja, é preciso uma pessoa que queira passar uma informação e outra para receber
essa informação. Também para que haja comunicação, é importante um assunto
a ser comunicado, um objeto a ser comunicado e a forma como será comunicado,
assim a gestão da comunicação se centra nesses quatro elementos.
2 SISTEMAS DE COMUNICAÇÃO DE PROJETOS

Para iniciar um planejamento e a gestão da comunicação é necessário
identificar quais são as informações que os stakeholders querem receber e qual é o
nível de formalização que essa comunicação se dará. Também se faz necessário
definir a periodicidade ou gatilho que dará início a comunicação, por exemplo,
o objeto de relatório de desempenho de projeto geralmente é emitido ao final de
uma interação, então é interessante que o plano de comunicação não tenha datas
fixas, mas o gatilho, que é o encerramento da interação.
O nível de formalização é importante em algumas situações, por exemplo,

em comunicações que envolvem contratos de terceiros, é relevante que as
comunicações sejam formais e que tragam alguma evidência do que foi decidido
ou solicitado, como um e-mail ou adendo de contrato ou até mesmo um novo
contrato em comunicações mais formais.
A comunicação do dia a dia geralmente é informal e não gera registros,

então se deve diferenciar o que seja um simples bate-papo e esclarecimento de
dúvidas entre a equipe e as reuniões de projeto. Lembrando que as reuniões
devem gerar as memórias de reunião para formalização do que foi decidido e os
encaminhamentos da decisão do projeto.
Em gestão de projetos alguns objetos são clássicos e dificilmente estarão

fora do planejamento de comunicação, conforme o quadro a seguir:
161
QUADRO 6 – COMPONENTES PLANO DE COMUNICAÇÃO
A comunicação do projeto deve seguir a formalização necessária, ou

seja, para equipes menores, quando se possa recorrentemente reunir-se em
questão de instantes, a comunicação deve ser mantida em níveis de formalidades
baixa. Assim, pouca burocracia e alto nível de comunicação informal, exceto
nos momentos críticos, quando haja uma reunião com uma pauta específica. Já
projetos maiores, em que exista um número maior de membros na equipe, se
faz necessário um nível de formalização maior na estruturação da comunicação,
então dificilmente ocorrerá uma reunião com toda a equipe, mas várias reuniões
em que haja uma estruturação de liderança para propagação dessa comunicação.
Então, para que haja integridade que a informação não seja alterada ao longo
da cadeia hierárquica, há a necessidade da formalização através de e-mails ou
portais.
Existe uma boa prática para evitar os e-mails para questões de projeto,
uma vez que os e-mails são de uso recorrente e, às vezes, múltiplos projetos
emitem muitos e-mails, e somados aos e-mails corporativos e pessoais, tornam
nossas caixas postais um volume intenso de dados com que não conseguimos
lidar ou quando conseguimos, nos tomam muito tempo.
Assim, é de bom tom que se adote um sistema de informações de projeto,

e que todas as comunicações ocorram dentro dele. Toda a comunicação entre a
equipe e com o gerente de projeto deve ocorrer associado a um pacote de trabalho,
questão ou risco associado ao projeto.
Dessa maneira, se torna mais fácil gerenciar o projeto, uma vez que o
gerente de projeto pode acessar o banco de dados onde encontra as questões de
projeto, podendo ordenar pela severidade e analisar quais são as questões de
projeto que não tiveram atualização nos últimos dias e assim cobrar então dos
responsáveis alguma providência. Geralmente, visto que o sistema é adotado
maciçamente pela equipe, praticamente, elimina toda comunicação de projeto
por e-mail, proporcionando assim transparência às decisões e às providências
tomadas por cada um dos membros de projeto.
162
TÓPICO 3 | COMUNICAÇÃO DO PROJETO
Também é importante a utilização de sistemas de informação para a

colaboração de documentos. Estes documentos principais, o termo de abertura de
projeto e os planos de cronograma e orçamento, devem ser colaborados por toda
a equipe. Entretanto, deve-se ter cuidado para que a versão oficial do projeto,
chamado de linha de base, seja identificada para que eventuais alterações não
aprovadas sejam imediatamente identificadas, uma vez que toda alteração de
projeto deve ser formalizada por um comitê de mudanças.
EXEMPLO
Um exemplo de plano de comunicação está representado na figura a
seguir, que apresenta cada documento gerencial e técnico, se a comunicação é
mandatória, qual público-alvo, o meio de comunicação, frequência e responsável
pela elaboração do documento.
QUADRO 7 – EXEMPLO DE PLANO DE COMUNICAÇÃO
Público-alvo
Uma das ferramentas mais utilizadas atualmente para gerenciar a

comunicação de projetos é o Trello, conforme a figura a seguir. Esse serviço tem
uma versão gratuita para projetos menores e planos para uso corporativos. O
exemplo que segue se destina a tornar o conteúdo mais claro para o aluno e pode
ser adaptado para outras ferramentas.
163
FIGURA 6 – KANBAN NO TRELLO
FONTE: Trello (2018, s.p.)
Para a utilização do Trello como ferramenta auxiliar na gestão de projetos,

é possível utilizar ferramentas que auxiliam na gestão dos pacotes de trabalho.
Conforme o exemplo acima, é possível a criação de um quadro Kanban para
melhor visualização e, para controle os demais controles, ainda é possível
incluir a data de entrega da atividade, o responsável por desempenhá-la, anexar
documentos, entre outros, conforme a figura que segue:
164
TÓPICO 3 | COMUNICAÇÃO DO PROJETO
FIGURA 7 – INFORMAÇÃO DA ATIVIDADE (TRELLO)
FONTE: Trello (2018)
Neste sentido, outra funcionalidade importante nos sistemas de apoio à

gestão de projetos é que exista um controle de versão. Um documento que pode
ser editado por todos, pode ser editado de uma maneira inadequada por um
membro, dessa forma, é necessário identificar e voltar à versão anterior. Caso
não tenha esse controle de versão, pode haver equívocos e trabalhos podem ser
perdidos.
165
RESUMO DO TÓPICO 3
• A gestão de comunicação é um elemento importante na execução dos projetos.
• Para iniciar o planejamento e a gestão da comunicação, é necessário identificar

quais são as informações que os stakeholders querem receber e qual o nível de
formalização que essa comunicação terá.
• A comunicação do projeto deve seguir a formalização necessária.
• Para equipes menores, deve ser mantida em níveis de formalidades baixa,

sendo assim, pouca burocracia e alto nível de comunicação informal.
• Para projetos maiores, se faz necessário um nível de formalização maior na

estruturação da comunicação, então dificilmente ocorrerá uma reunião com
toda a equipe, mas sim várias reuniões em que haja uma estruturação de
liderança para propagação dessa comunicação.
166
AUTOATIVIDADE
1 Elabore um plano de comunicação para o projeto da festa de formatura, com

pelo menos três artefatos, identificando seu tipo, seu público-alvo, meio de
comunicação, frequência e responsável.
167
168
UNIDADE 3
TÓPICO 4
GARANTINDO E CONTROLANDO A QUALIDADE

DO PROJETO
1 INTRODUÇÃO
Durante a execução do projeto, um ato contínuo é aferir e garantir a
qualidade dos projetos. Qualidade aqui não é somente fazer bem feito ou evitar
que as falhas aconteçam, significa aferir se os procedimentos planejados estão
sendo executados conforme o proposto.
Dificilmente conseguiremos garantir a qualidade e ter excelência em

projetos. Se cada execução de uma atividade for realizada de maneira diferente,
não há uma base de conhecimento, gera-se, assim, aleatoriedade nos resultados.
Ou seja, o projeto em uma iteração pode ser excepcional e na iteração seguinte ter
um resultado inferior, isso ocorre por conta dessa aleatoriedade ao não se ter um
padrão de execução.
Os padrões são geralmente estabelecidos pelos procedimentos, que podem

ser diagramas de fluxograma de processos com atividades, ou até mesmo podem
ser expressos através de checklist. A garantia da qualidade vai aferir não se os
resultados do projeto estão adequados, mas sim, se os procedimentos propostos
estão sendo realizados corretamente. A proposta aqui é que haja uma padronização,
que a variabilidade e aleatoriedade sejam minimizada e deste modo, consiga-se
saber se um procedimento precisa ser aperfeiçoado ou não.
2 AUDITORIAS
Essa averiguação da execução de um determinado procedimento planejado
recebe o nome de auditoria. De uma forma coloquial e leiga, auditoria remete a
pessoas indesejadas que perseguem o que os membros da equipe estão fazendo de
errado para levar à chefia e denunciar os que estão trabalhando “errado”. Assim,
a auditoria tem por sua finalidade a averiguação da realização de um processo,
frente ao planejado. Uma variação entre o processo planejado e como ele está
sendo executado denomina-se não conformidade.
Porém, essa forma é incorreta e fruto de uma imposição de sistemas

de qualidade sem a devida maturidade da organização para tal. Auditoria,
corretamente, seria a avaliação de conformidades, ou seja, a pergunta que se faz
é: as pessoas estão executando conforme o planejado? E se não estiverem, qual é
a real causa disso?
169
Essa nova abordagem de entender a auditoria remete a um método

pedagógico educacional de criar uma cultura voltada para a qualidade, a
preocupação não é denunciar ou penalizar aqueles que não estão seguindo o
processo, mas sim, entender o que está levando ele a não executar corretamente
um processo. Isso pode ser motivado pela falta de factibilidade no processo, ou
seja, o processo foi desenhado de uma forma tão ideal, que foge da realidade da
pessoa que está executando, gerando muita lentidão.
O processo pode gerar, também, não conformidades porque as pessoas

desconhecem o procedimento em detalhes. Isso é normal, uma vez que alguns
procedimentos são tão detalhados que inibem a pessoa de cada execução ao
checar os procedimentos.
Muitas vezes é vantajoso para a equipe perguntar para o colega do lado

como se faz um procedimento do que pegar manuais extensos ou fluxogramas
enormes para saber como lidar com determinada situação. Dessa maneira, é
importante que os processos sejam desenhados ou que checklists sejam criados
de forma a entender e formalizar no nível adequado para a execução de uma
atividade.
Por exemplo, caso seja a execução de um projeto de um avião, os

manuais devem ser extremamente detalhados por motivos de segurança. Uma
falha mesmo que mínima poderá ocasionar uma tragédia, então não existe
escapatória e a formalidade se faz necessária nesse tipo de projeto, os manuais
são extremamente detalhados e as auditorias são extremamente rigorosas para
seguir todos os procedimentos.
Todavia imaginemos agora um outro cenário, um processo de identidade

visual dos sistemas de informação. Esse tipo de procedimento precisa também
ser padronizado, pois envolve ações de marketing e ergonomia do produto
para o usuário final, porém uma pequena falha aqui ou lá não gera impactos
drásticos e irreversíveis, que podem ser contornados sem maiores prejuízos para
a organização. Nesse segundo exemplo, não faz sentido criar fluxogramas ou
checklists muito detalhados, basta que a equipe seja organizada, treinada e um
checklist mínimo seja determinado.
Outro fator importante nas auditorias é que sejam categorizadas as não

conformidades pela sua severidade. Esta categorização dará ao gerente do projeto
uma noção das não conformidades que precisam ser corrigidas antes de liberar
o produto e que podem passar por uma interação e serem corrigidos em outro
momento.
170
TÓPICO 4 | GARANTINDO E CONTROLANDO A QUALIDADE DO PROJETO
Desse modo, uma boa auditoria é aquela que apresenta ao gerente de

projeto evidências que possam melhorar o seu desempenho e o controle do
projeto e da equipe. Apesar de não ser obrigatório ao auditor, é desejável que
este esteja acima do gerente de projeto, por exemplo o patrocinador do projeto,
pois dará ao auditor uma independência para avaliar as não conformidades sem
se preocupar com o que pode ocorrer para si, em um cenário onde o gerente de
projeto tem autoridade sobre ele, inclusive da demissão.
a. Gráficos de controle
Os gráficos de controle são um instrumento gerencial para aferir o

grau de alcance de um objetivo mensurado por um indicador. Como visto nas
seções anteriores, os objetivos têm por sua natureza ser ambíguos e precisam
ser mensurados e operacionalizadas pelos indicadores de desempenho para dar
clareza ao que se quer perseguir.
Com os indicadores elaborados durante a fase de planejamento, estes

são combinados com a dimensão tempo ou a dimensão de eventos. Essas duas
dimensões podem ser apresentadas em um gráfico de linha, representando assim
a variação desse indicador ao longo do tempo.
O tempo também pode ser substituído por número de eventos, por

exemplo, um gráfico de coluna que represente o índice de falhas identificadas
por interações. Os gráficos permitem uma gestão visual do progresso do projeto
e podem também representar episódios de intervenções para aferir se uma
solicitação de mudança provocou a melhora ou piora em um indicador.
3 CONTROLE DO PROJETO
Nesta seção serão apresentados os conceitos e técnicas para o controle de
projetos. Essas práticas são fundamentais para lidar com os desvios naturais que
o gerente de projeto irá se defrontar durante a execução.
3.1 ELABORANDO O RELATÓRIO DE DESEMPENHO DO

PROJETO
A periodicidade da elaboração do relatório de desempenho de projetos
deve estar prevista no planejamento do projeto, mas, geralmente, é emitido ao fim
de uma interação. Os itens que compõem o relatório de desempenho, descritos
a seguir, são abordados de maneira básica podendo ser adequados para cada
projeto, mas em geral seguem essa estrutura.
171
O relatório de desempenho de projeto inicia apresentando de forma

gráfica os desvios do projeto, geralmente utiliza-se um gráfico com a curva S do
valor agregado do projeto, ou seja, três linhas em um gráfico de controle, onde
haverá no eixo horizontal a linha do tempo e no eixo vertical o custo do projeto
(VARGAS, 2002).
A primeira linha significa valor planejado e o valor retirado do

planejamento, ou seja, o desembolso de esforço convertido em reais, ou a moeda
financeira vigente. A segunda linha compara o valor investido, obtém-se no
sistema de informação o apontamento de horas, o volume de esforço empreendido
multiplicado pelo valor unitário de suas horas.
Esse número acumulado deve ser projetado na linha do tempo, por

exemplo, se dois profissionais trabalharam 40 horas cada, gerando 80 horas de
esforço, e se a hora deles custar R$10,00 então teremos um ponto no custo total
do projeto de R$800,00. Neste exemplo, é importante notar que os valores são
acumulados, ou seja, se na interação eles trabalharem mais 80 horas, não significa
um ponto de R$800,00, mas sim R$1600,00 sempre comparando o que foi investido
desde o início do projeto até o ponto do controle.
A terceira linha significa o valor agregado, obtém-se todos os itens da EAP

que foram dados como conclusos e de forma análoga somam-se as horas estimadas
para sua conclusão, projetam-se também no gráfico desde o início do projeto até o
momento do ponto de controle, ou seja, também de forma cumulativa.
Com essas três linhas, pode-se comparar e tirar deduções de forma

grosseira, mas também de uma forma abrangente a situação do projeto em termos
de prazo, custo e escopo. Caso o valor acumulado do valor planejado estiver
superior ao custo realizado de projeto, pode significar que o esforço que estava
planejado para ser realizado não aconteceu. E, dessa forma, deve ser investigado,
mas geralmente isso acontece quando se estima duas pessoas trabalhando e
uma delas precisa se ausentar, seja por doença, para trabalhar em outro projeto
ou qualquer outra natureza, isso não significa um problema de estimativas de
esforço, mas sim estimativas na dedicação da equipe.
Caso o valor planejado seja superior ao ponto de controle de valor

agregado, significa que o gerente de projeto estimava entregar um determinado
pacote de trabalho e não concluiu todas as atividades previstas ou concluiu
atividades de menor montante de esforço.
Seguindo, se o desvio entre o custo atual for superior ao valor agregado,

entende-se que houve problemas de estimativas e o esforço do projeto está
maior do que o planejado. Cabe reiterar de forma bem destacada que essas
comparações são grosseiras, dando um mapa geral e, portanto, superficial do que
está acontecendo com o projeto em termos de prazo, custo, esforço e escopo, mas
essa análise não requer interação social alguma e precisa ser realizada, pois tem
por sua natureza ser objetiva.
172
Para efeitos de fórmula, temos dois indicadores extraídos dessa técnica,

sendo o valor o indicador de variação de cronograma como o valor agregado
dividido pelo valor planejado. Se o valor for acima de 1, significa cronograma
positivo, ou seja, adiantado, se o valor for menor que 1, significa cronograma
negativo, atrasado.
Outro indicador clássico dessa técnica é o CPI - Índice de Custo, dividindo

o valor agregado pelo custo despendido, tendo a mesma comparação acima,
número acima de 1, orçamento favorável. Costuma-se dizer no meio de gestão de
projetos que esse indicador de valor agregado é ruim, mas para efeitos de análise
objetiva e abrangente inicial, ele dá uma boa visão do projeto apesar das suas
limitações.
FIGURA 8 – CPI – ÍNDICE DE CUSTO
Uma destas limitações é que os indicadores e os pacotes de trabalho são

igualados não representando e não levando em conta a precedência de atividades.
Ou seja, pode ser proposital ou de uma forma involuntária que adiante atividades
que não são o caminho crítico do projeto.
Entretanto, estas atividades, se antecipadas, melhoram o indicador de valor

agregado de forma fantasiosa. Imagine que o valor agregado esteja desfavorável
ao gerente de projeto e ele pode melhorar o indicador com a finalização de uma
atividade e ele tem duas alternativas com mesmo valor agregado.
Uma atividade é de baixo risco e a outra de alto risco, sendo a segunda mais
complexa. Para efeitos do indicador por si, a primeira atividade gerará resultados
gráficos imediatos, porém o projeto continua com o risco. A segunda atividade,
por ser mais complexa, terá uma grande probabilidade de não gerar resultados
no indicador de forma imediata, mas pensando no projeto como um todo, é
importante eliminar riscos de forma gradativa e não ir postergando decisões. Esse
173
é o paradoxo dos indicadores: eles devem fazer parte dos instrumentos de gestão,
mas devem ser combinados com uma análise qualitativa para que os resultados
sejam sustentáveis ao longo do projeto.
Dessa maneira, observamos outras dimensões do relatório de desempenho,

depois de apresentar análise gráfica, esses desvios precisam ser analisados
como a interação social com a equipe. Ou seja, durante a elaboração do projeto
é importante que a equipe tenha ciência dos indicadores de valor agregado e
consigam identificar as causas de problemas desses desvios. As causas podem
então ser registradas como questões de projetos de alta severidade, se for um
desvio grande, ou de baixa severidade, se for um desvio dentro dos parâmetros
do projeto.
Para cada questão de projeto aberta, por motivo de ser uma causa de desvios,
o gerente de projeto em conjunto com a equipe deve formular ações corretivas do
projeto. Essas ações corretivas podem endereçar melhorias na execução ou nos
procedimentos para que a execução consiga alcançar o planejamento na próxima
interação, ou nas próximas iterações, mas também pode haver um consenso
da equipe e do gerente de que esse desvio cedeu por uma comprovação que as
premissas de projeto durante as estimativas não foram realizadas como verdade.
Por exemplo, em um caso de desenvolvimento de software, a estimativa

do projeto era que testaria uma versão do projeto do aplicativo em oito horas,
porém, existe a premissa que essas oito horas só seriam válidas com três servidores
de testes com a base de dados atualizados de clientes. Durante a execução iniciou-
se os testes apenas com um servidor, ou seja, a premissa foi rompida e podendo
ocasionar que esse desvio não possa ser recuperado no futuro e então uma
segunda categoria de ações corretivas, as solicitações de mudança.
As solicitações de mudança são solicitações que a equipe, e principalmente

o gerente de projeto, coloca no relatório de desempenho de projeto e apresenta
os stakeholders, e principalmente ao seu patrocinador, para explicar que o
planejamento atual já não é mais factível de ser perseguido e precisa ajustes com
a nova configuração de premissas e fatos que foram fatos novos que foram sendo
conhecidos durante a execução. Obviamente que existirá um grande conflito
natural entre o patrocinador, que deseja ver o plano cumprido, e o gerente de
projeto de ter um plano factível e uma equipe motivada, pois no exemplo citado
acima, não foi culpa da equipe o atrasado do projeto.
Esse conflito deve ser mediado pela habilidade de negociação do gerente

de projeto. Essa habilidade dificilmente consegue ser ensinada de forma teórica, ou
até de forma acadêmica, ela pode até ser pesquisada, mas não pode ser aprendida
sem a prática. O gerente de projeto que queira desenvolver a competência de
negociação, deve assumir uma posição o mais cedo possível em sua carreira e
melhor ainda ao lado de grandes profissionais experientes.
174
Outro ponto importante no relatório de desempenho de projeto é a análise

de riscos de projeto. Esta análise pressupõe a apresentação para o patrocinador
dos riscos com alta exposição, ou seja, alto impacto e alta probabilidade que
aconteça. Apresentam-se ainda ao patrocinador as medidas dentro do programa
que estão sendo tomadas para que esse risco não aconteça ou que ao menos os
impactos sejam minimizados.
Com essa análise, pode-se apresentar um outro elemento do relatório de

desempenho de projetos, a situação dos próximos marcos de projeto. Lembrando
que marcos de projetos significa pontos de controle, em que há uma entrega
relevante para o encerramento do projeto ou uma entrega parcial.
Por mais que o projeto possa estar com alguns desvios intermediários, pode
ser que o gerente de projeto apresente alternativas, sejam elas de solicitações de
mudanças ou ações corretivas normais de execução de projeto, para que os marcos
não sejam afetados. Ou seja, uma reorganização de cronograma, orçamento,
pessoas e procedimentos, de forma que o marco do projeto seja mantido. Para
manter o marco de projeto pode ser necessário, por exemplo, a diminuição de
características de projeto daquela versão do marco, e também deve ser negociado
com os stakeholders de forma que o objetivo do projeto não fracasse.
Na análise de marcos de projeto, não se remete só ao plano, mas também

ao termo de abertura de projeto e apresenta quanto do termo de abertura está
sendo concluído ou está em risco. De qualquer maneira, seja um relatório positivo
ou negativo, o gerente de projeto deve de forma ética e responsável apresentar a
realidade do projeto, seja ela qual for aos stakeholders.
Outro indicador importante é o nível de envolvimento dos stakeholders

como, por exemplo, stakeholders que não atendem aos convites de reuniões de
projeto.
De toda forma, independentemente da natureza e grandeza do projeto,

a apresentação do relatório de desempenho deve ser a mais sintética possível,
e o seu entendimento deverá atender ao nível de um leigo em gerenciamento
de projetos. Caso o gerente de projetos apresente um relatório complexo que
somente ele e sua equipe saibam, e desse modo, precisa ser “traduzido” para o
stakeholder, este não atenderá a sua finalidade.
Um bom relatório de desempenho tem por característica ser simples,

deve ser capaz de proporcionar a uma pessoa de fora do contexto do projeto
o entendimento de uma forma abrangente a respeito da situação do projeto, os
principais pontos de atenção e os principais pontos de reação da equipe frente a
sua execução.
175
EXEMPLO
O gerente do projeto deseja utilizar a técnica de valor agregado para
controlar o andamento do projeto. Na figura a seguir são apresentados os pacotes
de trabalho para o escopo referente ao projeto da parte física da loja.
A técnica poderia ser utilizada para mensurar o montante financeiro, mas

o gerente do projeto entendeu ser interessante mensurar pelo valor de esforço em
horas, para facilitar a comunicação com sua equipe. Neste sentido:
• Na coluna “VP total” o GP aloca Valor do esforço envolvido com cada pacote
de trabalho a ser concluído, conforme suas estimativas.
• Na coluna “VP até hoje”, o GP apresenta o montante de horas que deveriam ser
dispendidas até o momento do relatório de projeto.
• A coluna “% concluído até hoje” é um valor percentual que representa o quanto
uma tarefa está concluída.
Por exemplo, se o projeto tiver 50 elementos a serem realizados para ser

concluído, e o engenheiro só fez 10 elementos, essa coluna deve estar como 20%.
Se a atividade foi completamente concluída, não restante nenhuma pendência,
essa coluna deve estar definida como 100%. Ou seja, é o progresso físico da tarefa
analisado pelo GP.
• A coluna “VA” é o valor agregado, ou seja, é um campo calculado que multiplica

o “% concluído até hoje” com o campo “VP total”. Representa em horas o
quanto a atividade está concluída.
• Na coluna “CA” serão lançadas as horas efetivamente executadas em cada
pacote de trabalho. Essas horas serão retiradas dos apontamentos diários de
trabalho executado pela equipe.
• O campo “SPI” é um campo calculado que representa a divisão entre a coluna
“VA” pela coluna “VP até hoje”. O valor resultante é o quanto em termos
percentuais o projeto está dentro do prazo. Se estiver abaixo de 100%, está
atrasado no cronograma. Se estiver acima de 100%, está adiantado.
• O campo “CPI”, por sua vez, é a razão entre o campo “VA” e “CA”. A resultante
é o quanto em termos percentuais o projeto está dentro do orçamento. Se estiver
abaixo de 100%, está mais caro que o planejado. Se estiver acima de 100%, está
mais barato.
176
QUADRO 8 – PLANILHA DE CONTROLE DE VALOR AGREGADO (1)

%
VP total VP até hoje Conckuído VA CA SPI CPI
até hoje
1 Estrutura física 1700 0 N/A 0 0
1.1 Projetos 1700 0 N/A 0 0
1.1.1 Seleção de fornecedores 240 0
1.1.2 Contratação 80 0
1.1.3 Arquitetônico 420 0
1.1.4 Estrutural 300 0
1.1.5 Hidráulico 140 0
1.1.6 Elétrico 140 0
1.1.7 Iluminação 80 0
1.1.8 Sonoro 100 0
1.1.9 Segurança 200 0
Após planejar a planilha de controle de valor agregado, o GP apresenta no

primeiro relatório o resultado da coleta de valor agregado de projeto, conforme
a figura a seguir:
FIGURA 9 – PLANILHA DE CONTROLE DE VALOR AGREGADO (2)
O quadro apresenta alguns dados do desempenho de cronograma

e orçamento do projeto. De forma global, o projeto apresenta um SPI de 84%
(atrasado) e um CPI de 109% (mais barato).
Mas o GP sabe que esses dados são globais e quantitativos, ou seja, uma
vez que ele sabe que o projeto está atrasado, precisa investigar pacote de trabalho
a pacote de trabalho, para perceber qual atividade está deixando o projeto
atrasado.
177
Existem duas atividades já concluídas (seleção de fornecedores e

contratação). Seu SPI está em 100%, mas o CPI está acima de 100%. Isso quer dizer
que as estimativas foram inflacionadas. A seleção de fornecedores, por exemplo,
era para levar um esforço de 240 horas, mas levou 200 horas. Enfim, essas duas
atividades foram bem.
Melhor ainda está o projeto arquitetônico, sendo que 40% dele está
concluído e superou as expectativas de prazo, uma vez que 100 horas eram
estimadas, porém 40% de 420 horas totais representam o equivalente de
andamento de prazo de 168 horas. Excelente!
Em custos, o projeto arquitetônico também está muito bem! Para entregar

40% do projeto, gastaram-se apenas 19% do esforço. Ou seja, está mais barato
também.
Mas o gerente ainda procura as atividades ofensoras de prazos do projeto.
A questão do projeto estrutural preocupa o GP, uma vez que seus

indicadores estão bem aquém do desejado em termos de prazo e custo.
Pior ainda são os projetos sonoros e de segurança, praticamente, os

membros desses pacotes de trabalho só se empenharam em uma reunião de duas
horas. Mas o planejado era para fazer bem mais que isso!
Destaque para a questão de projeto de segurança que de forma inusitada

está com CPI de 100%, ou seja, a estimativa está adequada em termos de custos,
pois essas 2 horas representam 1% do valor agregado, mas em termos de prazo,
está terrível.
O GP então tomou as ações corretivas e no segundo ponto de controle do

retrato do projeto está conforme o quadro a seguir:
178
Repare que houve uma melhora em termos de prazos, mas em custos

piorou. Vide figura a seguir:
FIGURA 9 – GRÁFICO DE PROGRESSO DO PROJETO
O projeto arquitetônico era para estar 95% pronto, mas está somente com
79% do planejado em termos de cronograma. Repare também que estão gastando
menos horas de trabalho. Será que não é por isso que o projeto atrasou? Estão
economizando horas, pois o projeto demandaria 400 horas de esforço. Só gastaram
300 horas. O “barato” nesse caso, saiu “atrasado”. O GP precisaria investigar por
que desse desvio.
Esse mesmo fenômeno de “economia” de esforço em horas pode ser

observado no projeto de iluminação, que investiu apenas 45 horas, mas era para
se empenhar 80 horas! Essa atividade já era para ser concluída, mas ainda está
em 75%.
No caminho inverso, e não menos preocupante, está o projeto estrutural

da loja, que está com SPI de 107%, ou seja, adiantado aos prazos, mas já gastou
90% do estimado para entregar metade da tarefa! O GP terá com certeza de
renegociar custos dessa atividade. Entregar adiantado pode custar caro!
179
O projeto elétrico parece o pacote de trabalho que mais está dando

felicidade ao GP, com adiantamento de prazos e dentro dos custos. Na verdade,
em gestão de projetos, essa característica de indicadores é um “sonho” para o GP,
mas difícil de acontecer, infelizmente.
Após as ações corretivas, no terceiro ponto de controle de projeto, a

situação é representada pelo quadro a seguir:
Repare que nesse ponto de controle era para estar todas as atividades
encerradas (“VP até hoje igual ao “VP total)”, porém existem duas atividades com
80% executadas (projetos sonoro e de segurança). Interessante constatar que essas
duas atividades estão com estimativas boas, ou seja, o que estão trabalhando,
estão entregando proporcional. O problema é que o esforço previsto não foi
despendido, gerando atraso no cronograma.
A Figura 10 apresenta o controle em horas e a Figura 11 apresenta o

controle em desempenho global de prazo e custo. Repare que o GP conseguiu
diminuir a distância entre o planejado e o SPI, mas mesmo assim, não conseguiu
alcançar a linha de 100%, gerando atraso nas atividades de projeto.
180
FIGURA 10 – GRÁFICO DE PROGRESSO DO PROJETO
3.2 MONITORANDO INDICADORES DO PROJETO

Quando pensamos em relação ao controle de projeto, remetemos à
execução do planejado, minimizando os desvios de projeto que podem ocorrer
durante a execução. Esta afirmação está correta, porém, incompleta.
No controle de projeto, não só tentamos tomar medidas para manter a

execução dentro do planejado, mas também buscamos oportunidades de melhoria
ao alterar os planos para que se consiga alcançar os objetivos propostos no termo
de abertura de projeto. Dessa forma, a definição dos desvios de projeto significa
a distância entre o executado e o planejado.
Para um leigo, desvio de projeto basicamente se define como desvios

de cronograma e, principalmente orçamento, se tornando duas dimensões
vulgarmente definidas como o sucesso do projeto. Cronograma e orçamento são
dimensões extremamente relevantes para projetos com ampla base histórica, ou
seja, projetos com baixo nível de incerteza e alto grau de detalhamento por meio
de lições aprendidas passadas e projetos similares já executados. Existem, porém,
outras dimensões tão importantes quanto o cronograma e orçamento.
Todavia, quando lidamos com projetos de grau de incertezas maiores,

cronograma e orçamento são dimensões tão importantes quanto as outras,
como escopo, qualidade, riscos, recursos humanos, comunicação, stakeholders
181
e aquisições. Assim, o desvio de projeto deve ser a comparação do executado

versus o planejado de todas as nove áreas de conhecimento de projetos, assim
como outras específicas explicitadas dentro do termo de abertura.
Deste modo, a atividade de controle de projetos por si deve ser uma

estrutura racional, evitando qualquer tipo de subjetividade ao identificar os
desvios. Isso se torna relativamente simples quando, durante a elaboração do
termo de abertura de projetos e dos planos detalhados, o gerente de projetos
se preocupa em identificar os atores do projeto, escopo (de forma bem clara)
e quando se vale de indicadores de desempenho para mensurar e clarificar o
sucesso do projeto.
Todavia, para gerente de projeto, seja para ganhar tempo ou simplesmente

por não acreditar na importância dos indicadores, a atividade de controle pode se
tornar uma tarefa bastante complexa e sempre suscetível a questionamentos por
seus pares, e principalmente, pelos stakeholders. Isso ocorre porque a dimensão
do cronograma e do orçamento são basicamente definidos por indicadores
universais, como a duração em horas ou dias e valores financeiros, por exemplo.
Por outro lado, quando não analisamos por indicadores, as dimensões

de qualidade ficam complexas ao analisar se determinado produto de trabalho
do projeto realmente está adequado para uso e adequado pela proposta a que
eles se destinam. Além das escalas de mensuração explicitadas pelos indicadores,
também fornecem os níveis de tolerância de desvios, pois estes são naturais em
projetos.
Entretanto, os desvios para um projeto de baixa incerteza podem ser

tolerados, por exemplo, em um projeto de seis meses, pode-se ter um desvio
estimado de até três dias de duração. Esses três dias são considerados uma
tolerância, pois um cronograma necessariamente não precisa ser preciso na sua
execução, alguns imprevistos podem ocorrer por meio de variações naturais e
aleatórias.
Contudo, em projetos de inovação, com altíssimo grau de incerteza,
é improvável que um projeto comece em determinada data e seja concluído
exatamente no prazo estimado. Assim, a tolerância do desvio para projetos de
inovação e alta incerteza devem ser maiores do que projetos que apresentam
base histórica. E, dessa forma, para um projeto de inovação, um cronograma de
seis meses com um desvio de dois meses de atraso em seu cronograma pode
não ser um aspecto crítico, demonstrando ser uma questão natural, fruto do
desenvolvimento do conhecimento durante o projeto.
Cabe reiterar, caso você esteja em um projeto em que haja um grande

detalhamento e base histórica, ele não pode ser categorizado como projeto inovador.
A inovação tem por sua característica a indisponibilidade do conhecimento para
elaborar planos detalhados, esses detalhamentos ocorrem durante a execução
para controlar projetos de alta inovação. Deste modo, normalmente, trabalha-se
por meio de gráficos de controle baseados em burn-down.
182
Os gráficos de burn-down, conforme demonstrado na figura a seguir, são

utilizados para perceber a velocidade de entrega de cada característica de projeto
em cada iteração, ou seja, serve como uma contagem regressiva para que todos os
itens do projeto sejam entregues.
FIGURA 11 – EXEMPLO DE GRÁFICOS BURN-DOWN
De forma clássica, os projetos com base histórica utilizam gráficos

de controle progressivos com base no gráfico de controle da curva S, ou seja,
a comparação na linha do tempo da dimensão custo em relação ao escopo,
dando origem à técnica de valor agregado, porém, para se trabalhar com todas
as dimensões de sucesso de projeto, é interessante um conjunto de gráficos de
controle, que consigam entender o projeto de uma maneira abrangente.
Dessa forma, não adiantam os indicadores de cronograma e orçamento

estarem bons e em uma situação de tranquilidade, sendo que o nível de risco do
projeto e a qualidade das entregas contêm um índice de falhas acima do normal,
e muitos pontos que podem ocasionar problemas futuros. Assim, um conjunto de
gráficos que representa o projeto da sua maneira global pode ser representado
por um painel de controle.
4 ENCERRAMENTO DO PROJETO
Após as atividades planejadas do projeto, sua execução e controle que
levaram o produto final a ser desenvolvido, o encerramento do projeto continua
sendo um processo de gestão de projetos que muitas vezes é visto como apenas
um evento de comemoração.
183
Porém, na verdade, o encerramento do projeto se trata de um conjunto de

atividades que devem ser realizadas para que aconteça um repasse do produto
desenvolvido, bem como os ativos inerentes ao desenvolvimento do projeto.
Após o ciclo de planejamento, execução e controle repetido por várias

vezes no projeto, é natural que haja desvios e ações corretivas documentadas ao
longo da história do projeto. Essas ações corretivas (aparentes “erros” de projeto
e planejamento) podem ser entendidas de forma positiva como lições aprendidas
para futuros projetos a serem iniciados pela organização.
Assim, as lições aprendidas devem ser documentadas e categorizadas por

assuntos para que um projeto a ser iniciado possa se valer do conhecimento de
projetos passados. Servem como dicas para que o gerente de projeto não venha
incorrer nos mesmos erros que levaram a desvios de projetos passados.
Uma importante lição aprendida que se pode dizer como clássica são os
desvios relacionados à estimativa de pacotes de trabalho. Esses aprendizados
devem ir para uma base de conhecimento em que se possa ir coletando dados de
diversos projetos até que se tenha uma métrica de produtividade dos projetos,
bem como o índice de retrabalho dos projetos em uma determinada organização.
As lições aprendidas podem ser categorizadas pelas próprias áreas de

conhecimento de gestão de projetos com vistas a sua simplificação na busca do
uso de lições aprendidas para futuros projetos. E, nem todas as lições aprendidas
devem ser catalogadas na base de conhecimento, pois caso haja muitas lições
aprendidas pode haver um desinteresse em buscar esse conhecimento e tornar
esse esforço inútil. Dessa maneira, é importante que somente as lições aprendidas
mais relevantes devam ser catalogadas na base de conhecimento.
As lições aprendidas são tão relevantes, que é importante que a

organização incentive o seu uso e caso um projeto não venha a atender a alguma
lição aprendida de projeto passado, essa inobservância deve-se tornar um risco
de alta probabilidade e deve entrar no processo de gestão do projeto em questão.
Isso ocorre porque quando um gerente de projeto não aproveita o

conhecimento de gerentes passados, pode-se entender algum tipo de negligência
técnica ou um atendimento de pressões de stakeholders, e esses eventos devem ser
esporádicos e quando acontecerem devem ser evidenciados a todos os stakeholders
que uma ação similar ocorreu no passado com consequências negativas para o
projeto.
Outro processo relevante no encerramento do projeto é o repasse de

conhecimento para a área que irá manter o projeto em operação. Isso é muito
comum em projetos de desenvolvimento de produto, em que o projeto é
responsável pelo desenvolvimento de especificações, protótipos e operação
piloto.
184
Após esse projeto estar concluído, o produto deve ser produzido em série
e a área de conhecimento de gestão de projetos perde o apelo e aparecem outras
técnicas administrativas como gestão de processos (BPM) para produzir um
produto em larga escala.
Porém, essa transição entre gestão de projetos e gestão de operações deve

ser realizada com muita cautela e atenção para que a linha de operação consiga
entender cada decisão tomada durante o projeto e por que o projeto ou produto
tem tais características físicas e de montagem.
Um terceiro processo importante durante o encerramento do projeto ocorre

quando os contratos de terceiros são finalizados. Muitas vezes, tais contratos têm
cláusulas de encerramento rigorosas como vistorias e liquidação de pagamentos
e essas devem ser realizadas com muito compromisso e ética.
DICAS
Como Leitura Complementar sugerimos proceder à leitura dos textos

que seguem: BRANDÃO, Marcius Gomes et al. Monitoramento e controle de projetos
com e-kanban e burndown: um relato de experiência. In: V WGPS–Workshop de
gerenciamento de projetos de software. 2012. p. 39. Disponível em: <https://www.
researchgate.net/publication/260058777> e VALLERÃO, Alexandre Guido et al. Modelo de
monitoramento e controle de projetos de desenvolvimento de software conduzidos sob
o Scrum. 2015. Disponível em: <https://bdtd.ucb.br:8443/jspui/bitstream/123456789/1454/1/
Alexandre%20Guido%20Vallerao.pdf>. Boa leitura!
185
RESUMO DO TÓPICO 4
• Durante a execução do projeto, um ato contínuo é aferir e garantir a qualidade

de projetos.
• Essa averiguação da execução de um determinado procedimento planejado

recebe o nome de auditoria.
• A auditoria tem por sua finalidade a averiguação da realização de um processo,

frente ao planejado.
• Os gráficos de controle são um instrumento gerencial para aferir o grau de

alcance de um objetivo mensurado por um indicador.
• A periodicidade da elaboração do relatório de desempenho de projetos deve

estar prevista no planejamento do projeto, mas geralmente é emitido ao fim de
uma interação.
• As solicitações de mudança são solicitações que a equipe, e principalmente o

gerente de projeto, coloca no relatório de desempenho de projeto e apresenta
aos stakeholders, e principalmente ao seu patrocinador, para explicar que o
planejamento atual já não é mais factível de ser perseguido e precisa ajustes
com a nova configuração de premissas e fatos que foram sendo conhecidos
durante a execução.
• Após o ciclo de planejamento, execução e controle repetido por várias vezes no

projeto, é natural que haja desvios e ações corretivas documentadas ao longo
da história do projeto. Essas ações corretivas (aparentes “erros” de projeto e
planejamento) podem ser entendidas de forma positiva como lições aprendidas
para futuros projetos a serem iniciados pela organização.
186
AUTOATIVIDADE
1 Para cada tipo de gráfico ou indicador, explique em que situações estes são
utilizados.
a) Gráficos de burn-down.
b) CPI – Índice de custo.
c) Gráfico de progresso do projeto.
187
188
REFERÊNCIAS
ANDRADE, Eduardo Leopoldino de. Introdução à pesquisa operacional. Rio
de Janeiro: LTC, 1998.
ANTÓNIO, Nelson Santos; TEIXEIRA, António. Gestão da qualidade: de

Deming ao modelo de excelência da EFQM. Lisboa: Edições Sílabo, 2007.
BARCAUÍ, André B. PMO-Escritórios de projetos, programas e portfólio na

prática. Brasport, 2012.
BLANCHARD, Kenneth H.; ZIGARMI, Patrícia; ZIGARMI, Drea. Liderança e o

gerente minuto. Record, 1986.
CARVALHO, Marly; PALADINI, Edson. Gestão da qualidade: teoria e casos.

Elsevier Brasil, 2013.
CHIAVENATO, Idalberto. Gestão de pessoas. Elsevier Brasil, 2008.
COHN, Mike. Desenvolvimento de software com Scrum: aplicando métodos

ágeis com sucesso. Bookman, 2000.
CRUZ, Fábio. Scrum e PMBOK unidos no Gerenciamento de Projetos.

Brasport, 2017.
CUKIERMAN, Zigmundo Salomão. O modelo PERT/CPM aplicado a projetos.

Editora Rio, 1977.
DINSMORE, Paul Campbell. Transformando estratégias empresariais em

resultados através da gerencia por projetos. Qualitymark Editora Ltda., 1999.
ENSSLIN, L.; NETO, G. M.; NORONHA, S. M. Apoio à decisão: metodologias

para estruturação de problemas e avaliação multicritério de alternativas. Insular,
2001.
HUNTER, James C. Como se tornar um líder servidor. Rio de Janeiro: Sextante,

v. 136, 2006.
JURAN, Joseph M. A qualidade desde o projeto: novos passos para o

planejamento da qualidade em produtos e serviços. Cengage Learning Editores,
1997.
KERZNER, Harold. Gestão de projetos: as melhores práticas. Bookman Editora,

2016.
189
LACERDA, Rogério Tadeu. O sucesso em gerenciamento de projetos: a
estruturação de um modelo de avaliação a partir de uma visão construtivista.
2009. Tese de Doutorado. Universidade Federal de Santa Catarina, Centro
Tecnológico. Programa de Pós-Graduação em Engenharia de Produção.
LACERDA, Rogério Tadeu; ENSSLIN, Leonardo; ENSSLIN, Sandra Rolim. Um

estudo de caso sobre gerenciamento de portfólio de projetos e apoio à decisão
multicritério. Revista Gestão Industrial, v. 6, n. 1, 2010.
MINTZBERG, Henry et al. Criando organizações eficazes. São Paulo: Atlas, p.

09-31, 1995.
MINTZBERG, Henry; QUINN, James Brian. O processo da estratégia.

Bookman, 2001.
MORICOCHI, Luiz; PINO, Francisco Alberto; VEGRO, Celso Luís Rodrigues.

Método Delphi como alternativa para previsão de safras: o exemplo do café.
Informações econômicas – Governo do estado de São Paulo – Instituto de
Economia Agrícola, v. 25, p. 47-54, 1995.
NORTON, D. P.; KAPLAN, R. B. Kaplan e Norton na prática. Gulf professional

publishing, 2004.
OLIVEIRA, Lisandra Valim de et al. Avaliação de desempenho e gerenciamento

de projetos: uma análise bibliométrica. Gestão e Projetos: GeP, v. 7, n. 1, p. 95-
113, 2016.
PEREIRA, Paulo; TORREÃO, Paula; MARÇAL, Ana Sofia. Entendendo Scrum

para gerenciar projetos de forma ágil. Mundo PM, v. 1, p. 3-11, 2007.
PMI, A. Guide to the project Management body of knowledge. Project

Management Institute, Pennsylvania USA. 2013.
PORTER, Michael E. Vantagem competitiva: criando e sustentando um

desempenho superior. Rio de Janeiro: Campus, 1992.
PRADO, Darci. Pert/Cpm. Editora de Desenvolvimento Gerencial, 1998.
RIBEIRO FILHO, José Francisco et al. Características da personalidade de

estudantes de ciências contábeis: análise do conhecimento baseado no Modelo
Myers-Briggs Type Indicator (MBTI). Contabilidade, Gestão e Governança, v.
13, n. 2, 2010.
ROZENFELD, Henrique; FORCELLINI, Fernando Antônio; AMARAL, Daniel

Capaldo. Gestão de desenvolvimento de produtos: uma referência para a
melhoria do processo. Editora Saraiva, 2000.
190
SALLES JR, Carlos A.C. et al. Gerenciamento de riscos em projetos. Rio de
Janeiro: FGV, 2006.
SHENHAR, Aaron J. Strategic Project Leadership® Toward a strategic approach

to project management. R&d Management, v. 34, n. 5, p. 569-578, 2004.
SORDI, José Osvaldo de. Gestão por processos: uma abordagem da moderna
administração. Saraiva, 2005.
SOUZA, Celso de. Liderança diferenciada. 2015. Disponível em: <http://www.

liderancadiferenciada.com.br/>. Acesso em: 25 jun. 2018.
TRELLO. Disponível em: <www.trello.com>. Acesso em: 10 maio 2018.
VARGAS, Ricardo Viana. Análise de valor agregado (EVA) em projetos.

Brasport, 2002.
VARGAS, Ricardo Viana. Gerenciamento de projetos. 6. ed. Brasport, 2005.
191

Gestão de Projetos

Enviado por

Dados do documento

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

Gestão de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

Gestão de Projetos

Prof. Rogério Lacerda

Revisão, Diagramação e Produção:

Ficha catalográfica elaborada na fonte pela Biblioteca Dante Alighieri

A Gestão de Projetos é muito relevante nas organizações atuais,

A disciplina foi disposta em três unidades, a primeira possibilita

Outro ponto interessante da Unidade 1 é a conceituação de projetos e

Na Unidade 2, nós faremos com detalhes a exposição de conteúdos de

A Unidade 3 se destina à exposição de conteúdos a respeito da

Esperamos que o conteúdo atenda não só a sua necessidade acadêmica,

Desejo ótimos estudos!

Professor Rogério Lacerda

Você já me conhece das outras disciplinas? Não? É calouro? Enfim, tanto

Na Educação a Distância, o livro impresso, entregue a todos os acadêmicos desde 2005, é

Assim, a UNIASSELVI, preocupando-se com o impacto de nossas ações sobre o ambiente,

Aproveito o momento para convidá-lo para um bate-papo sobre o Exame Nacional de

TÓPICO 1 – DE ONDE VÊM OS PROJETOS?................................................................................... 3

TÓPICO 2 – DEFINIÇÃO E TIPOS DE PROJETOS.......................................................................... 21

TÓPICO 3 – GESTÃO DE PROJETOS................................................................................................. 43

UNIDADE 2 – PLANEJAMENTO DE PROJETOS............................................................................ 63

TÓPICO 1 – COMO DEFINIR O ESCOPO DO PROJETO?............................................................ 65

TÓPICO 2 – COMO PLANEJAR O TEMPO E O CUSTO DO PROJETO?................................... 83

TÓPICO 3 – PREPARANDO PARA A EXECUÇÃO.......................................................................... 113

UNIDADE 3 – EXECUÇÃO E CONTROLE DE PROJETOS............................................................ 125

TÓPICO 1 – E SE ALGO SAIR DO PLANEJAMENTO?.................................................................. 127

TÓPICO 2 – MOBILIZAÇÃO DA EQUIPE......................................................................................... 143

TÓPICO 3 – COMUNICAÇÃO DO PROJETO.................................................................................. 161

TÓPICO 4 – GARANTINDO E CONTROLANDO A QUALIDADE DO PROJETO................. 169

• compreender os conceitos sobre a gestão de projetos.

• entender a gestão de projetos como parte da gestão estratégica;

• compreender os conceitos de gestão de portfólio de projetos.

TÓPICO 1– DE ONDE VÊM OS PROJETOS?

TÓPICO 2 – DEFINIÇÃO E TIPOS DE PROJETOS

TÓPICO 3 – GESTÃO DE PROJETOS

DE ONDE VÊM OS PROJETOS?

Existem várias técnicas e abordagens utilizadas na realização de um

A estratégia também pode ser vista como um posicionamento, e com

Outra forma de visão da estratégia é como um padrão. Ou seja, a estratégia

Por último, a quarta forma de entender a estratégia é por meio da estratégia

Nesta ótica de estratégia como perspectiva do gestor, é necessário fazer o

Essas quatro visões estratégias são de suma importância para a

Por exemplo, uma organização industrial que fabrica bens de consumo

Já, empresas de produtos tecnológicos dependem fundamentalmente da

Capital intelectual, neste exemplo, pode ser explicado por um quadro de

A partir do conhecimento sobre os tipos de estratégia organizacional,

2 FORMAS DE EXECUÇÃO DA ESTRATÉGIA: PROCESSOS E

Uma estratégia, como vimos na seção anterior, se trata de intenções

Sem o norte estratégico, a organização não passará de pessoas e

Existem basicamente duas formas de operacionalizar a estratégia e

Processos recebem uma entrada e, a partir da execução de suas atividades,

FIGURA 1 – ELEMENTOS DE UM PROCESSO

FONTE: O autor (2018)

Como exemplo de um processo, podemos analisar o processo de montagem

FIGURA 2 – PROCESSO DE MONTAGEM DE UM AUTOMÓVEL

No entanto, outros tipos de processo não são tão determinísticos, pois

Por mais que haja um esforço das organizações em padronizar esses

Em suma, o primeiro tipo de processo é bem mecanicista, executado

A outra forma de execução de estratégias é por meio de projetos.

Neste sentido, é possível observar, no Quadro 1, as principais diferenças

QUADRO 1 – GERENCIAMENTO ESTRATÉGICO DE PROJETOS

Processos enquanto projetos têm em comum a melhoria ou uma

Como exemplos de projetos, podemos citar a abertura de mais pontos

A Figura 3 apresenta um esquema resumido de como projetos e processos

FIGURA 3 – ABERTURA DE UMA NOVA FILIAL DE UMA LOJA