INTRODUÇÃO

Como o próprio nome diz, a disciplina de Fundamentos de

Gerenciamento de Projetos traz ao aluno uma consistente base para o
posterior entendimento das disciplinas técnicas da área. Faz a devida
correlação entre a história da humanidade e a existência de projetos,
mesmo que sem técnicas apuradas ou metodologias.
Já no século XX, a gestão de projetos de maior complexidade e
risco faz dessa disciplina uma das mais úteis bases de sustentação do
aluno, tanto para a formação profissional como para as competências a
serem desenvolvidas. Nesse contexto, veremos os inúmeros assuntos que
orbitam o universo de projetos, de fatores motivadores à sua relação
direta com as decisões estratégicas das companhias. Desse modo,
abordaremos os diversos processos de gerenciamento de projetos
constantes no PMBOK, 6a edição, e como devem ser melhor utilizados
como recursos tecnológicos.
Em pleno século XXI, estamos inundados por variadas
metodologias e guias com melhores práticas de gestão, assim como
associações e centros de estudo. Cada vez mais, as organizações estão
investindo na ciência da gestão de projetos, criando e dando poder aos
seus escritórios de projetos, e incentivando a qualificação dos seus
profissionais. Isso não é por acaso: tais entidades apuraram a correlação
direta entre a gestão profissional dos seus projetos e o maior nível de
sucesso desses esforços.
Nesse contexto, esse material tem como objetivo apresentar os
conceitos fundamentais de Gerenciamento de Projetos e oferecer
reflexões da sua aplicação, bem como de uma visão de conjunto do
processo de gerenciamento das aquisições aplicado a projetos, permitindo
a compreensão dos seus mecanismos e da sua dinâmica. Para tal, iremos:
conhecer os conceitos fundamentais acerca de projetos, gestão
de subprojetos, de programas e de portfolios;
conhecer como o projeto nasce nas organizações e o seu
histórico paralelo à raça humana;
analisar a importância dos stakeholders no cenário de
qualquer projeto;
relacionar os processos de gestão com planejamento estratégico e os 49 processos de
gerenciamento de projetos;
conhecer as técnicas e boas práticas principais de planejamento, organização e controle das
aquisições de um projeto;
conhecer os elementos principais de processos licitatórios privados e públicos;
conhecer os elementos principais de seleção e administração de contratos, e
revisar as dez áreas de conhecimento e como os recursos tecnológicos disponíveis hoje
podem apoiar o gerente de projetos no processo de controle e decisório.
SUMÁRIO
MÓDULO I – FUNDAMENTOS DE GESTÃO DE PROJETOS ................................................................... 7

EVOLUÇÃO DO GERENCIAMENTO DE PROJETOS .......................................................................... 7

Histórico ...................................................................................................................................... 7
Definição de projeto .................................................................................................................. 9
Diferenças e semelhanças entre projetos e trabalhos operacionais ............................... 14
SUBPROJETOS, PROGRAMAS E PORTFÓLIO DE PROJETOS ......................................................... 17
Subprojetos .............................................................................................................................. 17
Programas................................................................................................................................. 17
Portfólio de projetos................................................................................................................ 21

MÓDULO II – PROCESSOS DE GERENCIAMENTO DE PROJETOS E CICLO DE VIDA ........................ 25

ALINHAMENTO EMPRESARIAL PARA O GERENCIAMENTO DE PROJETOS .................................. 25

Planejamento estratégico e projetos .................................................................................... 25
Fatores motivadores de projetos .......................................................................................... 30
Stakeholders .............................................................................................................................. 34
Habilidades e competências do Gerente de Projetos ........................................................ 37
Project management office (PMO) ........................................................................................... 44
Estruturas organizacionais ..................................................................................................... 48
PROCESSOS DE GERENCIAMENTO DE PROJETOS ........................................................................ 59
Grupos de processos............................................................................................................... 59
Ciclo de vida de um projeto .................................................................................................... 61
Dez áreas de conhecimento de gerenciamento de projetos, segundo a 6a edição do
PMBOK ...................................................................................................................................... 71
Documentos-chave: Termo de Abertura do Projeto (TAP) e Plano de Gerenciamento do
Projeto (PGP) ............................................................................................................................ 77
Linha de base e a tripla restrição .......................................................................................... 82
Controle geral de mudanças .................................................................................................. 84
Critérios de um projeto de sucesso ...................................................................................... 87

MÓDULO III – AQUISIÇÕES EM PROJETOS......................................................................................... 89

INTRODUÇÃO ................................................................................................................................... 89
AQUISIÇÕES EM PROJETOS ............................................................................................................. 90
PLANEJAMENTO DE AQUISIÇÕES EM PROJETOS.......................................................................... 95
O QUE precisamos? ................................................................................................................. 95
ONDE conseguimos o que precisamos? ............................................................................... 96
COMO obter o que precisamos?............................................................................................ 96
QUANDO conseguiremos ter o que precisamos? ............................................................... 97
 QUANTO nos custará o que precisamos?............................................................................. 98
QUAIS os riscos que corremos ao adquirir o que precisamos? ........................................ 98
PROCESSOS LICITATÓRIOS ............................................................................................................. 99
Pré-Seleção de fornecedores .............................................................................................. 100
Termo de referência ............................................................................................................. 101
Obtenção de propostas ....................................................................................................... 103
Análise de propostas ............................................................................................................ 105
MODELOS DE CONTRATOS E A SUA APLICAÇÃO ...................................................................... 108
PRÁTICAS DE ADMINISTRAÇÃO DE CONTRATOS ...................................................................... 112
Eixo aderência ....................................................................................................................... 113
Eixo comunicação ................................................................................................................. 114
Eixo alteração ........................................................................................................................ 115
Eixo conflito ........................................................................................................................... 115
ENCERRAMENTO DE CONTRATOS .............................................................................................. 116
Encerramento a termo ......................................................................................................... 116
Rescisão.................................................................................................................................. 116
Resolução ............................................................................................................................... 117
Resilição ................................................................................................................................. 117
Aceitação de escopo ............................................................................................................. 118
Transferência de custódia ................................................................................................... 118

MÓDULO IV – RECURSOS TECNOLÓGICOS DE GESTÃO DE PROJETOS ......................................... 119

DEMONSTRAÇÃO DAS PRINCIPAIS FERRAMENTAS DE GERENCIAMENTO DE PROJETOS ... 119

WBS ou EAP ........................................................................................................................... 119
Cronograma ........................................................................................................................... 128

CONCLUSÃO ....................................................................................................................................... 141

BIBLIOGRAFIA .................................................................................................................................... 143

BIBLIOGRAFIA INDICADA PARA AQUISIÇÃO ................................................................................... 146

PROFESSORES-AUTORES ................................................................................................................... 147

MÓDULO I – FUNDAMENTOS DE GESTÃO
DE PROJETOS

Neste módulo, abordaremos a evolução dos projetos na história da humanidade, com relação
à sua complexidade e forma de gestão. A seguir, faremos uma reflexão sobre os conceitos de projetos
em si, assim como de portfólio, stakeholders e outros. Também apresentaremos a Gestão Estratégica
e a sua influência nos projetos a serem selecionados nas companhias. Por fim, abordaremos as
características-chave de um gestor de projetos de sucesso e de um escritório de projetos.

Evolução do gerenciamento de projetos

Histórico
Desde os primeiros registros de presença humana na Terra, já encontramos evidências de
projetos sendo efetuados. É evidente que obras de grande magnitude, como a Muralha da China
ou o templo de Dendur (hoje localizado no Museu Metropolitan de Nova York), são comprovações
de que os projetos são, praticamente, paralelos à raça humana. Infelizmente, outros exemplos da
Antiguidade não tiveram a mesma sorte – como os Jardins suspensos da Babilônia, com citações da
sua existência, mas sem evidências físicas da sua grandiosidade. Outros projetos ficaram no
intermédio desses extremos e tem apenas algumas ruínas como evidência do seu passado, como
algumas obras dos povos gregos e romanos.
Com o passar do tempo e dos séculos, outras produções humanas foram incrementando a
sua tecnologia e, cada vez mais, tais produções foram-se apoiando em melhores práticas e menos
em improviso. As grandes navegações – exemplo do movimento expansionista de países como
Portugal e Espanha, e Inglaterra posteriormente – exemplificam projetos de sucesso com as grandes
navegações dos séculos XIV a XVII. À medida que o homem foi implementando projetos, dessa ou
de outra natureza, de maior ou menor porte, os índices de fracasso foram reduzindo. No entanto,
foi no século XX que, realmente, os projetos e a sua gestão passaram a ser vistos pela ciência da
Administração como merecedores de uma devida atenção e análise. Muitas empresas passaram a
investir, fortemente, nos projetos, e não fazia sentido geri-los sem um mínimo de técnica e até de
metodologias. Os erros estavam trazendo prejuízos, o que impulsionou estudos mais profissionais
na recém-nascida área, batizada de “gerenciamento de projetos”. Não foi diferente na Agência
Espacial norte-americana, NASA, em que, a partir dos seus projetos, especialmente o Apolo, houve
emprego intenso da disciplina de gerência de projetos.
Não por acaso, em 1969, foi criada uma entidade para compartilhar as melhores práticas de
gestão de projetos, a Project Management Institute – PMI. Os seus fundadores decidiram que não
podiam mais gerir projetos nas respectivas firmas de maneira informal, e passaram a redigir textos
e trocar experiências, presencialmente, sobre os seus modos de trabalhar, com foco na padronização
dos processos. Nascido na Pensilvânia, EUA, com cinco voluntários, o PMI passou a uma
participação global, graças à tecnologia e à virtualização do século XX. Milhares de membros ou
associados entram em contato na sua plataforma, e esse incrível aumento de participantes fez com
que a entidade lançasse a primeira versão do seu guia com uma estrutura básica de melhores práticas
chamado de PMBOk – Project Management Book of Knowledge. Mais ou menos, de 4 em 4 anos,
os membros do PMI e os seus voluntários se reúnem para editar o PMBOK e lançar uma nova
versão. Hoje em dia, há interações virtuais em todo o mundo e em tempo real para se discutir
alterações e adendos às versões anteriores. Em setembro de 2017, foi lançada a 6a edição do
PMBOK, em dez idiomas, que é a versão vigente do guia.
Até por ter-se tornado uma entidade referência em gerenciamento de projetos, ou seja, um
benchmarking mundial nesse campo, o PMI também compôs o “pacote de conhecimento” ao criar
uma certificação, o Project Management Professional – PMP –, que serve, até hoje, como um selo de
expertise no PMBOK bastante reconhecido e aceito mundialmente. A certificação PMP tem sido uma
meta de inúmeros profissionais que atuam com projetos, mas outras certificações foram criadas mais
recentemente e atendem a demandas mais específicas de profissionais do meio, das quais sobressaem:
certificação CAPM – técnico certificado em gerenciamento de projetos;
certificação PfMP® – profissional de gerenciamento de portfólio;
certificação PMI-SP – profissional em gerenciamento de cronograma;
certificação PMI-RMP – profissional em gerenciamento de riscos do PMI;
certificação PgMP – profissional de gerenciamento de programas e
certificação PMI-ACP – profissional certificado em métodos ágeis do PMI.

Outra entidade que também tem contribuído à evolução da ciência da gestão de projetos,
apoiando como irradiadora verdadeiramente global de melhores práticas é a International Project
Management Association – IPMA. Do outro lado do Atlântico, mais recentemente, o governo do
Reino Unido criou e fez nascer, em 1989, a PRINCE2 – Project IN Controlled Environments –,
metodologia britânica mais focada em um modelo estruturado e prescritivo do que o do PMBOK,

8
e que também tem tido boa participação mundial. Também há algumas certificações emitidas pela
organização da PRINCE2 que, assim como as do PMI, trazem valor agregado e enriquecimento de
carreira aos profissionais depositários das mesmas.
A International Organization for Standardization – ISSO – publicou, em 1997, a norma
10.006, na qual associa a gestão de projetos com a política da qualidade. No padrão dessa entidade,
foram discriminados processos de gerenciamento. A versão final desse padrão não conflita com o
PMBOK, sendo complementar a ele, apesar de menor em tamanho.
Mais recentemente, a história de gerenciamento de projetos testemunhou o nascimento das
metodologias ágeis. Tornaram-se bastante conhecidas a partir de 2001, quando um grupo de
especialistas em desenvolvimento criou a chamada Aliança Ágil, em que uma série de conceitos
comuns a todos os métodos por eles empregados foi apresentada. A abordagem Scrum, um dos
exemplos mais conhecidos das metodologias ágeis, tem sido empregada em várias corporações, de
maneira exclusiva ou aliada aos modelos mais tradicionais, como o do PMI ou de outra entidade
irradiadora de gerencia de projetos.
Independentemente da entidade de gerência de projetos ou das universidades que apoiam a
formação e qualificação de profissionais no meio, o fato é que nunca se investiu tanto em projetos
nas organizações. Segundo o renomado autor Ricardo Vargas, “cerca de 15 trilhões de dólares são
hoje empregados em projetos. Isso significa cerca de 25% de toda a economia mundial”. Essa
espantosa estatística corrobora a crescente demanda global por profissionais altamente competentes
nesse saber e afasta a ideia de que essa disciplina seria um modismo passageiro.
O gerenciamento de projetos é, hoje, verdadeiramente universal, aplicável a qualquer
setor de atividade, tanto na esfera profissional como pessoal. Em pleno século XXI, os benefícios
do gerenciamento de projetos, obtidos pela aplicação de técnicas, tem uma repercussão
indiscutível e universal.

Definição de projeto
Segundo o PMBOK, projeto é um esforço temporário praticado para criar um produto, serviço
ou resultado exclusivo. O autor Gozzi complementa essa definição afirmando que um projeto é um
conjunto de atividades coordenadas “com limitações e restrições de tempo, custo e recursos”.

Exclusividade
A exclusividade ou unicidade, ou seja, a produção de um output único, é um dos traços mais
marcantes de projetos. De fato, nenhum projeto é idêntico a outro, em grande parte porque os seus
produtos ou serviços finais sofrem profundas diferenças entre si. Por mais que comparemos projetos
produzidos em uma mesma empresa ou em uma mesma indústria, como a da construção civil, cada

9
empreitada dessas terá os seus próprios diferenciais. No caso de uma empresa de engenharia, que
constrói edifícios residenciais no Peru há 15 anos, nenhum dos projetos dessa entidade serão
idênticos, até porque seriam separados no tempo, teriam usado diferentes tecnologias, teriam sido
destinados a clientes (moradores) distintos, teriam tido design, acabamento e metragem específicos,
teriam sido construídos em terrenos diferentes e, finalmente, teriam sido concluídos por times de
operários, engenheiros e arquitetos distintos.
Um projeto como a campanha de marketing da sofisticada marca Louis Vuitton exemplifica
bem essa característica da unicidade, posto que o produto comercializado é distinto do anterior, o
apelo da propaganda é inédito, são outras as características de distribuição, diferentes os locais em
que ocorrerão eventos de lançamento para a mídia, bem como os times de criação, entre outros.
A unicidade ocorre, igualmente, em projetos pessoais e familiares, como uma viagem. Mesmo
que se visite a mesma cidade em anos distintos, a viagem será outra. O projeto mudou. Apesar do
destino ter sido o mesmo, a própria cidade pode ter sofrido alterações, o hotel em que a família
ficará pode ser outro, haverá uma duração específica, o roteiro pode ser outro, alguns membros da
família entram ou saem nas distintas vezes, o financiador do tour pode ser alterado, etc. Viagens,
como projetos que são, também são exclusivas, não se repetem.
Dessa forma, projetos são únicos, exclusivos, singulares. Nunca um projeto feito um dia poderá
ser repetido exatamente nos moldes que fora concebido originalmente, mesmo porque a tecnologia
terá evoluído, o time executor e o gerente poderão ser outras pessoas, e assim sucessivamente.

Temporariedade
Projetos são finitos, ou seja, tem uma duração limitada. Realmente, é possível identificar essa
característica na construção das pirâmides no Egito, levadas a cabo do início ao fim, a duras penas,
mas esse empreendimento teve afinal um término. Alguns autores atribuem a característica da
finitude de projetos ao esforço “faseado”, como comenta o autor Gozzi acerca do projeto Copa do
Mundo de 2014 no Brasil, quando afirma que “alguns estádios foram reformados; outros,
construídos. Melhorou-se a infraestrutura de aeroportos e da mobilidade de cidades nas quais
haveria jogos. Foram reservados locais de treinos e acomodação para 32 seleções. Preparam-se hotéis
e restaurantes para receber milhões de turistas”. Essas evidências de fases, ou seja, etapas do início
até o final do projeto, comprovam a finitude da Copa 2014, tornando-o um evento aderente ao
conceito de projeto. Nesse sentido, projetos tem fim.
Da construção das pirâmides maias, no século VIII, na Guatemala, ao lançamento do novo
modelo de avião ERJ-145, nos anos 2000, pela Embraer, ou uma campanha para as eleições gerais
do México, em 2018, mesmo que separados por milênios e por distâncias geográficas, esses três
exemplos foram projetos, já que cabem nessa atribuição de temporariedade (início e final claros)
dos projetos, tão ressaltada pelo PMBOK.

10
 Os três projetos anteriormente citados foram temporários, tiveram cada qual uma duração
específica, sendo elaborados progressivamente, desde o dia 1 de atividades até a sua conclusão final.
No caso das pirâmides maias, cuja destinação da obra era erguer templos religiosos, os primeiros
momentos do projeto se deram pelo desenho que, provavelmente, foi vislumbrado pelo que teria
sido o gerente do projeto, em seguida, pelo transporte das pedras à posição planejada de construção
e a necessária mobilização da mão de obra para começar a tarefa de erguimento. Tão logo os demais
recursos físicos para a construção foram trazidos, deu-se a efetiva construção das pirâmides e, enfim,
o seu término bem-sucedido.
Igualmente, o lançamento do novo modelo pela Embraer, após anos de desenho e pré-
projeto, estudos e testes, até a concreta construção da “máquina” e testes considerados de sucesso
“no ar”, até a campanha de marketing junto a diversos governos para a futura venda, o projeto
provou-se temporário até o lançamento oficial do novo modelo. No México de 2018, não foi
diferente, ou seja, também se apurou o traço da temporariedade nas eleições. De fato, para todos
os candidatos concorrentes, a eleição foi tratada como um projeto e com a especificidade (ou até
agravante) de haver, efetivamente, uma data final, a da eleição, que foi o dia final da campanha.
É conveniente acrescentar que, para alguns setores da economia e alguns tipos de projetos,
como na área de eventos, o fator temporariedade é ainda mais importante do que qualquer outra
parte do conceito total de projetos. Uma festa de casamento ou um evento, como Rock in Rio, são
exemplos de projetos do tipo eventos, e não têm, praticamente, nenhuma margem de escolha no
que tange à temporariedade, isto é, não podem atrasar! A festa de casamento, uma vez marcada,
dificilmente pode ser alterada, até por todas as reservas feitas para aquele dia e faixa de horário. Há
contratações importantes, como a da igreja (ou outro templo religioso da escolha do casal),
fechamento com a casa de festas e a entrega da empresa de bebidas e do buffet. Ademais, essa data
será usada no convite de todos os convidados, alguns dos quais poderão ter de se deslocar em grandes
distâncias para chegar à celebração, exigindo-lhes um planejamento. Trata-se de um projeto
temporário e com pouquíssima margem de manobra caso haja atrasos de alguma ordem.
O festival do Rock in Rio, que ocorrerá no período de 27 de setembro a 06 de outubro de
2019, é outro exemplo no qual a temporariedade dos projetos é levada ao pé da letra. Após anúncio
feito em diversas mídias sociais e nas principais redes de televisão brasileiras e internacionais, todos
os ingressos foram vendidos rapidamente. As datas dos diversos shows já foram pré-marcadas,
algumas das quais já divulgadas também, assim como algumas das atrações principais (cantores e
grupos, locais e internacionais). A parte da execução desse evento, evidenciada pelos diversos shows,
dia após dia, ocorrerá entre 27 de setembro até 06 de outubro, seguindo o que foi publicamente
difundido como o prazo do projeto. A organização desse tipo de projeto tem pouquíssima margem
de manobra caso haja imprevistos naquele período.

11
 Na última edição do Rock in Rio, em 2017, houve um episódio, no mínimo, curioso: Lady
Gaga, uma das maiores estrelas esperadas do evento, teve problemas de saúde às vésperas do seu dia
de apresentação e não conseguiu participar. Diante desse imprevisto, os gestores do projeto
decidiram anunciar publicamente o problema e, ao mesmo tempo, a reposição da janela deixada
pelo show de Lady Gaga com outra atração, o Maroon Five. Aos possuidores de ingresso que não
quisessem a alternativa, foi dada a opção do reembolso. Essa tática da organização do projeto foi
claramente paliativa, mas funcional para o que tinham disponível em tão pouco tempo. Essa
alternativa proposta ao grande público do show evidenciou que, quando se trata de projetos de
eventos, inclusive esse que é ao vivo, o traço da temporariedade é uma força poderosíssima.
Um ponto adicional a ressalvar sobre temporariedade de projetos é distingui-la de rapidez.
Mesmo que projetos sejam temporários, isso não significa que sejam rápidos. Não! Duradouro é o
projeto, o empreendimento, a iniciativa em si. Quando uma empresa faz um projeto, ela sabe que
até os produtos ou serviços serem entregues, a iniciativa estará em andamento. Tão logo sejam
concluídos os objetivos do projeto, ele poderá ser encerrado. No entanto, isso pode levar dias ou
um razoável intervalo de tempo.
Há projetos de variadíssimas durações, de dias a anos! Há setores econômicos cujos projetos
são bastante céleres, como projetos ligados à tecnologia, cujos esforços podem levar de 2 a 3
semanas, sendo os seus cronogramas divididos em dias e até em horas, justamente para garantir um
maior controle. No entanto, é importante ressaltar que nem todos os projetos de firmas ou setores
tecnológicos, ou que são motivados por tecnologia, são curtos. Podem ocorrer megaprojetos de
implementação em corporações multinacionais que tenham cunho tecnológico, como uma
alteração de todas as plataformas físicas ou modelos de notebooks de todos os usuários.
Evidentemente, será um projeto mais longo para os padrões do mundo da tecnologia. Tanto
complexidade como dispersão geográfica tornarão mais longo esse projeto.
Comparativamente, os projetos realizados em outros ramos de atividade econômica podem
ter uma média de duração (muito) mais extensa, de anos a décadas. A indústria farmacêutica é uma
área com projetos reconhecidamente longos, já que os medicamentos comercializados por essas
entidades levam, no mínimo, um par de anos antes de serem lançados para o usuário final nas
farmácias. Não raro, isso pode até levar décadas, uma vez que, até chegar ao público para consumo
nas prateleiras, os projetos submetem esses medicamentos a inúmeros e extensos testes, além de
outras exigências e pré-requisitos governamentais de alta complexidade a ser apresentados. No
Brasil, um projeto de lançamento de medicamento novo por uma farmacêutica só conseguirá ser
efetivamente implementado, ou seja, ter a venda liberada, após a aprovação da Agência Nacional
de Vigilância Sanitária – ANVISA.
A esfera pública, em todos os níveis – municipal, estadual e federal – também tendem a ter
projetos com maior duração, até pela maior cobrança popular e maior magnitude dos mesmos. Uma

12
obra governamental de construção de uma usina hidroelétrica, mesmo que tenha parte de capital
privado, será um projeto de grande duração, invariavelmente. Quando um governante assume uma
posição de prefeito, por exemplo, esperam-se dele rápidas ações para melhoramento do município.
Evidentemente, isso se dará por meio dos projetos que ele implementar e da qualidade no gerenciamento
dos mesmos. O eleitor que apostou nesse prefeito e que o colocou nessa posição, deu-lhe um voto de
confiança e, naturalmente, cria uma expectativa sobre os projetos que o elegido efetivará no seu
mandato. Muitos políticos, inclusive, usam a duração do seu mandato como desculpa para serem
reeleitos, alegando que não conseguiram efetivar todos os seus projetos no primeiro mandato,
precisando do segundo para implementar as demais realizações planejadas, mas não entregues.
Empresas de exploração e extrativismo mineral, inclusive as petrolíferas, também fazem
projetos com durações bastante extensas. Conforme a autora Jennifer Fogaça, para projetos de
refino de petróleo, primeiramente, há a fase de estudos geológicos para avaliar o nível de petróleo
presente. Se for economicamente viável (reserva volumosa), serão iniciadas as escavações, que
poderão se dar tanto no mar quanto em terra. Posteriormente, ocorrerá a fase do projeto chamada
de purificação, momento em que o petróleo passa pelas torres de fracionamento ou destilação por
diversas vezes. Dessa fase de destilação, normalmente, são resultantes gás, gasolina, óleos
lubrificantes e querosene, conforme ilustração abaixo:

Figura 1 – Refino de petróleo

Fonte: FOGAÇA, Jennifer Rocha Vargas. Refinamento do petróleo. Brasil Escola. Disponível em:
<https://brasilescola.uol.com.br/quimica/refinamento-petroleo.htm>. Acesso em: jan. 2019.

13
 Assim como nem todos os projetos de uma empresa de tecnologia serão curtos, nem todas as
empreitadas de uma farmacêutica, de um órgão público ou de uma petroquímica serão longas, mas
há uma maior tendência de que esses negócios sigam a tendência dessas generalizações.
Aqui, cabe fazer a diferenciação entre os conceitos de projeto e produto do projeto. “O produto
do projeto é aquilo que será entregue ao cliente e que deve estar referido no objetivo do projeto. O
produto é o novo bem ou serviço criado pelo projeto” (VALERIANO, 2001, p. 123). Enquanto a
construção das pirâmides do Egito foi um projeto empreendido há alguns milênios, o que temos
hoje de pé em Gizé são as pirâmides. Elas, em si, são o produto do projeto. O projeto (erguimento
delas) já foi concluído, conforme aliás reza a definição da temporariedade, vista anteriormente. A
temporariedade, como traço marcante de projetos, não se estende, necessariamente, aos produtos
dele, tanto que temos, até hoje, o produto desse projeto a ser contemplado em Gizé.
Um governador decide pela construção de uma nova avenida na capital do seu estado e
empreende com sucesso o projeto. Tão logo ocorra a inauguração dessa avenida, o projeto estará
concluído, mas a avenida recém-criada e a ser usada pelos cidadãos é o produto do projeto. O intuito
e o desejável é que esse produto seja útil aos moradores por décadas e até por mais de um século à
frente. Isso nos leva à conclusão de que a temporariedade dos projetos não deverá, necessariamente,
estender-se à temporariedade dos seus resultados. Pelo contrário, a meta da maioria dos gestores deve
ser que seus produtos ou serviços gerados pelos projetos sejam duradouros.
Para o desenvolvimento de um software, por exemplo, comporiam o projeto a sua concepção,
o seu desenvolvimento, a prova de conceito e a implementação piloto dele em um ambiente restrito,
como em um departamento apenas. Uma vez terminado com sucesso o piloto, seria concluído o
projeto. O software, em si, com as suas funcionalidades, produto do projeto, poderá ser usado daqui
para a frente pelos setores interessados dessa empresa até quando for útil (CAMARGO, 2014).

Diferenças e semelhanças entre projetos e trabalhos operacionais

Já sabemos que projetos são temporários e únicos, sendo distintos do conceito de trabalhos
rotineiros (ou processos). Enquanto projetos não se repetem, os processos têm como marca
registrada a repetição padronizada das suas entregas ou uma entrega continuada. A construção de
uma filial da CAF em uma nova cidade seria um evento único, já que haveria a construção de um
prédio exclusivo, diferente de qualquer outro construído no passado ou no futuro, a ser entregue
em dado período de tempo (temporário), tratando-se, por isso, de um projeto.
Por outro lado, o controle diário de estoque de uma firma de pintura ou a análise de crédito de
cliente em uma instituição financeira seriam exemplos de trabalhos rotineiros ou processos, dado o
seu cunho essencialmente repetitivo e cíclico. Uma fusão entre duas companhias gigantes automotivas
seria um megaprojeto, por se tratar de um esforço único e não repetível. No entanto, após a fusão ter
sido concretizada com sucesso, o dia a dia da nova empresa fundida seria processual, rotineiro.

14
 A operação diária de uma esteira de produção no chão de uma fábrica de fertilizantes seria
um trabalho operacional, já que os produtos finais da esteira seriam idênticos, padronizados,
repetitivos. No entanto, quando essa esteira de produção sofrer uma renovação em 80% das suas
peças, no ano que vem, isso será um projeto.
Outro aspecto que difere os dois conceitos é o foco de ambos. Normalmente, para o projeto,
há um foco em mudança, na expansão do negócio, em melhorias. Enquanto isso, para o trabalho
rotineiro a prioridade acaba sendo a manutenção da organização, a regularidade do dia a dia.
Segundo Valeriano (2001, p. 12),

as operações correntes são constituídas de vários processos produtivos e

administrativos executados por equipes permanentes dedicadas a cada um
dos processos, metodicamente repetidos (...) e constituem o trabalho
característico das fábricas de bens de consumo (automóveis, medicamentos,
produtos eletroeletrônicos, de entretenimento etc.), das instituições
prestadoras de serviços (saúde, ensino, transportes, comunicações), das
empresas fornecedoras de energia (eletricidade, combustíveis), do comércio,
dos bancos, etc. Outros tipos de operações são as atividades da
administração: administração de pessoal, finanças, compras, etc.

Essa distinção entre projetos e processos é bastante importante para aplicarmos as boas
práticas de gestão de projetos devidamente. Segue uma pequena lista de exemplos de projetos:
lançamento de nova opção de investimento;
criação de novo modelo de avaliação de desempenho;
demolição de shopping center;
reforma da casa de praia da família;
implementação de nova via férrea;
fundação de uma praça;
expansão de parque industrial;
instalação de células fotovoltaicas;
inauguração de feira de produtos e
instalação de autoatendimento em unidades bancárias.

Segue uma lista de exemplos de trabalhos operacionais (processos):

emissão de notas fiscais;
compra de material de expediente;
inspeção visual de esteira de produção;

15
 venda de mercadorias;
contagem automatizada de estoque;
controle de identificação de passaporte;
entrevista para vaga de departamento;
expedição de autorização de saída de embarcações;
assinatura de contrato de renovação com fornecedor e
validação de documentos automaticamente em instituição financeira.

Apesar das diferenças acima cobertas, há três pontos de convergência entre projetos e
processos. A primeira semelhança entre eles seria que ambos são feitos por pessoas. Por mais
automatizada que seja uma unidade bancária e usuária de tecnologias mais modernas, ainda se
necessita da presença do ser humano, isto é, da força de trabalho para executar as suas diversas
funções e processos. Talvez de maneira até mais clara, o mesmo se dá no ambiente de projetos, em
que a participação humana é essencial, tanto na execução das tarefas pelo time como pelo gerente
de projeto com a sua experiência técnica e tomada de decisão.
O segundo ponto afim é que tanto processos como projetos têm limitações de tempo e de
recursos, e isso afeta a sua gestão, já que nenhum dos dois detêm recursos ilimitados. Estamos falando
de qualquer tipo de recurso existente. Há o financeiro, o humano, o material (ou físico) e recurso
intangível do conhecimento, das habilidades, das informações. Nem projetos nem processos têm
todos os recursos à sua inteira disposição, sendo necessário que as empresas façam as suas priorizações.
Como terceira semelhança entre projetos e trabalhos operacionais, teríamos que ambos são
devidamente planejados e controlados para um melhor resultado. Dificilmente, hoje se permite
improviso na gerência de ambos. Nos dois ambientes, há estudos prévios de viabilidade e
planificação. Mesmo quando um processo simples está rodando em um setor, não se prescindem
avaliações contínuas de performance. Nem em projetos podemos nos dar o luxo de não planejar
nem de monitorar as entregas. Isso seria inaceitável na maioria das empresas.
Em suma, teríamos o seguinte quadro comparativo de processos e projetos:

Quadro 1 – Semelhanças e diferenças entre processo e projeto

trabalho a ser realizado

tipos processo (trabalho rotineiro) projeto

semelhanças realizados por pessoas;

limitados aos recursos disponíveis e
planejados, executados e controlados.

diferenças contínuo e repetitivo temporário e exclusivo

16
Subprojetos, programas e portfólio de projetos
Subprojetos
O conceito de projetos foi visto anteriormente, mas há necessidade de cobrirmos alguns
outros conceitos muito comuns no dia a dia de projetos e que fazem inclusive parte do jargão da
ciência do gerenciamento.
O primeiro é o conceito de subprojetos. De fato, existem projetos que são divididos em partes
menores, para facilitar a sua gestão. A essas partes menores, chamamos de subprojetos. Conforme
Vargas, “os subprojetos são responsáveis por uma pequena parte do projeto total ou por fases
extremamente específicas do projeto e podem, na maioria das vezes, ser terceirizadas ou
desenvolvidas por grupos isolados”. É importante ressaltar que os subprojetos devem ser geridos
como projetos, e não como força de trabalho ou como uma missão menor. Na parte de governança,
inclusive, deve ser nomeado um líder para cada um dos subprojetos; esse coordenador ou subgerente
responderá pela performance do seu subprojeto junto ao gerente de projeto.
O conceito de subprojeto é também bastante comum quando o projeto tem várias frentes
regionais e é então dividido em subprojetos, como “Subprojeto Região A”, “Subprojeto Região B”,
e assim sucessivamente. Outro exemplo seria a subdivisão de um projeto em vários subprojetos,
como “um projeto de melhoria na satisfação do cliente, que pode incluir três subprojetos, os quais
estão inter-relacionados e precisam ser gerenciados de modo coordenado e centralizado: 1)
aperfeiçoamento de funcionalidades do produto; 2) treinamento da equipe de pré-venda e 3)
melhoria do atendimento pós-venda” (GOZZI, 2016).
O autor Torres traz outros exemplos, como:

subprojetos baseados no processo do projeto, como uma fase específica no

ciclo de vida do projeto; subprojetos que atendem aos requisitos de
habilidades de recursos humanos, como encanadores ou eletricistas
necessários em um projeto de construção; subprojetos que envolvem
tecnologia especializada, como testes automatizados de programas de
computador em um projeto de desenvolvimento de software.

Programas
Um segundo conceito, mundialmente usado no ambiente de projetos, é o de programa,
definido pelo PMBOK como “um grupo de projetos relacionados gerenciados de modo coordenado
para a obtenção de benefícios e controle que não estariam disponíveis se eles fossem gerenciados
individualmente”. Isso significa que um grupo de projetos, por si só, não seria um programa

17
necessariamente. Somente cabe o conceito de programa quando os projetos fazem parte de um todo
e são inter-relacionados, coesos e, por isso, garantem maior sinergia entre si.
O termo programa, normalmente, é mais empregado em iniciativas de maior tamanho, de
alto risco ou que apresentem valor para o negócio da organização como um todo. Desse modo,
como a magnitude desses empreendimentos é maior, faz todo o sentido o uso dessa denominação.
Todos os projetos que estiverem contidas no programa, também chamado de estrutura guarda-
chuva, serão os projetos necessários para a empresa chegar à finalidade macrodefinida.
A Agência Espacial norte americana, NASA, é um excelente exemplo de utilização do conceito,
com o seu programa aeroespacial composto pelos diversos projetos de exploração in loco, e os de
pesquisa e desenvolvimento que essa entidade tem feito nas últimas décadas. Outros exemplos seriam:

as empresas de serviços públicos, que frequentemente falam de um

‘programa de obras’ anual, uma série de projetos desenvolvidos com base
em esforços anteriores. Muitas organizações sem fins lucrativos possuem
um ‘programa de arrecadação de fundos’ para obter apoio financeiro
envolvendo uma série de projetos distintos, como uma campanha para
atrair novos sócios ou um leilão. A publicação de um jornal ou uma revista
também é um programa em que cada problema específico é gerenciado
como um projeto (Torres, p. 113).

Em uma empresa automotiva, como a Ford, um novo modelo de carro a ser lançado pode
ser considerado um programa, subdivido em projetos como estudo de mercado, design, atualização
dos componentes, etc. Na Marinha brasileira, há o Programa Nuclear da Marinha, que contém dois
projetos: (1) Projeto de Construção do Núcleo do Poder Naval e (2) Sistema de Gerenciamento da
Amazônia Azul (SisGAAz). O primeiro projeto visa incrementar o poderio naval da Marinha com
diversas ações como aquisições de tecnologia mais moderna e construção de estaleiros. O segundo
projeto visa “ampliar a capacidade de monitoramento e controle das águas jurisdicionais e das
regiões de busca e salvamento sob responsabilidade do Brasil”1. O Programa Nuclear só será
considerado bem-sucedido quando ambos os projetos tiverem sido inteiramente entregues,
comprovando a natureza de interdependência entre eles.
Um ponto adicional a ser ressaltado é que programas podem ou não ter fim. Diferentemente
de projetos, que são temporários, como sabemos. Programas (como o da NASA) não tem fim
virtualmente, já que exploram o espaço. Assim também ocorre com um programa como o de

1
Disponível em: https://www.defesa.gov.br/industria-de-defesa/paed/projetos-estrategicos/projetos-estrategicos-da-
marinha-do-brasil Acesso em: jan. 2019.

18
recursos humanos da sua empresa. Ele pode conter projetos de variadas frentes (treinamentos,
recrutamentos, promoções, etc.), que terminam e se renovam ano a ano, ou em prazos maiores.
Evidentemente, para alguns programas, há um final pré-definido, normalmente atrelado à entrega
dos seus projetos constituintes e ao real alcance dos seus objetivos.
A seguir, as figuras ilustram a relação entre os 3 conceitos – subprojetos, projetos e programas:

Figura 2 – Distinção dos conceitos

Figura 3 – Programas, projetos e subprojetos

19
 Figura 4 – Gestão de programas

Fonte: TORRES, p. 69.

Para melhor diferenciação dos conceitos de projetos e programas, vale a leitura de parte do
texto do autor Clay Susini Aquino Junior, na qual explica:

no Brasil e, principalmente, no setor corporativo privado, projetos são

erroneamente definidos como Programas apenas por serem grandes. Mas o
tamanho é, simplesmente, a consequência, e não o motivo para um programa
existir. Outras justificativas usadas para transformar conjuntos de Projetos em
Programa são o aproveitamento da dinâmica comum de vários recursos e a
existência de inúmeras frentes de trabalho com mais de um time. Realmente,
Programas possuem essas características, mas apenas como consequência de
um fator maior: a concepção de uma ideia geradora de um benefício
estratégico, dando origem a um conjunto de iniciativas independentes
responsáveis por concretizar o benefício idealizado. Um Programa, antes de se
tornar um conjunto de projetos, nasce como uma ideia estratégica geradora
de um benefício singular, sem a real certeza de que virá a se tornar dois, cinco
ou dezenas de Projetos independentes. No momento de concepção do
Programa, não sabemos ao certo o que deve ser feito para atingir o benefício
idealizado, tampouco como fazer. Sabemos apenas que uma série de tarefas
independentes gerará um benefício estratégico e único. E é comum um
Programa, em plena execução, ainda gerar novos Projetos com o intuito de
consolidar o benefício estratégico definido anteriormente.2

2
AQUINO JUNIOR, Clay Susini. Diferenciando programas de projetos. Disponível em:
http://www.pmisp.org.br/enews/edicao1112/artigo_01.asp Acesso em: jan. 2019.

20
 De fato, se compararmos com o conceito de projetos explorado anteriormente, o esforço de
um projeto é mais palpável e concreto do que o de um programa. Até no que tange aos benefícios
obtidos pela empreitada, torna-se mais fácil e previsível listarmos as vantagens que um projeto trará.
Essa tarefa não é tão fácil quando se deve predizer os benefícios de um programa, até porque a
extensão no tempo tende a ser maior. Outro elemento que dificulta a previsão dos benefícios de um
programa tem a ver com a sua própria estrutura, já que é composto por inúmeros projetos no seu
interior. Isso torna a medição dos benefícios também mais complexa ou, pelo menos, mais
demorada. Sobre essa questão, o autor Clay comenta:

como exemplo, podemos citar o Programa de Aceleração do Crescimento

(PAC) do Governo Federal. O Programa possui como objetivo construir
infraestrutura logística e energética para sustentar o crescimento do País.
O objetivo de um Programa sempre terá a característica de ser abstrato, já
que na concepção da ideia só há a expectativa do benefício e não do objeto
entrega. Não sabemos exatamente o que terá que ser feito para que o
benefício seja obtido, tampouco como. O Governo Federal dividiu o PAC
em seis Subprogramas e duas Frentes de Trabalho. Os Subprogramas do
PAC são: PAC Energia, PAC Habitação, PAC Cidade Melhor, PAC
Comunidade Cidadã, PAC Água e Luz Para Todos e PAC Transportes.3

Portfólio de projetos
Não menos importante do que os conceitos anteriormente cobertos, há outro conceito, no
meio de gerenciamento de projetos, bastante comum, conhecido como portfólio. Aqui, já há uma
ligação concreta com a estratégia da companhia, já que o portfólio corresponde ao conjunto de
programas, projetos e subprojetos de uma entidade, vistos de maneira agrupada, ou seja, como uma
carteira mesmo. Em inglês, essa gestão de portfólio de projetos de uma companhia chama-se Project
Portfólio Management (PPM). A esse respeito, vejamos o que nos diz TORRES (2014):

A gestão de portfólio busca maximizar todos os recursos organizacionais e

alinhar esses as necessidades de médio e longo prazo da empresa. A gestão
de Projetos de Portfolio ou Gestão de Portfolio é um modelo de gestão dos
projetos mais amplo e completo. Desta forma, nenhum projeto é
concebido, selecionado, executado e transacionado sem passar pelos

3
AQUINO JUNIOR, Clay Susini. Diferenciando programas de projetos. Disponível em:
http://www.pmisp.org.br/enews/edicao1112/artigo_01.asp Acesso em: jan. 2019.

21
 critérios da Gestão de Portfolio. Os diretores e as equipes de
gerenciamento da diretoria, normalmente, assumem a responsabilidade de
gerenciar os portfólios para uma organização (p. 61).

De forma complementar, o gestor de portfólios assume grandes responsabilidades, como

o monitoramento de métricas mais estratégicas, a análise da performance financeira dos
projetos, o controle dos riscos, o cálculo do retorno sobre o investimento, a manutenção do
alinhamento dos projetos em curso com a realidade externa da companhia, a apuração de
tendências do negócio, entre outros.
A seguir, as figuras vêm ilustrar a relação de portfólio com os conceitos de subprojetos,
projetos e programas, anteriormente cobertos:

Figura 5 – Estratégia e projetos

22
 Figura 6 – Portfólio x programa x projeto x subprojeto

Figura 7 – Estrutura de portfólio, programa, projeto e subprojeto

23
 Figura 8 – Portfólio corporativo

Fonte: https://escritoriodeprojetos.com.br/portfolio-de-projetos

24
MÓDULO II – PROCESSOS DE GERENCIAMENTO
DE PROJETOS E CICLO DE VIDA

Neste módulo, veremos que como o gerenciamento de projetos se fundamenta em processos,

ou seja, grupos de ações e atividades inter-relacionadas e sobrepostas. Contemplaremos os 49
processos de gerenciamento de projetos e o conceito de ciclo de vida de um projeto genérico. Além
disso, apresentaremos as dez áreas de conhecimento e sua relação com a linha de base, assim como
os fatores-chave de sucesso de um projeto.

Alinhamento empresarial para o gerenciamento de projetos

Planejamento estratégico e projetos
O planejamento estratégico ocorre nos mais altos níveis da estrutura das organizações.
Normalmente, envolvem o conselho de acionistas, o presidente e altos diretores, grupo chave
responsável pela revisão da estratégia pré-definida da companhia na frequência devida. Tem-se
observado que os ciclos de revisão da estratégia estão cada vez mais curtos nas empresas, ainda mais
se considerarmos ramos de atuação mais competitivos e cambiantes, como é o de Tecnologia da
Informação ou de Telecomunicações.
O planejamento estratégico pressupõe análises além das fronteiras organizacionais, sendo
fundamental a compreensão dessa “foto” do ambiente antes da tomada de decisões ou antes de
(re)desenhar ou repensar a estratégia atual. Além do ambiente externo, fora dos limites empresariais,
há o interno ou organizacional, que também merece detida avaliação por parte da empresa. Há
diversas ferramentas para uma detalhada avaliação ambiental, sendo as duas mais famosas o Modelo
das Cinco Forças de Michael Porter e a Análise SWOT (ou PFOA, em português). Por ser uma
ferramenta clássica da Administração, optaremos pela segunda.
 A SWOT visa levantar os pontos fortes e pontos fracos, as oportunidades e ameaças presentes
na empresa em estudo. O seu nome deriva do acrônimo desses termos em inglês: Strengths,
Weaknesses, Opportunities e Threats. Os dois primeiros itens, pontos fortes e fracos, serão o
resultado da análise do ambiente endógeno da entidade. Esse diagnóstico será uma verdadeira
autoanálise ou raio-X da realidade interna, com apuração de potencialidades e vulnerabilidades.
As ameaças e oportunidades surgirão do levantamento do ambiente externo ou circundante
da companhia. Esse ambiente exógeno, evidentemente, é formado por elementos bastante
dinâmicos, de pouco ou nenhum controle por parte das empresas. Aqui, entram parâmetros
demográficos, políticos, socioeconômicos, legais, culturais, naturais, tecnológicos, entre outros.
Quando positivos, esses fatores atuarão como oportunidades, porque a organização poderá ser
beneficiada com tal cenário e, inclusive, alavancar ganhos. Quando os fatores externos tiverem
aspectos negativos, que imponham cenários prejudiciais à empresa ou até comprometam o cenário
futuro, serão apropriadamente chamados de ameaças.
Normalmente, a SWOT é construída da seguinte forma:

Figura 9 – Análise SWOT

Fonte: Shutterstock.

26
 Para efeito de exemplificação, os seguintes itens poderiam advir de uma análise dos fatores
internos de uma empresa qualquer:

a) Pontos fortes
boa localização geográfica dos pontos de venda;
boa qualidade no atendimento percebida pelos clientes;
know-how de mercado;
renome junto à clientela;
inovação tecnológica;
receptividade da força de trabalho;
vantagens de custos;
patentes por mais 3 anos;
flexibilidade em negociações com clientes;
líderes dos setores compromissados;
bons equipamentos;
economias de escala na produção;
alta liquidez financeira;
índices de lucratividade positivos, etc.

b) Pontos fracos
recursos humanos desmotivados com a política salarial;
propagandas ineficazes;
falta de sistema financeiro automatizado;
setor de compras burocratizado;
distribuição de produtos limitada;
pouca força de marca;
baixo conceito junto ao mercado;
custos fixos elevados;
localização não favorável;
falta de acesso a fontes de matérias-primas;
pouco controle sobre a rede de distribuição;
custo final elevado;
fragilidade no atendimento;
elevado grau de insatisfação em determinado produto ou serviço;
alto índice de devolução de mercadorias ou mercadorias danificadas, etc.

27
 Os seguintes itens poderiam advir de uma análise externa dessa mesma empresa:

a) Oportunidades
saída de concorrente forte;
incentivos fiscais;
potencial aliança estratégica com outro varejista;
ingresso em novo país (mercado internacional);
remoção de barreiras internacionais em novos mercados;
afrouxamento de regulamentações;
necessidades não satisfeitas do consumidor;
aumento do poder de compra do mercado;
maior disponibilidade de linhas de crédito;
economia aquecida;
alterações na legislação (tributária, trabalhista, ambiental, etc.) favoráveis à atividade
exercida pela empresa;
aliança estratégica, etc.

b) Ameaças
mercado demográfico em declínio;
fornecedor-chave com problemas de liquidez;
pouca inovação nas tecnologias de fabricação dos fornecedores;
guerra de preços na indústria;
mudanças nos padrões de consumo;
produtos similares com o valor final mais barato;
lançamento de produtos substitutos no mercado;
entrada de novos rivais no país;
redução no poder de compra dos consumidores;
instabilidade no mercado financeiro, etc.

A análise SWOT devidamente preenchida é um dado frio se não for usada para facilitar e
embasar o planejamento estratégico organizacional. Essa ferramenta, quando bem utilizada, traz
direcionamento e segurança nas decisões futuras, tanto que é, em seguida a levantamentos
macroambientais como esse realizado pela SWOT, que os altos executivos alinham a estratégia das
suas companhias no momento de escolha dos projetos a serem implementados. É óbvio que
tomadores de decisão de nível estratégico recebem inúmeras propostas de projetos, dos mais
variados conteúdos e envergaduras, oriundos de diferentes setores da empresa, e até algumas
propostas de projetos multissetoriais ou multidisciplinares.

28
 Entre essas alternativas ou propostas recebidas, certamente, há as boas opções de investimento
e outras que não se adequam à trilha estratégica adotada pela empresa. Sendo assim, no momento
de escolha, conhecido como “funil de oportunidades” ou seleção de projetos, algumas propostas
serão aprovadas (suportadas), enquanto outras não serão levadas à diante.
Tanto a estratégia empresarial como a política de seleção e priorização dos projetos terão de
ser conciliadas nos casos de ideias aprovadas. Dificilmente, uma proposta de projeto desalinhada
com a estratégia da companhia será aprovada pelo conselho deliberativo ou pelo presidente da
empresa para se tornar uma empreitada efetiva. Claro que existem algumas exceções, como projetos
motivados por imposição legal, conforme vimos no módulo 1. Sob essas circunstâncias, a empresa
não tem a opção de ignorar a premência do projeto, já que se trata de uma necessidade obrigatória
e precisa ser endereçada por meio de um projeto de adequação. Desse modo, tais projetos de
resposta a mudanças legislativas se tornam mandatórios e ingressam por isso no funil de
oportunidades com prioridade.
Segundo Vargas, há inúmeros fatores considerados no processo decisório (a favor ou contra)
uma ideia (ou proposta) de projeto. Além do alinhamento estratégico já citado, podem ser adicionados
outros itens, como a capacidade de execução do projeto, o retorno do investimento prometido por
ele, a sua complexidade, o nível de riscos previsto, a flexibilidade que será obtida e os recursos
atualmente disponíveis na entidade. Alguns empreendimentos são aprovados porque melhorarão a
reputação da empresa, ou porque prometem trazer compartilhamento e otimização de recursos.
Questionamentos adicionais podem ser feitos durante o julgamento ou funil de
oportunidades, tais quais se o projeto proposto trará uma carga de diversificação de mercado à
companhia, ou se a natureza da empreitada é familiar ou muito distante da que a organização
domina. Todo esse processo acima explicado, com os critérios de avaliação dos projetos proponentes
e a decisão por aprovação (realização), encontra-se na ilustração a seguir:

Figura 10 – Estratégia empresarial e seleção de projetos

Fonte: TORRES, 2014, p. 62.

29
 Evidentemente, há mais propostas de projetos no início do funil do que na sua saída.
Enquanto muitas propostas de projetos são rechaçadas e não se tornam projetos efetivamente,
outras são escolhidas por preencherem os critérios pré-fixados pelos avaliadores. Tais propostas
recebem o aval para ser implementadas. A maioria dos projetos selecionados e realizados nas
organizações atendem às necessidades mais adequadamente do que outros, ou assim foi percebido
pelos tomadores de decisão no momento da decisão. No cômputo geral, o processo de seleção de
projetos poderia ter essa visualização:

Figura 11 – Seleção de projetos

Fatores motivadores de projetos

É necessário aprofundar a razão de ser dos projetos nas organizações, ou seja, definir por que as
empresas investem nessas iniciativas. Normalmente, os maiores estimuladores de projetos nas empresas
são exógenos, tais quais a competição, padrões de qualidade, mudanças econômicas e fatores políticos.
Outro fator motivador de projetos dentro das companhias são os de cunho legal, conforme
visto anteriormente. Esses impulsionadores legais exigem atenção plena das empresas. Mudanças
nas diversas legislações são bastante comuns e precisam de rápida adequação. Quando muda a
legislação ambiental em um país, por exemplo, as empresas que ali estão precisam se adequar às
novas designações e isso é feito, normalmente, via projetos.

30
 Quando são aprovadas leis de alcance nacional (ou até internacional), com critérios mais
exigentes na questão da “pegada de carbono”, empresas poluidoras daquele país ou as afetadas pela
deliberação também precisarão esboçar uma rápida resposta e adequação às novas exigências. Muitas
vezes, as novas legislações impõem metas agressivas, e as companhias afetadas precisam implementar
projetos para responder à nova configuração imposta, sob pena de sofrerem represálias e multas, ou
mesmo comprometer as suas operações no futuro.
Um exemplo prático de como mudanças legais geram a necessidade de projetos ocorreu em
2014, quando uma lei brasileira obrigou todas as montadoras a fabricarem todos os seus automóveis
com airbags. Logicamente, essa nova definição provocou uma imensa quebra de paradigma para a
indústria nacional automotiva, mas não havia o que fazer senão adaptar-se à deliberação.
Em seguida, as montadoras brasileiras lidaram com a imposição e se adaptaram à nova lei por
meio da implementação de projetos internos de readequação. Com a obrigatoriedade de airbags em
todos os automóveis fabricados, essas empresas tiveram de refazer o design de muitos dos seus
modelos para entrar em conformidade com os futuros lançamentos. A inclusão desse atributo
adicional de segurança também afetou e exigiu um novo desenho nos seus sistemas de custos.
Outro tipo de mudança exógena que afeta o dia a dia de qualquer organização são as mudanças
tecnológicas. Esse é um dos fatores que mais exige atualização por parte das empresas, muito mais
bem-sucedida quando feita via projetos. As tecnologias de hardware e de software evoluem de forma
muito veloz na atualidade, por isso, somente com a visão de projetos é possível às empresas se
manterem razoavelmente atualizadas no quesito tecnológico, sendo que algumas impõem para si
prazos de readequação, como alguns órgãos públicos brasileiros. Alguns mantêm um parque com x
notebooks para os seus servidores ativos durante um prazo limite de 3 anos e se comprometem de fazer
um projeto de renovação ou de refresh desse maquinário todo ao final do período.
Tais projetos de atualização se repetem, aliás, em ciclos cada vez menores, por conta de a área
de Tecnologia da Informação (TI) sofrer reais mudanças em menor tempo. Não é surpresa que haja
uma grande presença do cargo de gestor de projeto nessa indústria há muito mais tempo do que em
outras, como confirma o autor Ricardo Vargas (2016): “alterações tecnológicas, que anteriormente
levavam décadas para serem implementadas por completo, hoje tomam apenas algumas horas, em
um nível de complexidade altíssimo”.
Outro fator exógeno motivador de projetos nas organizações é o requerimento dos seus
clientes. É natural que esse seja um dos maiores causadores de projetos no seio das empresas, já que
as organizações, em geral, geram receitas por meio das vendas de produtos ou serviços a essa
clientela. Quando uma entidade satisfaz e até supera as expectativas dos seus clientes, consegue
melhores resultados financeiros, distribui melhores dividendos, recompensa os seus colaboradores,
melhora a sua imagem, entre outras vantagens, em um grande círculo virtuoso trazido pelos seus
projetos de marketing. Nesse caso, obviamente, entram os projetos mercadológicos como os

31
lançamentos de produtos, serviços ou uma nova campanha de identidade visual, uma nova
promoção publicitária, pesquisas de tendências comportamentais, assim como iniciativas de recall
de produtos, relançamentos, expansões geográficas, etc.
Caso multinacionais decidam ingressar em um país pela primeira vez ou caso uma pequena
empresa de marcenaria inclua, no seu portfólio de produtos, um novo modelo de móvel, ambas
estarão, respectivamente, implementando projetos com foco total nos seus clientes, futuros ou
atuais. Esses projetos são movidos para melhor satisfazer a demanda do seu público-alvo e, por isso,
considerados verdadeiramente estratégicos. Um fracasso pode ser, até mesmo, uma questão de
sobrevivência, mais ainda se o setor de atuação tiver um alto nível de competição.
A ação dos concorrentes da empresa executora dos projetos é também uma feroz provocadora
de projetos. De fato, se um agente externo, rival de nossa firma, lança um novo produto com sucesso
de vendas, evidentemente, será necessária uma imediata reação de nossa parte. Isso se dará com a
concepção de um projeto envolvendo, no mínimo, o time de marketing e de produção para, juntos
e rapidamente, conceberem um projeto em reação ao lançamento promovido pelo concorrente.
Cabe ressaltar: ainda que tenhamos sucesso nesse projeto de contra-ataque, o fato de termos feito o
nosso lançamento em resposta ao dele, ou seja, posteriormente ao movimento do concorrente, pode
ser entendido negativamente pelo nosso consumidor.
Um exemplo real dessa situação de projeto alavancado pelo fator da concorrência ocorreu
com a Agência Espacial norte-americana, NASA. Em pleno período de Guerra Fria, os russos
lançaram, com sucesso, o seu primeiro satélite espacial, antes de qualquer outro país, pondo os
soviéticos na liderança da iniciante corrida espacial. Isso levou os norte-americanos a uma imediata
resposta, via criação de uma agencia não militar de conquista do espaço. Nesse contexto, a NASA
foi concebida por decreto do presidente Eisenhower em 1958.
Outro fator motivador de projetos, também externo à empresa, é a demanda da sociedade ou
da comunidade. Anteriormente, as empresas públicas detinham mais atuação e foco nesse tipo de
foco de projetos. No entanto, há pelo menos três décadas, a iniciativa privada também tem abraçado
esses tipos de projetos, de conotação maior e que visam um alcance muito além dos consumidores-
alvo habituais da empresa. Projetos com foco maior na justificativa societal costumam ter um apelo
social, cultural ou ecológico, diferente das atividades fins das entidades. Por isso, uma empresa de
produção, refino e distribuição de petróleo pode se ver investindo em projetos como peças de teatro,
limpeza de rios ou mares, circundantes a suas atividades.
Nessa mesma linha de projetos societais, algumas organizações apostam em empreitadas de cunho
social junto a populações menores carentes, como renovação da escola municipal ou uma campanha de
admissão de menores aprendizes. Há outras empresas que primam por projetos com mais ênfase
ecológica ou selo verde, quando promovem, por exemplo, um projeto de reciclagem de dejetos da
associação do bairro ou quando fazem parceria com a prefeitura para otimizarem a rede de esgoto.

32
 Nessa linha, o Instituto Coca-Cola implementou a Aliança Água+Acesso na zona rural
brasileira com campanhas de conscientização sobre o uso racional da água. “O programa começou
atuando com nove organizações em três estados. Atualmente, já são 15 projetos envolvidos em oito
estados. A perspectiva é de crescimento e o impacto deve chegar a 70 mil pessoas e mais de 200
comunidades em 2019”4.
No passado, havia mais críticas contra esses projetos societais por parte das corporações,
alegando que se tratava de manobras falsas ou oportunistas. Hoje em dia, os críticos estão
repensando a sua posição, já que são muitas as empresas investindo em projetos com fator
motivador distinto de sua atividade-fim, e a tendência é crescente, uma vez que já está provado que
a sociedade está esperando, e até cobrando, projetos dessa natureza por parte do setor privado.
Obviamente, os projetos também podem ser internamente justificados, ou seja, são
empreendidos pela necessidade do próprio negócio, como corte de custos ou otimização dos
processos. Quando uma empresa fabril faz um projeto de reengenharia do seu chão de fábrica
porque precisa otimizar o seu output, a grande motivação do projeto é interna mesmo. Ou mesmo
quando um setor como o de recursos humanos de um banco decide investir em um projeto de
aperfeiçoamento dos seus operadores de caixa, certamente, a justificativa foi principalmente
intrínseca, ou seja, melhorar a qualificação dessa equipe de modo a otimizar os serviços por eles
prestados. Além disso, como resultado também desse ciclo virtuoso, os clientes do mesmo banco
perceberão mais valor nesses atendimentos.
Outros setores empreendem os seus projetos, como a de recursos humanos, com o intuito de
aperfeiçoar a qualificações do quadro de funcionários, por exemplo, ao implementar um novo Plano
de Cargos e Salários. O setor de tecnologia da informação também é bastante conhecido por ter
sempre muitas implementações de projetos, muitos deles motivados por melhoramento interno do
parque de máquinas, por exemplo, tal como uma megainstalação de novos softwares de gestão.

4
Fernandes, Yuri. Gestão comunitária da água muda realidade de milhares de famílias nas zonas rurais da Bahia.
Disponível em: https://www.cocacolabrasil.com.br/historias/central-gestao-comunitaria-da-agua-muda-realidade-de-
milhares-de-familias-na-
bahia?gclid=Cj0KCQiAvqDiBRDAARIsADWh5TfNSLV0OIX7R4N9a4K5mQ3APmxO2xWshMdVnp_PSAyFpYYJNj0MvsUaAvTUE
ALw_wcB. Acesso em: jan. 2019.

33
Stakeholders
A palavra stake, em inglês, tem como um dos seus significados a palavra “interesse”, sendo
assim, uma pessoa interessada em um projeto é um stakeholder, ou um ator do projeto, um
envolvido, uma entidade (pessoa física ou jurídica), uma parte interessada ou constituinte. O
PMBOK 2017 acrescenta que

partes interessadas no projeto são pessoas e organizações ativamente

envolvidas no projeto ou cujos interesses podem ser afetados como
resultado da execução ou do término do projeto. Podem também exercer
influência sobre os objetivos e resultados do projeto.

Dificilmente, um projeto é bem-sucedido sem a devida gerência dessas personagens, que

podem atuar negativamente no empreendimento caso não percebam valor no mesmo. Porque os
projetos trazem mudanças, como falamos no módulo 1, haverá resistências naturais de alguns
stakeholders contra a execução do mesmo. De fato, diversos projetos fracassam por ter tido a
interferência negativa de um ou mais stakeholders. Quanto mais poderoso for um stakeholder, mais
risco é criado se essa parte tiver uma relação negativa em relação ao projeto.
Um exemplo desse contexto pode ser de um projeto interno, gerido pelo setor da
Contabilidade, que tenha sido negativamente percebido pelo departamento de informática. Se ele
tiver muito poder para bloquear o projeto, o risco aumenta. Ciente disso, o gestor de projeto da área
de Contabilidade deve agir rapidamente para reverter essa percepção do seu stakeholder negativo.
Projetos reconhecidamente poluidores, como os feitos por empresas mineradoras, são
costumeiramente bloqueados pela ação feroz de partes interessadas como ONGs ambientais, fundações
de índios e quilombolas ou comunidades locais. Como essas entidades são afetadas diretamente por
esses projetos, tendo os seus interesses prejudicados, a reação é negativa contra as empresas executoras,
via campanhas populares, acionamento do Ministério Público e com uso da mídia.
É importante frisar que a presença de stakeholders negativos é válida a todo e qualquer projeto,
independentemente da sua magnitude. Mesmo projetos domésticos ou internos podem ter
envolvidos que enxergam o projeto como lhes sendo desfavorável.

34
 Evidentemente, os stakeholders encontram-se no âmbito da empresa e fora dela, sendo
igualmente necessária a identificação de todos. Como sabemos que projetos são singulares, haverá
interessados distintos para cada projeto. No entanto, os principais stakeholders existentes na grande
maioria dos projetos são:
Gerente de projeto (GP) – é o personagem responsável pelo projeto. Integrador de todos
os demais stakeholders e que planeja o uso dos recursos. Detém a autoridade e a
responsabilidade de todo o esforço, respondendo pelo seu sucesso ou fracasso e pela sua
entrega plena. Falaremos mais desse stakeholder central no tópico seguinte.
Cliente – é o contratante ou demandante do projeto, aquele que utilizará os produtos ou
serviços a ser gerados ou quem adquire os resultados produzidos. É a parte interessada a
quem o projeto se destina. Pode ser um cliente externo ou interno do projeto. Apesar do
primeiro ser mais comum, há inúmeros projetos internos nas organizações cujos
destinatários são outros departamentos (divisões) ou pessoas de dentro da própria
entidade. Já os clientes externos não fazem parte da empresa executora do projeto. Por
exemplo, quando o setor financeiro solicita ao setor de informática que desenvolva um
novo sistema de emissão de notas fiscais eletrônicas, trata-se de um projeto interno em que
o setor de informática será o executor, atendendo a uma demanda do cliente (interno),
que é a área financeira.
Organização executora ou hospedeira – é a contratada, ou seja, a firma dentro da qual o
projeto será executado e cujos funcionários estão diretamente envolvidos na execução do
trabalho do projeto (CAMARGO, 2014).
Patrocinador – é a pessoa, o grupo ou a organização que, normalmente, tem a ideia do
projeto e a defende, estrategicamente, na alta cúpula da companhia. O patrocinador (ou
Sponsor) fornece os recursos financeiros e ideológicos para a execução do projeto.
Equipe – é o grupo de pessoas que responderão ao GP e que atuam diretamente na entrega
dos produtos ou serviços do projeto. Podem vir cedidos de outras áreas da companhia ou
do mercado, mas a sua função é de executar o projeto. Desse modo, Valeriano (2001)
afirma que a equipe do projeto “é multidisciplinar e tem uma vida limitada à duração do
projeto, isto é, o executante de um projeto está em uma posição transitória (...)
desempenhando certa tarefa em uma equipe transitória. (...) A equipe de projeto é extinta
com a obtenção de seu resultado” (p. 24).

Outros stakeholders poderão ser mapeados adicionalmente, variando bastante em função da

natureza do projeto e da indústria em questão. Alguns exemplos de partes interessadas identificáveis
nos diversos projetos poderiam ser: gerentes funcionais da organização executora do projeto, o
PMO (Escritório de Projetos), concorrentes, fornecedores de diversas ordens, agentes reguladores,

35
órgãos governamentais (das diferentes esferas), instituições bancárias, mídia, ONGs, órgãos de
classe, sindicatos, associações de bairro, institutos de pesquisa, hotéis, fundações, militares,
universidades, centros de pesquisa, hospitais, famílias, acionistas, etc.
A seguir, temos uma boa visualização dos principais constituintes em um ambiente de projeto:

Figura 12 – Partes interessadas do projeto

Fonte: VARGAS, 2016.

36
 Na figura a seguir, temos o mesmo esquema preenchido com os stakeholders da SulAmérica,
empresa brasileira de seguros:

Figura 13 – Mapa de stakeholders – Sulamérica

Fonte: http://ri.sulamerica.com.br/static/ptb/perfil-missao-visao-e-valores.asp?idioma=ptb

Habilidades e competências do Gerente de Projetos

Como toda equipe necessita de um líder, não seria diferente no contexto de projetos, sendo
tal posição ocupada pelo gerente. Há inúmeras habilidades que fazem toda a diferença para esse
maestro de todo projeto, tanto que a literatura destina muitos capítulos sobre o tema, que é motivo
de muitas teses. Há bastante discussão sobre qual a ideal combinação de habilidades e competências
que um gerente de projeto deve apresentar para garantir sucesso nas suas empreitadas. Apesar das

37
diferentes qualidades ou traços elencados pelos diversos autores, tem-se concordado que um gerente
de projeto deveria deter os 3 grandes grupos ou esferas de competências citados a seguir:
a) Habilidades do negócio – capacidade de conhecer o ramo de atividades do projeto, as
suas tendências e movimentos, a parte verdadeiramente técnica do projeto, o know-how
do setor, seja qual for, bancário, varejo, extrativismo, etc.
b) Habilidades de gerenciamento de projetos – como gestor e responsável pelo
empreendimento, caberia ao gerente conhecer as técnicas de gestão de projetos, as
ferramentas de otimização.
c) Habilidades gerenciais ou comportamentais – também se espera do gerente um aspecto
mais soft, intangível, evidenciado em competências interpessoais, como a empatia,
liderança efetiva, boa negociação, tomada de decisão de qualidade, entusiasmo,
transparência, entre outras.

Na prática, essas 3 esferas se sobrepõem e poderiam ser representadas da seguinte maneira:

Figura 14 – Esferas de competência do gerente de projetos

38
 Vale fazermos algumas reflexões sobre o tema a partir do texto de Luis Torres (2014, p. 106-
109), a seguir.

Gerenciamento de projetos: conhecimentos, habilidades e atitudes

A habilidade em gerenciar projetos é muito similar com a habilidade de gestão em áreas

administrativas, as mesmas competências usadas em áreas correlatas podem facilmente
serem adaptadas ao gerenciamento de projetos e vice-versa. Espera que o gerente de projeto
possa conduzir o projeto do conceito (iniciação) até a entrega final (encerramento) com
exímio e excelência dentro das expectativas das partes interessadas que não se limitam a
escopo, tempo, custo, qualidade, risco, etc. Essas expectativas são circunstancias e podem
afetar todas áreas de conhecimento do guia PMBoK® e outras áreas de fronteira que não
presentes no guia. Cada organização se adaptada e cria seu conjunto de exigências e define
seus critérios de entrega e sucesso para o gerenciamento de projetos. Para tanto, são
necessárias algumas referências básicas para evoluirmos no contexto, já que sabemos a
diferença entre gestão e gerenciamento e plano de planejamento. Quais são as habilidade,
conhecimento e atitudes que podem conduzir o projeto ao sucesso? Como definir e
caracterizar sucesso para Projetos, Programas e Portfólios?

Gerenciar projetos requer um conjunto de competências técnicas e não-técnicas que

objetivam tal excelência, nesse capítulo iremos abordar esse conjunto de habilidades,
conhecimentos e atitudes que influenciam os resultados dos projetos e também os tipos de
estruturas organizacionais e como cada uma delas pode influenciar na forma e modelo de
gerenciamento de projetos.

Conhecimentos

Para gerenciar projetos, programas e portfólios é necessário um conjunto de conhecimentos.

Fundamentalmente, é necessário que o gerente de projeto conheça o negócio ou a estratégia
do negócio da organização. Se o gerenciamento do projeto ocorre na indústria, é importante
que gerente tenha conhecimento do setor, bem como suas características, sazonalidade e
ambiente interno e externo.

É relevante o conhecimento do negócio, já que há projetos que visam aumento de receita,

redução de custos, ampliação e até maximização de recursos. Caso o gerente de projetos não
esteja habituado com o setor, segmento ou não tiver conhecimento correlatos sobre
características especificas do segmento onde atua, pode não atender as expectativas dos
envolvidos de forma plena e absoluta. Porém, se o gerente de projetos tiver sólidos
conhecimento em metodologias de gerenciamento de projetos bem como ferramentas e

39
 técnicas, o gerente de projetos pode influenciar de forma positiva o resultado do projeto.
Mesmo em circunstancias onde o gerente de projetos não tenha sólidos e fundados
conhecimento no segmento que atua. Neste caso, o gerente de projeto será um facilitador
das metodologias, integrador dos conceitos e, por meio das ferramentas e técnicas poderá
controlar os resultados e expectativas dos projetos. Da mesma forma se o projeto ocorrer
em um segmento de serviços, onde a velocidade de resposta a uma demanda de mercado
faz toda diferença; tais como: empresas que desenvolvem aplicações, ou serviços sazonais,
ter dinamismos para responder essas necessidades de mercado é fundamental para atender
uma necessidade pontual ou mesmo responder a uma oportunidade de negócio.

O conhecimento de negócios não se restringe apenas ao ambiente do projeto. Vamos tomar

como referência um projeto em um banco, qual é o negócio principal de um Banco? Muitos
irão dizer cartão de credito, previdência, seguros e tantos outros serviços. De certa forma,
estão todos certos, já que são produtos que trazem resultados financeiros e muito destes,
excelentes, resultados. Mas ao perguntar para um diretor de operações ou executivo de
negócios de um banco, muito provavelmente, esse irá dizer que o Conta Corrente é o negócio
principal, já que o Banco entende que por meio desse serviço que além de bons resultados,
alavanca outros serviços e produtos. É comum em noticiários, jornais ou revistas verificarmos
que as receitas oriundas de serviços ao correntista (conta corrente) paga todos os custos
operacionais do banco (folha de pagamento, custos diretos, custos associados aos
funcionários, etc.). Desta forma, evidencia-se a relevância do serviço, bem como a
responsabilidade em prover o serviço por parte do banco. Dito isto, se o gerente de projeto
estiver trabalhando com um projeto que impacte a conta corrente, como ele deve gerenciar
esse projeto? Como mais um projeto ou como um projeto estratégico? Caso seja percebido
que o projeto gerenciado é um projeto de portfólio, projeto estratégico, não apenas alcançar
o resultado sob os aspectos operacionais será o principal objetivo, mas acima de tudo
maximizar recursos, operacionalizar receitas e trazer valor agregado para o Banco, se
estivermos em um projeto bancário de cunho estratégico.

Desta forma, o conhecimento não apenas da melhor abordagem, iterativa, incremental ou

linear será o diferencial, como também, conhecimento de disciplinas correlatas como
matemática financeira, estatísticas, padrões e standards de qualidades, administração de
contratos, relacionamento com fornecedores e por fim técnicas e ferramentas que viabilizem
a execução do projeto. Não se espera que o gerente de projetos seja um: super-homem dos
negócios. O que se busca aqui é desenvolver um profissional que traga resultados e valor
agregado aos negócios que está inserido de tal sorte que além de alavancar resultados
financeiros possa ainda mais. É recomendável que, além das habilidades interpessoais, o
gerente de projetos saiba disseminar suas habilidades por meio de coach, gestão de pessoas
e tenha conhecimento não apenas das disciplinas de gerenciamento e projetos e também de
disciplina que corroborem com desenvolvimento das pessoas ao seu redor, por isso que
também é relevante as habilidades gerenciais e ou comportamentais.

40
 Habilidades

O PMBoK traz um conjunto de habilidades interpessoais que considera relevantes para o

sucesso da interação durante o ciclo de vida do projeto, entretanto essas habilidades que o
guia recomenda são importantes não apenas para o gerente mas para todos os executivos
de projetos que buscam entender o ambiente organizacional e obter com esse uma boa
interação e resultados, o guia aponta as seguintes habilidades interpessoais: liderança,
formação de equipe, motivação, comunicação, influência, tomada de decisão, consciência
política e cultural, negociação, confiança, administração de conflitos e coaching.

TORRES, Luis. Gerenciamento de projetos: conhecimentos, habilidades e atitudes. In:

Fundamentos do gerenciamento de projetos. Rio de Janeiro: Elsevier, 2014.

De forma muito similar, mas sintética, Valeriano (2001, p. 139) apresenta o quadro, a seguir,
com os “atributos desejáveis de um gestor de projetos”:

Quadro 2 – Atributos do gestor de projetos

conhecimento do sistema administrativo-financeiro da

organização

conhecimento do sistema de administração de rh da

organização
conhecimento
conhecimento da organização, de suas práticas,
organizacional
políticas e valores

consciência de custo e das implicações administrativas

das decisões técnicas
conhecimentos conhecimentos dos produtos, missões e mercados ou
clientes da organização

conhecimento em áreas correlatas à especialização

competência técnica na área de especialização

conhecimento domínio de métodos de pesquisa

técnico capacidade de planejamento, organização e controle

capacidade de liderança

capacidade de autoanálise
capacidade de alocação de recursos

41
 capacidade de gerar confiança no superior
habilidades de
escolha do estilo de liderança adequado
comando
habilidade de tomada de decisão

habilidades capacidade de trabalhar em equipe

outras criatividade

habilidades habilidade de relacionamento pessoal

capacidade de redigir com clareza, precisão e concisão

posicionamento interesse por questões administrativas

em relação a disciplina de trabalho
aspectos
atitudes entrosamento com pessoal externo à organização
internos e
externos ambição profissional

estratégia de hábito de atacar o problema pela revisão da literatura

ação hábito de leitura sistemática de textos técnicos

Fonte: Valeriano (2001, p. 139).

Por último, mas não menos importante, temos o texto do reconhecido autor André Barcaui
(2006) sobre o tema.

O equilíbrio necessário para se tornar um excelente gerente de projetos

Atualmente, muito se fala sobre gerência de projetos. Tanto em meio acadêmico quanto
profissional. Mas até que ponto a atividade de gerenciar um time em direção a um objetivo
específico com prazo determinado pode ser considerada uma disciplina? E se assim não for,
como almejar ensiná-la por meio de cursos de aperfeiçoamento para gerentes ou
certificações? Que variável acaba sendo mais importante na condução de um projeto: o
conhecimento técnico e metodológico ou as chamadas habilidades interpessoais de quem o
conduz? Em outras palavras, é preferível um gerente com profundos conhecimentos técnicos,
mas com pouca experiência e vivência na gerência de pessoas? Ou seria melhor considerar
um gerente com pouco ou até nenhum conhecimento técnico, mas que dominasse como
ninguém o lado interpessoal e de relacionamento de equipes? Ou talvez devesse existir um
meio termo, como um gerente atuante em todas as dimensões. Mas se assim for, qual a
composição ideal de cada competência? Deveria essa composição variar com o tipo de
projeto que estaria sendo gerenciado?

42
Projetos versus pessoas

Independente do segmento de indústria ou ramo de negócio, a atividade de gerenciar

projetos vem crescendo de maneira exponencial no mercado de trabalho. O interesse pela
atividade assumiu proporções significativas no mundo corporativo, principalmente para que
as empresas possam atender melhor a necessidade de se produzir cada vez melhor, mais
rápido, mais barato, com menos recursos e com a devida qualidade. Esse interesse se
confirma por meio da grande procura pela carreira de gerência de projetos e pela quantidade
de investimento em treinamentos, consultorias e ferramentas sendo feito atualmente. No
livro Gerente também é Gente: Um Romance sobre Gerência de Projetos, o personagem
principal da história, recém-promovido a gerente, tem que enfrentar três diferentes projetos,
com diferentes níveis de complexidade ao longo de sua saga. Para tanto, conta com a ajuda
de um gerente mais experiente, que acaba por ensiná-lo que gerenciar projetos é muito mais
do que somente o uso de técnicas e ferramentas. Para obtenção do sucesso, é preciso ser
um bom conhecedor de pessoas, e o protagonista acaba aprendendo isso ao mesmo tempo
em que tem que administrar sua vida profissional e pessoal. Com base nessa visão, o livro
tenta apresentar uma visão menos limitada a métodos e processos, sendo mais abrangente e
considerando também o lado humano do gerente de projetos, inclusive abordando pontos
como: conflitos pessoais, inseguranças e medos inerentes ao cargo.

Na vida real, o gerente, líder, ou coordenador de projetos, acaba por desempenhar um papel
de fundamental importância para o sucesso dos projetos de uma organização. Se
considerarmos que esses projetos representam o meio para a realização da estratégia de
negócios da empresa, a importância de um bom gerente no comando acaba constituindo
fator crítico para esse sucesso. No entanto, as características que determinam um gerente de
projetos de sucesso nem sempre são tão facilmente mapeáveis. Historicamente, o
conhecimento técnico, do negócio e a própria formação acadêmica eram considerados
pontos fundamentais para a boa escolha de um gerente.

Mais recentemente, outras características passaram a ser consideradas e valorizadas.

Habilidades antes consideradas como desejáveis, passam a assumir um outro grau de
importância. São elas: relacionamento interpessoal, gestão de conflitos, inteligência
emocional, liderança, comunicação, negociação, coaching, etc. Todas essas características
somadas certamente representam um peso importante no perfil de um gerente de sucesso.
Mas não se tem ao certo a medida de quanto esse conjunto de habilidades de gerenciamento
significa na composição desse perfil. Principalmente em relação a outras competências
consideradas clássicas e mais ligadas à disciplina como: uso da metodologia, disciplina e
conhecimento técnico.

O próprio PMI (Project Management Institute) na mais recente versão do PMBoK (Project
Management Body of Knowledge), passou a valorizar de maneira mais evidente algumas

43
 características ligadas ao direcionamento da equipe e gerência de stakeholders. Algumas das
modificações feitas em suas áreas de conhecimento sugerem uma maior “humanização” da
gerência de projetos e não somente competências técnicas do gerente enquanto planejador,
controlador, executor e responsável geral pelo projeto. Esse movimento, apesar de legítimo,
acaba por provocar interessantes discussões sobre até que ponto as habilidades de
gerenciamento, considerada por muitos autores como “a arte de gerenciar” pode ser ainda
mais fundamental do que o próprio conhecimento técnico em si, aliado à utilização de uma
forte metodologia de gerenciamento.

BARCAUI, André. O equilíbrio necessário para se tornar um excelente gerente de projetos.

Revista MundoPM, 2006. Disponível em: <http://www.eduwork.com.br/artigos/ver/gerencia-
de-projetos-arte-ou-disciplina>. Acesso em: jan. 2019.

É óbvio que a garantia do sucesso do projeto não dependerá somente dessa qualificação do
gerente, mas vimos a repetição de vários traços indubitavelmente desejáveis para esse profissional.
Além da natural necessidade de conhecimento técnico e de experiência com guias como o PMBOK
ou de outras metodologias, concluímos que o gerente de projetos diferenciado necessita também de
comportamentais. As visões apresentadas acima somente corroboram a conclusão de que o papel
desse stakeholder é realmente definitivo no ambiente de projetos.

Project management office (PMO)

O PMO é uma unidade empresarial ou um departamento responsável pelos projetos de uma
organização. A sua denominação tem outras variações, como Escritório de Projetos (EG), Escritório
de Gerenciamento de projetos (EGP), Comitê Diretor de Projetos, Coordenação de Projetos,
Escritório de Apoio a Projetos ou, simplesmente, Project Office (PO). O PMO pode assumir
diversas funções e abrangências, necessariamente dependentes do estágio da sua implantação e das
carências da sua empresa, além do grau de complexidade dos projetos.
Geralmente, o PMO inicia as suas atividades com responsabilidades mais básicas e claras,
como treinamento dos gerentes de projetos da companhia, criação e unificação de novos modelos
(templates) de documentação usada nos diversos projetos e melhor integração de gestores de projetos
e gestores funcionais. É comum o PMO aperfeiçoar padrões no gerenciamento, assumindo uma
metodologia ou fazendo uma combinação de várias. Outro papel costumeiro que esse órgão assume
é de treinamento em softwares úteis de gerencia de projeto (tal qual o Ms Project, o WBS Chart
Pro, Primavera, etc.).

44
 À medida que evoluem, esses escritórios de projetos podem também enviar de maneira
consolidada e periódica à alta administração, ou até mesmo ao presidente (CEO) da empresa,
relatórios com os dados dos múltiplos projetos em curso, os seus respectivos progressos, pontos de
atenção, benefícios obtidos, revisões críticas, riscos, etc.
Em um nível ainda mais sofisticado, os PMOs podem assumir também o papel de monitores
centrais de todos os prazos e orçamentos dos projetos atuais das organizações, além de

análise e aprovação de propostas de projetos segundo objetivos estratégicos da

organização e critérios complementares, distribuição de recursos de acordo
com prioridades estabelecidas, identificação de conflitos e recomendações para
solução, revisão crítica e avaliação de projetos, atuação externa com foco nos
clientes e patrocinadores (VALERIANO, 2001, p. 109).

Uma recomendação geral para o sucesso desses escritórios é que eles tenham as merecidas e
necessárias autoridade e autonomia. Na literatura de projetos, há diversos casos de PMOs que
falharam na sua missão porque não receberam o aval ou endosso das suas diretorias ou presidências.
Outros casos de fracasso trazem até detalhes de sabotagem contra as atividades do escritório.
Uma vez que se trata de um órgão que cobrará resultados de outros setores, e que exporá
números e performances, faz-se imprescindível que a criação de um PMO seja combinada com uma
campanha interna para conscientizar a todos a respeito da função desse departamento, evitando as
naturais resistências. O apoio de toda a organização ao escritório, certamente, será uma peça-chave
para a obtenção das vantagens que a sua boa operação traz normalmente.
Nesse sentido, Barcaui explica que

uma característica interessante é que a maioria dos PMO’s é montada

somente quando as empresas não suportam mais perder dinheiro com os
seus projetos. Em outras palavras, até o momento, a maioria dos Escritórios
de Projeto foi montada de maneira reativa. A expectativa do stakeholder é
que o PMO deva ser uma espécie de “Messias ou Salvador de projetos” e
organize o desconforto da empresa no que diz respeito à gestão de projetos
(BARCAUI, 2006, p. 11).

Além disso, com a crescente valorização à gestão de conhecimento, diversos escritórios de

projetos estão criando e mantendo um depositório das Lições Aprendidas (Lessons Learned) dos
múltiplos projetos. Geralmente, esse documento é produzido pelos gestores de projetos acerca das
experiências positivas e negativas vividas nos seus projetos e é um documento emitido no

45
encerramento da empreitada. No caso de empresas com a presença de PMOs, esse documento passa
a seguir um fluxo, sendo entregue pelo gerente do projeto ao responsável do PMO.
Com o tempo, essas ricas informações existentes nos documentos de Lições Aprendidas
poderão ser usadas pelo próprio órgão para cruzar dados, criar estatísticas e medir as performances
por meio dos históricos dos projetos documentados. Ultimamente, esses documentos de lições
aprendidas têm sido informatizados e estão sendo colocados em repositórios on-line, em pastas
compartilhadas ou na intranet das organizações.
Tal documentação apoia futuros gestores nas suas decisões, já que esses profissionais, cientes
do conteúdo dos documentos, poderão evitar a repetição dos erros incorridos pelos seus colegas e,
evidentemente, poderão seguir possíveis conselhos que eles tenham feito em documentações de
Lições Aprendidas.
A disseminação de PMOs nas organizações tem sido bastante razoável, inclusive nas
prestadoras de serviços. O Hospital Israelita Albert Einstein em São Paulo, por exemplo, concluiu
o projeto de criação do seu escritório de projetos em 2010 e, anualmente, a sua diretoria promove
uma pesquisa junto aos diversos setores para reavaliar a utilidade do órgão. O PMO desse hospital
é considerado tão chave que é visivelmente colocado no organograma da empresa, conforme vemos:

Figura 15 – PMO na estrutura do Hospital Albert Einstein

Fonte: http://www5.each.usp.br/wp-content/uploads/2016/07/EAIP-O-Caso-do-Hospital-Albert-Einstein.pdf

46
Para finalizarmos o tema, segundo o autor Luis Torres:

Um escritório de projetos (EP) pode ter autoridade para gerenciar,

controlar, delegar e assinalar o início de um projeto, tomando medidas de
controle conforme a necessidade para manter os objetivos de negócios
consistentes. Além disso, o EP pode estar envolvido na seleção, no
gerenciamento e na mobilização de recursos de projetos compartilhados
ou dedicados. (TORRES, 2014, p. 99).

A seguir, a figura ilustra bem quais são as funções mais usuais do PMO:

Figura 16 – Funções do PMO

Fonte: Torres (2014, p. 102).

47
 Em suma, cabe apurar os inúmeros benefícios percebidos com a adoção de escritórios de
projetos. Notadamente:
distribuição mais inteligente de recursos (humanos e materiais);
seriedade e profissionalismo na gestão;
uniformidade na documentação de projetos;
criação e manutenção de uma cultura de projetos;
integração de sistemas de informação empresariais;
manutenção de acervo de lições aprendidas e
maior produtividade das equipes executoras do projeto.

Estruturas organizacionais
A maneira como uma equipe de projeto é composta, como e se os gerentes de projeto têm
autonomia na gestão, se há ou não um escritório de projetos ou se as comunicações fluem
rapidamente são apenas alguns pontos de realidade diretamente dependentes do modelo da
estrutura adotado por suas organizações. É evidente que o tipo de estrutura hierárquica vigente em
uma referida empresa poderá implicar maior ou menor importância dada ao gerenciamento de
projetos, permitindo ou tolhendo a sua evolução.
Alguns modelos são mais propícios à evolução do gerenciamento de projetos e à própria
carreira do gerente de projetos; outras estruturas nem tanto. Há, principalmente, três grandes
formatos de organização para manejar o trabalho e as pessoas nas entidades.

Organização funcional
Desde a formação dos primeiros exércitos, essa estrutura foi criada, de modo que, até hoje, é
diretamente associada às entidades militares. Em seguida, a estrutura foi adotada pela igreja católica,
para conseguir mais controle da sua operação. Até a atualidade, esse modelo funcional, também
conhecido como hierarquizado ou piramidal, é presente e usado em diversas organizações, de
qualquer esfera e porte. Vejamos como essa estrutura se relaciona com o contexto de projetos.
Em uma estrutura funcional de hoje, uma equipe de projeto é composta por pessoas do
mesmo departamento. Todos os recursos necessários para a equipe do projeto vêm da organização
funcional. Na prática, são os gerentes dos setores (funcionais) que irão executar os projetos. Por
exemplo, se o projeto for relacionado à função de finanças, os recursos do projeto virão do
departamento financeiro. Se forem necessários recursos de contabilidade, financeiros e jurídicos,
todos estarão disponíveis dentro do departamento financeiro, e assim por diante.

48
 Uma segunda maneira para obter os recursos para um projeto dentro de uma organização
funcional é executar o projeto em parcelas, e cada parcela será executada no seu respectivo
departamento. Desse modo, se um projeto de grande porte previsse recursos do departamento
financeiro, do departamento de compras, do departamento de TI e do departamento de
manufatura, tal projeto seria dividido por departamento em uma organização funcional, ou seja,
cada qual faria a sua parte no todo, cada uma das áreas entregaria a sua própria expertise em relação
às atividades do projeto e com relativa independência. No final, todas as partes distintas seriam
integradas em uma solução final.
Uma das grandes vantagens dos projetos executados nas organizações baseadas na
funcionalidade é que, geralmente, há autoridade clara, já que os gerentes de projetos também
tendem a ser os gerentes funcionais. Eles não necessitam negociar com outras organizações em
relação aos recursos, já que todos os recursos necessários se reportaram na mesma organização
funcional. Essa unidade de chefia acaba sendo também benéfica aos membros da equipe do projeto,
pois responderão somente a um gestor, que é definido e nomeado sob essa estrutura.
Outra vantagem dessa organização é que os membros da equipe tendem a ser familiarizados
entre si, uma vez que todos, em teoria, trabalham na mesma área e também tendem a trazer
conhecimentos de negócios aplicáveis ao projeto. A especialização também é um fator favorável ao
modelo, já que unifica os profissionais por conhecimento dentro das respectivas especialidades
verticais (finanças, informática, recursos humanos, produção, etc.).
Por outro lado, uma das principais desvantagens da organização funcional é que as áreas
funcionais podem não ter todos os especialistas necessários para trabalhar em um projeto. Por
exemplo, um projeto do departamento financeiro, com um componente de tecnologia, pode ter
dificuldades na aquisição de recursos especializados, tal como Administradores de Base de Dados,
pois as únicas pessoas qualificadas para esse tipo de trabalho podem estar trabalhando no seu próprio
departamento funcional. Isso dificulta e, por vezes, inviabiliza projetos que sejam multissetoriais ou
multidisciplinares. A esse respeito, Valeriano (2001) afirma que

qualquer tipo de trabalho que venha a ser atribuído, que envolva mais de um
departamento e que esteja fora desse quadro é considerado uma anomalia ou
uma excrescência – a organização funcional não foi feita para responder a
solicitações extemporâneas e, em consequência, não está preparada para
executar outro trabalho interdepartamental que não o correspondente ao
processo produtivo (...), não sendo capazes de dar pronta resposta a problemas
que exijam cooperação de vários departamentos (p. 17).

49
 Outra desvantagem dessa estrutura é que os membros da equipe poderão ter outras
responsabilidades fora do projeto. Eles podem trabalhar em outros projetos, mas têm, tipicamente,
a responsabilidade de dar suporte aos seus próprios departamentos, o que poderia impactar a
capacidade de atender os prazos do projeto, dada a disponibilidade de tempo menor.
Uma estrutura funcional pode ser exibida como vemos a seguir, na hipótese de o projeto se
dar no seio do departamento de produtos:

Figura 17 – Estrutura organizacional functional

Fonte: Torres (2014, p. 123).

Outro exemplo dessa configuração funcional seria:

Figura 18 – Exemplo de estrutura functional

Fonte: Valeriano (2001, p. 16).

50
Organização matricial
As organizações matriciais permitem que os departamentos funcionais tenham o seu foco nas
competências específicas dos negócios e que, ao mesmo tempo, os projetos sejam integrados por
especialistas de toda a organização. Desse modo, é o modelo intermediário entre o “Funcional” e o
“Por projetos” (a ser visto em seguida).
Nesse modelo, por exemplo, os profissionais administradores de base de dados podem-se
reportar a um departamento funcional, mas seriam alocados para trabalhar em vários projetos em
outros setores requerentes. Um recurso do jurídico poderá se reportar ao departamento jurídico e
também ser designado a um projeto em outro departamento que necessite desse tipo de especialista.
A vantagem principal da organização matricial é a alocação com eficiência de todos os
recursos, especialmente as qualificações raras, que não são necessárias em tempo integral no projeto.
Por exemplo, os especialistas em modelagem de dados poderão não ser utilizados em tempo integral
em um único projeto, mas poderão ser inteiramente aproveitados, já que serão alocados em outros
projetos nos quais forem úteis.
A organização matricial também é mais flexível quando trata das mudanças das necessidades
e das prioridades do negócio, já que permite a transversalidade entre os setores.
A desvantagem principal da firma tipo matricial é que as relações de subordinação são
complexas. Algumas pessoas podem-se reportar ao gerente funcional para quem pouco trabalho é
executado, ao mesmo tempo em que trabalham para um ou mais gerentes de projetos. Com isso,
torna-se mais importante para os funcionários desenvolver rapidamente habilidades de gerenciamento
do tempo, de forma a garantir que as expectativas de trabalho de múltiplos gerentes sejam atendidas.
Essa organização também requer uma boa comunicação e a cooperação entre os diversos
gerentes funcionais e gerentes de projetos, pois necessitarão utilizar os mesmos profissionais. Esse é
um dos maiores problemas da estrutura matricial, que resulta em acúmulo de funções. Segundo
Valeriano (2001),

em alguns momentos, um profissional reporta-se a seu chefe de

departamento e, em outros, ao gerente de projeto (...). Desse modo, os
chefes se sentiam diminuídos e desprestigiados com ‘interferências’ nos
seus redutos e na prestação de serviços, por parte dos seus subordinados,
para ‘estranhos’. Por sua vez, sem uma clara distribuição de autoridade e
responsabilidade, os profissionais ficavam confusos, sobre a quem prestar
contas e quais, entre seus chefes, serão os que realmente avaliarão seu
desempenho para fins de recompensas, promoções, etc. (p. 19-20).

51
 Sem dúvida, essa problemática da dupla chefia, comum na estrutura matricial, resulta em
acúmulo de funções: do ponto de vista do funcionário, que é alocado em mais de um projeto, há
necessidade de responder a mais de um gestor e, ainda, concluir as suas tarefas funcionais do dia a dia.
Uma empresa sob modelo matricial, em geral, poderia ter a configuração apresentada a seguir,
na qual fica evidente a maior facilidade de projetos transversais ou multissetoriais:

Figura 19 – Exemplo de estrutura matricial

Fonte: Valeriano (2001, p. 19).

Adicionalmente, cabe ressaltar que o modelo matricial pode apresentar três subdivisões
possíveis: a estrutura Matricial Fraca, a Matricial Balanceada e a Matricial Forte, a serem explanadas
no texto de Torres (2014, p. 127-131).

Figura 20 – Estrutura matricial fraca

52
 A estrutura Matricial Fraca é predominantemente funcional. Como pode ser observado, as
equipes estão separadas por especificidades e a gestão é hierárquica. No entanto, surge a figura do
coordenador de projetos (ou líder de projetos). Isso significa que um dos recursos da estrutura,
normalmente o mais sênior ou com mais experiência organizacional, ficará responsável pela
administração e coordenação do projeto. Nessa estrutura, o coordenador de projeto, não tem as
mesma atribuições e responsabilidade que o gerente de projeto. Como pode ser visto, o coordenador
de projeto está dentro de uma estrutura organizacional funcional, e as atividades e rotinas diárias
ainda devem ser executadas por ele. Vale dizer que, nessa estrutura, o coordenador de projeto dedica
parte do seu tempo ao gerenciamento de projeto e a maior parte às atividades diárias.
A seguir, vejamos as vantagens e desvantagens da estrutura Matricial Fraca:
Vantagens – para o coordenador de projetos é uma experiência ter contato com as
ferramentas e técnicas do gerenciamento de projetos, bem como avaliar as suas
competências e habilidades. Além disso, os recursos podem trabalhar em atividades diárias
e projetos simultaneamente, e as equipes começam a ter contato com as metodologias de
gerenciamento e projetos, mesmo que de forma incipiente, mas inicia-se o aprendizado.
Desvantagens – dupla subordinação, de modo que os recursos começam a perceber que
existe uma subordinação direta à hierarquia e, ao mesmo tempo, cobranças pelos
resultados dos projetos. Dadas as prioridades dos gerentes funcionais e dos projetos,
ocorrem tensões e conflitos sobre as atividades a serem executadas. Mesmo que a
prioridade dos projetos seja baixa, existem cobranças sobre os resultados dos projetos, e
isso acaba gerando expectativas não atendidas e frustrações.

53
 Dando maior força a papel coordenador de projetos, tem-se a estrutura Organizacional
Balanceada, como explicitada na figura a seguir.

Figura 21 – Estrutura matricial balanceada

Nessa estrutura, o coordenador de projetos passa a ter o papel de gerente de projeto, e não
mais executa atividades diárias ou rotinas de operação. Mesmo estando presente em uma estrutura
com fortes características funcional, nesse modelo, o elemento da equipe (normalmente, mais
sênior) passa a exercer a função de gerente de projetos em tempo integral. Durante o período do
projeto, ele atuará como gerente do projeto.
Quando o projeto terminar ou for cancelado, esse profissional volta para as suas
responsabilidades, atividades e operação diárias. No caso de os projetos serem recorrentes, ele
poderá ocupar a posição por um tempo maior. No entanto, é relevante lembrar que, na Estrutura
Matricial Balanceada, o profissional não é gerente de projeto ele está gerente de projetos pelo
período ou tempo dos projetos.
A seguir, vejamos as vantagens e desvantagens dessa estrutura:
Vantagens – como estamos falando de estruturas matriciais, as vantagens são bastante
similares entre as estruturas Fraca, Balanceada e Forte. No entanto, podemos destacar que,
nessa estrutura, o gerente de projeto pode aplicar os métodos, as ferramentas e técnicas de
gerenciamento de projetos. A sua dedicação à gestão e ao controle do projeto é exclusiva,
permitindo uma maior e melhor interação com os processos e dinâmicas da gestão. Além
disso, o exercício da função gerente é uma forma de amadurecer profissionalmente quanto
às práticas de gestão de pessoas e recursos, bem como preparar para funções futuras de
gerente de projetos ou em outras áreas de gestão.

54
 Desvantagens – a principal diz espeito a estar gerente. Como podemos perceber, se o
projeto acabar, o recurso que tinha papéis e responsabilidades de gestor volta ao papel de
equipe, voltando a executar as suas atividades e rotina da função. Muitas vezes, isso causa
uma tensão e conflito entre os membros da equipe, que não conseguem mais percebê-lo
como um igual, já que, por um período longo, exerceu função de direção e controle. Para
o profissional que, até então, era gerente, pode gerar uma frustração em relação ao retorno.

É altamente recomendável para o profissional, ao ocupar a responsabilidade de gerente dentro

de uma estrutura matricial balanceada, que reveja a sua posição dentro da organização do projeto e
reavalie as suas relações, entendendo que isso é um papel transitório e que deve usar esse período
como aprendizado e familiarização com as tendência, situações e características da gestão. Caso não
ocorra uma promoção ou estabilização do papel de gerente, é recomendável que, ao voltar às suas
rotinas anteriores, volte com mais maturidade e habilidade para lidar com as pessoas
hierarquicamente, bem como com as suas limitações e características, de modo a evitar frustração e
melhor administrando as relações futuras
Nessa direção, vamos à estrutura Organizacional Matricial Forte – a mais comum nas
organizações e que tem um volume acentuado de projetos.

Figura 22 – Estrutura matricial forte

Como podemos perceber, nessa estrutura, surge uma gerência ou diretoria para
gerenciamento de projetos. Os gerentes de projetos ficam agrupados sob essa gerência e utilizam os
recursos organizacionais na consecução dos projetos.

55
 Para o gerenciamento de projetos, essa estrutura permite a disseminação dos conhecimentos,
das ferramentas e técnicas de gestão de projetos, e permite um controle mais eficiente dos recursos
humanos, financeiros e estratégicos da empresa, não com uma eficiência máxima, mas os recursos
passam a ser melhores administrados.
Os gerentes de projetos alocam os recursos organizacionais à medida que os projetos
necessitam, e os recursos também atuam nas atividades diárias. Dado que o gerente de projeto sênior
tem o mesmo nível hierárquico que os demais gerentes funcionais, a estrutura fica mais estável
quanto à administração, gestão e ao controle dos projetos.
A seguir, vejamos as vantagens e desvantagens dessa estrutura:
Vantagens – essa estrutura permite uma melhor alocação de recursos e otimiza os recursos
para o controle dos projetos. Os membros da equipe podem trabalhar em processos e
rotinas internas, e nas atividades do projeto. Nessa estrutura, existe um melhor controle
sobre o gerenciamento das equipes, tem-se uma maior eficiência e eficácia sobre a
coordenação das atividades dos projetos, a informação se torna mais fluídica e constante
sobre os aspectos de gerenciamento dos projetos, e se obtém um suporte mais efetivo das
áreas funcionais, dado que ocorre uma melhor fluidez da comunicação sobre projetos
tanto horizontal quanto vertical.
Desvantagens – dupla subordinação, de modo que a equipe do projeto atua em atividades
diárias para os projetos e passam a ter dois gerentes – os funcionais e dos projetos –,
gerando uma rede de tensões, disputa pelos recursos mais eficientes e estratégicos. Projetos
concorrentes disputam recursos, aumentando a complexidade para monitorar e controlar
o projeto, as rotinas e os processos.

Organização projetizada
Como o próprio nome diz, nesse modelo, o gerente de projeto tem mais margem de exercer
a sua posição, tendo maior autoridade sobre os recursos disponíveis do projeto. No modelo
projetizado ou por projetos, a equipe executora do projeto é alocada e consolidada
temporariamente, ou seja, enquanto durar a empreitada, esse time estará dedicado até a conclusão
do projeto ou enquanto forem necessários. O mesmo vale para a alocação do gerente do projeto,
incumbido para a empreitada e exclusivamente dedicado. Sendo assim, a alocação do time no
projeto é praticamente integral ou exclusiva, não havendo concorrência do tempo do time entre
projeto e departamento (como vimos na estrutura matricial).
Em um caso de projeto de maior tamanho, é possível formar departamentos funcionais em
torno da equipe do projeto. Isso é especialmente prático quando um programa grande possui dúzias
ou centenas de pessoas designadas por um longo período de tempo. As vantagens desse modelo por
projetos incluem uma clara autoridade, já que o gerente do projeto também é o gerente funcional,

56
e um foco claro, já que todos os integrantes da equipe possuem somente o projeto como
responsabilidade principal.
As desvantagens dessa organização incluem a duplicação de recursos, já que os recursos
escassos devem ser duplicados para os projetos diferentes. Por exemplo, um projeto de maior porte
pode ter a própria área de recursos humanos. Outro ponto possivelmente desfavorável é o risco de
ociosidade de algum recurso da equipe, dada a sua integral alocação no projeto. Se um profissional
não estiver sendo 100% empregado no projeto X e não houver outro projeto para ele ser alocado,
haverá de fato essa ociosidade.
Adicionalmente, nesse modelo por projetos, poderá surgir alguma preocupação sobre como
realocar ou desmobilizar as pessoas e os recursos, quando os projetos forem encerrados. Em uma
organização funcional, as pessoas ainda possuem trabalho dentro do departamento funcional e
retornam para lá ao final do projeto. No entanto, em uma organização por projeto, não fica tão
claro para onde cada recurso do time deverá ser designado tão logo seja concluído o projeto. Isso
poderá gerar algum tipo de desconforto e temor por parte dos recursos.
A estrutura projetizada poderia ter essa configuração:

Figura 23 – Estrutura organizacional projetizada

gerenciamento de
programa ou portfólio

gerente de gerente de gerente de gerente de

projetos projetos projetos projetos

equipe equipe equipe equipe

equipe equipe equipe equipe

equipe equipe equipe equipe

Fonte: Torres (2014, p. 124).

A seguir, a figura esboça importantes características relacionadas a projetos e o seu cruzamento

segundo os tipos de estruturas organizacionais que vimos.

57
 Quadro 3 – Comparação de Modelos de Estrutura Organizacional

estrutura da matriarcal
organização
funcional por projeto
características fraca balanceada forte
do projeto

autoridade do gerente de pouca ou baixa a moderada a alta a quase

limitada
projetos nenhuma moderada alta total

pouca ou baixa a moderada a alta a quase

disponibilidade de recursos limitada
nenhuma moderada alta total

quem controla o orçamento gerente gerente gerente de gerente de

misto
do projeto funcional funcional projetos projetos

função do gerente de tempo tempo tempo tempo tempo

projetos parcial parcial integral integral integral

Equipe administrativa do tempo tempo tempo tempo tempo

gerenciamento de projetos parcial parcial parcial integral integral

Nesse quadro comparativo, fica bastante evidente que há mais chances de carreira em gerência
de projetos nos formatos matricial e projetizado. Conclui-se que, em uma firma tipo funcional, é
mais rara a existência do cargo de gerente de projetos e de uma carreira na área.
No que tange, especificamente, à posição do gerente de projetos nessas três grandes estruturas,
em comparação à do gestor funcional, há mais autoridade do primeiro em relação ao segundo à
medida que seguimos da esquerda à direta. Ou seja, em direção às estruturas matriciais e projetizada,
o cargo do gerente do projeto assume mais autoridade e relevância. Contrariamente, no movimento
inverso, seguindo os modelos mais à esquerda do quadro, já teremos um gerente de projetos com
pouca ou nenhuma autoridade em comparação com os gerentes funcionais.

Figura 24 – Estruturas organizacionais e autoridade

58
Processos de gerenciamento de projetos
Grupos de processos
É comum que o ensino e a aplicação dos conceitos da disciplina de projetos sejam
fundamentados em processos, o que faz sentido se entendermos que projetos são realizados pela
integração de múltiplos processos de gestão e aperfeiçoamento. De fato, no guia do PMBOK, há
cinco grupos ou categorias de processos de gerenciamento de projetos, sendo eles:
grupo de processos de iniciação – responsável por definir e autorizar o projeto ou o início
de uma das suas fases;
grupo de processos de planejamento – responsável por definir e refinar os objetivos, bem
como planejar a ação necessária para alcançar os objetivos e o escopo para os quais o
projeto foi realizado;
grupo de processos de execução – trata da integração das pessoas e outros recursos para a
concreta implementação do plano de gerenciamento do projeto;
grupo de processos de monitoramento e controle – função de medir e avaliar,
regularmente, o progresso do projeto, identificando variações em relação ao planejado, de
forma que possam ser tomadas ações corretivas, quando necessário, para atender aos
objetivos do projeto;
grupo de processos de encerramento – tem por missão a formalização da a aceitação do
produto, serviço ou resultado (também conhecida como homologação), objetivando a
condução do projeto (ou de uma fase) a um final ordenado.

A orientação é de que um projeto faça a implementação desses 5 grupos de processos,

considerando que processos são grupos de ações e atividades inter-relacionadas e sobrepostas. Os
processos pertencerão sempre a um dos cinco grupos ou naturezas, no entanto, na prática, eles serão
realizados de forma iterativa, de acordo com o esboçado pelas duas figuras a seguir:

59
 Figura 25 – Processos em Gerenciamento de Projetos

Figura 26 – Interação de processos em Gerenciamento de Projetos

60
 Adicionalmente, na 6a edição do guia do PMBOK, os cinco grupos de processos de
gerenciamento são divididos ou quebrados em um total de 49 processos, separados por área de
conhecimento, a serem implementados à medida que o projeto for sendo consumado. A ilustração, a
seguir, demonstra como tais processos interagem no decorrer do tempo de vida de um projeto, isto é,
a saída de um dos processos, provavelmente, será a entrada de outro. Fica evidente o alto grau de
sobreposição, mencionado anteriormente, entre esses processos de gerenciamento. Realmente, um
processo não precisa ser concluído para o outro ser iniciado, podendo ser realizados paralelamente.

Figura 27 – Interação entre processos de Gerenciamento de Projetos

Ciclo de vida de um projeto

Assim como nós, seres humanos, conhecemos o conceito de ciclo de vida, o mesmo raciocínio
existe no contexto de projetos, e não poderia ser diferente. Projetos são entidades vivas, orgânicas e
finitas, sendo natural que também possuam o seu próprio ciclo de vida. Isso reforça, mais uma vez,
a característica de temporariedade própria dos projetos, em concordância com o que foi estudado
no primeiro módulo.
Devemos salientar que é comum a confusão entre os conceitos de ciclo de vida e processos de
gerenciamento de projetos. Em conformidade com o que vimos há pouco, os processos de
gerenciamento de projetos encontram-se distribuídos na vida útil do projeto. Em outros termos,
esses processos de gerenciamento “rodam” dentro do ciclo de vida de um projeto.

61
 A seguir, a figura demonstra esse esquema, apontando o ciclo de vida da empreitada com a
linha mais grossa e os processos rodando dentro desse limite.

Figura 28 – Ciclo de vida

De forma complementar, é importante ressaltar que os grupos de processos, normalmente,

são fixos para todos os tipos de projeto, ou seja, todos os projetos terão os cinco grupos de
gerenciamento. No entanto, quando esses processos são mais detalhados ou quebrados, chegaremos
às fases do projeto. Essas divisões ou etapas servirão para conectar o esforço do começo até o seu
final. O ciclo de vida de um projeto é, consequentemente, obtido pela soma das suas fases. A figura
exibe uma sequência típica de fases no ciclo de vida de um projeto genérico:

Figura 29 – Fases do ciclo de vida do projeto

62
 É necessário observar que as fases de um projeto são bastante específicas de cada ramo de
atuação. Dependendo da atividade a que pertence a companhia executora do projeto, as
denominações das diversas fases de um projeto irão variar. Do mesmo modo, a depender do setor
responsável pela empreitada, também encontraremos nomes diversos dados às fases desses projetos.
Em síntese, os nomes das fases serão, necessariamente, distintos e variáveis entre um projeto e outro,
só confirmando o traço da exclusividade apresentado no primeiro módulo.
Por exemplo, um projeto feito pela divisão de Pesquisa e Desenvolvimento não terá as
mesmas fases de um projeto que esteja ocorrendo na divisão de controle cambial de um banco.
Ainda que haja outros projetos acontecendo nesses mesmos setores, as fases terão denominações
específicas e, possivelmente, distintas. Vale ressaltar um ponto em comum entre eles: todos rodarão
os cinco grupos de processos de gerenciamento de projetos, ainda que as fases sejam,
respectivamente, diferenciadas. A seguir, a ilustração demonstra exatamente esse ponto:

Figura 30 – Processos e atividades

Fonte: Vargas (2016).

A divisão do ciclo de vida em fases nitidamente facilita o controle do projeto por parte do
gerente, tornando o seu foco mais segmentado, sem perder a noção do todo do esforço. Como
exemplo, o projeto de desenvolvimento de um sistema teria as seguintes fases compondo o seu ciclo
de vida (VALERIANO, 2001, p. 134-136):
fase A- design conceptual;
fase B – design detalhado;
fase C – Pesquisa e desenvolvimento do produto e serviços associados;
fase D – produção, construção, instalação;
fase E – operação, utilização e serviços associados, e
fase F – retirado do serviço e descarte.

63
 Figura 31 – Fases de um projeto específico

Fonte: VALERIANO (2001).

Convém ressaltar que a transição entre uma fase à sua seguinte pressupõe um produto, uma
transferência de saber ou uma entrega ou entregável. Podemos estar falando de um documento,
uma reunião solene ou um resultado tangível e verificável, como seriam o Plano de Gerenciamento
de projeto ao ser entregue, ou um Protótipo do produto do projeto, um relatório de performance
bimestral, a fundação da obra ou um módulo de um curso. Seguem exemplos de possíveis pontos
de transição:

64
 Figura 32 – Pontos de transição

Fonte: PMBOK (2017).

A entrega a ser feita entre uma fase e outra do projeto, normalmente, passará pela aprovação
do cliente do projeto. Se estiver conforme os requisitos previamente acordados, o “ok” do cliente à
entrega definirá a autorização de passagem para a próxima etapa. De modo suplementar, essas
transições de uma fase para a outra devem ser encaradas como um ponto de controle de qualidade
do projeto. O gerente deve apoiar-se no time para avaliar o andamento do esforço durante essas
transições interfases. Se cabível, deverá implementar ajustes.
Segundo Valeriano (2001, p. 126-127), as diferentes fases do ciclo de vida poderiam ser
individualmente caracterizadas da seguinte forma:

a) Fase de iniciação
Essa fase dá início ao projeto, sendo um conjunto de percepções, vontades e interesses, em
geral, estimulado por uma demanda ou necessidade de entidade externa, ou por uma oferta ou
oportunidade da organização ou do grupo que empreenderá o projeto. Segue-se a identificação da
necessidade ou da oportunidade, e da maneira de supri-la, isto é, identificar o problema e conceber
via de solução. A fase se caracteriza pelo comprometimento da organização em dar prosseguimento
à fase seguinte. Aqui, é comum fazer uma estimativa dos esforços a serem despendidos,
especialmente em termos de custos e prazos, para dar base à iniciação.

65
 b) Fase de planejamento
Com as informações levantadas na fase de iniciação, procede-se ao planejamento,
estabelecendo-se o escopo do projeto progressivamente. Em geral, costuma-se desdobrar o
planejamento em duas subfases: planejamento preliminar e planejamento detalhado.
O planejamento preliminar contém informações globais do empreendimento que será
encetado, com a definição do produto do projeto, a maneira de obtê-lo, os custos, os prazos, os
demais recursos e os comprometimentos necessários, os riscos envolvidos, etc. Essa subfase é útil
para as negociações com as partes interessadas, a fim de conciliar os objetivos, os esforços a serem
empregados, começar a definição de responsabilidades, etc.
Em seguida, é realizado um planejamento detalhado do projeto, para permitir a sua execução
e o seu controle. Enquanto o planejamento preliminar visa à compreensão do problema ou da
necessidade e a sua forma de realização, o planejamento detalhado precisa definir todas as atividades
que envolvem a utilização dos recursos, com a explicitação dos produtos de cada “pacote de
trabalho”, os seus requisitos e destinos. As interfaces, os diversos processos técnicos e administrativos
e compromissos internos são preestabelecidos. Todo um esquema de controle é instituído à medida
que a definição das condições de execução for sendo fixada. Tal controle será exercido sobre o
produto (processos, materiais, qualidade), sobre os processos gerenciais e administrativos, sobre os
recursos (custos) e sobre os prazos planejados. A equipe do projeto é definida, selecionada e montada
em negociações, em geral, com a administração da organização executante do projeto.

c) Fase de execução
Consiste em pôr em ação todas as tarefas planejadas, nas condições de qualidade, custos,
prazos e de forma a alcançar os objetivos das partes interessadas. Essa fase se caracteriza por um
intenso trabalho de equipe, sob a coordenação geral do gerente de projeto, com muitas ações
gerenciais descentralizadas, por exemplo, as gestões do projeto. Desse modo, o gerente poderá
delegar a um dos executantes a gestão da qualidade, a gestão do suprimento, etc. Os resultados da
execução devem ser documentados e fazem parte fundamental da gestão das comunicações.

d) Fase de controle
A fase de controle do projeto segue pari passu a de execução, podendo dar origem a diversos
retorques e ajustagens no planejamento inicial, mantendo, no entanto, o escopo do projeto. Cada
gestão tem o seu controle peculiar, mas os controles de todas as gestões são coordenados e
harmonizados pelo controle geral de mudanças, importante processo da gestão da integração.

66
 e) Fase de encerramento
Uma vez atingido o objetivo, o projeto deve ser encerrado, com algumas disposições finais, a
partir da aceitação do produto. Deverão ser tomadas providências para a conclusão de contratos,
encerramento administrativo, devolução de materiais, espaços, etc. Antes da dispensa e dissolução
da equipe, deve ser procedida uma avaliação geral e levantamento das “lições aprendidas”.

Concluímos o estudo do conceito de ciclo de vida e da exploração dos eventos mais comuns
de cada uma das suas fases. Nesse momento, torna-se conveniente investigarmos o comportamento
de alguns parâmetros em referência à história de um empreendimento. Em outras palavras, faremos
um interessante exercício de reflexão de como alguns fatores se comportam no decorrer do ciclo de
vida de um projeto genérico. Vejamos:
Custos de pessoal – é comum que esses custos sejam ascendentes na história de um projeto,
ou seja, são menores nas primeiras etapas, tendem a crescer e, normalmente, atingem o pico
na fase de execução do projeto, exatamente por haver mais entregas. Posteriormente, sofrem
uma queda, já que há a desmobilização de muitos recursos, especialmente com o final da
fase de execução. Esse comportamento é demonstrado no gráfico a seguir:

Figura 33 – Custos de pessoal no projeto

67
 Custos de mudança – os custos para refazer ou imprimir retrabalhos em qualquer projeto
tendem a ser crescentes no ciclo de vida. As mudanças são mais facilmente toleradas nas
fases iniciais da empreitada. À medida que caminhamos para a execução, por outro lado,
torna-se muito mais oneroso fazer correções no projeto, conforme gráfico a seguir:

Figura 34 – Custo de mudança no projeto

Influência dos stakeholders – o poder das partes interessadas ou a sua capacidade de

influenciar mais fortemente os rumos do projeto, inclusive no que tange às características
finais do produto do projeto, tende a ser mais alta no início ou nas primeiras fases. A
posteriori, essa influência tende a decair, à medida que é realizado progressivamente o
projeto. O gráfico, a seguir, demonstra esse comportamento do parâmetro:

Figura 35 – Influência dos stakeholders

68
Grau de risco – usualmente, o comportamento dessa grandeza em um projeto segue um
movimento decrescente. À proporção que o projeto é entregue, o grau de risco deverá cair.
Outra forma de avaliar esse aspecto é segundo o grau de incertezas, que repete a tendência
decrescente. O projeto avança e a incerteza relativa à empreitada cai, segundo exposto a seguir:

Figura 36 – Grau de risco de projeto

Quantidade de pessoas (nível de staff) – em geral, a quantidade de pessoas em um

projeto começa exígua e vai aumentando com as maiores necessidades que a fase de
execução costuma exige. É comum o pico do nível de staff ocorrer no ponto central da
etapa de execução do projeto, dada a maior quantidade de tarefas e entregas a ser
completadas. No entanto, ainda nessa fase de execução, já são iniciadas desmobilizações
dos recursos humanos que não sejam mais necessários. O gráfico dessa grandeza para um
projeto genérico, seguiria uma curva normal:

Figura 37 – Quantidade de pessoas em projeto

69
 É apropriado fazermos a ressalva de que os comportamentos dos parâmetros acima foram
obtidos na média dos projetos, podendo haver para um dado projeto uma tendência diferente ou
até contrastante das citadas.
Outro ponto importante é que alguns projetos não seguem, necessariamente, todo o seu ciclo
de vida original, podendo sofrer interrupções ou, até mesmo, ser extintos. Um exemplo seria de um
projeto ter sido concebido sob condições apropriadas da economia e da política cambial, mas que
uma crise repentina na Ásia tenha comprometido a estabilidade local com a disparada do dólar.
Essas novas condições externas e desfavoráveis podem fazer com que o projeto não valha mais a
pena, inclusive financeiramente.
Esse quadro de mudança de cenário ocorre com alguma frequência em episódios de alteração
do comportamento do nosso cliente final. Nosso projeto pode ter nascido com um objetivo, mas
essa alteração do gosto do consumidor pode, definitivamente, inviabilizar a continuação de nosso
empreendimento. Como resultante, ambos os projetos poderão ser suspensos ou até mesmo
abortados (encerramento prévio), evidentemente após a análise e anuência do gerente de projeto,
do cliente, do patrocinador e de outros stakeholders-chave.
Outro problema é que, por vezes, um projeto demora muito a ser efetivamente implementado
nas empresas, até devido à excessiva burocracia na sua aprovação. Quando, finalmente, eles são
autorizados e iniciados, o cenário que os justificou pode ser outro, inclusive pior. A empresa referida
pode ter perdido o timing para acessar aquele consumidor originalmente visado. À luz desses riscos,
e com o nosso mercado cada vez mais mutante, os projetos precisam ser rapidamente avaliados e,
se viáveis, prontamente implementados, sob pena de perderem o cenário favorável e, possivelmente,
não serem mais praticáveis. Da mesma forma que os dois casos anteriores, esse ciclo de vida também
não será seguido na sua totalidade, se for decidida a sua suspensão ou, até mesmo, o aborto do
projeto pelo setor executor.
Quando situações desfavoráveis como essas prejudicam um projeto, cabe serem devidamente
avaliadas no postmortem, ou seja, levantadas as causas do término prematuro de cada empreitada e
registradas no documento de lições aprendidas, em conformidade com o já exposto. Nesse
documento, seriam colocados os porquês desse encerramento precipitado do projeto, de modo a
evitarmos os erros ali relatados nas futuras iniciativas. Tal documento servirá até de alerta e
ensinamento aos demais gestores da empresa. Um projeto que não tenha vivido todo o seu ciclo de
vida teria a seguinte aparência:

70
 Figura 38 – Projeto com ciclo de vida incompleto

Dez áreas de conhecimento de gerenciamento de projetos, segundo a 6a

edição do PMBOK
A 6a edição do PMBOK, de 2017, apresenta dez áreas de conhecimento, sendo elas:
gerenciamento da integração do projeto;
gerenciamento do escopo do projeto;
gerenciamento do cronograma do projeto;
gerenciamento dos custos do projeto;
gerenciamento da qualidade do projeto;
gerenciamento dos recursos do projeto;
gerenciamento da comunicação do projeto;
gerenciamento dos riscos do projeto;
gerenciamento das aquisições do projeto e
gerenciamento das partes interessadas do projeto.

Em linhas gerais, as áreas têm os seguintes focos:

Escopo – área que define o “o que” do projeto, ou seja, o trabalho necessário a ser feito
para a geração bem-sucedida do produto ou serviço contratado pelo cliente e da boa gestão
do esforço geral.
Cronograma – área que calcula o tempo em que será concluída a empreitada, respeitando a
temporariedade, traço fundamental de qualquer projeto, como vimos no primeiro módulo.
Custo – área responsável pelo cumprimento do custo dentro do orçamento aprovado. Quanto
mais respeitarmos o limite de custo, maior será a margem de lucro da empresa executora.

71
 Qualidade – área da satisfação dos os requisitos mínimos de qualidade ou necessidades,
inclusive de acordo com a expectativa dos stakeholders. Anteriormente, as empresas
focavam na correção de problemas, o que levava a aumento de custos (retrabalho). Hoje
em dia, há maior foco no planejamento de prevenção de erros.
Recursos – área que define insumos materiais e os recursos humanos do projeto,
preocupa-se com a distinção de papéis e responsabilidades de cada membro da equipe,
assim como as suas habilidades.
Stakeholders – área que determina a importância dos envolvidos no projeto, por meio da
sua identificação e do mapeamento, via grau de importância, interesses e poder face ao
projeto. O gerente do projeto deve gerir expectativas e manter o nível de engajamento
desses interessados.
Comunicação – área que delimita os destinatários de comunicações durante todo o
projeto, assim como mídias a ser usadas, frequências e regras de armazenagem dessa
documentação.
Riscos – área que identifica o que pode dar certo ou errado no projeto, os seus impactos e
as possíveis respostas a cada um desses eventos.
Aquisições – área que define qual produto ou serviço deve ser comprado adquirido
externamente, ou seja, fora das fronteiras da empresa executora. Nessa área, desenvolvem-
se os relacionamentos com os fornecedores.
Integração – décima área de conhecimento, que coordena e conecta os diversos elementos
constitutivos do projeto. Ela deve ser a harmonizadora das demais áreas de conhecimento.

Um ponto de ressalva é que nem todos os projetos precisam usar ou implementar todas as dez
áreas. Ao contrário, deve-se avaliar em cada projeto quais áreas deverão, de fato, ser iniciadas ou
utilizadas. Por outro lado, o gerente de projeto que assim fizer, deve estar ciente de que, sempre que
deixar de planejar algum aspecto de área de conhecimento, poderá perder o controle sobre a mesma.

72
 A seguir, a ilustração de Vargas (2016) serve para mostrar como as áreas devem ser encaradas,
ou seja, de maneira integrada:

Figura 39 – Dez áreas do conhecimento

Como adiantado no tópico 2.1, a 6a edição do PMBOK traz 49 processos de gerenciamento

distribuídos pelas 10 áreas de conhecimento. A seguir, iremos listar esses processos por área de
conhecimento. As numerações apresentadas de cada área correspondem ao seu capítulo no
PMPOK. Vejamos:

4. Gerenciamento da integração do projeto

4.1 Desenvolver o termo de abertura do projeto
4.2 Desenvolver o plano de gerenciamento do projeto
4.3 Orientar e gerenciar o trabalho do projeto
4.4 Monitorar e controlar o trabalho do projeto
4.5 Gerenciar o conhecimento do projeto
4.6 Realizar o controle integrado de mudanças
4.7 Encerrar o projeto ou fase

73
 5. Gerenciamento do escopo do projeto
5.1 Planejar o gerenciamento do escopo
5.2 Coletar os requisitos
5.3 Definir o escopo
5.4 Criar a EAP
5.5 Validar o escopo
5.6 Controlar o escopo

6. Gerenciamento do cronograma do projeto

6.1 Planejar o gerenciamento do cronograma
6.2 Definir as atividades
6.3 Sequenciar as atividades
6.4 Estimar as durações das atividades
6.5 Desenvolver o Cronograma
6.6 Controlar o Cronograma

7. Gerenciamento dos custos do projeto

7.1 Planejar o gerenciamento dos custos
7.2 Estimar os custos
7.3 Determinar o orçamento
7.4 Controlar os custos

8. Gerenciamento da qualidade do projeto

8.1 Planejar o gerenciamento da qualidade
8.2 Gerenciar a qualidade
8.3 Controlar a qualidade

9. Gerenciamento dos recursos do projeto

9.1 Planejar o gerenciamento dos recursos
9.2 Estimar os recursos das atividades
9.3 Adquirir recursos
9.4 Desenvolver a equipe
9.5 Gerenciar a equipe
9.6 Controlar os Recursos

74
10. Gerenciamento das comunicações do projeto
10.1 Planejar o gerenciamento das comunicações
10.2 Gerenciar as comunicações
10.3 Monitorar as comunicações

11. Gerenciamento dos riscos do projeto

11.1 Planejar o gerenciamento dos riscos
11.2 Identificar os riscos
11.3 Realizar a análise qualitativa dos riscos
11.4 Realizar a análise quantitativa dos riscos
11.5 Planejar as respostas aos riscos
11.6 Implementar respostas aos riscos
11.7 Monitorar os riscos

12. Gerenciamento das aquisições do projeto

12.1 Planejar o gerenciamento das aquisições
12.2 Conduzir as aquisições
12.3 Controlar as aquisições

13. Gerenciamento das partes interessadas do projeto

13.1 Identificar as partes interessadas
13.2 Planejar o engajamento das partes interessadas
13.3 Gerenciar o engajamento das partes interessadas
13.4 Monitorar o engajamento das partes interessadas

75
 As dez áreas de conhecimentos e os seus respectivos processos de gerenciamento podem ser
visualizados sob a forma anterior, em uma lista, ou de modo tabelado, como apresentado a seguir.
Na coluna da esquerda, constam as áreas de conhecimento e, na da direita, os cinco grupos de
processos, perfazendo o total de 49 processos. Vejamos:

área de monitoramento
iniciação planejamento execução encerramento
conhecimento e controle

4. integração 4.1 desenvolver 4.2 desenvolver o plano 4.3 orientar e 4.5 monitorar e 4.7 encerrar o
o termo de de gerenciamento do gerenciar o controlar o projeto ou fase
abertura do projeto trabalho do trabalho do
projeto projeto projeto
4.4 gerenciar o 4.6 realizar o
conhecimento controle
do projeto integrado de
mudanças

5. escopo 5.1 planejar o 5.5 validar o

gerenciamento do escopo
escopo 5.6 controlar o
5.2 coletar os requisitos escopo
5.3 definir o escopo
5.4 criar a EAP

6. cronograma 6.1 planejar o 6.6 controlar o

gerenciamento do cronograma
cronograma
6.2 definir as atividades
6.3 sequenciar as
atividades
6.4 estimar as durações
das atividades
6.5 desenvolver o
cronograma

7. custos 7.1 planejar o 7.4 controlar os

gerenciamento dos custos
custos
7.2 estimar os custos
7.3 determinar o
orçamento

8. qualidade 8.1 planejar o 8.2 gerenciar a 8.3 controlar a

gerenciamento da qualidade qualidade
qualidade

76
 área de monitoramento
iniciação planejamento execução encerramento
conhecimento e controle

9. recursos 9.1 planejar o gerenciamento 9.3 adquirir 9.6 controlar os

dos recursos recursos recursos
9.2 estimar os recursos das 9.4 desenvolver
atividades a equipe
9.5 gerenciar a
equipe

10. comunicação 10.1 planejar o 10.2 gerenciar 10.3 monitorar

gerenciamento das as as
comunicações comunicações comunicações

11. riscos 11.1 planejar o 11.6 implementa monitorar os

gerenciamento dos riscos r respostas aos riscos
11.2 identificar os riscos riscos

11.3 realizar a análise

qualitativa dos riscos
11.4 realizar a análise
quantitativa dos riscos
11.5 planejar as respostas
aos riscos

12. aquisições 12.1 planejar o 12.2 conduzir as 12.3 controlar as

gerenciamento das aquisições aquisições
aquisições

13. stakeholders 13.1 identificar 13.2 planejar o engajamento 13.3 gerenciar o 13.4 monitorar o
as partes das partes interessadas engajamento engajamento
interessadas das partes das partes
interessadas interessadas

Fonte: https://escritoriodeprojetos.com.br/processos-do-guia-pmbok-sexta-edicao

Documentos-chave: Termo de Abertura do Projeto (TAP) e Plano de

Gerenciamento do Projeto (PGP)

Termo de abertura do projeto (TAP)

Tão logo seja confirmada a necessidade de um projeto, será emitido o Termo de Abertura
do Projeto (TAP) ou Project Charter. Esse documento visa oficializar ou autorizar a abertura do
projeto dentro da empresa executora do mesmo. Por isso, o TAP é gerado na fase preliminar ou
de iniciação do empreendimento.
Podemos fazer algumas recomendações sobre o seu conteúdo. Normalmente, é feita uma
introdução para efeito de contextualização, com algumas linhas da justificativa do projeto, ou

77
melhor, para quais necessidades ele está sendo criado, o seu porquê. Devemos também agregar
algumas linhas com os requisitos do projeto, bem como os seus objetivos gerais e específicos. Sobre
o tema de definição dos objetivos de um projeto, o autor Ricardo Vargas (2016) sugere a utilização
de critérios SMART, conforme abaixo:

Figura 40 – Critérios SMART

No documento do TAP, também é comum encontrarmos esses elementos:

produtos esperados da empreitada;
definição dos seus principais stakeholders;
premissas – tudo o que é assumido ou pressuposto como certo no projeto, sendo validado
e acordado, torna-se uma premissa5;
restrições – todo fator restritivo do projeto que afete, em maior ou menor grau, a sua
execução ou manutenção dentro do curso ideal6;
nomeação ou designação do gerente do projeto e as suas responsabilidades;
orçamento preliminar;
cronograma macro ou sumarizado, e
riscos inicialmente identificados.

5
Exemplo 1: farão parte da equipe executora do projeto os recursos Mario, Moisés e Daniel, cedidos antecipadamente pelo
seu gerente funcional. Exemplo 2: o dólar ficará ancorado a R$ 4,00 ao longo do ciclo de vida. Exemplo 3: o horário de
trabalho do projeto será o turno da manhã, de 08h30 às 12h30, horário de Brasília.
6
Exemplo 1: a data final desse projeto será 01/12/2021, sem autorização para postergações. Exemplo 2: o teto
orçamentário desse projeto é de U$ 290.000,00. Exemplo 3: apenas os membros do setor de contabilidade poderão acessar
a sala de execução do projeto.

78
 Uma vez pronto e concebido o documento, é altamente recomendável que o TAP seja
assinado pelo patrocinador do projeto, com a finalidade de torná-lo devidamente reconhecido. Após
a assinatura dessa certidão de nascimento, o projeto estará oficializado ou autorizado. Graças à
importância desse ato e como forma de também valorizar a posse do gerente de projeto, o
documento assinado deve ser distribuído internamente na empresa executora ou, pelo menos, o
fato anunciado junto aos stakeholders mais ligados ao projeto. Essa comunicação pode ser feita por
meio de inúmeras mídias, mas tem sido comum o compartilhamento do arquivo do TAP por e-
mail ou por anúncios feitos em reuniões, presenciais ou virtuais, graças a ferramentas cada vez mais
comuns nas empresas, tais como Skype, Google HandOut, Webex, Citrix go to Meeting, Adobe
Connect, Microsoft Office Live Meeting, entre outros.
Com o TAP assinado e amplamente divulgado, o projeto encontra-se pronto para passar da
etapa de concepção. Conforme vimos em tópico anterior sobre o ciclo de vida, trata-se da fase
seguinte de planejamento, a ser conduzida pessoalmente pelo gerente do projeto. Será no período
de planejamento que, como já sabemos, ocorrerão os detalhamentos das estimativas e
pormenorizações mais concretas, assim como as definições mais fundamentais da empreitada. Nessa
fase seguinte do planejamento, a grande meta do gestor do projeto passará a ser a confecção do
Plano de Gerenciamento do Projeto (PGP).

Plano de Gerenciamento do Projeto (PGP)

O Plano de Gerenciamento do Projeto (PGP), plano geral do projeto ou, simplesmente,
plano do projeto tem por fim ser um plano exequível e provedor das diretrizes para a execução do
esforço. Deve haver coordenação na elaboração e integração do planejamento, nas quais as áreas de
conhecimento, tratadas no tópico 2.3, serão apropriadamente integradas. Devido a esse foco, o PGP
é o documento-chave da área de integração de um projeto.
Valeriano (2001, p. 13) complementa que o PGP é “o documento que consubstancia as
decisões, tomadas em um determinado momento, em cada um dos níveis, e que visa à consecução
de objetivos finais a serem alcançados em determinado período”.
Para o autor Vargas (2016), “o processo de desenvolver o plano de gerenciamento do projeto
inclui as ações necessárias para definir, coordenar e integrar todos os planos auxiliares em um plano
de gerenciamento do projeto”. De fato, o plano do projeto conterá os nove subplanos ou planos
auxiliares das demais (nove) áreas de conhecimento:
plano de gerenciamento do escopo;
plano de gerenciamento do custo;
plano de gerenciamento do cronograma;
plano de gerenciamento dos recursos;
plano de gerenciamento das comunicações;

79
 plano de gerenciamento do risco;
plano de gerenciamento dos stakeholders;
plano de gerenciamento da qualidade e
plano de gerenciamento das aquisições.

Uma vez que esses subplanos sejam elaborados pelo gerente de projetos, teremos chegado às
linhas de base de cada uma das áreas de conhecimento (assunto do próximo tópico). O plano do
projeto é fruto da combinação desses planos em um único documento. Uma vez concluído, o PGP
define as linhas de referência a ser seguidas por todo o ciclo de vida que resta à frente. Ele poderá
conter os seguintes documentos, por área de conhecimento:

documentos de tempo e atividades

atributos de atividades

estimativa de custos de atividades

lista de atividades

requerimentos de recursos de atividades

cronograma do projeto

diagramas da rede de atividades do projeto

dados do cronograma

calendários do projeto

lista de marcos do projeto

documentos de aquisições

pacote de documentos de aquisições

declarações de trabalho

propostas de fornecedores

critério de seleção de fornecedores

80
 documentos de stakeholders

registro de stakeholders

matriz de engajamento de stakeholders

documentos de escopo

registro de mudanças

solicitações de mudanças

documentação de requerimentos

matriz de rastreabilidade de requerimentos

documentos de custo

documentos de requerimentos de fundos

orçamento do projeto

documentos de recursos

organograma

descrição de cargos

avaliação de desempenho da equipe

documentos de comunicação

dados de desempenho do trabalho

informação de desempenho do trabalho

relatórios de desempenho do trabalho

81
 documentos de qualidade

listas de verificação

planilhas de medições de controle

métricas da qualidade

documentos de riscos

registro de riscos

estrutura analítica de riscos

Linha de base e a tripla restrição

A linha de base (ou baseline) é um conceito muito presente no jargão de gestão de projetos,
já que significa a medida de desempenho da empreitada. Pode ser usada no dia a dia do projeto
como uma régua de comparação entre o que se planejou e o que foi concretamente entregue, sendo
usada como ferramenta de avaliação de performance do projeto. Em síntese, sem uma linha de base,
nenhum projeto pode ser controlado, já que não haveria uma referência ou um norte para se avaliar
o sucesso do empreendimento.
Em geral, as três linhas de base mais comuns são:
Linha de base de escopo – obtida por meio da confecção da ferramenta da EAP (a ser
descrita no módulo final). Entregas não contidas na linha de base do escopo não farão
parte do projeto.
Linha de base de tempo – obtida por meio da confecção da ferramenta do Cronograma (a
ser melhor detalhado no módulo final). Da mesma forma, toda atividade ausente do
cronograma não deverá ser realizada, já que foge da baseline.
Linha de base de custo – evidenciada no orçamento final do projeto (retiradas as reservas
gerenciais para custos desconhecidos). Contém os custos das tarefas do projeto e a reserva
de contingência do projeto (proteção contra riscos).

O programa aeroespacial da NASA, comentado por diversas vezes em tópicos anteriores, usa
o conceito de linha de base desde 1967. Nas missões espaciais da série Apollo, foi criado um manual
de gerenciamento de programa, contendo as fases existentes em cada um dos projetos, as respectivas
EAPs e a linha de base do programa (CAMARGO, 2014).

82
 Outro tema da disciplina de gerenciamento de projetos, derivado inclusive do conceito de
linha de base, é a restrição tripla ou tríplice restrição em projetos. Essa restrição é formada pelos
vértices das áreas de conhecimento de escopo, de tempo e de custo. Nesse ponto de nossos estudos,
já conseguimos perceber que é difícil a manutenção de um equilíbrio das demandas conflitantes
desses três parâmetros. Apesar deles serem pré-fixados no Plano de Gerenciamento do Projeto
(consoante ao tratado no tópico 2.4.2), é comum durante a execução do projeto surgirem demandas
que alterem essas especificações e que exijam um replanejamento por parte do gerente do projeto.
Também há a possibilidade de serem percebidos erros ou omissões no plano original ou
necessidades de adaptações à linha de base original. Se for uma inclusão necessária na área de tempo,
há uma probabilidade de que essa alteração afete o vértice do custo. Se for uma mudança no vértice
do custo, poderemos perceber impacto no tempo ou no escopo do projeto, e assim sucessivamente.
Por exemplo, uma mudança de aumento de escopo seria a inclusão de um novo cômodo no projeto
original da construção da casa da família. Certamente, esse item adicional geraria aumento nos
custos e nos tempos originais do projeto, de modo que o cômodo adicional significaria refazer o
escopo do projeto, incluindo esse novo item. Além disso, a sua construção aumentaria o custo total
original do projeto, já que seria muito provável a necessidade de mais recursos financeiros e, talvez,
até humanos para a consecução dessa obra complementar. À luz do mesmo caso hipotético,
poderíamos contar com um possível impacto de atraso no cronograma do projeto, devido à adição
do cômodo. Se a data original para a conclusão do projeto fosse a primeira quinzena de janeiro de
2010, com essa adição de escopo, talvez a data prevista recalculada passasse a ser início de fevereiro
de 2010.
A restrição tripla pode ser ilustrada da seguinte forma:

Figura 41 – Restrição tripla

83
Controle geral de mudanças
Por melhor que seja a qualidade do planejamento do gestor do projeto, eventualmente,
surgem necessidades de mudanças na linha de base, como vimos nos exemplos ao final do tópico
precedente. Vargas (2016) explica que esse processo

é realizado desde o início do projeto até o seu término. O controle de

mudanças é necessário porque raramente a execução dos projetos segue
com exatidão o plano de gerenciamento do projeto. O plano de
gerenciamento do projeto, a declaração de escopo do projeto e outras
entregas precisam ser mantidos por meio do gerenciamento contínuo e
cuidadoso das mudanças.

Valeriano (2001) também aponta que:

Todos os parâmetros do projeto (tempo, custos, requisitos de qualidade e

de desempenho, em geral) devem estar sob controle para detectar
afastamentos em relação ao previsto em cada um deles. Isto é feito por
meio de medidas de desempenho adequadas para cada caso particular e as
causas dos afastamentos ou discrepâncias devem ser removidas e, se for o
caso, aplicar medidas corretivas sobre o resultado. Alguns dos afastamentos
observados podem necessitar de planejamentos adicionais ou
replanejamento para ajustar a realidade com o esperado. Isso pode
significar remanejamento ou mudanças de pessoal, de prazos, de materiais,
de processos. As mudanças do escopo e os respectivos reflexos e
consequências devem ser claramente documentados, os documentos
alterados aprovados e deles deve ser dado conhecimento às partes
interessadas. Mudanças no escopo que afetem o cliente ou o patrocinador
ou contratante do projeto devem ser por esses aprovadas, mediante
negociação do gerente do projeto e demais partes interessadas. Sempre que
for o caso, devem ser tomadas as necessárias ações preventivas ou
corretivas, mantendo sempre os resultados conforme o planejado. Como
em todas as gestões, as lições aprendidas devem ser reconhecidas,
identificadas e organizadas para utilização posterior (p. 200-201.).

84
 Aqui, cabe ressaltar a função-chave do gerente de projeto na avaliação dos impactos de cada
uma das mudanças solicitadas, já que deverá considerar quais áreas de conhecimento serão
possivelmente afetadas se houver efetiva aceitação da proposta.
No pedido de mudança, iniciado pelos diversos stakeholders, o proponente da alteração
descreverá a sua demanda juntamente com uma justificativa, mas o gerente poderá delimitar os
limites de aprovação, ou seja, quem deverá participar na análise dessas solicitações de mudança.
Tem-se tornado comum a composição de grupos ou comitês de controle de mudança nas empresas
executoras dos projetos.
Segundo Valeriano (2001, p. 177), “a avaliação e a aprovação de mudanças são feitas por um
colegiado multidisciplinar (Comissão de Controle de Mudanças) com representantes das áreas
administrativas e gerenciais e das áreas de conhecimento envolvidas”. Esses comitês de mudança
analisarão as solicitações oficialmente submetidas, sendo o processo feito, muitas vezes, on-line, por
meio de sistemas de controle. Em seguida, o pedido será avaliado, podendo ser rejeitado (arquivado)
ou aprovado (implementação da mudança solicitada).
Em resumo, o controle geral de mudanças dos projetos deve ser formal e processual, além de
amplamente divulgado aos stakeholders. Todo esse tratamento de solicitação de mudanças é
representado no fluxograma a seguir:

85
 Figura 42 – Controle de mudanças

Fonte: VARGAS (2016).

86
Critérios de um projeto de sucesso
A definição de projeto de sucesso depende muitíssimo de qual stakeholder irá respondê-la,
mas devemos pensar, prioritariamente, na resposta obtida pelo próprio gerente de projetos, pelo seu
patrocinador, pelo seu cliente e pela equipe. Evidentemente, ao término do projeto, o gerente irá
medir se o projeto foi ou não bem-sucedido, por meio de critérios pré-estabelecidos.
O ideal é que esses critérios de medida do sucesso tenham sido previamente acordados com
os stakeholders-chave, tais quais os citados acima. Isso evitaria dúvidas ou percepções subjetivas, que
comprometeriam a avaliação final do projeto.
A utilização das áreas de conhecimento e as suas respectivas linhas de base, conforme
dissertado nos tópicos anteriores, deverão ser aditadas para se fazer a comparação entre planejado e
realizado, de modo a facilitar a conclusão acerca da performance do projeto.
As perguntas, a seguir, podem ser usadas pelo gestor de projetos para questionar os seus
envolvidos e obter uma definitiva, real e final posição sobre o sucesso da empreitada:
Projeto foi concluído dentro do prazo definido no cronograma?
Projeto respeitou o orçamento original?
Projeto entregou todo o escopo previsto e alinhado com o cliente?
Projeto usou, efetivamente, os recursos físicos da empresa?
Projeto acatou os padrões de qualidade pré-acordados?
Projeto cumpriu os requisitos de segurança do trabalho exigidos pela legislação?
Projeto tratou os stakeholders convenientemente?
Projeto cumpriu as promessas de comunicação (reuniões, telefonemas, e-mails,
teleconferências, relatórios de status, etc.) e com a devida frequência?
Projeto estimulou corretamente o seu time para entregar de forma otimizada o escopo
do projeto?
Projeto recebeu dos seus fornecedores as matérias-primas e demais insumos na forma e
qualidade técnicas pedidas em contrato?
Projeto respeitou a cultura da empresa?

Torres (2014, p. 116) indica cinco fatores críticos de sucesso nos projetos:
capacitação comportamental – habilidades de relacionamento fazendo a diferença no
trabalho em equipe;
metodologia consistente de gerenciamento – articulação entre as boas práticas e a expertise
da empresa;
governança de projetos – definição de regras de suporte institucional aos projetos
sistema de informações de gerenciamento de projetos – processos consistentes apoiados
por ferramentas eficazes e
capacitação técnica – habilitação progressiva com autonomia e em diversos formatos.

87
MÓDULO III – AQUISIÇÕES EM PROJETOS

Neste módulo, veremos o gerenciamento de aquisições no ambiente de um projeto,

utilizando como fio condutor do seu ciclo de vida. Em seguida, passaremos pela identificação das
necessidades, pelo planejamento do trabalho, pela busca dos recursos e pela administração dos
contratos de fornecimento.

Introdução
O princípio da escassez, fundamental na Economia, reconhece que todos os recursos
disponíveis para uso humano são finitos (ainda que os seus estoques possam parecer, a um exame
superficial, inesgotáveis) e define a medida da escassez de um recurso como sendo o custo
(ambiental, social, técnico e econômico) da sua obtenção. Uma das consequências desse princípio
é a inviabilidade de um indivíduo, grupo ou uma organização possuírem ou controlarem todos os
recursos de que necessitam para operar e atingir os seus objetivos, obrigando-os a interagirem entre
si para conseguir o que lhes falta.
Essa realidade é a origem do comércio e, por extensão, de todo o corpo de conhecimento
desenvolvido ao longo do tempo com o objetivo de assegurar que o indivíduo, grupo ou organização
possam ter acesso aos recursos faltantes, dentro de uma relação de custo-benefício razoável e de
acordo com regras minimamente seguras e aceitáveis para as partes envolvidas.
Modernamente, esse corpo de conhecimento é tratado pelas organizações como um
macroprocesso de trabalho indispensável, com grande influência nos resultados da atividade e que
atende a vários nomes: suprimentos, compras, aquisições, etc. Cada organização configura esse
processo de acordo com as peculiaridades de sua atividade. No entanto, há um conjunto de
princípios, técnicas e boas práticas que constitui uma base comum de conhecimento aplicável
igualmente à maioria das organizações e à maior parte das situações de obtenção de recursos.
As diferenças entre operações e projetos, particularmente a temporalidade, fazem com que
metodologias de aquisição voltadas para projetos possuam algumas características específicas, mas
isso não altera aquela base comum de conhecimento.
Trataremos aqui do gerenciamento de aquisições no ambiente de projetos, mantendo a
análise ao nível das diretrizes aplicáveis à maioria das organizações. Quando necessário, serão
assinaladas as diferenças entre a aplicação em organizações privadas e públicas. Como fio condutor,
utilizaremos o ciclo de vida do projeto e passaremos pela identificação das necessidades, pelo
planejamento do trabalho, pela busca dos recursos e pela administração dos contratos de
fornecimento. O tema será abordado pelo ângulo gerencial, sendo os aspectos jurídicos e processuais
mencionados apenas quando necessário para o entendimento do contexto. A vastidão do tema e os
limites desse módulo impedem que os tópicos sejam abordados na profundidade ideal, mas
esperamos oferecer uma visão de conjunto que permita a compreensão do processo e oriente para
estudos mais específicos conforme necessário.

Aquisições em projetos
Se visualizarmos um projeto como um grupo de pessoas encarregado de desenvolver uma
solução para uma necessidade especificada, é fácil perceber que essa equipe estará, desde o primeiro
dia, diante de um velho problema: não possuir os recursos necessários para realizar o seu trabalho –
entendendo “recurso” como qualquer elemento (energia, materiais, meios de produção,
conhecimento, trabalho, etc.) requerido para atingir o resultado desejado. Desse modo, a equipe é
levada a formular – e buscar respostas – para algumas questões:
O QUE precisamos para realizar o projeto?
ONDE conseguir o que precisamos?
COMO obter o que precisamos?
QUANDO conseguiremos ter o que precisamos?
QUANTO nos custará o que precisamos?
QUAIS riscos estaremos correndo ao adquirir o que precisamos?

Conhecidas as respostas, é preciso efetuar um trabalho sistemático para conseguir

aprovisionar o projeto com os recursos necessários respeitando os requisitos e restrições de
qualidade, prazo e custo estabelecidos. Da qualidade das respostas e do trabalho efetuado a partir
delas, dependerá não apenas o sucesso, mas a própria existência do projeto.

90
 Para conseguir esse resultado, a organização e, por extensão, a equipe do projeto precisam
compreender a essência de um processo de gerenciamento das aquisições aplicado a projetos e a sua
dinâmica, e, a partir daí, desenvolver uma metodologia adequada às suas especificidades. Dois
elementos são definidores desse processo: o princípio do Risco e o princípio da Qualidade.
Aplica-se o princípio do risco ao projeto como um todo, mas adquire especial importância
nas aquisições devido ao fato de que muitos recursos são tecnicamente complexos, têm um impacto
elevado no orçamento ou requerem tempo considerável para se tornarem disponíveis (ou seja, têm
potencial para causar danos sérios ao projeto). Isso exige que o gerenciamento das aquisições nunca
se afaste do gerenciamento de riscos, e define o critério básico de tomada de decisão nas aquisições:
o de menor risco para o projeto. A ameaça ao projeto estabelece também um dos princípios centrais
nas contratações: a transferência do risco entre cliente e fornecedor. Escolher a melhor alternativa
em cada caso tem grande influência sobre a probabilidade de sucesso das aquisições e, por
consequência, do próprio projeto.
Outro aspecto característico das aquisições em projetos é que, devido aos prazos geralmente
curtos, é usual que os recursos se tornem disponíveis apenas pouco tempo antes de serem utilizados.
Alguns (via de regra, os principais) tem longo prazo de obtenção e precisam ser adquiridos com
muita antecedência, em uma fase do projeto em que a incerteza das informações ainda é elevada.
Novamente, o risco de erros é elevado, assim como a possibilidade de que sejam descobertos apenas
após o recebimento do recurso. Os danos podem ser consideráveis e, eventualmente, irreparáveis.
Isso leva ao segundo elemento definidor: o princípio da qualidade. Organizar o trabalho das
aquisições segundo os princípios dessa área de conhecimento, associando-os a um gerenciamento
sistemático de riscos, é a melhor maneira de assegurar um bom resultado para o projeto. Desse
modo, a boa prática reconhecida no gerenciamento de aquisições é a ênfase no planejamento e na
aplicação de procedimentos que:
procurem minimizar o risco de não conformidades e
organizem o trabalho de modo a buscar sempre o “bom da primeira vez”.

Devido a essa necessidade, não é surpresa que os processos de gerenciamento de aquisições

sejam modelados segundo o ciclo de Deming (PDCA). Em particular, o PMI (2017) define o
trabalho da área de aquisições em projetos (Project Procurement Management) como sendo
distribuído em três processos: planejamento (plan procurement), execução (conduct procurement) e
controle (control procurement); considerando subentendido que o controle implica realimentação
para corrigir os desvios e melhorar continuamente o resultado, temos aí o PDCA clássico. Cabe
notar que a abordagem preconizada pelo PMI reproduz a base comum de conhecimento referida
anteriormente e constitui um conjunto de diretrizes utilizável por qualquer organização para

91
desenvolver a sua própria metodologia de gerenciamento de aquisições em projetos. Utilizaremos
esse modelo para completar a análise inicial do processo.
O processo de planejamento tem início juntamente com os planejamentos das demais áreas
(escopo, custos, riscos, etc.), e os seus resultados se integram ao documento mestre de planejamento
do projeto, o Plano do Projeto (mais informações no tópico 3). Esse processo tem o seu maior nível
de atividade durante as fases de iniciação e de planejamento do projeto, prosseguindo, na fase de
execução, para efetuar as atualizações periódicas que venham a ser necessárias. As suas entradas, saídas,
técnicas e ferramentas, segundo o entendimento do PMI (2017) são mostradas no quadro 5.
O processo de execução das aquisições transcorre, naturalmente, durante a fase de execução
do projeto, com duas peculiaridades: (a) tem início tão logo o planejamento do projeto seja
aprovado, já que vários recursos são de longo prazo e impactam, diretamente, o caminho crítico, e
(b) ultrapassa a fase de execução e só termina na fase de encerramento do projeto, já que alguns
contratos só podem ser concluídos após a entrega do produto do projeto. A sua modelagem,
segundo o PMI (2017), é mostrada no quadro 6. O processo de controle, por sua vez, acompanha
o de execução ao longo de todo o seu período de atividade. A modelagem do PMI (2017) para esse
processo é mostrada no quadro 7.
Em um plano mais operacional, podemos subdividir o processo de execução em três
subprocessos, que se superpõem parcialmente ao longo do tempo: a busca, a contratação e a
administração. O primeiro engloba todo o trabalho necessário para, partindo da necessidade
especificada de um recurso, obter opções de fornecimento do mercado e selecionar a mais adequada;
o segundo representa o trabalho de transformar a opção de fornecimento escolhida em um contrato
(acordo formal entre cliente e fornecedor); o terceiro inclui o trabalho de gerenciar os contratos
firmados, assegurando a disponibilização dos recursos ao projeto e o correto atendimento às
condições acordadas entre as partes. O tópico Processos Licitatórios apresenta, em maior detalhe, a
busca das melhores opções. O tópico de Modelos de Contratos trata da contratação, e os tópicos
Administração de Contratos e Encerramento de Contratos, da administração.

92
 Quadro 5 – Elementos do processo de planejamento de aquisições

entradas técnicas e ferramentas saídas

conhecimento plano de gerenciamento das

termo de abertura do projeto
especializado aquisições

caso de negocio bases de dados estratégia de aquisições

plano do projeto interpretação de dados procedimentos licitatórios

métodos de seleção de declaração de trabalho de

documentação do projeto
alternativas aquisições

fatores ambientais da critérios para seleção de

reuniões
organização hospedeira fontes

ativos organizacionais da
decisões make-or-buy
organização hospedeira

estimativas de custo

solicitações de mudanças

documentação do projeto
atualizada

ativos organizacionais
atualizados

Fonte: adaptado de PMI.

93
 Quadro 6 – Elementos do processo de execução das aquisições

entradas técnicas e ferramentas saídas

plano do projeto conhecimento especializado fornecedores selecionados

documentação do projeto publicidade acordos

documentação de
encontros com licitantes solicitações de mudanças
aquisições

propostas de fornecedores análise de dados plano do projeto atualizado

fatores ambientais da competências interpessoais documentação do projeto

organização hospedeira e de trabalho em equipe atualizada

ativos organizacionais da ativos organizacionais

organização hospedeira atualizados

Fonte: adaptado de PMI.

Quadro 7 – Elementos do processo de controle das aquisições

entradas técnicas e ferramentas saídas

plano do projeto conhecimento especializado documentação concluída

informações sobre o
documentação do projeto gestão de pleitos
desempenho do trabalho

documentação de
acordos análise de dados
aquisições atualizada

documentação de
inspeções pedidos de mudança
aquisições

documentação de
auditorias plano do projeto atualizado
mudanças aprovadas

informações sobre o documentação do projeto

desempenho do trabalho atualizada

fatores ambientais da ativos organizacionais

organização hospedeira atualizados

ativos organizacionais da
organização hospedeira

Fonte: adaptado de PMI.

94
 Outro elemento importante é o paralelismo entre o processo de aquisições realizado pela
organização hospedeira de forma contínua, para sustentar a sua operação, e o processo temporário
estabelecido para o projeto. Como já comentado, os processos são semelhantes, mas não idênticos
e, dependendo do posicionamento do projeto na organização, podem ocorrer dificuldades. Em uma
organização do tipo funcional, estruturada exclusivamente para atender à sua operação, as aquisições
do projeto são realizadas pelo setor especializado (gerência de compras, departamento de
suprimentos ou similares), de acordo com os seus procedimentos e critérios. O risco de conflitos
por prioridades, critérios de decisão e outros é alto, e só pode ser resolvido com a ação dos
patrocinadores e o envolvimento do setor de compras no projeto.
Outras organizações, estruturadas para realizar uma operação, possuem, no entanto, setores
e equipes permanentes dedicadas a projetos – são as chamadas organizações matriciais. Nelas, a
equipe do projeto é autorizada, normalmente, a adquirir parte dos recursos, segundo critérios de
valor ou de natureza do recurso. Desse modo, a boa prática para o sucesso é a existência de uma
matriz de responsabilidades bem-feita entre o projeto e o setor de compras. Nesse ambiente, a
equipe do projeto precisa contar com profissionais competentes em aquisições e usa os
procedimentos e as ferramentas do setor de compras.
Por fim, existem as organizações cuja atividade-fim é a realização de projetos e que, dessa
forma, estruturam-se para isso. Nessas organizações projetizadas, a equipe do projeto costuma ser
responsável por adquirir todos os recursos necessários, apenas respeitando as diretrizes e
procedimentos corporativos. Aqui, o ponto-chave é a montagem, dentro de equipe do projeto, de
um grupo de aquisições com todas as competências e capacidades necessárias para realizar o
trabalho. Em qualquer caso, o responsável pelo projeto deve, desde o primeiro dia, identificar em
qual ambiente de aquisições se encontra e se preparar para trabalhar de acordo com ele. Tentar
ignorar a autoridade funcional do departamento de compras ou insistir em delegar a ele aquisições
que o projeto não quer (mas deveria) fazer são atitudes contraproducentes que só podem prejudicar
o resultado final.
Utilizando os conceitos básicos apresentados acima, podemos seguir o percurso das aquisições
de um projeto, começando por responder às perguntas elaboradas no início dessa Unidade.

Planejamento de aquisições em projetos

O QUE precisamos?
Antes de tudo, precisamos entregar o escopo do projeto. Esse escopo é explicitado na
Estrutura Analítica do Projeto (EAP), e a primeira fonte de identificação dos recursos é esse
documento. Se uma EAP identifica como entregas parciais do projeto um estudo de engenharia ou
um equipamento, esses elementos se tornam, automaticamente, recursos necessários para que o

95
escopo do projeto possa ser completado. Com isso, o último nível de uma EAP representa o
conjunto de recursos a serem obtidos para o projeto. Naturalmente, quanto mais detalhada for a
EAP mais bem-definidas são as necessidades de recursos. Com isso, o primeiro passo para planejar
as aquisições de um projeto é a elaboração da lista de necessidades a partir do último nível da EAP.
Evidentemente, como a EAP é dinâmica, a lista também o será.

ONDE conseguimos o que precisamos?

Há três fontes de recursos para um projeto: a organização hospedeira, o seu cliente (se for
externo àquela organização) e o universo externo a essas três entidades (o mercado). Desse modo,
impõe-se como segundo passo, a classificação da lista de necessidades em dois grupos de recursos:
os internos e os que devem ser adquiridos no mercado. Esse exercício não é tão simples como possa
parecer, já que envolve não apenas conhecimento das possibilidades do mercado e das entidades
centrais, mas também decisões estratégicas sobre uso de recursos próprios que podem estar sendo
disputados para outras aplicações, políticas de tratamento de risco (aversão ou tolerância), sigilo,
propriedade intelectual, disponibilidade financeira, etc. Essa análise é conhecida como Make-or-
Buy, literalmente, Fazer-ou-Comprar. É comum que os documentos iniciais do projeto como o
Termo de Abertura e a Declaração de Escopo tragam diretrizes e restrições a respeito, como uma
exigência de conteúdo local mínimo ou uma regra sobre terceirização de serviços. As políticas e os
regulamentos da organização hospedeira e do cliente também são fontes de orientação. Geralmente,
a equipe do projeto não tem informações e autonomia suficientes para tomar todas as decisões
necessárias sobre a origem dos recursos, devendo recorrer à hierarquia ou aos patrocinadores do
projeto para concluir a análise. Mesmo essas instâncias, muitas vezes, não conseguem responder
imediatamente, ficando na dependência de informações adicionais (às vezes, geradas pelo próprio
projeto) para decidir. Isso pode fazer com que a obtenção de recursos importantes seja
comprometida, e cabe à equipe do projeto manter os responsáveis informados e sensibilizados, no
limite das suas competências, para assegurar que essas decisões iniciais direcionadoras de todo o
trabalho sejam tomadas de maneira tempestiva e com qualidade.
A análise Make-or-Buy produz a lista de aquisições, que é um subconjunto da lista de
necessidades relacionando os recursos que deverão ser adquiridos no mercado. Com ela, é possível
responder à terceira pergunta.

COMO obter o que precisamos?

Agora, trata-se de mapear o mercado com o objetivo de avaliar as condições gerais em que
cada recurso poderá ser obtido, buscando informações como quantidade de fornecedores existentes,
a sua distribuição geográfica, modos operatórios típicos desses fornecedores (formas de negociação

96
e venda, por exemplo) e, especialmente, os riscos envolvidos. Por exemplo, identificar que um
equipamento não possui fornecedores no país aponta para a necessidade de uma licitação
internacional, o que representa um processo de aquisição mais complexo; quanto mais cedo essa
circunstância for conhecida, mais tempo a equipe do projeto terá para se preparar, mitigando os
riscos. Outro resultado desse mapeamento é a possibilidade de racionalização das aquisições pelo
aproveitamento de opções disponíveis no mercado, por exemplo, a aquisição de “pacotes” de
serviços de um só fornecedor em vez de várias contratações separadas, ou ainda a combinação de
vários equipamentos complementares em um só fornecimento integrado (um sistema de geração e
distribuição de energia funcionando, em vez de geradores, painéis de distribuição, cabeamento, etc.
acompanhados de serviços de instalação à parte).
Esse exercício pode, e frequentemente leva, a ajustes na EAP, já que é interessante para o
planejamento e, sobretudo para o controle do projeto, que as entregas de último nível coincidam,
tanto quanto possível, com a lista de aquisições.

QUANDO conseguiremos ter o que precisamos?

Os prazos de obtenção dos recursos são decisivos para a realização do projeto. Vários deles
farão parte do caminho crítico, significando que qualquer atraso no processo de aquisição provocará
o atraso do projeto inteiro. Mesmo os recursos que não se encontram nesse caso podem provocar
problemas em cascata se não estiverem disponíveis no momento certo. Por isso, a qualidade das
estimativas de prazo das aquisições influencia fortemente a qualidade do planejamento do projeto
como um todo e deve receber atenção proporcional a esse potencial de provocar danos.
Cada item da lista de aquisições deve ter o seu prazo de obtenção avaliado, desde o início da
preparação para a licitação até a colocação do recurso à disposição do usuário. E cada estimativa
deve ser associada a uma margem de erro, proporcional à qualidade das informações utilizadas
(como referência para determinação de erros de estimativas, recomendamos os padrões da AACE).
É normal que o planejamento comece com estimativas de menor confiabilidade, no entanto, por
outro lado, é imperativo que essas estimativas sejam refinadas no menor prazo possível, até um nível
de erro considerado aceitável para a tomada de decisões e o controle do projeto.
As estimativas de prazo de obtenção devem ser transferidas para o cronograma do projeto,
passando a fazer parte do prazo total de realização da entrega à qual o recurso atende. À medida que
o planejamento for refinado, as estimativas globais devem ser substituídas por sequências de
atividades, com estimativas de prazo e margens de erro específicas. Essa transferência deve ser feita
tomando por base a data mais cedo de necessidade do objeto no projeto (montagem de um
equipamento, por exemplo, ou início de um dado serviço) e desdobrando o processo de aquisição
para montante a partir daí. A data mais cedo de encerramento do processo de obtenção coincide
com a data mais cedo da necessidade do recurso.

97
QUANTO nos custará o que precisamos?
Deve ser elaborada uma estimativa do custo de obtenção para cada item da lista de aquisições,
seguindo os mesmos princípios da estimativa de prazos (o custo estimado é o do processo de
obtenção, já o preço do recurso é uma parte desse custo). Os custos das aquisições têm impacto tão
significativo sobre o projeto quanto os prazos, dado que podem corresponder à maior parte do
orçamento. A importância de estimá-los com qualidade não precisa, acreditamos, ser enfatizada. As
estimativas de custos devem ser transferidas para o plano de contas do projeto, passando a fazer
parte do orçamento do mesmo.
Cabe notar, tanto para os custos quanto para os prazos, que as estimativas elaboradas pelo
grupo de aquisições, nessa fase, podem entrar em desacordo com estimativas anteriores preparadas
durante os estudos de viabilidade do projeto. Nesse caso, é preciso identificar os pontos de
discrepância e comparar as fontes de informação para manter no planejamento a estimativa de
maior qualidade. Esse exercício deve ser feito o mais rapidamente possível, dado que a própria
continuação do projeto pode ser rediscutida caso prazos e valores maiores do que os inicialmente
previstos sejam levantados com fundamento pelo grupo de aquisições.

QUAIS os riscos que corremos ao adquirir o que precisamos?

A partir das informações anteriores, é possível iniciar a identificação e a avaliação dos riscos
presentes em cada processo de aquisição. Fatores como prazos longos, custos elevados,
complexidade técnica, inovação, propriedade intelectual, necessidade de sigilo, quantidade e
localização de fornecedores, etc. devem ser observados e, se for o caso, relacionados como ameaças
ou oportunidades na obtenção de cada recurso. Nesse exercício, convém utilizar os critérios
definidos para a gestão de riscos do projeto. Caso tais critérios não estejam disponíveis ou se
mostrem complexos demais para a finalidade desejada, é possível efetuar uma análise qualitativa dos
riscos com aplicação de escalas de probabilidade e impacto pré-definidas. Recomenda-se o apoio de
especialistas nessa etapa do trabalho.
Os riscos são dinâmicos e a sua avaliação deve ser revista periodicamente, à medida que o
trabalho avança. Os resultados devem ser transferidos para o mapa de riscos geral do projeto. As
ações mitigatórias que vierem a ser definidas devem ser acompanhadas sistematicamente pela
gerência do projeto.
O conjunto de informações vistas constitui um documento-chave de planejamento e controle
do projeto chamado “quadro de aquisições”. A integração entre esse documento, a EAP, o
cronograma e o orçamento é necessária para um gerenciamento eficiente do projeto. Não é demais
lembrar que a maioria dos resultados do projeto é criada por meio e dentro dos contratos de
fornecimento de bens e serviços – os atrasos e os custos extras não acontecem no cronograma ou no

98
orçamento, mas se originam na realização daqueles contratos. Integrar os contratos com os
elementos-chave de controle do projeto é altamente benéfico, mesmo indispensável, para assegurar
a qualidade do controle e maximizar as chances de sucesso.
O quadro de aquisições é o elemento principal para a complementação do planejamento das
aquisições. Partindo do conteúdo do quadro, que representa o escopo de trabalho do grupo de
aquisições (seja ele do projeto ou do departamento de compras), é preciso avaliar aspectos como:
Equipe – quantas pessoas, com quais perfis de competência, serão necessárias para realizar
o trabalho delineado no quadro de aquisições? Essas pessoas deverão ser mobilizadas por
quanto tempo? Quais treinamentos deverão ser ministrados? Elas serão alocadas ao projeto
ou pertencerão ao setor especializado da organização hospedeira?
Procedimentos – quais procedimentos de trabalho serão utilizados pelo grupo? Quais já
existem e quais deverão ser elaborados?
Desempenho – quais os indicadores a serem utilizados para medir o desempenho do
gerenciamento das aquisições? Como serão efetuadas as avaliações externas?
Comunicação – quais relatórios deverão ser emitidos? Qual o conteúdo, a periodicidade,
o veículo e os destinatários de cada um? Como será efetuada a segurança da informação?
Como será efetuado o arquivamento do acervo ao final do projeto?
Recursos – qual a infraestrutura necessária ao trabalho do grupo? Essa infraestrutura está
disponível ou também deverá ser adquirida?

Essas informações, a exemplo daquelas levantadas no quadro de aquisições, também devem

ser transferidas para as áreas de gestão respectivas (plano de comunicação do projeto, por exemplo).
Tal interação, realizada em conjunto com as demais áreas de gerenciamento, é indispensável para
que o projeto venha a ter um planejamento consistente que sirva de base para uma execução e
controle eficazes. Concluída essa etapa, e com a ressalva de que todo planejamento é dinâmico e
deve ser mantido permanentemente atualizado, o trabalho de campo pode começar. Tem início a
grande etapa de busca.

Processos licitatórios
No contexto das aquisições, buscar significa obter respostas do mercado, analisá-las e tomar
uma decisão de compra. Partindo do quadro de aquisições, essa atividade se desdobra em um
processo licitatório para cada item da lista. Há várias maneiras de conduzir esses processos, de
acordo com a natureza e o valor de cada aquisição e dentro do marco normativo da organização
hospedeira. Tipicamente, uma aquisição de bens ou serviços segue um roteiro de quatro passos:
pré-seleção de fornecedores, elaboração do termo de referência, obtenção de propostas e análise de

99
propostas. Eventualmente, o primeiro passo pode ser suprimido se a organização já possuir um
cadastro de fornecedores homologados para participar das suas licitações ou se as normas internas
da organização determinarem que isso não seja feito (caso típico das organizações públicas).
Passemos em revista, sucintamente, cada um deles.

Pré-Seleção de fornecedores
Nesse passo, o grupo de aquisições deve identificar quem pode, quem quer e quem está apto
a fornecer o objeto licitado. Quem pode são os fornecedores que oferecem o objeto no mercado;
quem quer são aqueles que, além de oferecer o objeto, têm interesse em fornecer; aptos estão aqueles
que, podendo e querendo, atendem às condições mínimas definidas no edital e em normas e
regulamentos aplicáveis.
O conhecimento do mercado, indispensável a qualquer equipe de aquisições, permite
identificar os fornecedores potenciais de um dado objeto. De acordo com a estratégia de aquisições
definida no planejamento, a busca desses fornecedores poderá (ou não) ser restrita ao mercado
nacional, ou apenas ao internacional, ou ainda a empresas com determinadas características, etc.
Quanto mais fornecedores houver, maiores são as chances de se obter um bom resultado na
contratação, por isso, é importante não se ater apenas aos fornecedores já conhecidos e buscar
sempre novas opções.
Pelo menos para as aquisições de maior risco, é prudente fazer contato o mais rapidamente
possível com os fornecedores identificados para confirmar se, de fato, têm a capacidade esperada e
o interesse de, eventualmente, fornecer o que desejamos. Para isso, usa-se um Pedido de
Informações ou Request For Information (RFI), abrindo um canal de comunicação com o
fornecedor, informando-o das condições gerais da futura aquisição (especialmente, quantidades e
prazos, ainda que preliminares) e solicitando confirmação da possibilidade de atendimento e do
interesse em participar do processo licitatório. As respostas serão orientadoras desse processo e
funcionam como um primeiro filtro de pré-seleção. Essa consulta deve ser feita mesmo a
fornecedores já cadastrados ou homologados, já que as condições de fornecimentos previstas podem
não ser compatíveis com as possibilidades do fornecedor naquele momento, obrigando-o a declinar
do certame. Do ponto de vista do risco, quanto mais cedo esse tipo de situação for conhecido
melhor será administrado o processo de aquisição daquele objeto.
O resultado desse primeiro esforço gera uma lista provisória de fornecedores que se classificam
em duas categorias: aqueles já conhecidos, cadastrados ou homologados, e os desconhecidos. Pelo
menos nas aquisições de maior risco, não é aceitável incorporar fornecedores mal conhecidos no
processo. Nesse contexto, surge a necessidade de adquirir conhecimento e um grau mínimo de
confiança nesses fornecedores para aceitar a possibilidade da sua futura contratação. A maioria das
organizações envolvidas com contratações frequentes trata essa questão homologando os

100
fornecedores, seguindo um procedimento praticamente padronizado: uma visita técnica realizada
por especialistas para avaliar a capacidade de realização do fornecedor, e uma visita comercial
realizada por gestores para avaliar a qualidade da organização e a capacidade do fornecedor em
cumprir compromissos contratuais. Sendo os resultados satisfatórios, o fornecedor é aceito como
homologado ou cadastrado.
Organizações que realizam o cadastramento ou a homologação de forma sistemática
normalmente estabelecem como restrição ao projeto que os processos licitatórios sejam realizados
apenas com fornecedores constantes desse cadastro (exceções sendo tratadas caso a caso). A
legislação brasileira mais recente (BRASIL, 2016, artigo 36)7 autoriza empresas públicas e de
economia mista a efetuarem a pré-qualificação de fornecedores, dentro de determinadas condições.

Termo de referência
O grupo de aquisições deve elaborar a documentação a ser enviada aos futuros licitantes para
que esses possam preparar suas propostas. Essa documentação varia de acordo com o objeto,
podendo ser tão simples quanto um e-mail contendo alguns poucos requisitos ou tão complexa
quanto um diretório com muitos megabites de arquivos carregados de informações sofisticadas.
Genericamente, as informações devem ser organizadas em duas categorias: as descritivas do objeto
a ser adquirido e as descritivas das condições de aquisição do objeto. O conjunto das informações
pode receber muitos nomes (Edital, Convite, Pedido de Proposta, Request for Proposal, Tomada de
Preço, etc.). Genericamente, vamos chamá-lo de Termo de Referência.
As informações descritivas do objeto são reunidas em um documento (ou coletânea de
documentos) chamado Especificação e contendo as informações necessárias para o correto
entendimento do objeto pelos licitantes. Pode incluir qualquer tipo de documento necessário, desde
que respeite alguns critérios:
Objetividade – só é requisito o que se pode medir e verificar, de modo que não há espaço
para subjetividade em uma especificação. Se não é possível definir, adequadamente, um
requisito, é melhor não o incluir.
Neutralidade – uma especificação deve, tanto quanto possível, definir o que se deseja
sem direcionar a resposta. Há casos em que um produto específico deve fazer parte do
objeto e, nesse caso, deve ser citado. No entanto, esses casos devem ser limitados ao
mínimo indispensável.

7
Lei nº 13.303/16 – Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13303.htm Acesso em: 9
jun. 2019

101
 Viabilidade – uma especificação deve ser plenamente compreensível e viável para os
licitantes (por exemplo, exigir o atendimento a uma norma à qual os fornecedores não
têm acesso nega viabilidade à licitação).

A Especificação é redigida por especialistas, mas o grupo de aquisições deve efetuar uma
análise crítica do documento para assegurar sua consistência com o restante da documentação e
com o próprio projeto antes de liberá-la para os licitantes.
As informações descritivas das condições de aquisição, por sua vez, organizam-se em
condições de habilitação, condições de participação e condições de contratação. As condições de
habilitação correspondem aos requisitos que o fornecedor deve atender para qualificar-se a
participar do certame. São condições de habilitação típicas:
cadastramento ou homologação prévio;
apresentação de garantias (seguros, cartas de crédito, performance bonds);
apresentação de demonstrativos de regularidade fiscal (certidões, declarações);
apresentação de demonstrativos de regularidade comercial (balanços, atestados) e
apresentação de demonstrativos de capacitação (posse de equipamentos especiais,
qualificação da equipe, acesso a tecnologias, consórcios).

As condições de participação definem as regras da licitação. Tipicamente, tratam de:

agenda do processo;
documentação a ser apresentada pelos licitantes;
modelos de documentos a serem utilizados;
procedimentos de comunicação;
critérios de avaliação de propostas;
condições de desqualificação de licitantes e
apresentação de embargos, impugnações ou recursos.

As condições de contratação apresentam os elementos principais do futuro contrato a ser

assinado pelo licitante vencedor (minuta de contrato). Essa minuta deve abranger todos os itens de
atendimento obrigatório no contrato e aqueles que contribuem para os custos do fornecedor (por
exemplo, um fornecedor que deverá colocar uma equipe trabalhando nas dependências do
contratante precisa saber que essa equipe deverá respeitar normas de segurança ou de meio ambiente
cujo atendimento pode custar dinheiro). São elementos típicos de uma minuta de contrato:
obrigações do contratante e do contratado;
normas aplicáveis (não relativas ao objeto);
regras de medição e faturamento;

102
 tratamento tributário;
critérios de reajuste;
penalidades e bonificações;
cláusulas rescisórias;
sigilo;
propriedade intelectual;
regras de fiscalização do contrato;
condições de aceitação do escopo e
condições de encerramento do contrato.

Obtenção de propostas
A obtenção das respostas dos fornecedores pode seguir vários procedimentos, dependendo,
basicamente, da complexidade da aquisição. Para os objetos mais simples, como itens de prateleira
ou commodities, uma tomada de preço para decisão puramente financeira pode ser adequada. Para
isso, o pregão eletrônico (também conhecido como leilão reverso) é o método atualmente mais
indicado, sendo inclusive considerado preferencial pela legislação brasileira (BRASIL, 2016). Nele,
os fornecedores recebem o Termo de Referência, cadastram-se e, em seguida, participam de um
leilão em um sítio da Internet cujo vencedor é aquele que oferece o menor preço. Sendo um leilão
fechado, cada licitante coloca o seu preço e o resultado é anunciado em seguida. Sendo aberto, os
licitantes podem fazer lances, e o vencedor é o licitante que oferecer o menor preço dentro do tempo
de leilão. Apesar de considerado muito seguro, esse método pode ser burlado por cartelização ou
direcionamento da consulta, e o grupo de aquisições deve acautelar-se contra essas possibilidades.
Da mesma forma, deve ser evitado o uso desse método para objetos complexos, nos quais a decisão
não deve ser tomada com base apenas em preços. Nesses casos, a melhor alternativa é uma licitação
tipo técnica-preço. Nela, os fornecedores são convidados a apresentar propostas técnicas-comerciais,
respondendo ao Termo de Referência, para permitir análise e seleção posterior. Esse é o modelo
clássico para objetos de complexidade técnica média ou alta, longo prazo de entrega, custo médio
ou alto em relação ao orçamento do projeto, riscos de obtenção médios ou altos. Por ser mais
complexo, detalharemos esse método a seguir. Certamente, os detalhes operacionais podem variar
muito de uma organização para outra, mas os elementos básicos são praticamente universais.
O grupo de aquisições deve comunicar aos fornecedores o início do processo licitatório. A
partir daí, inicia-se um período de interações entre o grupo e os fornecedores que responderem à
convocação, agora alçados à categoria de licitantes. A duração desse período é definida no próprio
instrumento convocatório, e a agenda deve ser cumprida com rigor. Durante esse período, o grupo
deve manter especial cuidado com três aspectos: o tratamento isonômico aos licitantes, de modo a

103
evitar situações de favorecimento; o apoio aos licitantes no sentido de lhes dar as melhores condições
possíveis para preparar propostas de boa qualidade; o controle da comunicação.
O risco de favorecimento não apenas pode pôr a perder todo o processo de aquisição, com os
impactos previsíveis no projeto, como pode destruir carreiras e reputações, às vezes, injustamente.
Esse risco deve ser evitado por meio do respeito aos procedimentos licitatórios, da documentação e
rastreabilidade do processo, e de uma atitude de distanciamento cortês em relação aos licitantes.
Essa atitude deve ser combinada com ações de apoio, tais como:
definição de pessoas do grupo responsáveis por sanar dúvidas dos licitantes, e centralizar a
comunicação nelas;
organização de reuniões de esclarecimento;
fornecimento de informações adicionais sempre que necessário e
organização de visitas técnicas.

O controle da comunicação consiste em estabelecer protocolos para troca de informações entre

as partes e aplicá-los sistematicamente, não aceitando exceções. Alguns desses protocolos tratam de:
documentação e rastreabilidade de todas as comunicações;
divulgação das informações a todos os licitantes e
controle das revisões dos documentos licitatórios.

Convencionalmente, o processo licitatório se materializa pela entrega do Termo de

Referência aos licitantes em evento presencial (público ou privativo) e pelo recebimento das
propostas da mesma forma. Atualmente, esse método está sendo rapidamente substituído por
ambientes virtuais que reproduzem o roteiro presencial, porém oferecendo diversas vantagens.
Talvez, a principal seja a capacidade de conduzir processos licitatórios internacionais sem
necessidade de deslocamento de equipes e minimizando o problema do fuso horário. A rapidez da
troca de informações e a segurança na rastreabilidade das comunicações são outro grande benefício.
O grande obstáculo que dificultou durante muito tempo a adoção dessa tecnologia, a necessidade
de assinatura de documentos, já foi superado pela técnica da certificação digital. Recomendamos
que, na medida do possível, pelo menos os processos de aquisição principais sejam conduzidos com
apoio dessas tecnologias.
Como exemplo de regras de um conjunto de critérios para processos licitatórios, a seguir,
vejamos os cinco princípios que uma instituição financeira (CAF) adota para os projetos que realiza:
1. O mutuário deverá realizar uma licitação pública internacional para a aquisição de bens
cujo valor exceda o equivalente a US$ 500.000,00 (quinhentos mil Dólares), bem como
em caso de contratação de obras e de serviços de engenharia com valores que excedam o
equivalente a US$ 2.000.000,00 (dois milhões de Dólares). Os editais de licitação

104
 deverão apresentar ampla divulgação nos moldes legais, possibilitando assim a eficiência,
a transparência e garantindo a alta competitividade do processo licitatório.
2. Em situações especiais de contratações que tenham por objeto valores superiores aos
mencionados no parágrafo anterior, poderá ser utilizada a licitação pública nacional desde
que, por motivos de ordem técnica, forem devidamente justificadas pelo mutuário e
autorizadas, prévia e formalmente, pela CAF.
3. Para aquisições de bens de até o equivalente a US$ 500.000,00 (quinhentos mil
Dólares), ou no caso de contratação de obras e serviços de até o equivalente a
US$ 2.000.000,00 (dois milhões de Dólares), o mutuário aplicará regras e
procedimentos de licitação pública nacional.
4. Para contratações de consultorias, cujos valores excedam o equivalente a US$ 250.000,00
(duzentos e cinquenta mil Dólares), o mutuário aplicará procedimentos de licitação
pública internacional. Para contratações inferiores ao equivalente a US$ 250.000,00
(duzentos e cinquenta mil Dólares), o mutuário aplicará regras e procedimentos de
licitação pública nacional.
5. Publicidade – nos Certames e nas Competições Públicas Internacionais, os mutuários e
as agências de execução publicarão as notificações correspondentes em, pelo menos, 2
(dois) jornais de circulação nacional, respeitando também os requisitos das
regulamentações locais aplicáveis. Para todos os outros casos, os Mutuários e as agências
de execução informarão a CAF do procedimento antes de solicitar o concurso ou o
concurso de seleção.

Análise de propostas
Recebidas as propostas dos licitantes, o grupo de aquisições deve analisá-las e decidir sobre
qual delas melhor atende ao projeto. Isso requer, mais uma vez, um procedimento formal e
objetivo ainda que se trate de uma tomada de preço para um objeto simples. Não é viável decidir
um certame que envolve os interesses do projeto, da organização hospedeira, do cliente, de vários
fornecedores, de órgãos de controle, etc. de forma subjetiva (vale dizer, arbitrária). Há muitas
maneiras de organizar esse passo do processo, mas todas seguem, de modo geral, o mesmo roteiro
básico: análise dos requisitos eliminatórios; análise dos requisitos classificatórios técnicos e análise
dos requisitos comerciais.
Os requisitos eliminatórios são aqueles cujo não atendimento implica a saída do licitante do
certame. As condições de habilitação constituem requisitos eliminatórios típicos, mas também há
requisitos técnicos e comerciais que podem ter essa característica. Se a especificação define o
material de uma tubulação como sendo obrigatoriamente aço inox e o fornecedor oferece outro
material qualquer, ele deve ser eliminado por insuficiência técnica; se o prazo máximo de realização

105
de um serviço é especificado como doze meses e o fornecedor oferece quinze, temos a mesma
situação. No entanto, é preciso cuidado para não interpretar como eliminatórios requisitos que
admitem uma faixa de variação para atendimento. No exemplo acima, o prazo só seria eliminatório
se os doze meses requeridos fossem efetivamente o limite aceitável para o projeto. Caso contrário,
melhor seria considerar os doze meses como referência e classificar os fornecedores conforme seu
posicionamento em relação a esse prazo.
É boa prática informar no Termo de Referência quais requisitos são eliminatórios e qual o
método de análise de propostas será utilizado.
Os requisitos classificatórios são, evidentemente, todos os que não forem enquadrados como
eliminatórios. Dividem-se em dois grandes grupos: técnicos e comerciais. Podem ser analisados
separadamente ou não, de acordo com o marco normativo da organização ou os procedimentos
adotados pelo projeto. O critério de análise deve respeitar o critério de tomada de decisão já
comentado: menor risco para o projeto. Isso significa que não se trata de selecionar,
automaticamente, a de menor preço; trata-se de identificar, previamente, uma combinação de
fatores técnicos e comerciais que represente a solução mais adequada para o projeto e, daí, comparar
as propostas usando essa combinação como referência. Nesse sentido, pode ocorrer (e ocorre) que
o menor preço seja o melhor critério. No entanto, essa decisão deve decorrer das características da
aquisição. A proposta que mais se aproximar da referência adotada (ou superá-la) será, em princípio,
a mais adequada.
Uma das maneiras mais adequadas de colocar em prática esse princípio é usar técnicas de
análise multicritério, especialmente a mais conhecida delas, o Procedimento de Análise Hierárquica
(AHP). Como exemplo, consideremos que todos os requisitos classificatórios de uma licitação
possam ser reunidos em cindo grupos: preço, prazo, qualidade, quantidade e serviços (itens como
reajustes de preço e condições de pagamento ficam no grupo preço; itens de desempenho do objeto
caem no grupo qualidade, e assim por diante). De acordo com o objeto que estiver sendo adquirido
e com as condições do mercado, define-se a importância relativa entre cada par dos cinco grupos e
calcula-se a importância relativa de cada um segundo o algoritmo AHP8. Em situações simples, a
análise pode ser realizada com eficiência apenas com a ponderação dos grupos. Para objetos mais
complexos, podemos realizar o mesmo cálculo para os requisitos reunidos sob cada grupo9, de forma
que cada requisito será duplamente ponderado, oferecendo uma qualidade de análise superior. A

8
Se aplicarmos esse critério à compra de mil sacos de cimento comum, o atendimento aos requisitos de prazo, qualidade,
quantidade e serviços não deverá ser problema para os fornecedores, de modo que o grupo preço, provavelmente, receberá
o maior peso e terá maior importância. Na prática, isso significará uma compra pelo menor preço. No entanto, se estamos
contratando uma consultoria altamente especializada e de cujo trabalho dependem muitas outras coisas no projeto, os
maiores pesos cairão sobre serviços e qualidade. A proposta mais adequada não será, necessariamente, a mais barata.
9
Se tivermos quinze requisitos no grupo qualidade, por exemplo, qual será a importância relativa de cada um?

106
correta atribuição dos pesos é crucial para que o resultado da análise indique a proposta efetivamente
mais adequada. Erros nesse algoritmo podem criar riscos desnecessários e sérios para o projeto. A
aplicação do algoritmo deve ser feita, evidentemente, antes do recebimento das propostas, e a
validação do modelo pela hierarquia do projeto é indispensável para legitimar a futura escolha do
vencedor da licitação.
A análise multicritério é a ferramenta mais indicada para comparar elementos díspares como
o reajuste de um preço e o nível de serviço especificado para a assistência técnica, por exemplo. Para
maiores detalhes sobre AHP, recomendamos o material de leitura complementar dessa Unidade.
O segundo elemento da análise é uma escala de pontuação que permita posicionar a resposta
de um licitante em relação à referência do Termo de Referência. São usadas desde escalas conceituais
simples (atende, não atende, atende parcialmente) até escalas numéricas mais elaboradas. Uma
técnica eficiente é a escala numérica de zero central, em que a atribuição do valor zero à resposta do
fornecedor significa o atendimento pleno ao requisito, enquanto valores positivos à direita
representam respostas acima do mínimo estabelecido e valores negativos à esquerda mostram a
situação inversa. Avaliando dessa forma todas as respostas de uma dada proposta, é possível atribuir
uma nota a cada quesito multiplicando a pontuação pelo peso do mesmo (obtido pelo método
AHP). A média das notas forma o índice de conformidade da proposta. Particularmente, se uma
proposta obtiver índice zero ela terá atendido a todos os requisitos classificatórios dentro do mínimo
ou dos valores de referências especificados. Quanto mais positivo for o índice mais além desse
mínimo a proposta se coloca, e índices negativos significam atendimento insuficiente.
Realizando esse exercício para cada uma das propostas qualificadas teremos uma indicação
satisfatória sobre o grau com que cada uma atende às necessidades do projeto (e sempre dentro da
lógica do menor risco). Esse método possui as qualidades de ser objetivo, demonstrável e rastreável,
mas não é cirurgicamente exato – sempre há margem para alguma interpretação, o que recomenda
seu uso com a devida cautela.
Se a diferença de índices entre os licitantes for significativa, o vencedor pode ser escolhido
com base apenas nesse resultado, ao passo que, se essa diferença for pequena, é provável que
tenhamos um resultado inicial intermediário em que será possível apenas identificar os melhores
colocados. Nesse caso, podemos usar critérios de desempate como a pontuação obtida nos requisitos
mais importantes, uma solicitação de informações complementares sobre alguns requisitos para
permitir um melhor entendimento e revisão de notas e, por fim, a submissão de um resultado de
empate técnico à hierarquia do projeto para tomada de decisão.
De todo modo, o uso desse método ou de outros semelhantes é condição básica para que o
processo licitatório seja concluído de modo satisfatório. Cabe lembrar que os licitantes têm direito
à contestação dos resultados, e a melhor maneira de evitar esse contratempo que pode causar sérios
inconvenientes ao projeto é um procedimento transparente e defensável.

107
 Com a seleção do vencedor, a licitação deve ser encerrada formalmente com a respectiva
informação e agradecimento aos participantes. Agora, estamos prontos para entrar na terceira etapa
do processo de aquisição: a contratação.

Modelos de contratos e a sua aplicação

Um contrato é um acordo entre duas partes no qual uma delas tem uma necessidade e está
disposta a adquirir uma solução, dando algo em troca, e a outra possui a solução e está disposta a
cedê-la mediante uma contrapartida. Contratos podem ser explícitos ou não, escritos ou verbais, no
entanto, no ambiente de um projeto, só devem ser utilizados contratos formais escritos.
A princípio qualquer acordo entre as partes é válido desde que não seja ilegal, e a prática já se
encarregou de desenvolver os melhores modelos de contratos para cada tipo de aquisição. O estrito
enquadramento legal, obrigatório, faz com que nessa etapa do processo o grupo de aquisições deva
ser assessorada por especialistas do Direito, de modo a assegurar que o acordo firmado sobre requisitos
técnicos e comerciais seja respaldado por uma peça jurídica capaz de proteger os interesses da ambas
as partes dentro dos marcos pertinentes. Nesse ponto, convém comentar brevemente esses marcos.
Primeiramente, temos a legislação. No Brasil, os contratos entre particulares (entes do direito
privado) são regulados, em primeiro nível, pelo Código Civil (BRASIL, 2002). Os contratos
administrativos (firmados entre o Estado e os particulares) obedecem à Lei 8.666/1993 (BRASIL,
1993)10 e à Lei 13.303/2016 (BRASIL, 2016)11. A discussão desses marcos legais foge ao escopo
desse curso, mas cabem algumas observações:
a) O ente privado tem o direito de organizar os seus processos licitatórios como lhe convier
(inclusive não usar essa técnica de aquisições), mas o ente público é obrigado a seguir o
rito da concorrência, devendo ater-se às regras estipuladas na legislação.
b) Na contratação, ambos devem respeitar os respectivos marcos legais, mas o público é bem
mais específico do que o privado.
c) Não obstante as diferenças processuais, os princípios públicos e as boas práticas privadas
são muito semelhantes. O roteiro de licitação comentado no tópico Processos licitatórios,
por exemplo, é típico do serviço público, sendo adotado livremente por muitas
organizações privadas por ser reconhecido como eficiente. Outros princípios como o da
aderência ao edital (só se pode adquirir o que está especificado no documento de
consulta), a isonomia (nenhum fornecedor pode ser favorecido em relação aos demais), a
impessoalidade (o grupo de aquisições é o agente da transação, não o proprietário do
objeto adquirido) e outros, de observância obrigatória no ente público, são igualmente

10
Disponível em: http://www.planalto.gov.br/ccivil_03/leis/l8666cons.htm Acesso em: 9 jun. 2019.
11
Disponível em: http://www.planalto.gov.br/ccivil_03/_ato2015-2018/2016/lei/l13303.htm Acesso em: 9 jun. 2019

108
 reconhecidos como importantes no meio privado e aparecem em muitas normas internas
de compras e de compliance de grandes empresas.
A legislação também se preocupa em definir categorias de contratos e estabelecer regras
específicas para cada uma, criando um arcabouço mínimo que dê consistência jurídica aos
contratos. Desse modo, podemos distinguir contratos de compra e venda (usados quando a
propriedade de um bem é transferida do vendedor para o comprador mediante uma contrapartida),
contratos de locação (cessão do direito de uso mediante contrapartida), contratos de empreitada (o
objeto contratado passa a existir em função do contrato), e assim por diante. Sobre essa base jurídica
o mercado, com base na experiência acumulada, desenvolve modelos de contrato específicos para
determinados tipos de produto, segmento de atividade, etc.12
O tipo de contrato a ser utilizado é, normalmente, definido no Termo de Referência. Para
isso, o grupo de aquisições precisa, antes, avaliar diversos fatores. Alguns são estratégicos, como
disponibilidade de capital, capacidade gerencial, políticas de sigilo e similares, e outros específicos,
como o grau de definição do objeto, a situação do mercado e as peculiaridades de cada segmento
do mercado. Esse conjunto de fatores leva à seleção do modelo mais indicado, considerando as
categorias jurídicas e os aspectos gerenciais. Entre esses, o mais importante é o critério da
transferência de risco, segundo o qual cada parte tentará sempre transferir a maior parcela possível
dos riscos do contrato para a outra. Nesse sentido, o bom contrato é o que consegue o equilíbrio
entre as possibilidades e os interesses de ambas as partes. Contratos desbalanceados ou mal
selecionados distribuem obrigações e responsabilidades de forma desproporcional, aumentando
muito a probabilidade de falha (às vezes, tornando-a inevitável). Esse critério trabalha com a noção
de que o risco pode ser inserido no contrato de duas formas: a estruturação e a formação do preço.
O preço de um bem ou serviço, segundo essa noção, deve incluir sempre uma parcela de
contingência que corresponda à percepção do risco do fornecedor. Essa parcela será tanto maior
quanto maior for o risco assumido por ele, e vice-versa, variando entre limites que dependem do tipo
de objeto e das condições de fornecimento. Um fornecedor pode se recusar a apresentar proposta ou
firmar contrato caso considere que o risco transferido para ele é excessivo, e um dos elementos centrais
da negociação do preço de um contrato é o valor da contingência. Nessa negociação, o tema é a
transferência de risco entre contratado e contratante; o valor da contingência é consequente.
A estruturação do preço pode ser sintetizada em uma classificação simples – aliás, adotada
pelo PMI –, segundo a qual todo contrato se enquadra em três tipos básicos (passíveis de
combinações): contratos de preço fixo, de preço unitário e de preços administrados. A relação entre
esses três tipos e a transferência de riscos entre as partes é mostrada na figura a seguir.

12
Um contrato de serviços de TI tem uma estrutura característica que difere do um contrato de serviços de manutenção
industrial, por exemplo, embora ambos sejam contratos de empreitada.

109
 Figura 43 – Transferência de riscos entre contratante e contratado

Um contrato de preço fixo é aquele em que o preço do objeto está definido no momento da
sua entrada em vigor (preço fixo não deve ser confundido com preço à vista nem com preço
irreajustável). Esse tipo de contrato requer que o objeto e as condições de fornecimento estejam
bem-definidos e é, normalmente, preferido pelo comprador (sendo por isso, muitas vezes, adotado
erroneamente). O risco assumido pelo fornecedor ao fixar o preço de um objeto que pode ainda
não existir (um equipamento fabricado sob encomenda ou uma obra, por exemplo) é compensado
pela boa definição contratual e pelo preço mais elevado (contingência).
Se o objeto e as condições de fornecimento possuem indefinições ou estão sujeitos a
mudanças, um contrato de preço fixo, provavelmente, trará mais dificuldades do que benefícios e
o preço poderá ser elevado além do razoável. Nesse caso, entra em cena o contrato de preço unitário,
também conhecido como tempo e material: em vez de fixar um preço global para o objeto, esse
contrato define tarifas, ou seja, preços parciais para partes ou etapas definidas do escopo contratado
(preço por metro quadrado de piso colocado, ou preço da hora trabalhada de um profissional).
O valor devido pelo contratante é o produto da tarifa pelo resultado medido durante um
período de tempo. Essa solução retira do fornecedor um risco que seria excessivo se ele tivesse que

110
assumir um preço prefixado e ajuda a manter o custo total mais baixo com o controle da
contingência. O preço unitário não significa que o contrato não possua um valor; apenas esse valor
é referencial, não obrigatório. O valor final desse tipo de contrato só é conhecido no seu
encerramento, mas ele poderá ser encerrado antes da conclusão do escopo se os custos medidos
atingirem ou ultrapassarem, em certo limite, o valor de referência.
Se a incerteza sobre o objeto e as condições de fornecimento for muito alta e, mesmo assim,
a aquisição precisar ser feita, pode ser necessário utilizar um contrato de preços administrados ou
reembolsáveis. Dado o grau de indefinição, o contrato não possui um preço, mas uma referência
orçamentária. As despesas do fornecedor são medidas, comprovadas e reembolsadas pelo
contratante, acrescidas de uma taxa de administração definida em contrato. O risco para o
contratante é máximo, e mínimo para o fornecedor, por isso, o valor do contrato é menor do que
os dos outros tipos, para um mesmo escopo.
Outro ponto a ser levado em conta é o esforço gerencial associado a cada tipo de contrato.
Como regra geral, quanto menor a definição, maior o esforço. Na verdade, o menor preço obtido
em contratos de preços unitários ou administrados é compensado, ao menos em parte, pelo custo
interno do contratante. O grupo de aquisições deve incluir essa reflexão no seu planejamento,
particularmente no dimensionamento das equipes de administração dos contratos.
Projetos complexos podem decidir, como estratégia de realização, agrupar grande parte ou
mesmo todo o escopo em grandes contratos especiais. Normalmente, esses contratos são
combinações dos três tipos básicos descritos acima e se enquadram como empreitadas. Entre os
muitos tipos existentes, podemos citar quatro mais significativos:
a) Turn Key – é o contrato que absorve todo o escopo de um projeto, ou seja, a gestão do
projeto se torna, ao fim e ao cabo, a administração de um megacontrato. O risco para o
contratado é, obviamente, máximo, e o preço também será mais alto do que o de outras
modalidades de contratação. O contratante, por seu lado, corre o risco de perder o
controle sobre o projeto ao transferir todo o escopo a terceiros. No entanto, em
determinadas situações, essa opção pode ser justificada e gerar bons resultados.
b) Engineeering, Procurement, Construction (EPC) – em grandes projetos que envolvem a
implantação de ativos físicos complexos (unidades industriais, por exemplo), é usual que
uma parte considerável do escopo, envolvendo o projeto de engenharia, o fornecimento
de todos (ou quase todos) os materiais necessários para a criação do ativo, a sua construção
e montagem, e o seu comissionamento até a condição operacional, seja delegada a um só
fornecedor. O contrato EPC também coloca um risco bastante elevado para o fornecedor,
mas o contratante, ao permanecer responsável por partes do escopo (menores do que a
do fornecedor), pode ver-se na situação de ser gerenciado por ele. A administração de um
contrato EPC é complexa e requer alto grau de planejamento e capacidade gerencial de
ambas as partes.

111
 c) Engineeering, Procurement, Construction, Management (EPCM) – variação do contrato
EPC, em que o fornecedor se torna responsável pelo gerenciamento das funções EPC. O
cliente contrata essas funções de outras empresas e as coloca sob a responsabilidade do
fornecedor EPCM. O risco para esse fornecedor é mais baixo do que no EPC comum, e
o do contratante é proporcionalmente maior. No entanto, a transferência do esforço de
administração EPC para um fornecedor pode ser interessante para o contratante.
d) Contrato de Aliança – é possível quebrar o paradigma da transferência de risco adotando
modelos de contrato associativos, em que o risco passa a ser compartilhado pelas partes.
É o caso do contrato de aliança, também conhecido como Open Book, pelo fato de
requerer a apresentação de informações completas das duas partes para que o contrato
possa ser construído (a quatro mãos). Difere de um consórcio ou joint venture pelo fato
de a relação cliente-fornecedor ser preservada, dentro de condições de parceria. Substitui
os modelos EPC, EPCM e Turn Key, e possui um bom histórico de sucessos.

Práticas de administração de contratos

Com o contrato assinado, inicia-se a sua administração. Essa atividade tem por objetivo
assegurar que o objeto adquirido seja colocado à disposição de quem dele precisa, nas condições
especificadas, e que o acordo firmado com o fornecedor seja cumprido na íntegra. Para isso, a
administração do contrato envolve duas funções e quatro eixos de ação:
funções
relações contratuais – compreendem todo o trabalho necessário para assegurar o êxito
do contrato e cobrem os quatro eixos de ação, e
diligenciamento – busca assegurar a conformidade técnica do objeto à especificação
contratual.

Em contratos pequenos, uma só pessoa pode assumir as duas funções, no entanto, à medida
que o porte e a complexidade do contrato aumentam, torna-se necessário dividi-las entre um
Gerente de Contrato (GC) e um Fiscal. O primeiro tem perfil de competência gerencial, e o
segundo deve ser um especialista no objeto do contrato. Esses profissionais podem precisar de
auxílio, o que leva a equipes de administração contratual com dezenas de pessoas. Como já
comentado, o grupo de aquisições deve considerar esse fator no planejamento do trabalho.

112
 A equipe de administração do contrato precisa ter uma atitude adequada ao trabalho,
caracterizada por três diretrizes:
Respeito ao contrato – ele, os seus anexos e documentos complementares são as únicas
referências aceitáveis (além da legislação) para organizar e controlar o trabalho, bem como
para dirimir quaisquer dúvidas.
Respeito aos fatos – o ambiente do contrato é factual e objetivo, não devendo ser poluído
por opiniões e subjetividades. Se algo está apoiado em evidências, é inútil contrapor
vontades e palpites.
Respeito às pessoas – o contrato é impessoal e as equipes são agentes das suas
organizações. Os problemas devem ser tratados com rigor técnico e firmeza gerencial,
mas dentro de um ambiente de civilidade em que o tratamento respeitoso contribui para
a busca de soluções equilibradas.

Tal atitude é a base para uma administração bem-sucedida e deve ser adotada pelas equipes
de ambas as partes.

Eixo aderência
A aderência ao contrato é uma responsabilidade de ambas as partes, e consiste em assegurar
que o trabalho transcorra conforme as determinações contratuais. Não há espaço, no ambiente
contratual, para improvisações ou informalidades. As pessoas responsáveis pela execução de um
contrato devem segui-lo, simplesmente, e fatos novos ou imprevistos devem ser encaminhados por
meio dos procedimentos pertinentes. Naturalmente é possível interpretar a letra de qualquer
contrato, mas esse recurso deve ser usado com discernimento pelos seus gestores de modo a respeitar
o espírito com que o contrato foi negociado e assinado. Principalmente, o critério de análise e
decisão deve preservar o interesse do projeto, evitando a criação de riscos desnecessários.
Algumas das rotinas principais para assegurar a aderência são:
Medição e faturamento – praticamente, nenhum contrato de um projeto é pago à vista, e
a forma de pagamento é uma cláusula das mais importantes. A sua aplicação,
normalmente, requer um procedimento complementar que detalha o passo-a-passo
administrativo, e a sequência usual é a apresentação de um boletim de medição que, sendo
aprovado, autoriza o fornecedor a emitir uma nota fiscal de cobrança. O boletim (ou
documento equivalente) descreve as entregas que estão sendo medidas e o valor a pagar,
sendo instrumentado com todas as evidências necessárias para justificar a cobrança. O GC,
por sua vez, apoia-se nas informações dos especialistas para avaliar a medição, podendo
aceitá-la no todo ou em parte. Esse procedimento deve receber tratamento prioritário
dentro das rotinas administrativas, já que o atraso de pagamentos, além de irregularidade

113
 contratual passível de penalidades e pleitos, pode causar sérias dificuldades ao fornecedor
e, por via de consequência, ao próprio projeto.
Gestão de pendências – a execução de um contrato gera desvios que devem ser corrigidos
para que o escopo seja adequadamente realizado. Quando algo que deveria ter sido feito
não o foi ou apresenta uma não conformidade, temos uma pendência a ser sanada.
Pendências, por definição, afetam algum outro aspecto do trabalho (ainda que seja o aceite
final do escopo), e têm prazo de resolução e responsável definido. O GC deve manter um
registro de todas as pendências ocorridas no contrato e tomar as providências necessárias
para que não se tornem fonte de problemas em cascata, amplificando negativamente
situações que poderiam ser resolvidas com facilidade.
Ação de presença – nenhuma administração contratual é verdadeiramente eficaz se a equipe
do contratante não se fizer presente diante do fornecedor. Seja por meio de reuniões
regulares, visitas, diligências ou mesmo permanência no local de execução do contrato, essa
presença deve ser planejada e prevista no contrato. A presença do contratante, via de regra,
torna a execução do contrato mais ágil e segura, evitando ou resolvendo rapidamente
problemas que de outra forma tomariam um vulto indesejado e desnecessário.
Negociação – o cotidiano da execução de um contrato envolve o exercício constante da
interpretação dos pontos de dúvida, tomadas de decisão sobre dificuldades imprevistas,
ajustes de programação para absorver contingências, etc. Isso significa negociação entre as
partes, sob pena de tornar a administração do projeto praticamente inviável. O GC deve
compreender essa realidade e adotar não apenas uma postura adequada como preparar-se
para atuar dessa forma, estabelecendo, por exemplo, uma agenda de encontros com o
fornecedor para “passar a limpo” os assuntos correntes e revisar o progresso do contrato
(mesmo que não haja nada muito grave a tratar).

Eixo comunicação
A comunicação contratual é essencial para o êxito, e busca assegurar que as partes tenham plena
consciência da situação do trabalho e possam, a partir daí, atuar com eficiência na sua administração.
Além disso, partes interessadas do projeto podem requerer informações regulares do contrato para
fins legais ou de controladoria. Isso implica definir com clareza quais os protocolos de comunicação
a serem utilizados (relatórios, eventos de acompanhamento, redes de comunicação digitais) e assegurar
que os mesmos sejam adequadamente utilizados. A comunicação também deve lidar com o dilema
de preservar a segurança de informações, muitas vezes, confidenciais e, ao mesmo tempo, manter a
transparência de uma atividade particularmente sujeita a questionamentos e dúvidas sobre a lisura dos
procedimentos. Os relatórios de situação, registros de eventos e demais documentos de comunicação
devem ser calibrados para atenderem a essas necessidades de forma equilibrada.

114
Eixo alteração
Todo contrato está sujeito a sofrer alterações devidas ao surgimento de fatos novos ou não
conformidades ocorridas na execução do contrato e que não possam ser corrigidas. Processos de
aquisição bem conduzidos produzem contratos de boa qualidade que, se bem administrados,
provavelmente serão pouco alterados. O contrário pode gerar contratos com uma sucessão tal de
modificações que se tornam incontroláveis.
A alteração contratual não é negativa em si e deve ser tratada como um evento normal. Para
isso, é preciso que o contrato incorpore um procedimento para registrar, encaminhar e submeter à
aprovação as alterações propostas pelas partes. Esse procedimento segue um roteiro simples: a
proposta de alteração deve ser formal e fundamentada com suas justificativas e a avaliação dos
impactos que causará no projeto. A proposta é avaliada sobre sua viabilidade e aplicabilidade, sendo
aprovada ou não. Apenas alterações aprovadas podem ser implantadas, e sua incorporação ao
contrato é feita por meio de Aditivos Contratuais. Alterações contratuais realizadas e pagas sem o
aditivo correspondente caracterizam irregularidades sérias na administração contratual.

Eixo conflito
O ambiente de execução de um contrato é conflituado, o que não significa que seja
necessariamente agressivo. O conflito é inevitável, já que mesmo os melhores contratos não estão a
salvo de desvios na realização, de divergências de interpretação e mesmo de comportamentos
inadequados das partes. O GC deve estar preparado para identificar o conflito e agir o mais rápido
possível de modo a impedir o seu agravamento, preservando o contrato e o projeto de turbulências
que podem ter consequências graves. Deixando de lado conflitos de comportamento (que também
devem ser tratados com atenção), os conflitos oriundos de questões objetivas sobre a realização do
contrato são encaminhados sob a forma de pleitos, também conhecidos como claims.
Um pleito não deve ser confundido com uma alteração: essa é um episódio normal na vida
do contrato, aquele corresponde a uma anormalidade. Pleitos são reivindicações de uma das partes,
que se julga prejudicada nos seus direitos, visando obter compensações para o prejuízo que considera
ter sofrido ou estar sofrendo. Uma alteração mal gerenciada pode, eventualmente, dar origem a um
pleito, mas apenas isso. O pleito consiste em uma exposição de motivos, fundamentada com todas
as evidências necessárias, e em uma demanda de ressarcimento ou de ajuste de conduta pela parte
supostamente ofensora. É dirigido à hierarquia superior à do GC e constitui a última instância de
negociação antes do recurso a uma arbitragem ou processo judicial, por isso deve sempre ser
preparado com apoio de especialistas jurídicos. Via de regra, a negociação de pleitos produz acordos
para evitar o desgaste, a demora e as incertezas de uma pendência na Justiça. Pleitos também
precisam ser incorporados ao contrato por meio de aditivos.

115
 Lições aprendidas – o processo de aquisição e, em particular, a gestão do contrato geram
um aprendizado que não deve se perder. A equipe de aquisições deve implantar, desde a
fase de planejamento, um procedimento de lições aprendidas, e o gestor do contrato deve
utilizá-lo, estimulando também o fornecedor a fazê-lo. O conhecimento adquirido é uma
fonte principal de melhoria contínua para a organização.

Encerramento de contratos
O contrato deve ser encerrado de forma ordenada, e isso, de acordo com os marcos legais,
pode ocorrer de várias maneiras, nem todas positivas para o projeto. As principais são:

Encerramento a termo
Forma normal de encerramento contratual, que pressupõe o atendimento a quatro condições:
escopo completado e aceito;
pagamentos efetuados e reconhecidos;
regularidade fiscal e trabalhista e
ausência de negociações em aberto ou pendências judiciais.

Por princípio, todos os contratos do projeto devem ser encerrados dessa forma. Cabe notar
que a existência de negociações estende a vigência do contrato até a sua conclusão, o que pode, por
consequência, estender o período em que o GC, o grupo de aquisições ou mesmo o gerente do
projeto permanecem mobilizados. O encerramento do projeto também pode ficar pendente nesses
casos. Uma das soluções usuais, quando o contrato está sob responsabilidade direta do projeto, é
transferi-lo para o Departamento de Compras ou o Jurídico da organização hospedeira.

Rescisão
Encerramento antecipado e unilateral do contrato, por decisão de uma das partes após a outra
parte ter incidido em uma cláusula rescisória prevista no próprio contrato (inadimplência, atraso
excessivo, inidoneidade, por exemplo). Quando tal situação ocorre, a parte prejudicada passa a ter
o direito a rescindir o contrato, mas essa ação é uma escolha, normalmente tomada após negociações
e alguns passos preparatórios como cartas de advertência. A rescisão não é amigável e, via de regra,
tem desdobramentos judiciais. As partes, especialmente o GC e o grupo de aquisições, devem
procurar evitar ao máximo essa situação, já que ela representa tudo o que se deve evitar no projeto.

116
 O impacto do afastamento abrupto de um fornecedor pode significar a paralização e até a
inviabilização da continuidade de um projeto (exatamente aquilo que se pretendia evitar com todo
o esforço do gerenciamento de aquisições). Dependendo das circunstâncias, uma rescisão no meio
de um projeto pode ter consequências danosas, inclusive para as carteiras dos responsáveis
envolvidos. Isso posto, há casos em que a rescisão se torna inevitável e deve ser executada. O GC, o
grupo de aquisições e os responsáveis pelo projeto devem, por meio dos mecanismos de controle do
contrato e do projeto, identificar, o mais cedo possível, a possibilidade de uma situação rescisória
acontecer e preparar-se para enfrentá-la, elaborando soluções alternativas.

Resolução
Encerramento antecipado e imprevisto de um contrato por motivo de força maior. Aqui, as
partes não têm controle sobre o acontecimento e não podem ser responsabilizadas pela
inviabilização do compromisso assumido. É o caso de uma catástrofe natural, ou de um choque
econômico súbito e de alto impacto. Em muitos casos, a inviabilidade deve ser demonstrada antes
do encerramento por resolução ser confirmado. Em geral, é um evento amigável, mas sempre
negativo para ambas as partes. Quando o evento causador atinge apenas a parte contratada, o efeito
prático sobre o projeto é semelhante ao de uma rescisão, com o agravante da imprevisibilidade.
Resoluções contratuais costumam ser sinônimo de crise em qualquer projeto e devem, na medida
do possível, ser avaliadas no gerenciamento de riscos das aquisições.

Resilição
Encerramento antecipado por ato de vontade de uma ou ambas as partes. Há várias situações
possíveis para uma resilição, por exemplo, o distrato (desinteresse mútuo na continuação do
contrato), a renúncia (desistência de uma das partes, com abandono dos seus direitos contratuais)
e a denúncia (desinteresse de uma das partes, comunicado com antecedência em conformidade com
cláusula contratual). Os casos de resilição podem ter impacto variado sobre o projeto: alguns são
controlados (a denúncia, quando for iniciativa do projeto) e outros não. O impacto negativo de
uma resilição tende a ser menor do que o de uma rescisão ou resolução, no entanto, ainda assim,
são situações que devem ser evitadas na medida do possível.
O encerramento de um contrato requer a assinatura de um Termo de Encerramento, dando
plena quitação das obrigações de ambas as partes (não é o caso da rescisão, naturalmente). Em
projetos, há duas variações comuns que devem ser previstas pelo grupo de aquisições e pelo GC de
cada contrato. Vejamos a seguir.

117
Aceitação de escopo
Em contratos complexos, é frequente acontecer que o diligenciamento considere o objeto pronto
para ser recebido (escopo completo) enquanto há questões gerenciais em aberto (pleitos, por exemplo).
Nesses casos, podemos utilizar um termo de aceitação de escopo. Esse documento não encerra o
contrato, mas libera o objeto para ser incorporado ao projeto e citando eventuais paralizações ou atrasos.
Essa opção, conquanto muito útil em algumas situações, deve ser adotada com cautela e apenas quando
realmente necessário, já que podem surgir questões de custódia, responsabilidade técnica, transferência
de direitos e similares que se tornem problemas maiores do que os benefícios que se pretendia conseguir
com o aceite antecipado do objeto. É boa prática que um termo de aceitação de escopo seja preparado
pela assessoria jurídica do projeto, não apenas pelo grupo de aquisições.

Transferência de custódia
Alguns contratos incluem no seu escopo elementos que se estendem além do ciclo de vida do
projeto, como a garantia de um prédio (5 anos após o “Habite-se”) ou a assistência técnica aos
usuários de um equipamento durante a primeira fase de sua operação. Esses contratos precisam
continuar em vigor após o encerramento do projeto, no entanto, de agora em diante, sob a
responsabilidade de outra equipe. O GC e o grupo de aquisições devem efetuar uma transferência
de custódia, passando à nova equipe todo o histórico do contrato e cumprindo os procedimentos
corporativos pertinentes13. A parte contratada não tem ingerências nesse ponto, mas deve ser
mantida informada e participar de uma transição.
Realizado o escopo do quadro de aquisições, a missão do grupo de aquisições no projeto estará
(quase) concluída. Se os recursos tiverem sido disponibilizados conforme as especificações e em
tempo hábil, se o orçamento tiver sido respeitado e os contratos tiverem sido encerrados sem
maiores problemas para a organização hospedeira e os fornecedores, então o trabalho terá sido
vitorioso. Mas ainda há algo a fazer: o processo de gerenciamento das aquisições no projeto também
precisa ser encerrado. Para isso, teremos que:
arquivar corretamente a documentação dos contratos;
compilar e divulgar as lições aprendidas (aquisições e contratos são fontes muito ricas de
conhecimento, de modo que desperdiçar a oportunidade de aproveitá-lo é insensatez);
desmobilizar os meios utilizados no trabalho (escritórios, TI, etc.) e
desmobilizar a equipe.

Feito isso, finalmente, poderemos comemorar e iniciar outro projeto.

13
Nem sempre há necessidade de documentos formais de transferência, mas o registro do evento é sempre uma boa
prática.

118
MÓDULO IV – RECURSOS TECNOLÓGICOS
DE GESTÃO DE PROJETOS

Neste módulo, veremos algumas aplicações tecnológicas de gerenciamento de projetos. Para

tal, as aplicações serão devidamente descritas e aplicadas a casos reais ou hipotéticos.

Demonstração das principais ferramentas de gerenciamento

de projetos
WBS ou EAP
Como sabemos, na fase do ciclo de vida chamada de iniciação, o escopo do projeto ainda é
definido de forma bastante rudimentar, preliminar ou sumarizada. No entanto, mais à frente na
etapa do planejamento, todas as estimativas deverão ser regiamente detalhadas. Isso ocorrerá tanto
para escopo como para as demais áreas de conhecimento.
A EAP – Estrutura Analítica do Projeto – ou WBS – Work Breakdown Structure – é,
justamente, a ferramenta mestra da área de conhecimento do escopo, já que detalha, graficamente,
o que estará contido no escopo do projeto, identificando as entregas previstas, “os resultados físicos
ou semiprodutos, obtidos ao longo do projeto. Serve para medir e avaliar o desempenho do projeto”
(VARGAS, 2016). A EAP pormenoriza os componentes mais elementares, ao dividir o produto do
projeto em partes lógicas e inter-relacionadas hierarquicamente.
Segundo Valeriano (2001, p. 201), a ferramenta “consiste em uma forma de apresentação do
projeto que o explicita em suas partes físicas, softwares, serviços e outros tipos de trabalho, a qual
organiza, define e mostra, graficamente, tanto o produto a ser feito como o trabalho a ser realizado
para obtê-lo. Ela consiste em uma decomposição do produto e dos processos necessários para obtê-
lo, bem como das tarefas gerenciais consequentes”. A EAP é apresentada como um organograma,
também conhecido como árvore de decomposição do projeto ou árvore de decomposição do
trabalho, como podemos verificar no exemplo a seguir:

Figura 44 – Árvore de decomposição do projeto – exemplo

Fonte: Vargas, 2016.

A EAP é um instrumento orientado eminentemente ao trabalho do projeto, ou seja,

decompõe o escopo em partes menores, servindo também na parte de comunicação com os
stakeholders, por ser uma ferramenta bastante visual. Quando totalmente concebida, ela ajudará os
stakeholders a melhor visualizarem e entenderem as entregas previstas do projeto. Como a EAP
divide os componentes do todo, discriminando os elementos de escopo, ela evita que qualquer
trabalho seja esquecido.
Na prática, o desenho de uma EAP é iniciado pela decomposição do escopo-macro do projeto
em blocos cada vez menores e de entregas progressivamente diminutas. Tais desmembramentos
chegam a um ponto ideal ou ao nível de detalhamento desejado de fim, chamado na literatura de
pacotes de trabalho.

120
 Na EAP a seguir, os pacotes de trabalho são facilmente identificáveis, já que estão localizados
no terceiro (e último) nível de decomposição, conforme indicado:

Figura 45 – Exemplo de EAP

Como serve para evidenciar os componentes do escopo do projeto, a EAP direcionará os

trabalhos da própria equipe executora, facilitando a atribuição de “donos” para cada pacote de
trabalho e permitindo estimativas de custos pela atribuição dos recursos necessários a cada entrega. A
ferramenta também será útil na identificação de possíveis riscos do projeto, graças à visualização
detalhada do escopo que a ferramenta permite. O mesmo motivo permite ao gerente de projetos usar
a EAP na definição de tempos de duração de cada pacote de trabalho, quebrando-os em atividades.

121
 Na sua versão final, a EAP servirá de orientação-base para a maior parte do planejamento do
projeto. Essa ferramenta de escopo será entrada para diversas outras áreas de conhecimento, como
mostra a figura a seguir:

Figura 46 – EAP como subsídio de outras áreas

No que concerne à confecção de EAPs, em geral, as estruturas podem ser geradas por meio de
softwares bastante conhecidos e populares no mercado, inclusive naqueles mais acessíveis e contidos
do pacote da Microsoft Office. Facilmente, podemos elaborar uma EAP via Powerpoint, Word ou
MS Project por meio do recurso “organograma”, no menu do SmartArt (CAMARGO, 2014).
Outras opções de software para confecção de EAPs são o Visio e o XMind, mas há também
no mercado a oferta de recursos tecnológicos concebidos e direcionados, exclusivamente, para a
construção de EAPs. Um dos mais celebrados entre os gestores de projeto é o software WBS Chart
Pro., desenvolvido pela empresa Critical Tools.

122
A seguir, a EAP foi confeccionada com esse recurso:

Figura 47 – EAP pelo WBS Chart Pro

123
 Outros programas úteis na criação de uma EAP são o WBS Tool.com e o OpenProj – ambos
podem ser baixados on-line gratuitamente. As duas EAPs, a seguir, foram concebidas por meio
desses dois softwares, respectivamente:

Figura 48 – EAP pelo WBS Tool.com

Figura 49 – EAP pelo Open Proj

124
 Um ponto adicional e positivo sobre o programa do OpenProj é que a sua aplicação vai além
da mera elaboração da EAP, sendo uma ferramenta mais ampla de gerenciamento de projeto. O
OpenProj pode ser usado para controle de tempo e de custo, além de permitir a associação de tarefas
aos responsáveis (controle de recursos). Outra vantagem é ser um sistema que funciona igualmente
nos ambientes Windows como Linux, por ser um software livre.
O texto a seguir, do renomado autor Carlos Magno, esclarece mais detalhes acerca da EAP e
explica o passo a passo da sua confecção.
O texto a seguir, do renomado autor Carlos Magno, esclarece mais detalhes acerca da EAP e
explica o passo a passo da sua confecção.

Os dez mandamentos da estrutura analítica do projeto

A Estrutura Analítica do Projeto (EAP), tradução de Work Breakdown Structure (WBS), é o

coração de todo o planejamento do projeto. A partir dela, são elaborados o cronograma e o
orçamento.

125
 I – Cobiçarás a EAP do próximo

Aprender com o passado é uma habilidade importante do gerente de projetos. Antes de

iniciar a elaboração da EAP do seu projeto, verifique como foi estruturado o escopo de
projetos semelhantes. Consulte outros projetos da empresa, veja a literatura e converse com
outros profissionais de gerenciamento que atuaram em projetos que tiveram como objetivo
a geração de produtos e serviços similares.

II – Explicitarás todos os subprodutos, inclusive os necessários ao gerenciamento do

projeto

O produto ou serviço que não estiver na EAP não faz parte do escopo do projeto. Desse
modo, não deixe nenhum de fora. Se durante a execução do projeto, algum membro estiver
trabalhando em uma atividade que não esteja contribuindo para algum produto da EAP, ele
estará trabalhando fora do escopo do projeto. Se esse trabalho for necessário ao projeto,
devem ser utilizados os procedimentos para a sua inclusão no escopo. Os produtos e
serviços necessários ao gerenciamento do projeto também devem ser acrescentados à EAP.

III – Não usarás os nomes em vão

Não devem ser utilizados nomes vagos para os elementos da EAP, que gerem dúvidas
semânticas acerca de que produto está sendo representado. Utilize substantivos para
representar os produtos e serviços. Não indique o processo de geração dos mesmos, mas
sim a entrega desse processo. Dessa forma, em vez de “Testar o equipamento” (um serviço),
utilize “Teste do equipamento”; em vez de “Elaborar o Manual do Equipamento”, utilize
“Manual do Equipamento”.

IV – Guardarás a descrição das entregas no Dicionário da EAP

As entregas devem ser claramente definidas no dicionário da EAP para que fique bem
explícito o trabalho a ser realizado.

V – Decomporás até o nível de detalhe que permita o planejamento e controle do

trabalho necessário para a entrega do produto ou serviço

O planejamento e controle incluem: escopo (verificação e controle de mudanças); tempo

(definição das atividades); custo (planejamento de recursos, estimativa de custo e orçamento)
e risco (planejamento do risco).

126
VI – Não decomporás em demasia, de forma a que o custo/tempo de planejamento e
controle não traga o benefício correspondente

Planejar e controlar tem o seu custo/tempo necessário a esse trabalho. Desse modo,
decomponha de acordo com a sua necessidade no projeto. Como exemplo, não adianta
decompor o escopo em subprodutos que durem 1 hora para serem gerados se o controle
será realizado semanalmente. Por outro lado, caso um projeto tenha deliverables com altos
níveis de incerteza (que implicam altos riscos) e custos elevados, os controles necessários
demandarão uma decomposição extremamente detalhada. Como exemplo, a EAP de um
projeto de construção de um veículo lançador de satélites (que custa algumas centenas de
milhões de dólares) será muito mais detalhada do que a EAP da construção de uma casa pré-
fabricada de 2 quartos (que custa algumas dezenas de milhares de reais).

VII – Honrarás o pai

Cada elemento da EAP deve ser um componente do elemento pai ao qual está subordinado.
Verifique se os elementos filhos na EAP são realmente componentes dos elementos pais. Por
exemplo, o fato de um treinamento depender de um manual do equipamento ter sido
disponibilizado não quer dizer que faça parte do treinamento a elaboração do manual.

VIII – Decomporás de forma que a soma das entregas dos elementos componentes
(filhos) corresponda à entrega do elemento pai (mandamento dos 100%)

Ao decompor um subproduto, nenhuma parte dele deve ser esquecida. Lembre-se de que a
soma dos subprodutos componentes deve ser equivalente ao subproduto que foi
decomposto. Por exemplo, ao decompor um Estudo de Viabilidade da fase de Concepção,
não poderíamos esquecer do Relatório conclusivo do estudo.

IX – Não decomporás em somente um subproduto

Um elemento da EAP não deve ter somente um componente (filho). De acordo com o
mandamento anterior, se um elemento tem somente um componente, ele é igual ao pai. Se
for, porque representá-lo duas vezes? Quando isso ocorrer, verifique se, na realidade, não
esqueceu de algum componente. Caso não tenha esquecido, é desnecessária a
representação do elemento filho.

127
 X – Não repetirás o mesmo elemento como componente de mais de uma entrega

Não podemos ter um elemento como componente (filho) de mais de um subproduto (pai).
Por exemplo, se para ministrarmos dois treinamentos utilizarmos a mesma apostila, não
devemos colocá-la como subproduto dos dois treinamentos a elaboração da mesma. É
importante ressaltar que podemos ter elementos com o mesmo nome compondo
subprodutos diferentes, mas cada um com um significado diferente.

MAGNO, Carlos. Os dez mandamentos da estrutura analítica do projeto. Disponível em:

https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto
Acesso em: jan. 2019.

Cronograma
No tópico 2 do módulo 2, vimos que o foco da área de conhecimento de tempo é zelar pelo
cumprimento do prazo final do projeto, fazendo jus à temporariedade dos projetos. Esse
monitoramento e controle do tempo é feito principalmente pela ferramenta do cronograma.
As técnicas ou softwares modernos com ênfase no controle dessa duração têm permitido aos
gerentes dos projetos o desenvolvimento de cronogramas mais sofisticados e mais precisos, porém
um breve histórico se faz necessário.
Um dos primeiros instrumentos criados, especificamente, para o gerenciamento de projetos
foi o gráfico de Gantt. Surgido nas primeiras décadas do século XX, a sua principal motivação foi
a necessidade de controle de projetos pela marinha norte-americana. O autor do diagrama, Henry
Gantt, envolvido em um esforço durante a Primeira Guerra Mundial, desenhou uma matriz
cruzando as atividades ou tarefas do projeto com suas respectivas durações e interpendências. À
esquerda, plotou as atividades verticalmente listadas e, à direita do gráfico, inseriu o fator tempo,
com as durações das tarefas do projeto. Essas durações foram representadas por barras horizontais.
Na figura a seguir, temos um exemplo desse Diagrama de Gantt:

128
 Figura 50 – Diagrama de Gantt

semanas
etapa atividade
1 2 3 4 5 6 7 8 9

1 definição dos objetivos

2 operacionalização dos conceitos

3 seleção da amostra

4 questionário e pré-teste

5 definição dos recursos

6 seleção e treinamento

7 trabalho de campo

8 análise e interpretação

9 elaboração do relatório

10 análise e aprovação do projeto

Em meio às demandas de um programa militar chamado Polaris, também pertencente à

marinha norte-americana, na década de 1950, houve a necessidade de uma estimativa mais
quantitativa e probabilística das durações das atividades. Com isso, surgiu outro marco da história
de ferramentas de tempo em projetos: o Program Evaluation and Review Technique ou PERT.
Concomitantemente, desenvolveu-se na empresa DuPont o Método do Caminho Crítico, que
trouxe o conceito de caminho mais longo ou duradouro de um projeto.
As atividades constituintes desse caminho crítico não possuem folga alguma ou apresentam a
menor folga disponível no projeto todo. O método ensina que a duração desse caminho crítico
determina a duração total do projeto. Desse modo, com a identificação do caminho crítico e das suas
atividades constituintes, os gestores de projeto passaram a dar mais foco a essas tarefas críticas para
evitar possíveis atrasos nas suas execuções segundo as durações originais. De fato, se qualquer atividade
do caminho crítico sofrer atraso, haverá um risco de impacto direto no prazo final do projeto.

129
 Desde então, e até hoje, o campo da gerência de projetos tem aplicado o método de
dimensionamento do caminho crítico, seja manualmente, seja por softwares. No entanto, outros
inúmeros recursos (similares ou não) foram lançados com o mesmo objetivo de desenvolver
cronogramas de projetos. Em virtude da própria evolução tecnológica do século XXI aplicada à
gestão de projetos, o cenário tem sido favorável à universalização do uso do cronograma para gestão
de tempo ou prazo de qualquer projeto, independentemente do porte e indústria do mesmo. Desse
modo, cabe detalharmos o racional da elaboração progressiva da ferramenta.
Conforme exibido no tópico anterior, a EAP contendo os pacotes de trabalho compõe a
entrega total do projeto, daí ser um ferramental da área de escopo do projeto. No entanto, para
efeito de confecção de cronogramas, será necessário fazer a decomposição dos pacotes de trabalho
obtidos na EAP em atividades ou tarefas. Atividades devem ser entendidas como qualquer
componente do trabalho realizado no decorrer do ciclo de vida do projeto e que consome tempo e
recursos (CAMARGO, 2014).
A figura, a seguir, ilustra essa quebra dos pacotes em atividades como primeiro passo na
composição de um cronograma:

Figura 51 – Pacotes de trabalho x atividades

Fonte: VARGAS (2016).

130
 Como passo inicial da elaboração do cronograma, deve-se decompor as atividades a partir do
nível de pacotes de trabalho, conforme ilustrado na EAP a seguir:

Figura 52 – EAP e decomposição em atividades

As duas ilustrações, a seguir, feitas pelo software do WBS Chart Pro, exemplificam também
o procedimento de decomposição dos pacotes de trabalho em atividades:

Figura 53 – EAP

131
 Figura 54 – Parte de EAP com atividades decompostas

Posteriormente à identificação e listagem das tarefas a serem executadas no projeto, deverá

ser feito o sequenciamento ou relacionamento lógico entre elas. Segundo VALERIANO (2001), as
atividades devem ser

dispostas em uma sequência que considere a precedência de umas em

relação a outras. É como separar, em uma construção de um edifício, a
atividade de construção das fundações daquela que se segue a estrutura da
obra (...). Esse processo tem em vista dispor as atividades de forma que as
precedências sejam observadas. Há atividades que podem ser realizadas
independentemente de outras, mas há aquelas que precisam ter uma
relação de dependência temporal. A principal saída desse processo de
sequenciamento de atividades é o diagrama de rede do projeto, de forma
gráfica de mostrar as ligações lógicas e a interdependência das atividades
do projeto (p. 211).

132
 De fato, algumas atividades tem uma relação sequencial entre si, ou seja, uma é sucessora de
outra. Outras tarefas podem ser feitas paralelamente em relação a outras. Essas duas configurações
de interdependência são demonstradas nos diagramas usuais, a seguir:

Figura 55 – Interdependências entre atividades

relacionamento paralelo sequencial

representação
gráfica

O gerente de projeto também estima e aloca, para essas atividades, os recursos necessários à
sua execução de cada uma das tarefas e, como 3o passo, atribuirá durações a cada uma das atividades.
Muitas empresas não têm fontes seguras dessas informações, o que prejudica as suas estimativas.
Por outro lado, às que investem em gestão de conhecimentos e armazenagem de dados de lições
aprendidas, há mais facilidade nesse momento de estimativa de tempo, já que os registros dos
projetos anteriores poderão ser uma fonte interessantes dessas durações. Outra opção complementar
para definir as durações das tarefas é ouvir profissionais ou especialistas, como membros da equipe
executante do projeto e consultores experts.
Tal qual ocorre para a elaboração de EAPs, também existe uma oferta variada de softwares de
gerenciamento e controle de projetos. Todos possuem os seus respectivos recursos ou visões para a
geração de cronogramas, alguns bastante robustos. Entre a ampla oferta de sistemas disponíveis,
podemos elencar notadamente: MS Project, Primavera, Openproj, NetProject e Netoffice.

133
 A seguir, as figuras foram geradas pelas ferramentas do MS Project, do Openproj e do
NetProject, respectivamente:

Figura 56 – Cronograma

134
 Figura 57 – Cronograma

Figura 58 – Cronograma

Fonte: http://netproject.com.br/imgs/cronograma-gestao-projetos-ampliado.jpg.

135
 No OpenProj, por exemplo, há inúmeras possibilidades adicionais além do diagrama de
Gantt. O sistema também permite a inserção de dados relativos aos recursos necessários do projeto
(sejam humanos sejam materiais/equipamentos), conforme figura a seguir. Importante notar que,
na coluna “máximo de unidades”, está indicada a quantidade de pessoas planejadas. Há também a
opção de inserir os custos horários (R$) e se esses custos serão realizados no início ou fim do projeto
ou, até mesmo, rateados com outro departamento da empresa executora do projeto. Por fim, o
OpenProj também permite que cada recurso tenha um calendário único, a exemplo de um
profissional que só trabalhe no projeto parcialmente, ou 4 horas por dia, etc. Caso o recurso
“Bruno” (da figura) não esteja disponível no calendário padrão do projeto, que é de 08h00 às
17h00, pode-se adaptar o calendário daquele recurso à sua especificação, no caso para “período
matutino” (CAMARGO, 2014).
Todas essas opções citadas acerca do OpenProj também existem no Ms Project.

Figura 59 – Cronograma com alocação de recursos

Adicionalmente, o OpenProj, o Ms Project e a maioria de outros softwares permitem que o

esforço do time inserido vire um histograma dos recursos. Seguem alguns exemplos dessa visualização:

Figura 60 – Alocação de recursos

136
 Figura 61 – Alocação de recursos

300

275

250

225

200
uso dos recursos

175

150

125

100

75

50

25

09 16 23 30 06 13 20 27 06 13 20 27 03 10 17 24 01 08 15 22

janeiro fevereiro março abril maio

horas do pessoal na utilização dos recursos

Em função do histograma obtido, o gerente de projeto e outros usuários desses softwares terão
a indicação da carga de trabalho de cada recurso e o esforço disponível na equipe. O histograma
indica vários pontos no projeto, como se há sobrecarga, se deve postergar atividades não críticas ou
substituir recurso alocado por outro não sobrecarregado. Outras decisões poderão ser necessárias
em função do que mostram esses sistemas, como a opção de atrasar ou não algumas datas-marco do
projeto, ou criar uma margem de segurança onde houver sobrecarga do pessoal, etc.
No MsProject ou no OpenProj, também podemos incluir a coluna de percentual do
trabalho realizado com os dados reais do que foi concretizado do dia a dia do projeto. Para isso,
basta inserir coluna “% concluída” no nome do campo e inserir os percentuais à medida que as
tarefas vão sendo realizadas.

137
 Para conclusão do módulo, cabe a leitura do texto a seguir:

Cinco ferramentas gratuitas para gestão de projetos

Estabelecer boas relações entre o time é um dos fatores-chave para o sucesso de um projeto.
Aqui, vão cinco ferramentas para ajudá-lo nessa tarefa.

Da Redação, com IDG News Service, 19/03/2018 às 6h55

Certa vez, o manager de baseball Casey Stengel disse que “encontrar bons jogadores é fácil.
Difícil é fazê-los jogar juntos”. A afirmação, talvez, valha para o momento atual no que tange
aos recursos tecnológicos. Colaboração é um dos fatores-chave para o sucesso
independentemente do tamanho da companhia.

Com isso em mente, fica simples observar o quão importante é possuir a ferramenta de
colaboração certa para manter os times conectados e caminhando em uma mesma direção.
A Computerworld listou algumas soluções que podem ajudá-lo nesse sentido.

Podio – Trata-se de uma rede social corporativa que pode ser turbinada com funções
de gerenciamento de projeto. Cada usuário cuida de seu próprio perfil, que pode ser
associado a outras pessoas, como gestores, colegas envolvidos diretamente em
alguma iniciativa, líderes de projeto e desenvolvedores. Possui aplicativo de chat, troca
interna de e-mail, contatos, calendários e tarefas. Talvez uma das grandes vantagens
da ferramenta seja a possibilidade de customizar recursos, bem como, diversos apps
interessantes em um marketplace.

Asana – Ferramenta criada por dois ex-Facebook (Dustin Moskovitz, cofundador da

rede social de Mark Zuckerberg, e Justin Rosenstein, líder de tecnologia) para fazer
gerenciamento de projeto e fluxos permitindo que os usuários padronizem interfaces
de acordo com suas preferências e padrões de produtividade. Funciona na maioria
das plataformas (tablets, smartphones e desktops) e garante flexibilidade no controle
de tarefas e a fazeres, indica avanços e prazos e mantém as coisas em ordem. Grátis
para até 15 usuários. A partir daí, os valores mensais vão de US$ 50 a US$ 800,
dependendo do número de colaboradores na ferramenta.

138
 Trello – Solução grátis de gestão de projeto que oferece interface simples e intuitiva.
Utiliza o modelo chamado Kanban, que ficou famoso nos anos 1980 por ser
propagado pela Toyota. Os projetos são representados e organizados no que a
empresa se refere como quadros ou cartões contendo listas de tarefas e a fazeres
compartilhados entre usuários em tempo real.

Bitrix24 – É uma suíte que oferece CRM, gerenciamento de projetos, centrais de

contato com clientes, ferramentas de comunicação e colaboração e até mesmo sites e
designs de páginas de destino. O módulo de gerenciamento de projetos inclui controle
de tarefas, subtarefas, monitoramento de tempo, modelos, papéis, notificações,
gráficos de Gantt, e Kanban, além da integração com outras plataformas. E no módulo
de comunicação e colaboração o usuário pode contar com um portal de intranet, rede
social privada, bate-papo da empresa, calendários, gerenciamento de documentos,
fluxos de trabalho para aprovação, estrutura da empresa e outras ferramentas.

GanttProject – Agora, se gerenciamento de projeto é sua praia, essa é “a” ferramenta

para você. Esse app grátis e open source para gestão e agendamento foi desenvolvido
ainda em 2003 e passou por muitos ciclos de evolução. A solução permite que
usuários criem e organizem tanto tarefas quando avanços. Permite ainda exportar
informações em formatos como HTML e PDF. O lado ruim é que não oferece nenhuma
funcionalidade de redes sociais para listas de tarefas a serem feitas. Agora, se você
não precisa disso, essa tecnologia grátis lhe soará bem atrativa.

Fonte: CINCO ferramentas gratuitas para gestão de projetos. Disponível em: <
https://cio.com.br/5-ferramentas-gratuitas-para-gestao-de-projetos >. Acesso em: jan. 2019.

139
CONCLUSÃO

A gestão de projetos sistematizada começou no século XX, no entanto, estamos cercados por
projetos de maneira paralela à existência da raça humana. No primeiro módulo, vimos que, em épocas
primitivas, já se erguiam grandes obras – e com excelência –, o que evidencia a existência de um
mínimo de know-how para concluir esses eventos com sucesso. Também foi escopo deste trabalho a
conceituação de projetos, tidos como eventos temporários e únicos, assim como diferenciá-los de
outros conceitos fundamentais da disciplina, como trabalhos rotineiros, subprojetos, programas e
portfólio. É importante ressaltar a íntima correlação entre a estratégia empresarial, derivada do
planejamento estratégico, e a seleção de projetos dentro de uma corporação.
Não menos importante, visitamos as justificativas dos projetos, ou seja, os seus fatores
motivadores e entendemos o papel dos stakeholders na história de cada projeto. Entre esses
stakeholders, deu-se foco especial ao gerente de projetos e se levantou as principais habilidades que
ele deve apresentar para aumentar o seu índice de sucesso. Nesse mesmo ensejo, o Escritório de
Projetos (PMO) deve aparecer nas organizações mais evoluídas para melhor garantir a aplicação
desta ciência de projetos. Um elemento bastante impactante no gerenciamento é a própria forma
das empresas, assunto que tratamos por meio da distinção os três modelos principais de estrutura,
e salientando os seus prós e contras. A grande utilidade de entender esses diferentes modelos é prever
qual a relação e o impacto que eles terão no dia a dia de projetos.
No módulo 2, revisamos o conceito de processos de gerenciamento de projetos, divididos em
cinco grupos ou naturezas, que ocorrem em todo projeto, independentemente do tamanho da
companhia ou do setor de atuação. Diferenciamos os 49 processos da 6a edição do PMBOK do
tema de ciclo de vida – assunto que, evidentemente, é básico para a ciência de projetos, uma vez
que implica a própria temporariedade do conceito. A seguir, foi explanado como diversos
parâmetros – custos, pessoas, intervenção de stakeholders – podem-se comportar durante a vida útil
de uma empreitada, e se relacionou as funções de cada uma das dez áreas de conhecimento.
Adicionalmente, os documentos do Termo de Abertura do Plano de Gerenciamento de Projetos
foram devidamente valorizados e destrinchados, dada a sua importância crucial para uma boa gestão
de projetos e, inclusive, para a definição da linha de base do projeto.
Conforme vimos, as áreas de escopo, tempo e custo perfazem, juntas, a tríplice restrição de
todo empreendimento, tendo uma relação mútua entre si. Também vimos que o gerente de projeto
precisa seguir um gerenciamento metódico sobre as mudanças solicitadas, para evitar que haja
durante o ciclo de vida do projeto um descontrole sobre essas requisições. Concluímos o módulo
com o tema de projetos de sucesso.
No módulo 3, verificamos o gerenciamento de aquisições no ambiente de um projeto,
utilizando o seu ciclo de vida como fio condutor. Passamos pela identificação das necessidades, pelo
planejamento do trabalho, pela busca dos recursos e pela administração dos contratos de
fornecimento. Foram descritas as opções de fornecimento e seleção do mercado mais adequadas até
o ápice da escolha em um contrato – acordo formal entre cliente e fornecedor. Vimos as três fontes
de recursos para um projeto – a organização hospedeira, o seu cliente e o Mercado – e os riscos
associados a cada uma delas.
Na unidade de processo licitatório, abordamos o passo a passo dessas aquisições, respeitando
os critérios básicos da objetividade, neutralidade e da viabilidade, até o marco final da seleção do
fornecedor vencedor. Também foram explanados os modelos de contratos e as suas respectivas
vantagens e desvantagens, assim como compartilhadas várias lições de administração de contratos.
Por último, mas não menos fundamental, foi descrito o tema de encerramento dos contratos,
inclusive para fazer jus ao final do ciclo de vida do projeto.
No módulo final de recursos tecnológicos, aprofundamos duas das ferramentas mais úteis de
gerenciamento de projetos: a EAP (ferramenta de escopo) e o cronograma (instrumento de tempo).
Analisamos as suas respectivas funções e mostramos ao leitor o quanto ambos são necessários no dia
a dia do projeto. Exibiu-se que esse ferramental pode ser feito sob inúmeras formas e por meio de
softwares distintos – o que, na prática, só atesta a sua importância. De fato, a EAP e o Cronograma
são, atualmente, os instrumentais mais universais de gestão de projetos.
Em suma, pode-se concluir que o gerenciamento de projetos se tornou uma competência
estratégica para toda organização contemporânea. Da mesma forma, os profissionais que
conhecerem os seus fundamentos e aplicarem as suas boas práticas terão um evidente diferencial no
ambiente de trabalho e no mercado.

142
BIBLIOGRAFIA
BARCAUI, Andre. Gerente também é gente. Rio de Janeiro: Elsevier, 2012.

BARCAUI, Andre. PMO – Escritórios de projetos, programas e portfólio na prática. Rio de

Janeiro: Brasport, 2012.

CAMARGO, Marta Rocha. Gerenciamento de projetos: fundamentos e prática integrada. Rio de

Janeiro: Elsevier, 2014

CARVALHO, Fabio Câmara de Araujo. Gestão de projetos. São Paulo: Pearson Education do
Brasil, 2015.

FOGAÇA, Jennifer Rocha Vargas. Refinamento do petróleo. Brasil Escola. Disponível em:
https://brasilescola.uol.com.br/quimica/refinamento-petroleo.htm. Acesso em: jan. 2019.

FOGGETTI, Cristiano. Gestão ágil de projetos. São Paulo: Pearson, 2014.

GOZZI, Marcelo Pupim. Gestao de Projetos I. São Paulo: Biblioteca universitária Pearson –
BUP, 2016.

KERZNER, Harold. Gestão de projeto: as melhores práticas. Nova York: John Willey & Sons, 2009.

LEWIS, James. Project planning, scheduling & control. New York: McGraw-Hill, 2009.

MEREDITH, Jack R. Administração de projetos – uma abordagem gerencial. 4. ed. Rio de Janeiro:
LTC editora.

MONTES, Eduardo. Introdução ao gerenciamento de projetos: como gerenciar projetos pode fazer
a diferença na sua vida. 1. ed. São Paulo: PMP, 2017.

PMI – PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: um guia para o conjunto de

conhecimentos em gerenciamento de projetos. 6. ed. Pensilvânia: PMI, 2017.

TORRES, Luis. Fundamentos do gerenciamento de projetos. Rio de Janeiro: Elsevier, 2014.

143
VALERIANO, Dalton L. Gerenciamento estratégico e administração por projetos. São Paulo:
Makron Books, 2001.

VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 9. ed. Rio

de Janeiro: Brasport, 2016.

Sites
https://www.cocacolabrasil.com.br/historias/central-gestao-comunitaria-da-agua-muda-realidade-
de-milhares-de-familias-na-
bahia?gclid=Cj0KCQiAvqDiBRDAARIsADWh5TfNSLV0OIX7R4N9a4K5mQ3APmxO2xWs
hMdVnp_PSAyFpYYJNj0MvsUaAvTUEALw_wcB Acesso em: jan. 2019.

https://www.defesa.gov.br/industria-de-defesa/paed/projetos-estrategicos/projetos-estrategicos-da-
marinha-do-brasil Acesso em: jan. 2019.

https://canaltech.com.br/espaco/60-anos-de-nasa-conheca-a-historia-e-os-projetos-da-agencia-
espacial-dos-eua-118996/ Acesso em: jan. 2019.

http://www.inovarse.org/filebrowser/download/9152 Acesso em: jan. 2019.

https://escritoriodeprojetos.com.br/processos-do-guia-pmbok-sexta-edicao Acesso em: jan. 2019.

https://dicasgp.pmtech.com.br/fluxo-pmbok/ Acesso em: jan. 2019.

https://brasil.pmi.org/brazil/CertificationsAndCredentials/WhatarePMICertifications.aspx Acesso
em: jan. 2019.

https://blog.pmtech.com.br/tendencias-gp-2018 Acesso em: jan. 2019.

https://escritoriodeprojetos.com.br/portfolio-de-projetos Acesso em: jan. 2019.

http://www5.each.usp.br/wp-content/uploads/2016/07/EAIP-O-Caso-do-Hospital-Albert-
Einstein.pdf Acesso em: jan. 2019.

https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto/
Acesso em: jan. 2019.

144
http://www.pmisp.org.br/enews/edicao1112/artigo_01.asp Acesso em: jan. 2019.

https://www.pmtech.com.br/Templates/Termo%20de%20Abertura.doc Acesso em: jan. 2019.

http://ri.sulamerica.com.br/static/ptb/perfil-missao-visao-e-valores.asp?idioma=ptb Acesso em:

jan. 2019.

https://beware.com.br/academia/artigos/os-dez-mandamentos-da-estrutura-analitica-do-projeto/
Acesso em: jan. 2019.

https://www.projectbuilder.com.br/blog/caminho-critico-do-projeto-saiba-quando-e-como-
utilizar/ Acesso em: jan. 2019.

http://netproject.com.br/imgs/cronograma-gestao-projetos-ampliado.jpg Acesso em: jan. 2019.

https://artia.com/blog/software-de-gerenciamento-de-projetos/ Acesso em: jan. 2019.

https://cio.com.br/5-ferramentas-gratuitas-para-gestao-de-projetos/ Acesso em: jan. 2019.

145
BIBLIOGRAFIA INDICADA PARA AQUISIÇÃO
AACE International. TCM Cost Framework 7.3 – cost estimating and budgeting. American
Assotiation of Cost Engineering, 2012.

BRASIL, Ministério da Justiça. Normas para licitações e contratos na administração pública. Lei n.
8.666/1993 e suas alterações. Brasília-DF, Imprensa Nacional, 1993.

BRASIL, Ministério da Justiça. Código Civil Brasileiro. Lei n. 10.406/2002. Brasília-DF,

Imprensa Nacional, 2002.

BRASIL, Ministério da Justiça. Estatuto jurídico da empresa pública, da sociedade de economia

mista e de suas subsidiárias. Lei n. 13.303, de 30 de junho de 2016. Brasília-DF, Imprensa
Nacional, 2016.

COREY JR, J. J. Contract management and administration. 1. ed. [S.l.: s.n.], 2015.

PMI – PROJECT MANAGEMENT INSTITUTE. Guia PMBOK®: um guia para o conjunto de

conhecimentos em gerenciamento de projetos. 6. ed. Pensilvânia: PMI, 2017.

XAVIER, C. M. et al. Gerenciamento de aquisições em projetos. 4. ed. Rio de Janeiro: FGV, 2018.

146
PROFESSORES-AUTORES
Lorena Benchimol de Veloso é mestre em Administração de
Empresas e Comércio Internacional (Master of Business Administration
in International Management) pela European University
(Suíça/Portugal) desde 1999, com a distinção Magna Cum Laude. Em
2005, concluiu MBA em Gerenciamento de Projetos na Fundação
Getulio Vargas (FGV-RJ), com a titulação Summa Cum Laude e
recebeu, dessa mesma instituição, o grande prêmio pela primeira
colocação no evento nacional Project Management Day.
É palestrante convidada em encontros nacionais de Gerência de Projetos, desde 2007, e é
membro do Project Management Institute – PMI (Pennsylvania, Estados Unidos) –, do qual
também obteve, em 2005, a certificação de Project Management Professional (PMP)®.
Em 2000, teve início a sua experiência acadêmica como professora adjunta nos cursos de
graduação de Administração, Gestão Empresarial, Comércio Exterior, Gestão de Marketing e
Gestão de Órgãos Públicos. Em 2006, passou a professora convidada da Fundação Getulio Vargas
(FGV), atuando nos cursos de Pós-Graduação (MBA) de Gerência de Projetos, Gestão
Orçamentária, Gestão Empresarial, Gestão de Projetos em TI, Publishing Management e Fashion
Business. Desde 2016, é professora titular do FGV Online, na disciplina Fundamentos de
Gerenciamento de Projetos na FGV-RJ.
Iniciou a sua carreira profissional no Tribunal de Contas dos Municípios e Federação das
Indústrias, onde atuou por 7 anos em projetos de Total Quality Management e de Recursos Humanos.
Posteriormente, ocupou a posição de Analista de Projetos na criação e manutenção do Escritório
Nacional de Projetos (Project Management Office – PMO) da Souza Cruz/British American Tobacco
(BAT), na sede brasileira, no Rio de Janeiro. Iniciou carreira de gerente de projetos na Hewlett-Packard
(HP) do Rio de Janeiro, em 2004, atuando em projetos de Tecnologia de Informação com médias e
grandes corporações. Evoluiu para client manager de projetos de outsorcing e, finalmente, para gerente
de conta dos clientes Michelin, Anglo Ferrous, TV Globo, BR Distribuidora, Rexam e Chocolates
Garoto por 4 anos. De 2010 a 2018, foi a gerente de distrito do time Brasil do setor Printing and
Personal Systems Group (PPS), coordenando engenheiros e a rede de credenciadas HP em atendimento
a clientes corporativos, aplicando gestão de desempenho, controles de KPIs do negócio e gerindo
projetos de TCE-Total Customer Experience. Hoje, atua como consultora autônoma nas áreas de
Gerenciamento de Projetos, Gestão de Processos e Recursos Humanos.

147
 Maurini Elizardo Brito é engenheiro naval, especialista em Gestão
de Organizações e Marketing, mestre em Engenharia de Produção e
doutorando em Engenharia Ambiental. Possui mais de 30 anos de
experiência nas indústrias naval, automotiva, de óleo & gás e de energia,
atuando em projetos durante toda a carreira, além de mais de 15 anos como
consultor de gestão de projetos e empreendimentos, tendo atuado em
diversos megaprojetos recentes no Brasil.
É especialista em Comissionamento Industrial, tendo atuado em diversos projetos nos setores
de óleo & gás e de energia, e como consultor nos Jogos Olímpicos 2016. Também é professor da
FGV, do NPPG/Poli/UFRJ e do IPETEC/UCP. First Assessor da IPMA Brasil.

148