Apostila Gerenciamento de Projetos

Fundamentos do
gerenciamento de projetos
Apostila
FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 1

ÍNDICE
APRESENTAÇÃO 6
AULA 1: EVOLUÇÃO 7
INTRODUÇÃO 7
CONTEÚDO 7
PROJETOS 7
MUDANÇA DE PARADIGMA 8
METODOLOGIA APLICADA A PROJETOS – SÉCULOS XVIII E XIX 10
METODOLOGIA APLICADA A PROJETOS – INÍCIO DO SÉCULO XX 11
METODOLOGIA APLICADA A PROJETOS – SÉCULOS XX E XXI 13
SURGIMENTO DA CONCEPÇÃO DE PROJETO 14
CONCEITO DE PROJETO 15
PROJETOS SINGULARES 17
EXEMPLO 1 18
EXEMPLO 2 20
ATIVIDADE PROPOSTA 21
MUDANÇAS DE SUBSISTEMAS 22
APRENDA MAIS ERRO! INDICADOR NÃO DEFINIDO.
EXERCÍCIOS DE FIXAÇÃO 25
REFERÊNCIAS 27
AULA 2: CONCEITOS BÁSICOS 28
INTRODUÇÃO 28
CONTEÚDO 28
INTRODUÇÃO 28
CONCEITOS BÁSICOS RELACIONADOS AO GERENCIAMENTO DE PROJETOS 29
INFLUÊNCIA DOS MODELOS DE ESTRUTURAS ORGANIZACIONAIS EM GERENCIAMENTO DE
PROJETOS 34
COMPARAÇÃO ENTRE A TIPOLOGIA ORGANIZACIONAL ESTUDADA 41
APRENDA MAIS 43

REFERÊNCIAS 44
AULA 3: CICLO DE VIDA DO PROJETO 46
INTRODUÇÃO 46
CONTEÚDO 46
INTRODUÇÃO 46
ELEMENTOS CONCEITUAIS DO CICLO DE VIDA DO PROJETO 47
IMPACTOS NA DINÂMICA DE FLUXO DO CICLO DE VIDA DE UM PROJETO 52
APRENDA MAIS 59
REFERÊNCIAS 60
AULA 4: PROCESSOS 62
INTRODUÇÃO 62
CONTEÚDO 62
INTRODUÇÃO 62
GRUPO DE PROCESSO DE INICIAÇÃO 68
GRUPO DE PROCESSOS DE PLANEJAMENTO 69
GRUPO DE PROCESSOS DE EXECUÇÃO 71
GRUPO DE PROCESSOS DE MONITORAMENTO E CONTROLE 72
GRUPO DE PROCESSOS DE ENCERRAMENTO 73
APRENDA MAIS 74
REFERÊNCIAS 77
AULA 5: ÁREAS DO CONHECIMENTO 78
INTRODUÇÃO 78
CONTEÚDO 78
INTRODUÇÃO 78
ÁREAS DE CONHECIMENTO DE GERENCIAMENTO DE PROJETOS 84
REFLEXÃO 89
APRENDA MAIS 91

REFERÊNCIAS 93
AULA 6: CERTIFICAÇÃO PMI 94
INTRODUÇÃO 94
CONTEÚDO 94
INTRODUÇÃO 94
CONCEITOS DE CERTIFICAÇÃO 95
CERTIFICAÇÃO PELO PMI 100
OUTRAS CARACTERÍSTICAS DO PMI 103
APRENDA MAIS 105
REFERÊNCIAS 108
AULA 7: GERENCIAMENTO DE INTEGRAÇÃO - TAP 109
INTRODUÇÃO 109
CONTEÚDO 109
INTRODUÇÃO 109
PROCESSOS DE GERENCIAMENTO DE INTEGRAÇÃO 111
APRENDA MAIS 122
REFERÊNCIAS 125
AULA 8: GERENCIAMENTO DE INTEGRAÇÃO - PROCESSOS 126
INTRODUÇÃO 126
CONTEÚDO 126
INTRODUÇÃO 126
DETALHAMENTO DOS PROCESSOS DO GERENCIAMENTO DA INTEGRAÇÃO 126
CONCLUSÃO 142
APRENDA MAIS 143
REFERÊNCIAS 145

ANEXOS ERRO! INDICADOR NÃO DEFINIDO.
ANEXO 1 ERRO! INDICADOR NÃO DEFINIDO.
CHAVES DE RESPOSTA 146
AULA 1 146
AULA 2 146
AULA 3 147
AULA 4 147
AULA 5 147
AULA 6 147
AULA 7 148
AULA 8 148
CONTEUDISTA 148

Fundamentos do Gerenciamento de
projetos - Apostila
Apresentação
Se desejarmos gerenciar projetos, deveremos não só conhecer os principais
conceitos que envolvem essa atividade mas também identificar como vem
sendo concebida a visão das pessoas a respeito do assunto.
Afinal, tais noções se modificam na medida em que as organizações são

analisadas, de forma distinta, pela sociedade.
Nesta disciplina, definiremos os fundamentos que sustentam a gerência de

projetos e permitem a construção de metodologias para sua aplicação nas
empresas.
Sendo assim, esta disciplina tem como objetivos:
 Definir os principais conceitos relacionados ao gerenciamento de

projetos – tais como iniciação, planejamento, execução, monitoramento
e controle, e encerramento;
 Identificar o ciclo de vida de um projeto e os processos relacionados a
sua administração.

Aula 1: Evolução
Introdução
Entender a ferramenta de gerenciamento de projetos vai muito além do que
apenas aplicar uma ou mais metodologias de gerência no ambiente
empresarial.
Trata-se de observar como o homem compreende a noção de projeto e como

esta se insere dentro da organização contemporânea.
Nesta aula, conheceremos a evolução histórica desse conceito, identificando

seus desdobramentos na atualidade.
Objetivos:
 Conceituar projeto;
 Definir as diversas dimensões de singularidade aplicadas a projetos.
Conteúdo
Projetos históricos
Quando pensamos em projetos, muito nos questionamos quanto a sua
constituição e quanto à metodologia adotada pelas empresas para a aplicação
da ferramenta de gerenciamento de projetos.
Mas acabamos nos esquecendo de que esta é uma tarefa que realizamos
desde os tempos mais remotos: GERENCIAR PLANOS DE TRABALHO.
Quer ver alguns exemplos? Entre os primórdios, podemos citar as grandes

construções da antiguidade realizadas pelo homem, tais como: Milenar
pirâmide do Egito Planície de Gizé e Coliseu.

Galeria de vídeos
Assista ao vídeo A Necrópolis de Gizé.
Muitas dessas construções só foram concluídas após gerações até chegarem às

obras monumentais que conhecemos hoje:
Mas será que é possível pensarmos nesses monumentos históricos sem os

associarmos, incialmente, a um projeto? Provavelmente, NÃO!
Ao longo desta disciplina, entenderemos como esse conceito é aplicado na

atualidade, o que as organizações esperam ao elaborar projetos e como
podemos gerenciá-los.
Mudança de paradigma
Há muito tempo, o ser humano vem buscando formas possíveis de executar
ações de difícil concretização.
Os exemplos mais clássicos dessa tentativa incluem projetos de Engenharia

cujo resultado é um objeto tangível1. Nesses casos, podemos identificar
objetivos, recursos, custos e funcionalidades típicos de um plano de trabalho.
Além disso, dados históricos registram que, desde a antiguidade, esses

elementos já eram exigidos para a finalização de um projeto.
1
Tangível
Termo cuja origem vem do latim tangibĭlis e nos remete a tudo aquilo que podemos tocar
ou, em sentido mais amplo, perceber de maneira precisa.

Mas, no período do Renascimento2 e do Iluminismo3, houve uma mudança
significativa no padrão de realização de atividades: o conhecimento voltou a
ser o foco das atenções.
A partir da criação das Escolas Politécnicas na França, surgiu o novo

paradigma da sistematização da aprendizagem e do saber. Nesse cenário, o
elemento-chave de diferenciação passou a ser a METODOLOGIA4.
Entenda, a seguir, como essa noção auxiliou o gerenciamento de projetos.
2
Renascimento
Movimento cultural que surgiu na Itália, no século XV, contra as concepções teocêntricas
medievais.
Sua principal característica filosófica foi a transição do teocentrismo – que considerava

Deus como o centro do universo – para o antropocentrismo – que colocava o homem
nessa posição.
Logo, a partir dessa manifestação de ordem artística, cultural e social, o homem passou a
ser o centro de todos os interesses, e seu bem-estar constituía a preocupação primeira da
sociedade.
Apesar de revolucionária para a época, essa concepção de vida não era completamente
nova, pois a antiga civilização greco-romana já defendia a liberdade e a dignidade do
indivíduo em busca do homem ideal – do ponto de vista cívico –, intelectual e físico.
É justamente o renascer da cultura clássica que justifica a nomenclatura desse período da

história.
Adaptado de: http://www.notapositiva.com/dicionario_historia/renascimento.htm
3
Iluminismo
Movimento intelectual que ocorreu na Europa, no século XVIII, e teve sua maior
expressão na França – palco de grande desenvolvimento da Ciência e da Filosofia.
Também conhecido como Época das Luzes, esse período foi marcado por transformações
na estrutura social europeia, na qual os temas de discussão giravam em torno da
liberdade, do progresso e do homem.
Disponível em: http://www.significados.com.br/iluminismo/. Acesso em: 2 set. 2013.
4
Metodologia
Palavra derivada do vocábulo método, do latim methodus, que significa caminho ou via
para a realização de algo.

Metodologia aplicada a projetos – séculos XVIII e XIX
Na antiguidade, os métodos de realização de projetos aplicavam-se apenas a
objetos similares – tais como as próprias Pirâmides do Egito ou as câmaras
mortuárias do Vale dos Reis.
Mas, a partir da Revolução Industrial, fica claro que a metodologia para a

execução de projetos era necessária. Já durante o século XIX, essa
necessidade tornou-se mais evidente na realização de grandes e complexos
projetos – ainda que focados em Engenharia.
Em virtude do desenvolvimento da economia e do crescimento das demandas

da sociedade, era preciso criar uma estrutura industrial em escala – o que só
aconteceria se os modelos de projetos fossem sistematizados.
Por isso, esse período foi marcado pelo esforço de sistematização de grandes
projetos fomentados pelos governos de diversos países.
Veja, a seguir, alguns exemplos criados dentro e fora do Brasil.
Entre os projetos que se destacaram pela aplicação de métodos de execução,

podemos citar a construção de dois navios em território nacional, ainda no
período colonial:
 Nau Belém – localizado em um estaleiro do Pará;
 Nau São Sebastião 5 – localizado no arsenal da Marinha do Rio de
Janeiro.
5
De acordo com Greenhalgh (1951):
“Não se conhece quem foi o autor do risco [nome que se dava, antigamente, ao projeto]
tampouco se sabe de onde veio a mão de obra especializada empregada na construção.
Tinha 59,6 metros de comprimento, 15,5 metros de boca e 13 metros de pontal. Segundo
consta, o preço de sua construção, incluindo armamento e equipamento, foi de 50 Contos
de Réis”.

Como exemplos de grandes construções fora do Brasil, podemos citar:
 A malha ferroviária americana;
 Os metrôs de Paris e de Londres;
 A indústria naval europeia;
 O Canal de Suez;
 A Torre Eiffel etc.
Atenção
Nas indústrias, ainda existia o paradigma da elevação do esforço

atrelado ao aumento de horas de trabalho e a linearidade na
produção em escala.
Galeria de vídeos
Para saber mais sobre os grandes projetos construídos fora do

Brasil, assista aos seguintes vídeos:
 História do Canal de Suez;
 150 anos do metrô de Londres.
Metodologia aplicada a projetos – início do século XX

O início do século XX destacou-se como o momento em que as metodologias
aplicadas a projetos se fortaleceram.
Entre aqueles que contribuíram para implementar os modelos atuais de

trabalho, podemos citar:
Frederick Taylor

Os princípios defendidos por Taylor6 eram a sistematização de processos
industriais e a busca de melhores resultados dentro das organizações.
Henry Gantt
Os diagramas de Gantt7 – utilizados até hoje, com poucas modificações –
permitiram um melhor conhecimento dos fluxos de trabalho – tais como a
integração de ações, as interdependências em termos de concretização de
tarefas e os conflitos.
6
Taylor
Engenheiro norte-americano que revolucionou todo o sistema produtivo no início do século
XX ao introduzir o conceito da chamada Administração Científica – base sobre a qual se
desenvolveu a atual Teoria Geral da Administração.
Preocupado em estudar o tempo das ações humanas nas fábricas, Taylor acreditava na
possibilidade de redução dos tempos mortos e dos movimentos desnecessários do
operador, o que ampliaria as condições de otimização de qualquer processo de trabalho.
Adaptado de: http://www.infoescola.com/biografias/frederick-taylor/.
7
Henry Gantt
Engenheiro mecânico e assistente direto de Frederick Taylor, conhecido como o pai das
técnicas de planejamento e controle do trabalho. Estudando detalhadamente a ordem das
operações laborais, Gantt observou que o ser humano resistia a mudanças e a normas
grupais que afetavam diretamente sua produtividade.
Com o objetivo de manter o bem-estar dos trabalhadores articulado ao aumento de sua

eficiência operacional, ele construiu diagramas com barras de tarefas e marcos que
esboçavam a sequência e a duração de todas as suas atividades.
Esses gráficos de Gantt se converteram em eficientes ferramentas analíticas de

gerenciamento de projetos empresariais e, consequentemente, deram origem a outros
mecanismos mais modernos de avaliação de processos de trabalho – como, por exemplo, a
Estrutura Analítica do Projeto (EAP).
Adaptado de: http://www.programabrasil.org/henry-gantt/#.UbuH3vmG1oM.

Nesse cenário, as expectativas pela disponibilidade e rapidez de produtos – e,
ao longo do século, por serviços – ocasionou uma contínua preocupação com o
fator tempo.
Toda essa apreensão se refletiu nos métodos de desenvolvimento de projetos,

que buscavam associar as atividades a seu período de realização e aos
resultados esperados. Não é de se estranhar que o tempo seja um dos focos
do gerenciamento de projetos.
No início do século XX, as metodologias aplicadas a projetos que associavam

atividades, tempo e resultados se difundiram, rapidamente, em toda a área de
conhecimento de Engenharia.
Veja alguns exemplos extraídos de um relatório de acompanhamento de

projeto de aterro e estabilização de cais do complexo da ilha das cobras no Rio
de Janeiro:
Metodologia aplicada a projetos – séculos XX e XXI

Somente após a Segunda Guerra Mundial, os métodos aplicados a projetos
passaram a se desenvolver de forma massiva até chegarem àqueles que
conhecemos hoje.
O ponto de mudança foi a incorporação das seguintes metodologias:

 Program Evaluation and Review Technic (PERT) – oriunda de projetos
da indústria naval de defesa americana;
 Critical Path Method (CPM) – criada para auxiliar na manutenção de
plantas fabris.
Embora sua fonte de criação fosse distinta, ambas as técnicas matemáticas

passaram a ser adotadas rapidamente e de forma conjunta, associadas ao
diagrama de Gantt – que já se usava em larga escala.

Atualmente, há diversas metodologias que nos auxiliam em projetos – algumas
com foco em determinadas áreas de negócios e outras que podem ser
implementadas, de forma transversal, em várias áreas. Entre elas, destacamos
o Project Management Institute (PMI)8.
Material complementar
Para saber mais sobre as metodologias de gerenciamento de

projetos, leia os seguintes artigos complementar no ambiente
virtual:
 PERT/CPM – Manual do usuário;
 Metodologias em gerenciamento de projetos e sua
implantação em Tecnologia da Informação (TI).
Surgimento da concepção de projeto

Como vimos ao longo deste estudo, desde os tempos mais remotos, alguns
projetos já vinham sendo implementados pelo homem na sociedade.
Embora não nomeados como tal, esses empreendimentos ou essas

construções eram realizados com base em certas metodologias de execução.
A evolução dessa sistematização deu origem àqueles planos de trabalho

desenvolvidos atualmente dentro das organizações: os PROJETOS.
Você saberia definir esse conceito?
8
Project Management Institute (PMI)
Maior instituição internacional da atualidade dedicada ao conhecimento relacionado a
gerenciamento de projetos.

Pautados em uma visão contemporânea, Kaplan e Norton (2004) consideram
que as escolhas estratégicas realizadas por uma empresa se materializam pela
operacionalização de sua missão e de sua visão.
Essas estratégias, por sua vez, desdobram-se em iniciativas ou ações,

estruturando um verdadeiro PROJETO.
Para entender melhor essa concepção, veja, a seguir, algumas definições

difundidas na área de negócios.
Conceito de projeto
Na literatura mundial da área de negócios, encontramos diversas definições de
PROJETO que possuem aspectos em comum. Veja sua evolução ao longo do
tempo:
Norma francesa X-50-105 (1991)

“Passo a passo específico que permite estruturar, metódica e
progressivamente, uma realidade futura. [Ele] é definido e colocado
em serviço para elaborar a resposta à necessidade de um utilizador,
de um cliente ou de uma clientela, e implica um objetivo e ações a
serem empreendidas com recursos dados”.
Disponível em: http://www.norme-standard.com/47741/x50-105-aout-1991/.
Acesso em: 3 set. 2013.
Gasnier (2001)
“Conjunto de ações conduzidas para atingir um objetivo, com uma
organização bem definida. Essas ações comportam,
particularmente, fases de estudo e de realização. A aplicação de
uma estrutura de projeto justifica-se desde que o objetivo a atingir
necessite de uma coordenação de atividades transversas –
multifuncionais”.

ISO 10006 (2003)
“Processo único consistente com um conjunto ordenado e
controlado de atividades com data de início e término, conduzido
para atingir um objetivo com requisitos especificados, incluindo
restrições de tempo, custo e recursos”.
Disponível em: http://www.iso.org/iso/catalogue_detail.htm?csnumber=36643.
Acesso em: 3 set. 2013.
PMBOK (2008)
“Esforço temporário empreendido para criar um produto, serviço ou
resultado exclusivo”.
Definição acadêmica (2009)

“Empreendimento único, com início e fim determinados, que utiliza
recursos e é conduzido por pessoas, visando atingir objetivos
predefinidos.”
Conjugando esses conceitos, podemos considerar os seguintes aspectos típicos

de um projeto:
 Temporalidade finita;
 Objeto final definido;
 Uso de recursos no processo de transformação.
Mas se todos os projetos possuem características comuns, o que determina

sua particularidade? Descubra-o a seguir.

Para saber mais sobre a evolução do gerenciamento de

projetos, leia os seguintes textos:
 Gestão de projetos – abordagem conceitual;
 Gerenciamento de projetos – Dissertação de Paula
Torreão.
Projetos singulares
Vamos retomar alguns exemplos de monumentos criados pelo homem que
apresentamos no início da aula – tais como as Pirâmides do Egito, a Grande
Muralha da China e a Torre Eiffel.
Considerando essas construções e o que estudamos até o momento, você

acredita que cada projeto possui SINGULARIDADE9?
Se sua resposta foi positiva, você está correto: a percepção da singularidade

pode estar associada a um objeto único que surge do término de um projeto.
E cada um desses empreendimentos é um objeto particular.
Quando essa observação foi transferida para o modelo industrial, a

singularidade do objeto – PRODUTO –, que se centrava na noção de projeto
único, passou a relacionar-se, também, à ideia de operacionalização.
9
Singularidade
s.f. Qualidade do que é singular, unicidade. Peculiaridade distintiva essencial;
particularidade. Modo extraordinário de pensar, falar ou proceder; excentricidade.
Qualidade do que não é comum; originalidade.
Adaptado de: http://www.dicio.com.br/singularidade/; http://aulete.uol.com.br/singularidade.

Afinal, a produção em escala e a reprodução fidedigna de modelos originais
exigidas pela época demandava essa mudança – passo fundamental para a
garantia de qualidade e de conformidade dos produtos.
Sendo assim, o projeto se configurou como o primeiro passo para a produção

operacional. Isso nos permite diferenciar os conceitos de PROJETO e
OPERAÇÃO.
Veja, a seguir, alguns exemplos de projetos que implicaram operações.
Para saber mais sobre a noção de singularidade aplicada a

contratos públicos no Brasil, veja o conceito de que trata o
Artigo 25, Inciso II, da Lei nº 8.666/93.
Exemplo 1
Considere uma indústria metalúrgica voltada para a construção naval de 1920
que tenha projetado um dique seco para fazer reparos em navios até
determinada tonelagem.
Esse projeto de construção poderia se concretizar no período estipulado de,

por exemplo, 10 anos. A partir desse momento, ele entraria em operação,
ainda que as características do objeto gerado não fossem modificadas – tais
como a obsolescência tecnológica ou o requisito do cliente.
Veja, nesta sequência, a representação do referido projeto:

Obra do dique em andamento.
Projeto do dique terminado recebendo um navio da época.
Observe que o restante da infraestrutura do estaleiro ainda se encontra em

construção.

Dique em configuração mais recente, sem alterações do projeto original de
1920. Sua operação e suas atividades de manutenção ocorreram de forma
contínua e ininterrupta por cerca de mais de 70 anos.
Exemplo 2
O mesmo caso citado no exemplo anterior pode ser aplicado a um objeto
específico e replicável.
Tomemos como base um produto que esteja em produção por mais de 80

anos e que tenha sofrido pouquíssimas mudanças em relação ao projeto
original.
Na indústria, encontramos muitos produtos desse tipo que ainda se mantêm

atualizados no mercado em relação ao cliente que os utiliza.
Veja, por exemplo, a evolução da propaganda do Biotônico Fontoura – produto

que continua em linha de produção até hoje:

Para saber mais sobre o produto Biotônico Fontoura, conheça a

empresa que controla sua produção e distribuição:
Hypermarcas.
http://www.hypermarcas.com.br/marca_medicamento.php?id=190
Atividade proposta
Ambos os exemplos apresentados anteriormente nos remetem à singularidade
dos produtos. Assim como esses casos, há diversas situações similares no
mercado.
Vamos, agora, ampliar essa perspectiva de singularidade em um projeto,

aproveitando o exemplo 2 que acabamos de analisar.
Ao longo de mais de 100 anos de produção, observamos inúmeras mudanças

na forma de apresentação do produto Biotônico Fontoura ao consumidor. Em
virtude dessas alterações, o que caracterizaria a singularidade de seu projeto
original?

Mudanças de subsistemas
Combinando as dimensões de singularidades expostas neste estudo, é possível
entender como a indústria aplicou o gerenciamento de projetos ao longo da
segunda metade do século XX.
O objetivo era não só gerar produtos mas também deixar de lado a

necessidade de reinventá-los a cada mudança acarretada pelo tempo.
Uma decorrência direta e atual dessa atitude envolve os grandes

conglomerados fabris – como, por exemplo, os produtos da KIA e da Hyundai.
Desde o final do século passado, ambas as fábricas compartilham

infraestrutura fabril e mantêm produtos finais diferenciados – cada qual com
um projeto individualizado.
A perspectiva de compartilhamento a que nos referimos acabou sendo

sedimentada pela concepção sistêmica que, desde o final da década de 60,
vem permitindo conceber as organizações como sistemas abertos que
interagem com o ambiente.
Em outras palavras, a empresa é vista como um conjunto de partes que forma

um todo com elevado grau de interdependência e objetivos predefinidos. Cada
parte, por sua vez, comporta-se como um subsistema desse todo no qual está
inserida.
Logo, as mudanças que ocorrem em determinados processos dentro de

empresas representam alterações desses subsistemas, e não dos sistemas
maiores a que pertencem.
Por isso, é possível que haja projetos voltados apenas para modificações
pontuais, sem que toda a organização precise apresentar um resultado

finalístico novo – e sim mais rentável ou que melhor atenda aos requisitos do
ambiente.
Para saber mais sobre as marcas coreanas da Kia e da

Hyundai, que iniciaram, em 2011, o processo de operação de
suas unidades no Brasil, leia a notícia Hyundai e Kia
exportaram mais de 2 milhões de veículos em 2011.
Atendimento ao cliente
A crescente difusão do conceito de empresa como conjunto de subsistemas
trouxe benefícios à produtividade e à eficiência na indústria. E essa
flexibilidade se estendeu, também, ao consumidor.
Além da percepção de que a singularidade estava relacionada aos projetos e

aos processos que envolviam sua operação, surgiu uma nova visão associada à
personalização do produto para o cliente.
Agora, o foco estava na customização do projeto original para atender às

exigências dos consumidores.
Como exemplo de empresa que tomou essa atitude em relação a seu público-
alvo, podemos citar a Fiat, que, em 2010, enfatizou a possibilidade de o cliente
escolher entre mais de 9 milhões de combinações de seu produto, permitindo-
lhe obter um carro efetivamente único.

Atenção
Embora compartilhassem recursos na realização de processos que

levavam à geração do produto, muitas vezes, as organizações se
deparavam com requisitos ÚNICOS em função do atendimento
oferecido ao cliente.
Para saber mais sobre a atitude da Fiat em prol da atração de

clientes, leia o anúncio oficial de customização de seus
produtos divulgado em 2010: Novo Uno. Novo Tudo.
Prestação de serviços
Atualmente, podemos aplicar a concepção de singularidade não apenas ao
atendimento ao cliente, através da personalização de produtos, mas também à
área de prestação de serviços. Nesse caso, a possibilidade de customização vai
muito além dos elementos fabris.
Mas você deve estar se perguntando: como associar projetos a essa

perspectiva?
Ora, no momento em que um contrato é firmado – formalmente e de modo

consensual – entre o cliente e o prestador de serviço, determinam-se os
requisitos do consumidor bem como os direitos e as obrigações das partes.
Por definição, um contrato é único em função dessas obrigações. É justamente

essa singularidade do objeto contratual que aparece na aplicação mais recente
do gerenciamento de projetos dentro das organizações.

Todo contrato pode gerar para o contratado a criação de um projeto voltado
para o atendimento da singularidade ali acordada com o cliente.
Ancorado nessa particularidade, o contratado pode gerir seu negócio por

projetos, ainda que este seja baseado em processos sistematizados e
compartilhe recursos em sua infraestrutura.
Um exemplo que tanto pode ser aplicado na área pública quanto na privada é
a terceirização de serviços de limpeza.
Da ótica do contratante, trata-se de uma operação – atividade rotineira –,

mas, na visão do contratado, esse projeto está associado à singularidade que
rege a terceirização na forma de um contrato.
Momento pesquisa
Ao longo deste estudo, identificamos situações do passado similares àquelas
em que, atualmente, aplicamos o gerenciamento de projetos.
A partir dos exemplos expostos, pesquise, na região em que vive, casos

semelhantes e compartilhe-os com seus colegas no Fórum de discussões –
apresentando relatos, fotos, vídeos ou links sobre o assunto.
Exercícios de fixação
Questão 1
O Coliseu de Roma foi construído entre os anos 70 e 90 d.C. Iniciado por
Vespasiano e inaugurado, mais tarde, por Tito, esse empreendimento colossal
podia sustentar cerca de 50.000 espectadores em seu interior – em três
andares de edifício.

Esse local funcionou como área de entretenimento para a cultura vigente da
época por quase 500 anos. Comparando sua construção com os modelos
contemporâneos, podemos considerá-lo:
a) Uma operação de edificação.

b) Um projeto, somente após sua inauguração.
c) Um projeto, ainda que tenha demorado cerca de 20 anos para ser
finalizado.
d) Um pseudoprojeto, porque não ficou pronto durante o período de
governo de Vespasiano.
e) Uma operação, pois o período de construção foi inferior ao tempo em
que ficou em funcionamento.
Questão 2
De acordo com Dinsmore (2009), um empreendimento único – com início e fim
determinados – que utiliza recursos e é conduzido por pessoas, visando atingir
objetivos predefinidos, é chamado de:
a) Projeto
b) Atividade
c) Operação
d) Metodologia
e) Singularidade
Questão 3
O conceito de singularidade nos leva à identificação da existência de
determinado objeto que possui:
a) Um projeto único.
b) Múltiplos projetos.
c) Múltiplas operações.
d) Uma operação única.

e) Múltiplas metodologias.
Referências
DINSMORE, P. C. Como se tornar um profissional em gerenciamento de
projetos. Rio de Janeiro: Qualitymark, 2009.
GASNIER, D. G. Gerenciamento de projetos. 2. ed. São Paulo: IMAM, 2001.
GREENHALGH, J. O arsenal de Marinha do Rio de Janeiro na história:

1763-1822. Rio de Janeiro: A Noite, 1951. v. 1.
KAPLAN, R. S.; NORTON, D. P. Mapas estratégicos – convertendo ativos

intangíveis em resultados tangíveis. Rio de Janeiro: Elsevier, 2004.
PROJECT Management Institute. Um guia do conhecimento em

gerenciamento de projetos – Guia PMBOK. 4. ed. São Paulo: Saraiva, 2008.

Aula 2: Conceitos básicos
Introdução
Na construção de uma metodologia e em sua aplicação, o conhecimento dos
conceitos relacionados é fundamental tanto para se entender a dinâmica
metodológica quanto para permitir que customizemos a metodologia para
nossa realidade percebida e impactada, fazendo com que ela seja
efetivamente atuante no nosso sistema empresa.
Nesta aula, você identificará os principais conceitos relacionados ao

gerenciamento de projetos e suas definições utilizadas.
Definiremos as estruturas organizacionais envolvidas em um projeto e

conheceremos o ciclo de vida de um projeto.
Objetivo:
 Conhecer os conceitos básicos relacionados ao Gerenciamento de
Projetos;
 Definir as estruturas Organizacionais em projetos;
 Identificar os elementos que compõe o Ciclo de Vida de um Projeto.
Conteúdo
Introdução
Agora que vimos não só a evolução do conceito de projeto como a sua
definição atual e entendemos melhor como a questão da singularidade afeta a
percepção do que pode ser um projeto, vamos detalhar alguns conceitos
gerais relacionados ao gerenciamento de projetos.

Conceitos básicos relacionados ao Gerenciamento de Projetos
Conhecendo o conceito de um projeto, podemos associar a este conceito os
aspectos relacionados à natureza da atividade de gerenciamento de projetos.
Alguns pontos são bem identificados como:

 O projeto não existe a partir da organização que o suporta, mas decorre
de uma necessidade de mercado ou instituição;
 Todo projeto possui objetivo bem definido e que resulta em uma
tangibilidade, ainda que ela apresente detalhamento;
 O projeto possui início, meio, e fim bem definido;
 Não se deve confundir projeto com operação. Esta é rotineira e/ou
repetitiva e o projeto é singular;
 Projetos consomem recursos humanos, financeiros e materiais ao longo
do tempo;
 As escolhas estratégicas que balizaram o projeto podem gerar conflitos
frequentes entre qualidade, custo e prazo; e
 Como decorrência de seu ciclo finito, os recursos não gastos e
incorporados ao objeto finalístico são dispersados após o término do
projeto.
Podemos relacionar projetos com diferentes sistemas de produção sem que

deixemos de ter aplicabilidade. Podemos aplicar projetos de linha de produção
em modelos de produção em massa como por exemplo em indústria
alimentícia ou têxtil.
Também podemos aplicar a visão de projetos em modelos de produção em

lote, como por exemplo na indústria de equipamentos ou montadoras como
também no caso de produções de baixo volume e grande porte como obras de
engenharia e indústria naval
E para fazermos gerenciamento de projetos, a organização precisa ter alguns

requisitos?

Embora ao longo desta aula vamos estudar alguns modelos de estrutura que
facilitam a gerencia de projetos nas organizações, podemos pensar nestas
condicionantes de forma mais ampla.
Ao buscarmos gerenciar por projetos também vamos estar incorporando boas

práticas à organização que se ainda não as tem, vai precisar implementa-las.
Vejamos algumas destas boas práticas que se tornam decorrentes depois de
implantarmos uma gerencia por projetos:
 Foco na melhor e constante escolha de estratégias;
 Reconhecimento da necessidade de ferramental de planejamento;
 Incorporação da governança corporativa ao modelo de gestão;
 Mapeamento, padronização e integração de processos;
 Sistema de métricas integrado ao planejamento e controle da ação
planejada;
 Compromisso com a garantia da conformidade dos processos;
 Eficiência na alocação de recursos disponíveis
Diferença de Processo para Projeto

Em função das próprias similaridades que vão surgindo entre processos e
projeto pois todo o projeto tem processos, mas nem todo o processo é
projeto, surge a questão:
Como diferenciar?
Processo sempre vai ser contínuo e repetitivo enquanto uma determinada

estrutura o suportar enquanto o projeto vai ter uma definição clara no tempo,
ser singular e a estrutura é suportada pelo projeto, que se extinto leva junto a
estrutura.
Ambos tem a utilização dos recursos disponíveis como fator limitante e devem
ser planejados, escutados e controlados, sendo geridos por pessoas.

Por exemplo:
Em uma organização que execute múltiplos projetos simultâneos, parte da
estrutura existe apenas enquanto determinado projeto existir e outra parte
existe para suportar processo de rotina que são utilizados por qualquer projeto
que exista ou venha a existir, como o caso de uma setor de aquisições em
uma organização que opera por projetos.
Independente do ciclo de vida de determinado projeto, qualquer projeto

precisará fazer aquisições, então a organização precisa sistematizar um
processo de aquisições para atender diversos projetos.
Programa
Uma forma de gerenciar a complexidade de uma determinada situação é
integrar projetos que possuem objeto específico em um programa que agrupa
projetos de forma coordenada que busca gerar vantagens no atingimento
conjunto dos projetos.
Podemos ter esta situação quando o objeto resultante é integrado ou faz parte
de uma relação maior com determinado cliente, ou quando temos forte
compartilhamento de recursos que ao serem geridos de forma integrada tem
sua eficiência potencializada.
Carteira de Projetos (Portfolio)

Podemos considerar o coletivo de projetos. No caso a diferença do portfólio
para um programa é que a ideia de um portfólio é mais abrangente. Podemos
ter no portfólio conjunto de projetos e programas de uma mesma empresa ou
de uma mesma área da empresa.
Normalmente associamos uma estrutura relacional ao portfólio para

entendermos melhor as relações que podem existir entre seus componentes.
Sendo basicamente uma estrutura que contem projetos, programas e seus
agrupamentos locais, setoriais e corporativos.

O próprio entendimento da composição desta carteira pode não ser de
concepção simples. Veja a seguir dois estudos de caso de implantação de
gerenciamento de portfólio:
 Estudo de caso – Gerenciamento de portfólios de projetos (UTFPR)
 Gerenciamento do portfólio de projetos (PPM)
Subprojeto
Assim como os programas agrupam projetos para melhor gerencia-los face a
complexidade, podemos subdividir um projeto, como faríamos com um
sistema, em partes menores chamadas subprojetos .
Isto é muito útil por exemplo quando percebemos ser vantajoso terceirizar
parte do projeto, enquadramos esta parte como um subprojeto e como vimos
na aula anterior, a singularidade do contrato firmado com a terceirizada
garante que esta subdivisão mantenha atendimento com o restante do
projeto.
Podemos também fazer esta subdivisão quando podemos definir claramente

um membro da equipe para gerenciar uma parte bem identificada do projeto.
Stakeholders
O PMBOK 5 não só destacou, como elevou o status das partes interessadas
(stakeholders) face a importância que tem.
Podemos defini-los como organizações, grupos sociais ou indivíduos que além

de estarem ativamente envolvidos no projeto, podem ter interesses que sejam
afetados (positiva ou negativamente) pela execução ou inexecução do projeto.
Entendemos também que eles podem exercer influência sobre o projeto ou até
sobre seus resultados.

O gerente de projeto e sua equipe não só devem conhece-los, como
acompanhar suas necessidades e até mesmo buscar influenciá-los para
garantir o resultado esperado do projeto.
Embora possamos ter partes interessadas peculiares a uma organização ou

projeto, na maioria das vezes podemos agrupa-las em grupos afim.
Segundo XAVIER (2010), devemos fazer em seis grupos distintos:

“
 Gerente de Projeto: pessoa responsável pelo gerenciamento do projeto;
 Cliente: Pessoa ou organização que solicitou ou contratou produto ou
serviço do projeto;
 Membros da equipe: pessoas que compõe a equipe do projeto;
 Organização executora: empresa em que o projeto está sendo
executado;
 Patrocinador (sponsor): Pessoa ou grupo. Dentro ou fora da
organização executora, que provê recursos financeiros e/ou apoio
institucional para a execução do projeto; e
 Usuário: pessoa ou organização que irá utilizar o produto ou serviço do
projeto. “
Para entendermos melhor o conceito estudado até aqui, vejam os artigos

indicados nos links a seguir:
 Relacionamento entre empresa e stakeholders
 Análise de stakeholders
 Stakeholders e Desempenho Empresarial
Escritório de Projetos
Segundo o PMBOK, um escritório de projetos ou PMO (Project management
office), é uma unidade Organizacional que centraliza e coordena o
gerenciamento de projetos sob o seu domínio.

Aproveite para ler um dos seis artigos relacionados a escritórios de projetos
constantes no nosso Aprenda Mais.
Influência dos modelos de estruturas organizacionais em

gerenciamento de projetos
Qual o impacto que uma estrutura organizacional tem em um projeto?
Primeiro temos que considerar o grau de dependência dela ao próprio projeto.

a) No caso de um projeto constituir a própria ordenação jurídica da
organização (CNPJ próprio), a estrutura dele se confunde com a própria
organização e neste caso a modelagem da estrutura vai ser diretamente
desdobrada a partir da própria estrutura do projeto.
b) Na maioria das situações o projeto vai ter uma relação de dependência
com parte ou partes das estruturas da organização que o promove.
Vamos ampliar então a percepção desta segunda situação. Inicialmente um

gerente de projetos deve entender em que tipologia de organização ele está
inserido, até porque muitas vezes não será ele que vai definir a estrutura
organizacional da organização à qual o projeto está vinculado.
Embora tenhamos diversas tipologias de estruturas organizacionais podemos

centrar nosso foco de comparação em três delas: a funcional, a por projetos e
a matricial.
Estrutura Funcional
A estrutura funcional, é um dos modelos mais tradicionais e utilizado a quase
um século. Sua concepção básica envolve o agrupamento de atividades por
funções que são agrupadas por áreas de similaridades. O conceito comum
deste agrupamento é o departamento.
Como vantagens conhecidas podemos citar:

“
 Membros da equipe se reportam a somente um Gerente funcional;
 Os recursos similares são centralizados;
 As empresas são compostas por funcionários especialistas;
 A definição de carreira é muito clara e está de acordo com a
especialização técnica.”
Dinsmore (2009)
Como podemos constatar, as vantagens não são muitas nem se percebe

claramente seu impacto no projeto em si. Em situações em que a organização
possui projetos ocorrendo de forma sequencial e um de cada vez, estas
vantagens podem ser suficientes para obter-se resultados.
Um ponto notável neste tipo de organização é que o gerente de projeto não

tem um lugar explicitado na estrutura e normalmente acumula a função de
gerente de projeto com outra departamental que possui na estrutura
funcional.
Ela possui assim algumas desvantagens conhecidas. Vejamos agora as

identificadas por HELDMAN (2005):
“
 Os Gerentes de projeto costumam ser também gerentes funcionais:
Isto costuma puxar o gerente em várias direções e pode prejudicar os
projetos por falta de atenção. Se o gerente do projeto não for também
gerente funcional, a equipe do projeto pode não respeitar a sua
autoridade.
 Camadas de burocracia:
Esta estrutura torna mais lento o andamento do projeto, em razão da
demora para obter aprovação ou tomar decisões.
 Competição pelos recursos:

Quando se assumem diversas prioridades e projetos, um determinado
departamento pode desgastar-se com o tamanho do fardo, o que pode
prejudicar todo o trabalho.
 Os gerentes de projeto tem autoridade Limitada:
Os gerentes de projetos de organizações funcionais em geral dependem
muito das habilidades de negociação para obter recursos dos gerentes
funcionais. Também possuem pouca ou nenhuma autoridade para
delegar poderes aos membros da equipe. “
Exemplo gráfico de Estrutura Funcional:
Fonte da imagem: PMBOK 4 : 2.4.2
Estrutura por projetos

Estas estruturas são verticalizadas em relação ao projeto. Cada projeto está
ligado diretamente ao primeiro escalão da organização e as funcionalidades
são pertencentes ao projeto e segregadas nele.
Neste tipo de estrutura o Gerente de projetos tem efetivamente autoridade

sobre toda a estrutura que se desdobra a partir dele, o que permite que esta
estrutura priorize especificamente o projeto na qual está dependente.

Muitas vezes as organizações se estruturam desta forma quando a médio
prazo as estruturas organizacionais possuem componentes geográficos e/ou
por produtos e/ou divisionais. Assim o projeto surge com sua estrutura
segregada e ao seu término e inicio de operação, a estrutura já está
posicionada na organização. Vale por exemplo para organizações que planejam
possuir diversas unidades fabris dispersas geograficamente, onde cada
unidade fabril se inicia como um projeto específico em sua estrutura antes de
se tornar operação.
Dinsmore (2009) identifica algumas vantagens deste tipo de estrutura:

“
 Foco no projeto;
 Comunicação mais efetiva do que na estrutura funcional;
 Os membros das equipes se reportam apenas a um gerente; “
Também observamos este tipo de estrutura em organizações que atuam em

projetos que apresentam especificidades onde o compartilhamento de
funcionalidades com outros projetos não gera centralização de recursos.
Uma utilização que vem crescendo muito mas ultimas décadas é a utilização
deste tipo de estrutura em organizações que são contratadas como
prestadoras de serviços (cada projeto é um contrato) ou que são contratadas
pela área pública para a realização de um projeto de forma inteiramente
terceirizada em sua execução (sabemos pelo preconizado na 8.666/93 que não
se pode terceirizar a elaboração e a execução de um projeto para a mesma
empresa).
Temos identificadas também várias desvantagens nesta tipologia, HELDMAN

(2005) explicita as seguintes:
“
 Reescalação dos membros de equipes:

Encerrado o trabalho do projeto, os membros da equipe precisam
procurar novas atribuições. Pode não haver outro projeto
imediatamente disponível para alocá-los.
 Tempo ocioso:
Os membros da equipe com habilidades especializadíssimas talvez
somente sejam necessários em certas ocasiões para realizar atividades
específicas no projeto. O que fazer com o tempo livre deles é problema
difícil de resolver neste tipo de organização;
 Concorrência:
Os gerentes de projeto disputam entre si os melhores recursos
disponíveis dentro da organização ao formar suas equipes e ao obter os
recurso materiais e de suporte de serviços. Isto pode ser negativo par
ao cliente externo que tiver o azar de ficar com um gerente de projeto
que não seja o mais afortunado.”
Exemplo gráfico de Estrutura por projetos:

Estrutura Matricial
Uma solução interessante para minimizar as desvantagens e potencializar as
vantagens existentes nas estruturas funcionais e por projetos vem sendo
utilizada a mais de 50 anos e é conhecida como organização matricial.
Nestes tipos de estrutura o Gerente de projetos e os gerentes funcionais tem

um status hierárquico similar e uma vez constituído o projeto os gerentes de
projeto exercem autoridade sobre as equipes que estão constituídas para o
projeto.
Nestes modelos utilizam-se três modelagens matriciais: A matricial fraca, a

matricial forte e a matricial balanceada.
Vejamos cada uma delas a seguir:

a) Estrutura matricial fraca
Nesta estrutura o gerente de projeto embora constituído , parece mais com
um coordenador do projeto do que com um gerente. Ele inclusive pode não ter
dedicação de tempo integral ao projeto e por isto este modelo acaba sendo
muito parecido com o funcional.

b) Estrutura matricial balanceada e matricial forte
Nestas duas modelagens a figura do gerente de projetos é bem identificada e
com autoridade definida permanentemente na estrutura. O grau de vinculação
da equipe com o gerente é elevado e na maioria das situações o gerente do
projeto exerce mais autoridade sobre a equipe do que o seu respectivo
gerente funcional.
HELDMAN(2005) aponta algumas vantagens e desvantagens deste modelo:
“Vantagens:
 Foco da organização é o projeto;
 Podem surgir habilidades especializadas no projeto que são
disseminadas para toda a organização;
 Oportunidades de evolução de carreira para os membros das equipes
entre as partes das estruturas
Desvantagens:
 Mais de um chefe para os membros das equipes;
 Risco dos membros das equipes confundirem prioridades de trabalho
entre as orientações do gerente de projetos e dos gerentes funcionais;
 Aumento de conflito entre gerentes;”

Comparação entre a tipologia organizacional estudada

Podemos confrontar as principais características do projeto com cada uma
destas estruturas organizacionais e obter uma tabela comparativa como
exemplificado a seguir:
Estruturas Compostas
Embora as tipologias muitas vezes sejam utilizadas no seu formato de
concepção, no mundo real elas podem ser hibridizadas em função de
características específicas de determinada área de negócios ou até mesmo de
aspectos relacionados à cultura organizacional vigente.
Assim, podemos ver estruturas funcionais que em parte delas tenhamos

setores que operem em seu interior por projetos, ou estruturas matriciais
fortes, que cada gerente de projetos tenha uma estrutura funcional própria,
não do projeto mas de sua gerência de projetos

A todos estes modelos híbridos denominamos:
Estruturas compostas
Nas situações de maturidade de implantação do gerenciamento de projetos, as
organizações já perceberam que a tipologia estrutural é mera decorrência dos
requisitos dos clientes associada a uma conveniência gerencial administrativa e
que o fluxo de poder é emanado pelo que foi negociado no projeto com seu
cliente e/ou financiador.
Lerner (2011), explicita isto na seguinte forma:

“No ambiente de projeto atual, a autoridade máxima geralmente
fica com o patrocinador, e qualquer autoridade concedida ao
gerente de projeto [e definida nos termos de abertura de projeto.
Embora autoridade formal seja importante para o cargo de gerente
de projeto, os gerentes e executivos perceberam que o
gerenciamento de projetos funciona bem quando o foco é
direcionado não à autoridade formal, mas ao trabalho em equipe, à
comunicação, a cooperação, à confiança e aos objetivos do
projeto.”
Sucesso do Projeto
De que adianta gerenciar o projeto se ele não tem sucesso. Mais do que
atingir o resultado esperado, ter sucesso em um projeto implica em aspectos
que na maioria das situações extrapolam o próprio projeto como:
 Fidelização do cliente em outras relações de negócios;
 Aumento de participação no mercado com a potencialidade de novos
clientes;
 Maturidade no negócio e possibilidade de redução do tempo de entrega
dos projetos futuros;
 O cliente passar a ser o seu veiculo de publicidade.

Atividade proposta
A partir dos conceitos estudados, pesquise a estrutura de duas organizações
que apresentem estruturas distintas entre si para que possa comparar cada
estrutura com as tipologias estudadas e compartilhe com seus colegas no
fórum de debates, compartilhando relatos, fotos, vídeos ou links.
Aprenda Mais
Leia o artigo Gerenciamento de projetos na administração publica.
Leia o edital do SESI Projeto de implantação de EP.
Leia o artigo Escritório de Projetos: Uma Visão Geral.
Leia o artigo Implantação de EGP em pequenas e médias empresas .
Leia a tese Estruturas organizacionais da FGV.
Questão 1
Luidge tem pouca experiência , mas foi admitido como gerente de projeto. Ele
irá trabalhar em uma empresa de estrutura matricial e, sendo assim, qual deve
ser a expectativa dele quanto à comunicação:
a) Simples
b) Aberta e exata
c) Complexa
d) De fácil gerência
e) Centralizada

Questão 2
Juarez, patrocinador do projeto solicita uma reunião ao Rafael, gerente do
projeto, para verificar o andamento. Rafael tem dificuldade para reunir a
equipe para coletar informações pois a sua empresa deu prioridade a outros
projetos em andamento. Neste caso a estrutura na qual Rafael está inserido:
a) provavelmente é a matricial forte.

b) não pode ser de forma alguma a funcional.
c) tanto pode ser a matricial forte quanto a funcional pois se comportam
de forma similar.
d) provavelmente é a funcional.
e) é a matricial balanceada.
Questão 3:
O conceito estudado de Portfólio é entendido como:
a) Conjunto de programas e projetos.

b) Um tipo de estrutura.
c) Uma lista de subprojetos.
d) Um dos principais stakeholders.
e) Um projeto único.
Referências
DINSMORE, Paul C. Como se Tornar um Profissional em Gerenciamento
de Projetos, Ed. Qualitymark, Rio de Janeiro, 2009
XAVIER, Carlos Magno e outros. Metodologia de Gerenciamento de

Projetos METHODWARE, BRASPORT, Rio de Janeiro, 2010.

HELDMAN, Kim. Gerência de Projetos: Fundamentos: Um guia prático para
quem quer certificação em Gerência de Projetos, Ed. Elsevier, Rio de Janeiro,
2005
KERZNER, Harold. O que os Executivos precisam saber sobre

gerenciamento de projetos, Ed. Bookman, Porto Alegre, 2011.

Aula 3: Ciclo de vida do projeto
Introdução
Na construção de uma metodologia e em sua aplicação, o conhecimento de
sua dinâmica de fluxo e impactos que vem gerando mudanças ao longo do
tempo é fundamental tanto para se perceber como esta dinâmica afeta o
projeto, quanto a própria metodologia.
Nesta aula conheceremos o ciclo de vida do projeto, detalharemos a sua

estrutura e identificaremos como o Gerenciamento de Projetos Mudou para
projetos orientados a valor.
Objetivos:
 Entender o conceito de ciclo de vida do projeto;
 Detalhar a estrutura do ciclo de vida do projeto;
 Identificar os elementos que vem tendo mudança no gerenciamento de
Projetos.
Conteúdo
Introdução
Depois de termos estudado na aula anterior os principais conceitos associados
a gerenciamento de projetos e antes de iniciarmos aspectos estritamente
metodológicos estaremos nesta aula estudando a dinâmica de fluxo do
projeto, centrando nosso foco no ciclo de vida, tanto do projeto quanto do
gerenciamento do projeto.
Pensar em dinâmica de fluxo é essencial ao gerenciamento de projetos (e ao

gerente) pois permite que percebamos o projeto ao longo do tempo, não como
uma sequencia de etapas e atividades interdependentes, mas como um

conjunto que caminha no espaço tempo sofrendo transformação durante este
percurso.
Isto vai evidenciar para nós alguns aspectos peculiares a determinados

momentos e nos fazer entender melhor como gerenciar o projeto.
Inicialmente vamos abordar os conceitos relacionados ao ciclo e em seguida

confronta-los com as dinâmicas de fluxo que iremos abordar.
Elementos Conceituais do Ciclo de Vida do Projeto

Como já vimos, por definição, um projeto possui inicio e fim definidos e
podemos compô-lo com fases intermediarias que definem se ciclo de vida.
Vamos então começar com o próprio conceito de Ciclo de vida do Projeto,

segundo o PMBOK 4:
“Um conjunto de fases de um projeto, geralmente em ordem

sequencial, e que às vezes se sobrepõe, cujo nome e numero são
determinados pela necessidade de gerenciamento e controle da(s)
organização(ões) envolvida(s), a natureza em si e sua área de
aplicação. Um ciclo de vida pode ser documentado por
metodologia.”
Se observarmos diversas área de mercado vamos observar que muitas delas

usam terminologias de ciclos especificas e ajustadas para a área.
Podemos citar como exemplo a área de construção, onde é comum que o ciclo
de vida seja representado pelas fases:
 Viabilidade;
 Planejamento;
 Desenho;

 Construção; e
 Entrega
Ou então uma área de P&D de uma corporação, onde o ciclo de vida de uma
pesquisa é representado pelas fases de:
 Definição;
 Estudo de Viabilidade;
 Pesquisa;
 Seleção de Tecnologias / Fornecedores;
 Implementação ou Construção;
 Implantação;
 Acompanhamento Inicial da Operação; e
 Fechamento do Projeto.
Nas áreas de marketing para desenvolvimento de novos produtos e

representado pelas fases:
 Concepção;
 Pesquisa;
 Design;
 Contratação;
 Fabricação do Protótipo; e
 Fechamento do projeto.
Se estivéssemos atuando em uma área de promoção de eventos, teríamos as

fases de:
 Concepção;
 Preparação do Evento;
 Realização do Evento; e
 Fechamento do Projeto.
(Exemplos adaptados de XAVIER – 2010)

Assim, observamos que cada fase está relacionada a um conjunto de
atividades que guardam similaridade entre si e que podem ser relacionadas de
uma forma racional, centrada na entrega que o projeto como sistema busca
atingir. Por isto muitas vezes associamos as fases do ciclo a pontos técnicos de
atenção, relacionados ao objeto singular do projeto.
Se focarmos desta forma (técnica) não teremos uma única e melhor forma de
representar estas fases. Mas se pretendemos buscar uma metodologia de
gerenciamento devemos buscar as fases que compõe um ciclo de
gerenciamento, pois assim não incorporamos a questão técnica na
metodológica e focamos no ciclo do projeto como processo sistêmico.
Na figura a seguir, podemos verificar que uma forma interessante de fazer

esta correlação é associarmos o eixo tempo a uma função de concentração de
similaridades, que podemos denominar “volume de atividades” e ao longo
deste fluxo de tempo estabelecer um sistema de métricas de controle que nos
retornem informações desta dinâmica de fluxo.
GIDO (2010)
Uma percepção sistêmica interessante é se posicionarmos este ciclo do projeto

como parte de algo maior que envolva o ciclo de operação do objeto produzido

pelo projeto (visão típica do modelo industrial de projetos). Veja a
representação gráfica disto na figura a seguir:
(GIDO2010)
A solução metodológica indicada no PMBOK 4 busca atender a questão do

distanciamento do fluxo específico técnico de um projeto em relação ao seu
fluxo gerencial e aglutina, em quatro fases, esta percepção:
 Inicio do Projeto;
 Organização e Preparação;
 Execução do trabalho do projeto; e
 Encerramento do Projeto.
(PMBOK 4 – item 2.1.1)
Visualmente se associarmos o conceito anteriormente estudado de função de

volume de atividades ao volume acumulado de custos, obteremos uma
representação do ciclo similar à indicada a seguir.

Podemos indicar que tudo começa quando surge uma necessidade,
normalmente identificada e demandada pelo cliente. Normalmente estes
requisitos são formalizados por uma chamada de propostas (CP), do inglês
“request for proposal” (RFP). Mas também vemos inúmeras situações onde isto
não é claramente formalizado
Uma vez estudado e analisado o que o cliente demanda, produzimos uma

proposta que contém já definida uma estrutura, o que representa o final da
segunda fase exemplificada na figura anterior.
Uma vez tendo esta estrutura tendo sido acordada e formalizada podemos
passar para uma terceira fase que representa a implementação e execução
deste planejamento e ela dura tanto quanto for a complexidade do projeto.
Por último e com a finalidade de concluir o objeto singular do projeto temos

uma fase de encerramento, cujo objetivo é efetuar todas as conclusões
necessárias para que entregue o objeto, o projeto se encerre.
Mas para termos uma metodologia estruturada, cada uma destas fases deve
ter um detalhamento do que se espera dela. O PMBOK 4 definiu para isto um
conjunto de processos de gerenciamento de projetos que representam uma

visão por grupos de processos, mas que não guardam uma relação linear com
as fases do projeto.
Veremos isto de forma mais detalhada na aula 4. Por enquanto, vamos

desdobrar a visão da dinâmica de fluxo e sua relação com a agregação de
valor e mudança em um projeto.
Impactos na dinâmica de fluxo do ciclo de vida de um projeto

Nesta sequência vamos explicitar algumas relações que geram impacto na
dinâmica de fluxo do tempo de ciclo de um projeto
Uma primeira abordagem, envolve relacionar o percentual de término do

projeto com o seu ciclo no tempo. O início de um projeto por possuir diversos
processos que envolvem analise cognitiva e entendimento do objeto tende a
ter um fluxo lento.
Na medida em que se estrutura o projeto e que se executa tarefas dentro de

uma estrutura montada, o fluxo tende a se inverter e se tornar rápido (muito
mais rápido do que no início). Próximo do encerramento, em função do
incremento de atividades de controle e ajustes finos a tendência do fluxo é
voltar a se tornar lento, diminuindo a velocidade quanto mais próximo do final
do projeto estamos.
Algumas atividades de desmobilização também contribuem para isto por serem

morosas e não agregarem percentual de conclusão ao objeto.
Na figura a seguir podemos verificar visualmente esta dinâmica:

Adaptado de KERZNER (2011)
Outra dinâmica é confrontar o tempo com o nível de esforço dispendido no

projeto. Podemos perceber na figura a seguir como o volume de esforço está
concentrado no período de execução do projeto, onde as atividades
estruturadas dão a tônica da demanda.
Relacionando com o que vimos na figura anterior podemos relacionar que o

nível de esforço maior também está associado a uma velocidade maior de
atingimento de conclusão do projeto.
Como decorrência deste confronto, a taxa de eficácia de se adicionar esforço

ao projeto decai na medida em que aumenta o grau de conclusão do mesmo.
Isto deriva de que na medida em que concluímos o projeto, as atividades em
execução contribuem proporcionalmente menos com a o todo gerado.
Podemos evidenciar esta relação na figura a seguir:

Uma consequência do confronto visto anteriormente (esforço no tempo e
potencial de adicionar valor com este esforço) é que quanto mais próximo do
final de um projeto estamos, maior é o custo do ajuste (mudanças ou
correções) no projeto, justamente, pois a taxa de esforço sobre o que falta
para terminar um projeto gera necessidade de esforço crescente para menor
adicional.
Podemos evidenciar isto na figura a seguir:
Uma outra consideração que podemos ter relacionada a dinâmica do fluxo no

ciclo é confrontar a incerteza e risco com o tempo. Na medida em que
caminhamos no fluxo do ciclo do projeto, os riscos e incertezas decaem. Isto
também implica em uma menor pressão nos custos associados a ajustes ou
pequenos retrabalhos.

Veja na figura a seguir uma esquematização deste confronto entre risco e
quantidade arriscada. O interessante é que o maior risco ainda ocorre quando
o projeto pouco se materializou.
Este conceito está fortemente sedimentado na pratica de mercado e a própria

legislação pública na forma do art. 56 da LEI 8.666/93 (lei de licitações e
contratos) prevê a existência de garantia do contrato para arcar com eventuais
riscos decorrentes de sua execução, a qual se associa além do percentual
definido em lei, o valor do objeto tangível que faça parte do contrato, quando
ele está sob a guarda do contratado (fiel depositário).
Analisando esta dinâmica de fluxo no tempo podemos ainda perceber outras

relações que terão ligação com performance ou custos. Uma destas relações
possíveis e identificarmos para determinada natureza de objeto qual a melhor
duração do ciclo do projeto para termos os custos totais minimizados. Este tipo
de entendimento permite que ao modelarmos a estrutura do projeto no
planejamento busquemos um ponto ótimo na duração.
Na figura a seguir, podemos ver de forma esquemática gráfica, este ponto

onde obtemos a melhor relação de custo x benefício:

E de uma forma similar e pensando complementarmente, onde obtemos a

melhor performance em relação ao tempo do ciclo. Como pode ser visualizado
a seguir:
Outra percepção interessante no ciclo é associarmos a curva de esforço no

tempo vista inicialmente com a aplicação de pessoal no projeto. Embora esta
seja uma percepção bem antiga do ponto de vista de projetos industriais, no
modelo industrial típico, fazíamos esta associação como curva de carga de HH,
notadamente de HH direto. No caso de projetos que utilizem intensamente HH
na sua execução, esta relação continua válida, mesmo que não seja uma

atividade industrial (pode ser uma prestação de serviços com uso intenso de
HH).
Mas, contemporaneamente precisamos considerar todas as aplicações de

pessoas, sejam laborais no tempo (apropriação de HH), de supervisão e
controle e as cognitivas. Podemos agrupar estas ideias na forma de
habilidades humanas requeridas e confronta-la com habilidades técnicas.
A figura a seguir ilustra esta relação:
Adaptado de HELDMAN (2005)
Também como decorrência desta percepção da interação humana, se

confrontarmos as exigências de performance com a geração de
conflitos/ansiedade, que está visualizada na figura a seguir e a compararmos
com o gráfico anterior podemos perceber que o pico de conflitos também está
situado próximo do ponto onde a taxa de incremento de necessidades de
habilidades humanas está em sua maior expressão.

Por último, uma comparação interessante, ainda usando a questão das

pessoas no fluxo do tempo, a alocação das equipes em um projeto não é
linear. Normalmente iniciamos o projeto com um grupo pequeno e próximo do
ponto de inicio de execução, as equipes vão se agregando cada vez mais
rapidamente, vindas de outros projetos que encerraram ou de outros grupos
funcionais e ali permanecem em todo o período de velocidade acelerada do
fluxo.
Na medida em que a velocidade do fluxo decai, estas equipes também vão

sendo desmobilizadas e direcionadas para outros projetos ou outros grupos
funcionais, como pode ser visualizado na figura a seguir.

Aprenda Mais
Leia o artigo Habilidades de um gerente de projetos.
Leia o artigo sobre as Ferramentas BIM.
Leia o artigo Ciclo de vida da gestão em arquitetura de software.
Leia o artigo Uso de opções reais na avaliação de fases de um projeto.
Questão 1
Segundo o PMBOK 4, um conjunto de fases de um projeto, geralmente em
ordem sequencial, e que às vezes se sobrepõe, cujo nome e numero são
determinados pela necessidade de gerenciamento e controle da(s)
organização(ões) envolvida(s), a natureza em si e sua área de aplicação é
chamado de:
a) Portfolio
b) Estrutura por Projeto
c) Ciclo de Vida do Projeto
d) Mapa do Projeto
e) Matriz do Projeto
Questão 2
Juarez, empreendedor na área de eventos musicais que não usa a metodologia
de gerenciamentos de Projetos do PMI, solicita uma reunião ao Rafael, gerente
do projeto “Rock in Floripa”, para verificar o andamento do projeto. Rafael
apresenta que ele está finalizando a fase de concepção. Neste caso se a
organização de Juarez estivesse utilizando a metodologia do PMI, ele estaria
em qual fase do ciclo de vida do projeto?

a) Inicio do Projeto;
b) Organização do Projeto
c) Execução do trabalho do projeto
d) Encerramento do Projeto
e) Controle do Projeto
Questão 3
Uma necessidade, normalmente identificada e demandada pelo cliente,
normalmente é formalizada por um(a):
a) Lista de requisitos
b) RFP
c) WBS
d) Stakeholder
e) Pedido de serviço
Referências
2005
Project Management Institute, INC. Um Guia do Conhecimento em

Gerenciamento de Projetos GUIA PMBOK® 4ª Ed., Ed. Saraiva, São Paulo,
2008 (ATUALIZAR PARA A 5ª Ed.)
GIDO, Jack. Gestão de Projetos, Ed. Cengage Learnng, São Paulo, 2010


KERZNER, Harold. O que os Executivos precisam saber sobre
gerenciamento de projetos, Ed. Bookman, Porto Alegre, 2011

Aula 4: Processos
Introdução
seus processos é fundamental. Efetuar uma ligação das partes que compõe
um projeto sob a ótica sistêmica somente é possível se entendermos o que são
e como se relacionam seus processos associados.
Nesta aula conheceremos os principais grupos de processos do projeto,

detalharemos a sua composição e identificaremos as principais saídas destes
processos.
Objetivos:
 Entender a dinâmica dos processos de um projeto;
 Detalhar a estrutura dos principais grupos de processos do projeto;
 Identificar as saídas dos processos do projeto;
Conteúdo
Introdução
Após o nosso estudo relativo ao ciclo de vida do projeto e suas fazes, realizado
na aula anterior vamos detalhar como este ciclo pode ser percebido na forma
de processos de gerenciamento que de integram ao mesmo tempo em que se
desdobram para possibilitar um entendimento mais focal dos elementos que
compõe um projeto.
Neste momento a preocupação deve estar focada tanto da adaptação dos

recursos da organização aos processos do projeto, como também perceber
que restrições ambientais podem impactar no projeto.
Tanto o gerente do projeto como sua equipe devem concentrar esforços para
que:

a) Sejam selecionados processos que atendam os objetivos do projeto;
b) Escolher uma abordagem que atenda aos requisitos conhecidos;
c) Verificar se os requisitos das partes interessadas estão sendo atendidos
d) Identificar, monitorar e buscar manter equilíbrio entre demandas
concorrentes;
O conjunto de processos normalmente está associado ou ao fluxo do projeto e

que envolvem as diversas ferramentas e técnicas por área de conhecimento
que serão identificadas na aula cinco e desdobradas em outras disciplinas do
curso e os processos que se orientam ao próprio projeto e seu objeto e que é
fundamental para que o próprio escopo do projeto seja construído.
Orientação geral:
Tanto o Gerente como sua equipe devem ter atenção em cada processo às
entradas e saídas relacionadas ao processo.
Palavras-Chave:
 Integração
 Interdependência
O gerenciamento de projetos é metodologia baseada no modelo sistêmico de

transpormos a realidade para uma abstração racional e desta forma os
processos se comportam como subsistemas do um projeto.
Desta forma um dos focos de interesse refere-se às interações entre os

processos, assim como a percepção da empresa como sistema aberto deve ser
aplicada no próprio projeto.
Segundo o preconizado no PMBOK 4, Agrupamos os processos em cinco

grupos de processos, conhecidos como:
a) Iniciação;
b) Planejamento;

c) Execução;
d) Monitoramento e controle; e.
e) Encerramento
Um ponto que deve ser lembrado é que mesmo com a visão sistêmica, ainda
estamos no campo do conhecimento das ciências sociais aplicadas (e não no
das ciências exatas) e por isto um mesmo projeto pode ser gerenciados de
múltiplas formas e ainda assim resultar no mesmo objeto esperado.
Os processos então podem ser sobrepostos, limítrofes e até mesmo

recorrentes e ainda assim serem pertinentes e alinhados. O que alinha eles é a
própria saída esperada no fluxo de execução do projeto.
Podemos dizer que eles se permeiam entre si e que muitas vezes possuem
zonas de contato que nem sempre são distinguíveis pelo grupo social que atua
nos próprios processos. A figura abaixo (PMBOK 4 figura 3-1) visualiza
graficamente este conceito:
Como podemos verificar na figura a relação recorrente é sistêmica e alinhada

com o fluxo e no bojo desta relação o controle da ação planejada de um
processo é envolvida pelo monitoramento e controle.

Sistemicamente podemos encadear esta imagem, considerando que uma
entrega de um processo pode ser insumo de outro e assim construir uma
relação entre partes tal como ocorre em no conceito de um sistema.
Dessa forma uma visualização interessante entre estas relações de entrega e

de entradas pode ser construída usando esta conceituação sistêmica como
base conceitual, alinhando cada um dos grupos de processos como fluxo
linearizado. O PMBOK 4 em sua figura 3-2 (reproduzida a seguir) se apropria
desta conceituação sistêmica tradicionalmente construída para exemplificar
este fluxo entre os processos.
O PMBOK 5 acrescentou cinco processos aos já existente o que atualmente

compõe uma preconização de 47 processos, que podemos evidenciar de forma
gráfica e relacional as seguir:

(TRENTIM – 2013)
Site: http://blog.mundopm.com.br/wp-content/uploads/2013/03/figura-4-1024x765.jpg
No PMBOK 5 também ocorreu a transferência de alguns processos entre áreas

de conhecimento. Na figura a seguir temos evidenciadas estas mudanças e a
atual composição preconizada no PMBOK 5:

(TRENTIM – 2013)
Site: http://blog.mundopm.com.br/wp-content/uploads/2013/03/Captura-de-Tela-2013-03-14-
%C3%A0s-15.14.53.png
De uma forma gráfica podemos visualizar a sequência dos processos

segundo o PMBK 5 no Material Complementar.
Vamos então desdobrar os processos existentes nos grupos de processos em

cada um dos grupos!

Grupo de Processo de Iniciação
Agrupamos aqui os processos que irão definir um novo projeto ou uma nova
fase de um projeto existente.
Neste momento definimos o escopo inicial, comprometemos os recursos

financeiros iniciais e identificamos as partes interessadas internas e externas
que irão interagir e influenciar o resultado geral do projeto.
É aqui também que, caso ainda não esteja definido, o gerente do projeto deve
ser designado. Também inserimos estas informações no termo de abertura do
projeto e no registro das partes interessadas.
Logo que o termo de abertura do projeto é aprovado, ele se torna oficialmente

autorizado e mesmo que a equipe ajude na elaboração do termo, a aprovação
e o financiamento são externos a ela. Podemos evidenciar isto na figura a
seguir (PMBOK 4 – figura 3-4)
Uma das aplicações recorrentes deste grupo de processos ocorre quando, no

inicio de cada fase de um projeto, que possui complexidade elevada, dividimos
o projeto em fases e aplicamos a recorrência em cada fase.

Alguns dos processos de iniciação podem ser executados por:
a) Processos organizacionais;
b) Programas; ou
c) Portfolios externos
Algumas atividades que serão realizadas pelos processos que compõe este
grupo de processos:
 Definição das metas principais do projeto;
 Definição dos critérios de seleção do projeto;
 Nomeação do Gerente do projeto;
 Elaboração do termo de abertura do projeto
 Aprovação do termo de Abertura do Projeto
Saídas Principais:
 Termo de Abertura do Projeto (TAP); e
 Registro das Partes Interessadas
O que é TAP?
Veja no material de apoio modelo de Termo de Abertura de Projeto.
Grupo de Processos de Planejamento

Neste grupo de processos ocorre à informação a todos os envolvidos no
projeto aonde você vai chegar e como vai chegar lá.
Um ponto de reflexão:
Tempo gasto em melhorar o planejamento reflete em beneficio na execução
Outro ponto a se considerar neste grupo de processos é que as saídas destes

processos produzem documentos que serão utilizados durante todo o projeto.

Quando um bom planejamento é feito, dimensionamos bem os recursos,
conhecemos com boa precisão os custos e temos oportunidade de minimizar
conflitos no fluxo de atividades e no tempo requerido, sem que isto ocorra
durante a execução.
Dentre as diversas atividades que podemos fazer neste grupo de processos

destacam-se:
a) Definição precisa do que vai ser entregue no projeto;
b) Redação e publicação da declaração de escopo
c) Definição do orçamento do projeto
d) Definição das atividades e das estimativas de recursos
e) Elaboração do cronograma do projeto
f) Definição das habilidades especificas para realização das tarefas do
projeto
E em que a equipe pode também atuar?
Segundo XAVIER (2010):

“a equipe do projeto deve envolver as partes interessadas,
dependendo da influência delas no projeto, pois elas possuem
habilidades e conhecimento que podem ser aproveitadas no
desenvolvimento do plano de gerenciamento do projeto e em
quaisquer planos auxiliares.”
Saídas Principais neste grupo:

 Plano de gerenciamento dos requisitos;
 Declaração do escopo do projeto;
 Estrutura Analítica do Projeto (EAP);
 Lista e atributos das atividades;
 Cronograma do Projeto;
 Estimativa de custos das atividades;

 Requisitos de recursos financeiros do Projeto;
 Plano e métricas de gerenciamento da qualidade;
 Plano de RH;
 Plano de Gerenciamento das comunicações;
 Plano de Gerenciamento dos riscos; e
 Plano de Gerenciamento das aquisições
Grupo de Processos de Execução

Podemos considerar que este grupo de processos envolve a ação propriamente
dita do projeto. É nele que vamos ver acontecer o que foi definido e planejado
e onde a equipe ira “colocar a mão na massa” e transforma a ideia concebida
no objeto singular do projeto.
Durante estes grupos de processos, os resultados poderão requerer

atualizações no que foi planejado e respectivas correções de rumo que afetam
os planos produzidos no planejamento e que assim devem ser ajustados.
Também é neste grupo de processos que o maior volume de recursos do

projeto é alocado e também onde o gerente de projeto vai se deparar com a
maior parte dos conflitos que terá durante todo o ciclo de vida do projeto.
Algumas atividades que são feitas neste grupo de processos:

a) Criação efetiva da equipe
b) Atuação do Gerente de projeto na direção e chefia da equipe
c) Alocação dos recursos ao projeto
d) Realização de reuniões de acompanhamento de execução
e) Fornecer informações de andamento do projeto aos stakeholders
f) Gerenciar o progresso do projeto
g) Implantar os procedimentos de garantia da qualidade

Saídas Principais:
 Entrega das ações realizadas;
 Atualizações nos planos planejados;
 Alocação de recursos nas atividades;
 Coleta de dados para avaliação do desempenho.
Grupo de Processos de Monitoramento e Controle

Neste grupo de processos podemos confrontar se o que está sendo executado
está de acordo com o planejado e assim se o desempenho está sendo
alcançado. Eles servem de ponto focal para identificar a necessidade de rever
o planejamento e efetuar correção de rumos das ações em andamento.
Neste grupo de processos que efetivamos a gestão de mudanças
Atividades relacionadas a este grupo de processos:

a) Comparação de desempenho com o planejado;
b) Ações corretivas;
c) Avaliação da eficácia das ações corretivas;
d) Garantia de continuidade do projeto em relação ao planejado; e
e) Gerenciamento das mudanças.
Na experiência pratica, muitas vezes temos até dificuldade para separar a

execução do monitoramento e controle porque as estruturas de
monitoramento e controle estão distribuídas e operantes nas estruturas de
execução. Forma sem a qual não teríamos como coletar dados de controle de
forma tempestiva.
Segundo HELDMAN (2005),

“Processos de Monitoramento e controle tratam do monitoramento
do desempenho do projeto para certificar-se de que os resultados

atendem os requisitos do projeto. É durante estes processos que se
monitoram e examinam os pedidos de mudança.”
Ainda na perspectiva sistêmica adotada pelo PMBOK, este processo é contínuo

no ciclo e permite a equipe a qualquer momento ter iniciativa de ação em
relação a desvios e alterações não planejadas.
Principais saídas:
 Atualizações dos planos
 Solicitações de mudanças nos planos
 Geração de medições
Grupo de Processos de Encerramento

Pode parecer que o encerramento seja apenas um ponto de parada, de corte
em um projeto onde simplesmente dizemos que acabou.
O cliente tem seu objeto entregue, a equipe e os recursos são desmobilizado e

todo o esforço é direcionado a novo(s) projeto(s), mas não é bem assim.
O grupo de processos de encerramento do projeto é importante!
Neste momento se finaliza a documentação do que teve sucesso ou fracasso.

Registramos o que aprendemos e os exitos alcançados.
Vejamos algumas das atividades importantes neste momento:

a) obter a aceitação das entregas realizadas pelo projeto;
b) Documentar o que se aprendeu ao longo do projeto;
c) Arquivar os registros do projeto
d) Formalizar o encerramento do projeto; e
e) desmobilizar os recursos ainda alocados ao projeto.

Principais saídas:
 Entrega do objeto Final
 Desmobilização dos recursos
 Registro da experiência obtida
Reflexão:
Estas preocupações nestes grupos de processos foi percebida e criada pelo
PMBOK?
Claro que não, ela reflete uma consolidação de boas práticas em projetos que
vem sendo feitas ao longo do tempo. Veja no documento Programa de
trabalho como identificamos elementos de planejamento, execução,
monitoramento e controle em um relatório gerencial de 1928 relativo ao
projeto de ampliação do Estaleiro “Arsenal de Marinha do Rio de Janeiro”,
situado (e em operação contínua desde 1763 até hoje) na ilha das cobras no
RJ:
Atividade proposta
A partir dos conceitos estudados e dos links disponíveis no saiba mais debata
com seus colegas no fórum de debates, as similaridades e diferenças nos
processos de gerenciamento de projetos sob a ótica de metodologias distintas.
Compartilhe relatos, fotos, vídeos ou links.
Aprenda Mais
Leia o artigo da ENEGEP sobre a análise dos processos PMBOK em uma fábrica
de software.
Leia o artigo de Fernando Matesco sobre a importância de definição uma

metodologia para gerenciamento de processos em projetos.
Veja um comparativo entre SCRUM e PMBOK em gerenciamento de projetos.

Conheça a Metodologia de gerenciamento de projetos da MGP-SISP.
Leia a tese de Humberto Ferreira da Luz Junior que alinha RUP e SCRUM ao
PMBOK.
Questão 1
Qual das seguintes alternativas é verdadeira sobre processos essenciais de
Planejamento:
a) Podem interagir uns com os outros, dependendo da natureza do

projeto;
b) Possuem dependências claras que requererem que sejam executados
nas mesmas ordens;
a) Dependências são dependentes da natureza do projeto
b) São gerenciadas pelos membros da equipe através do projeto;
f) Possuem dependências que se modificam sistematicamente no tempo
em função de orientação das equipes
Questão 2
No planejamento do Projeto pode haver muitas divergências entre os
interessados, mas será privilegiado o ponto de vista do(a):
a) Cliente;
b) Gerente do Projeto;
c) Equipe;
d) Chefe do Gerente do Projeto;
e) Do dono da empresa que executa o projeto.

Questão 3
No PMBOK, o processo de Desenvolver o Cronograma é o cerne do grupo de
processos de Planejamento. Existem várias ferramentas e técnicas para
desenvolver o cronograma do projeto. Duas dessas técnicas são semelhantes e
permitem calcular a duração do projeto. A primeira usa a duração mais
provável, enquanto a segunda usa o que se chama de valor esperado (ou
média ponderada). Trata-se das técnicas
a) Critical Path Method (CPM) e Technical Calculation;

b) Weighted Average (TCWA), Network Critical Paths (NCP) e Technical
Calculation;
c) Weighted Average (TCWA), Calculation of Core Activities (CCA) e
Network Critical Paths (NCP);
d) Critical Path Method (CPM) e Program Evaluation and Review Technique
(PERT);
e) Program Evaluation and Review Technique (PERT) e Network Critical
Paths (NCP);
Questão 4
Os cinco grupos de processos descritos pelo PMBOK Guide que são utilizados
para organizar e descrever a realização do projeto são:
a) Análise, Programação, Teste, Implementação e Monitoramento

b) Levantamento e Classificação de Requisitos, Desenho, Programação,
Teste e Implementação.
c) Levantamento de Requisitos, Projeto, Design, Implementação e Teste
d) Planejamento, Organização, Projeto, Implementação e
Acompanhamento.
e) Iniciação, Planejamento, Execução, Monitoramento e Controle e
Encerramento.

Referências
2005

Gerenciamento de Projetos GUIA PMBOK® 4ª Ed., Ed. Saraiva, São
Paulo, 2008

TRENTIM, Mário H.. Gerenciamento de Projetos, Ed. Atlas, São Paulo, 2011
FLEMING, Thiers. O Novo Arsenal de Marinha na Ilha das cobras, Ed. D’A
Encadernadora S.A., Rio de Janeiro, 1929.

Aula 5: Áreas do conhecimento
Introdução
seus processos é fundamental. Efetuar uma ligação das partes que compõe
um projeto sob a ótica sistêmica somente é possível se entendermos o que são
e como se relacionam seus processos associados.
Nesta aula conheceremos tanto metodologias distintas que a partir da ideia de

ciclo de vida do projeto e de seus processos se desdobram de forma estrutural
distinta, quanto desdobraremos a escolha metodológica que está preconizada
no PMBOK em relação a percepção de áreas de conhecimento.
Objetivos:
 Entender o conceito de áreas de conhecimento;
 Detalhar modelos distintos de metodologias utilizados em
desenvolvimento de projetos;
 Identificar a escolha estrutural das áreas de conhecimento preconizadas
no PMBOK;
Conteúdo
Introdução
Após termos estudado o ciclo de vida do projeto, suas fazes e os grupos de
processos que estão associados a este ciclo de vida poderíamos imaginar que
o passo seguinte seria a execução do ciclo seguindo estritamente os
processos.
Neste ponto precisamos ter uma reflexão metodológica pois até agora o foco
do desdobramento, ainda que se venha construindo uma metodologia, era
iminentemente sistêmico.

A escolha de uma metodologia é fundamental para que o modelo de
gerenciamento de projetos seja efetivamente implementado.
Qual metodologia?
Embora em grande parte da disciplina e do curso o foco seja o que está

preconizado no PMBOK, nesta aula vamos detalhar como este ciclo pode ser
percebido na forma de processos de gerenciamento que de integram ao
mesmo tempo que se desdobram para possibilitar um entendimento mais focal
dos elementos que compõe um projeto.
Neste momento a preocupação deve estar focada tanto da adaptação dos

recursos da organização aos processos do projeto, como também perceber
que restrições ambientais podem impactar no projeto.
Temos variedades de metodologias para ajudar os gestores em todas as fases

de um projeto, desde o início da implementação do fechamento.
Considerando que uma metodologia é um modelo que os gerentes de projeto

empregam para a concepção, planejamento, implementação e realização dos
seus objetivos do projeto, antes de desdobrarmos a visão metodológica que
começa realmente a caracterizar a forma como o PMBOK apresenta sua
concepção vamos exemplificar algumas metodologias que se propõe a
beneficiar tipologias especificas de projetos a seguir:
Adaptive Framework
Nesta metodologia, o escopo do projeto é uma variável. Além disso, o tempo e
o custo são constantes para o projeto. Portanto, durante a execução do
projeto, o escopo do projeto é ajustado de forma a obter o máximo valor de
negócio do projeto.

Desenvolvimento Ágil de Software
Metodologia de desenvolvimento ágil de software por projetos tem como
principais características: ciclos curtos-denominados de entrega (sprints),
requisitos ágeis, cultura dinâmica da equipe, controle do projeto menos
restritiva, e ênfase na comunicação em tempo real.
Métodos de cristal
No método de cristal, os processos de projeto recebem uma prioridade baixa.
Em vez de os processos, este método se concentra mais na comunicação da
equipe, as habilidades dos membros da equipe, as pessoas, e interação.
Métodos de cristal vêm associados a metodologia ágil.
Dynamic Systems Development Model (DSDM)

Este é o sucessor de metodologia Rapid Application Development (RAD). Este
também é um subconjunto da metodologia de desenvolvimento ágil de
software e possui foco sobre o treinamento e documentação. Este método
enfatiza mais sobre o envolvimento do usuário ativo durante o ciclo de vida do
projeto.
Extreme Programming (XP)

Reduzir o custo de mudanças de requisitos é o principal objetivo da
programação extrema XP que enfatiza o feedback escala fina e continua no
processo, entendimento compartilhado e bem-estar programador. Em XP, não
há especificação de requisitos detalhados ou arquitetura de software
construído.
Feature Driven Development (FDD)

Esta metodologia é mais focada em processos simples, bem definidos e curto
período iterativo. Todo o planejamento e execução deste tipo de projeto
ocorrerá com base nos recursos.

Information Technology Infrastructure Library (ITIL)
Esta metodologia é um conjunto de melhores práticas em gerenciamento de
projetos. ITIL abrange um amplo aspecto do gerenciamento de projetos, que
se inicia a partir do nível de gestão organizacional.
Joint Application Development (JAD)

Envolver o cliente desde o início com as tarefas do projeto é enfatizada por
esta metodologia. A equipe do projeto e o cliente realizam sessões JAD
colaborativamente, a fim de obter a participação do cliente. Estas sessões JAD
ocorrem durante o ciclo de vida do projeto inteiro.
Desenvolvimento “Lean” (LD)

Desenvolvimento “Lean” concentra no desenvolvimento de software
satisfazendo o cliente vem como a mais alta prioridade. A equipe está
motivada para proporcionar o maior valor para o dinheiro pago pelo cliente.
PRINCE2
PRINCE2 tem uma abordagem baseada em processos de gerenciamento de
projetos. Esta metodologia é baseada em oito processos de alto nível.
Rapid Application Development (RAD)

Esta metodologia se concentra no desenvolvimento de produtos mais
rapidamente com maior qualidade. Quando se trata de levantamento de
requisitos a prototipagem é utilizada para obter requisitos claros e reutilizar os
componentes de software para acelerar os prazos de desenvolvimento. Neste
método, todos os tipos de comunicações internas são considerados informais.
Rational Unified Process (RUP)

RUP tenta capturar todos os aspectos positivos de metodologias modernas de
desenvolvimento de software e oferecê-los em um único pacote. Esta é uma
das primeiras metodologias de gerenciamento de projetos que sugeriam uma
abordagem iterativa para o desenvolvimento de software.

Scrum
Esta também é uma metodologia ágil. O principal objetivo desta metodologia é
o de melhorar a produtividade da equipe de forma dramática, removendo
todos os ônus possível.
Spiral
Metodologia espiral é o modelo Waterfall estendida com prototipagem. Este
método é usado em vez de usar o modelo Waterfall para grandes projetos.
Systems Development Life Cycle (SDLC)

Este é um modelo conceitual utilizado em projetos de desenvolvimento de
software. Neste método, existe a possibilidade de combinar dois ou mais
metodologias de gestão de projeto para o melhor resultado. SDLC também
fortemente enfatiza o uso de documentação e tem diretrizes rígidas sobre ela.
Waterfall (tradicional)
Este é o modelo legado para projetos de desenvolvimento de software. Esta
metodologia tem sido, na prática há décadas antes de as novas metodologias
foram introduzidas. Neste modelo, o desenvolvimento do ciclo de vida tem
fases fixas e prazos lineares.
IPMA
Associação mais antiga do que o PMI, mas atualmente com menos adeptos,
buscou inspiração nos modelos de projetos industriais para montra sua
metodologia;
ZOPP
Metodologia orientada a objetivos e usada inicialmente em modelos de
projetos industriais alemães. Usa a técnica Metaplan.

PCM
Metodologia para gerenciamento de ciclo de projetos, derivada do modelo LFA
(Logical Framework Aprroaching)
RBM
Metodologia de gerenciamento baseada em resultados.
MGP-SISP
Metodologia de gerenciamento de projetos de 2011 do governo federal para
sistemas de TI do governo.
Parcialmente adaptado de:
http://www.tutorialspoint.com/management_concepts/project_management_methodologies.htm
Como podemos ver, ainda que uma boa parte destas metodologias tenham
como foco a área de TI, existem diversas metodologias. A partir do momento
que nos propormos a focar uma delas, no caso do nosso curso a do PMI,
algumas especificidades da metodologia passam a gerar um entendimento
decorrente e dependente em vários aspectos: estrutural, doutrinário e de
entendimento do modelo.
Sim, entendimento do modelo!
Porque podemos ter situações em que nem todas as metodologias (incluindo a

do PMI) se encaixam perfeitamente no modelo real de projeto que estamos
precisando gerenciar.
Um outro aspecto importante nesta percepção envolve o software que vai ser
usado em apoio ao gerenciamento. Da mesma forma que as metodologias
nem sempre atendem 100% da realidade, os softwares podem não ser 100%
compatíveis com o que é preconizado nas metodologias.

Um exemplo simples é o MS-Project que justamente por buscar atender de
forma ampla diversas metodologias não atinge 100% de compatibilidade em
todas e por isto mesmo a Microsoft disponibiliza uma extensa ajuda on line
relacionando aspectos do software com as metodologias que podem estar por
traz do uso.
Veja de forma exemplificativa isto no site http://office.microsoft.com/pt-

br/support/results.aspx?qu=processos&ex=2&filter=1&av=zpj.
Entendido este aspecto, nosso próximo passo nesta aula é detalhar um dos
aspectos que diferenciam o preconizado no PMBOK de outras metodologias: as
áreas de conhecimento!
Áreas de Conhecimento de Gerenciamento de Projetos

A forma metodológica como o PMBOK trata o gerenciamento de processos do
ciclo de vida de um projeto é feita por áreas de conhecimento. Na medida em
que revisões são feitas na metodologia vários aspectos da metodologia vão
evoluindo, inclusive a forma como se agrupa este conhecimento.
Por exemplo no PMBOK 5 foi adicionada uma área de conhecimento

denominada Gerenciamento das Partes Interessadas, agregando mais uma
área de conhecimento as anteriormente preconizadas.
Então, o que seria uma área de Conhecimento?
Podemos definir uma área de conhecimento como um conjunto de requisitos

de conhecimentos desdobrados nos termos dos processos que a compõem.
Isto inclui as suas práticas, suas entradas e saídas, ferramentas e técnicas
associadas.

Ou seja, existe uma relação de interdependência da área com os processos de
gerenciamento de projetos que compõe os grupos de processos associados as
fases do ciclo de vida de um projeto.
E quais são estas áreas de conhecimento?

1) Integração; 6) Recursos Humanos;
2) Escopo; 7) Comunicações;
3) Tempo; 8) Riscos;
4) Custos; 9) Aquisições; e
5) Qualidade; 10)Partes Interessadas
De uma forma resumida, pois serão tratadas de forma mais detalhada em

outras disciplinas do curso, vejam o que cada área contempla:
1) Integração
Nesta área de conhecimento temos a descrição dos processos que integram
diversos elementos do gerenciamento de projetos, e que, podem ser
identificados, definidos, combinados, unificados e coordenados dentro dos
grupos de processos de gerenciamento de projetos.
“O gerenciamento de integração do projeto inclui os processos

necessários para identificar, definir, combinar, unificar e coordenar
os vários processos e atividades dos grupos de processos de
gerenciamento. No contexto de gerenciamento de projetos,
integração inclui características de unificação, consolidação,
articulação e ações integradoras que são essenciais para o término
do projeto, para gerenciar com sucesso as expectativas das partes
interessadas e atender os requisitos.”
(PMBOK, 2008)

2) Escopo
Aqui descrevemos os processos envolvidos na verificação do que o projeto
inclui como um todo, para que seja concluído com sucesso. Nesta área
aplicamos processos de planejamento e de controle e monitoramento. No
planejamento criamos um plano para o gerenciamento do escopo e no
controle e monitoramento controlamos o cumprimento do escopo planejado.
“O gerenciamento de escopo tem como objetivo principal definir e

controlar os trabalhos a serem realizados pelo projeto de modo a
garantir que o produto, ou serviço, desejado seja obtido através da
menor quantidade de trabalho possível, sem abandonar nenhuma
premissa estabelecida no objetivo do projeto.”
Dinsmore (2009)
3) Tempo
Nesta área temos os processos que gerenciam os prazos do projeto, também
possuindo processos de planejamento e de monitoramento e controle.
“O gerenciamento do tempo do projeto inclui os processos

necessários para gerenciar o término pontual do projeto.”
(PMBOK, 2008)
4) Custos
Esta área busca aglutinar e acompanhar os gastos associados ao projeto para
que o orçamento seja cumprido. Também possui vinculação direta com
processos de planejamento e monitoramento e controle.
“O planejamento dos custos tem por objetivo a elaboração do

orçamento do projeto, definindo-se os recursos que serão utilizados
(pessoas, equipamentos e materiais de consumo), suas respectivas
quantidades e as datas em que serão necessários.”
(XAVIER, 2010).

5) Qualidade
Aqui descrevemos os processos envolvidos na garantia de que o projeto
atenderá os requisitos estabelecidos pelo cliente. O foco da área é em
padronização, auditoria da qualidade e conformidade como garantia de
qualidade.
“O gerenciamento da qualidade do projeto inclui os processos e as

atividades da organização executora que determinam as políticas de
qualidade, os objetivos e as responsabilidades, de modo que o
projeto satisfaça às necessidades para as quais foi empreendido.
Implementa o sistema de gerenciamento da qualidade por meio de
políticas e procedimentos com atividades de melhoria contínua de
processos realizadas durante todo o projeto, conforme apropriado.”
(PMBOK, 2008)
6) Recursos Humanos
Aqui temos a área que busca organizar e gerenciar a equipe do projeto e a sua
aplicação nele, suas estruturas relacionais e capacitação.
“O plano de gerenciamento de recursos humanos contém a matriz

de responsabilidade, uma das principais ferramentas de
planejamento dos recursos humanos. Ela é uma tabela que mostra
a relação das pessoas associadas ao projeto e suas
responsabilidades. “
(TRENTIM, 2011)
7) Comunicações
Nesta área descrevemos os processos relacionados à geração, coleta,
disseminação, armazenamento e destinação final das informações que o
projeto necessita manter para uso na tomada de decisões pelo gerente e pela
equipe do projeto.

“O gerenciamento das comunicações do projeto inclui os processos
necessários para assegurar que as informações do projeto sejam
geradas, coletadas, distribuídas, armazenadas, recuperadas e
organizadas de maneira oportuna e apropriada.”
(PMBOK, 2008)
8) Riscos
Os processos desta área de conhecimento objetivam estabelecer
metodologicamente como os riscos serão identificados, analisados bem como a
planificação das ações que visem minimiza-los.
“O gerenciamento dos riscos do projeto inclui os processos de

planejamento, identificação, análise, planejamento de respostas,
monitoramento e controle de riscos de um projeto. Os objetivos do
gerenciamento dos riscos são aumentar a probabilidade e o impacto
dos eventos positivos e reduzir a probabilidade e o impacto dos
eventos negativos no projeto.”
(PMBOK, 2008)
9) Aquisições
Nesta área aglutinamos tanto as aquisições de itens (produtos) quanto a
prestação de serviços relacionados ao projeto, incluindo o gerenciamento dos
contratos relacionados às aquisições.
“O gerenciamento das aquisições do projeto inclui os processos

necessários para comprar ou adquirir produtos, serviços ou
resultados externos à equipe do projeto. A organização pode ser
tanto o comprador como o vendedor dos produtos, serviços ou
resultados de um projeto.”
(PMBOK, 2008)

10) Partes Interessadas
Nesta última e mais recente área de conhecimento, se buscou incluir processos
que explicitem as relações de interdependências entre as partes interessadas e
como fazer o planejamento, monitoramento e controle delas.
Reflexão
Para podermos concluir esta aula lanço duas reflexões:
A Primeira e mais óbvia é qual a área de conhecimento mais importante em

gerenciamento de projetos?
Podemos obter as mais variadas respostas a esta indagação se perguntarmos

a vários gerentes de projetos. Mas realmente existe alguma área mais
importante?
Considerando a percepção sistêmica preconizada por Katz e Kahn já em idos

dos anos 70, sistemas são sempre conjuntos de grupos sociais que interagem
continuamente em interdependências que se mantém conectadas por
alinhamento de objetivo comum entre as partes que os compõe. Assim as
estruturas são sempre secundárias ao grupo social e por isto dependentes
deles.
Leia o artigo de Francisco Antonio Coelho Junior e Luciana

Mourão com mais dados sobre a perspectiva de Katz e Kahn
Considerando esta perspectiva temos ainda um posicionamento relacionado

diretamente à gerenciamento de projetos proposto por Mersino (2011), em
que ele considera a cultura organizacional como um ponto essencial para o

gerenciamento dos projetos, salientando que basta observar os
comportamentos que são recompensados e os que são punidos para saber
como os projetos são gerenciados numa organização.
Como contraponto ao foco estritamente social, visto que sem as pessoas, as

estruturas não se sustentam, Trentim (2011) indica que é” o escopo do
produto e do projeto que determina todas as demais áreas. As tarefas são
feitas a partir da EAP, os custos são calculados a partir dos recursos estimados
para as tarefas, a qualidade depende do escopo do produto e projeto, as
comunicações são o suporte para o funcionamento do projeto, RH cuida do
maior ativo do projeto – as pessoas, o gerenciamento dos riscos tem como
objetivo manter o escopo nos trilhos e, por fim, as aquisições compram os
materiais e insumos que precisamos para trabalhar. Temos ainda a Integração,
que procura unir todas as demais áreas, além de coordenar, supervisionar e
integrar a gestão do projeto.”
A figura a seguir ilustra esta percepção de Trentim:
Figura retirada do site:

http://blog.mundopm.com.br/wp-content/uploads/2012/01/pmbok_areas.png

Atividade proposta
A partir dos conceitos estudados e dos links disponíveis no aprenda mais
debata com seus colegas no fórum de debates, as similaridades e diferenças
nas diversas metodologias existentes de gerenciamento de projetos e
confrontar com a escolha metodológica do PMBOK em dividir as áreas de
conhecimento em 10 áreas distintas. Compartilhe relatos, fotos, vídeos ou
links.
Aprenda Mais
Leia o artigo Desenvolvimento agil de software.
Leia o artigo de Antonio Geraldo Viana relacionado a aplicação da

metodologia ágil em gerenciamento de projetos
Leia o artigo Metodologias de desenvolvimento de software.
Leia o artigo Entendendo o Prince2™.
Leia a matéria que explica a metodologia ZOOP.
Leia o artigo relacionado a metodologia ITIL.
Leia o artigo sobre Transferência de Conhecimento e Lições.
Questão 1
A metodologia de desenvolvimento de projetos que tem como principais
características os ciclos curtos-denominados de entrega (sprints), requisitos
ágeis, cultura dinâmica da equipe, controle do projeto menos restritiva, e
ênfase na comunicação em tempo real é conhecida como:

a) PRINCE2;
b) ITIL;
c) ÁGIL;
d) PCM;
e) PMBOK
Questão 2
A metodologia de desenvolvimento de projetos em que existe a possibilidade
de combinar dois ou mais metodologias de gestão de projeto para o melhor
resultado é conhecida como:
a) SCRUM;
b) SDLC;
c) ÁGIL;
d) PCM;
e) PMBOK
Questão 3
A área que busca organizar e gerenciar a equipe do projeto e a sua aplicação
nele, suas estruturas relacionais e capacitação é conhecida como
gerenciamento:
a) do Escopo;
b) de Integração;
c) do Custo;
d) do Tempo;
e) dos recursos humanos

Referências
Gerenciamento de Projetos GUIA PMBOK® 4ª Ed., Ed. Saraiva, São
Paulo, 2008 (ATUALIZAR PARA A 5ª Ed.)

TRENTIM, Mário H. Gerenciamento de Projetos, Ed. Atlas, São Paulo, 2011
DINSMORE, Paul C. Como se Tornar um Profissional em Gerenciamento

de Projetos, Ed. Qualitymark, Rio de Janeiro, 2009.
MERSINO, Anthony. Inteligência Emocional para Gerenciamento de

Projetos. Ed. M. Books, São Paulo, 2011.

Aula 6: Certificação PMI
Introdução
Nesta aula, abordaremos as escolhas estruturais do conjunto de
conhecimentos preconizado pelo PMI, entendendo a estrutura do Instituto,
como ele propõe a utilização deste conjunto de conhecimentos pelo mercado,
seus processos de certificação e capacitação.
Objetivos:
 Identificar as escolhas estruturais preconizadas no PMI;
 Conhecer a certificação PMI;
 Entender a importância da capacitação para aplicação do preconizado
no PMBOK.
Conteúdo
Introdução
Ao longo das primeiras aulas, abordamos conceitos relacionados ao que é um
projeto, seus principais conceitos estruturais, a percepção de seu ciclo de vida,
seus processos associados e como podemos perceber estes processos de
forma estruturada.
Também pudemos ver alguns aspectos que são utilizados em diversas

metodologias de gerenciamento de projetos, indicando algumas diferenças
entre elas e na aula anterior sinalizamos que a escolha acadêmica deste curso
aborda de forma preferencial o conjunto de conhecimentos de gerenciamento
de projetos preconizada pelo PMI no seu PMBOK.
Isto ficará bem evidenciado nas duas ultimas aulas deste disciplina, onde
detalharemos uma das áreas de conhecimento preconizada pelo PMBOK.

A escolha de uma determinada metodologia de gerenciamento de projetos
implica em decorrências dependentes ao longo do tempo, pois ao fazermos
isto estamos também escolhendo estruturas que servirão de base para o
próprio gerenciamento.
Neste ponto surgem alguns questionamentos reflexivos:
Como garantir que estou usando corretamente uma metodologia? Para a

organização e para seus stakeholders10?
Algumas metodologias citadas nesta disciplina são descritivas e seus autores

embora indiquem-nas de forma detalhadas, deixam o profissional e a
organização com a escolha de como avaliar a implementação feita. Outras,
como a do PMI se baseiam em um modelo de certificação profissional que
busca garantir a conformidade na utilização da ferramenta
Vejamos inicialmente o que é um entendimento abrangente do conceito de

certificação.
Conceitos de certificação
Embora encontremos na literatura diversas definições para Certificação, elas
apresentam conceituação muito similar, pois o conceito tem um entendimento
pacífico para a quase totalidade da literatura. Para exemplificar
conceitualmente vamos utilizar a definição de certificação utilizada na
10
Stakeholders
"Pessoas e Organizações, como clientes, patrocinadores, organizações executoras e o
público, que estejam ativamente envolvidas no projeto ou cujos interesses possam ser
afetados de forma positiva ou negativa pela execução ou término do projeto. Elas podem
também exercer influência sobre o projeto e suas entregas." (PMBOK, 2012)

legislação brasileira para as atividades que o Inmetro supervisiona e que é
definida como:
“Um conjunto de atividades realizadas por uma organização de

terceira parte (organização independente) para atestar e declarar
que um produto, serviço, pessoa ou sistema está em conformidade
com os requisitos técnicos especificados.”
Retirado do site: http://www.normalizacao.cni.org.br/aval_conformidade_certificacao.htm
Acessado em 16/07/2013
A certificação é utilizada em diversas áreas e atividades, sendo que algumas

delas tem, no nosso país , uma regulamentação legal constituída a bastante
tempo, como por exemplo a certificação da qualidade de materiais e produtos
industriais pelo SINMETRO, através da Lei 5966 de 11/12/1973 que cria entre
outras coisas o INMETRO
A Lei com as atualizações correntes pode ser encontrada no site

http://www2.planalto.gov.br/ e no material de apoio.
O escopo de atuação do INMETRO pode ser visto no site do instituto:

http://www.inmetro.gov.br/inmetro/sinmetro.asp
A partir dele podemos verificar o escopo de regulamentação de certificação

que existe atualmente na nossa legislação.
Assim, a certificação pode ser de caráter voluntário, cuja decisão é exclusiva

da empresa que deseja obtê-la para atender a interesses estratégicos próprios
ou relacionados a seus stakeholders ou compulsório, quando estabelecida em
legislação:

Certificação Voluntária:
“Tem como objetivo garantir a conformidade de processos,
produtos e serviços às normas elaboradas, é decisão exclusiva da
empresa que fabrica produtos ou fornece serviços.
Assim sendo, quando a certificação é voluntária, podem coexistir no

mercado produtos e serviços certificados e não certificados. Nestes
casos, a certificação torna-se um diferencial de mercado em favor
das empresas que adotam a certificação.
A certificação voluntária de terceira parte deve ser executada com

base nas normas brasileiras, regionais ou internacionais, mas
podem também se basear em outras normas, desde que seu campo
de ação não esteja coberto por aquelas.”
Retirado do site: http://www.normalizacao.cni.org.br/aval_conformidade_certificacao.htm em

16/07/2013
Exemplos:
a) Certificação de uma fábrica de revestimentos de cerâmica utilizando a
norma NBR ISO 14001.
b) Certificação do processo de calibração de motores em bancada
utilizando a norma NBR 9001.
c) Cerificação de Acreditação Hospitalar de um centro de hemodiálise,
usando o Manual das Organizações Prestadoras de Serviços
Hospitalares preconizado pela ONA (Organização Nacional de
Acreditação).
Certificação Compulsória:
“Atende às questões de segurança e saúde, de interesse do país e
do cidadão, abrangendo as questões relativas aos animais, vegetais,

proteção da saúde, segurança (acidentes, desastres), meio
ambiente e temas correlatos.
O governo estabelece mecanismos de fiscalização no mercado

nacional e para os produtos importados, de modo a garantir o seu
efetivo cumprimento. A certificação compulsória deve ser executada
com base no regulamento técnico indicado no documento que a
criou e complementada por regra específica de certificação.
Por conter regras obrigatórias, o regulamento técnico é restrito ao

que é essencialmente papel do Estado ou do poder público impor à
sociedade, visando às atividades de saúde, segurança e meio
ambiente.”
Retirado do site: http://www.normalizacao.cni.org.br/aval_conformidade_certificacao.htm em

16/07/2013
Em ambas a certificações (voluntárias e compulsórias), a materialização do

cumprimento das conformidades preconizadas no processo de certificação se
dá pela emissão de um certificado que declara a conformidade às normas
preconizadas no sistema de certificação.
Para que isto ocorra podemos ter organismos de certificação, ou organizações

de certificação credenciadas quando são credenciadas por um organismo de
credenciamento.
Estas ações são materializadas através da emissão de um certificado

(documento emitido, de acordo com as regras de um sistema de certificação,
para declarar a conformidade às normas técnicas ou a outros documentos
normativos) ou da marca de conformidade (marca registrada aposta ou
emitida, de acordo com as regras de um sistema de certificação, para declarar
a conformidade às normas técnicas ou outros documentos normativos).

As organizações de terceira parte são normalmente denominadas Organismos
de Certificação (OC), ou Organismos de Certificação Credenciados (OCC),
quando são credenciadas por um organismo de credenciamento.
Podemos exemplificar este detalhamento nos organismos registrados no site

do INMETRO, no link: http://www.inmetro.gov.br/organismos/index.asp
Com base nestes conceitos podemos tecer algumas considerações em relação

à Certificação pelo PMI:
a) É uma certificação voluntária;

b) Não é dependente de certificações compulsórias;
c) Ser ou não certificado pelo PMI não impede de obter outras
certificações;
d) A organização utiliza o conjunto de conhecimentos de gerenciamento de
projetos preconizada no PMBOK pode ter múltiplas certificações e em
algumas situações especificas pode necessitar inclusive de mais de uma
certificação compulsória;
Estas considerações trazem alguns desdobramentos importante e que são

reflexos da escolha de uma metodologia. Se desejo utilizar uma determinada
metodologia de gerenciamento de projetos para obter o certificado, podemos
até compartilhar conceitos e ideias de outras metodologias de gerenciamento,
mas devemos ter estrita conformidade à estrutura preconizada na
metodologia, pois caso contrário não conseguiremos obter a certificação pela
organização certificadora que o fizer.
Uma outra questão para reflexão envolve a situação de termos por

característica de negócio a utilização de uma determinada certificação na
organização e em paralelo termos os profissionais certificados em
gerenciamento de projetos pelo PMI. Devem se observar todos os requisitos
estruturais de ambos instrumentos para que possamos ter e manter as

certificações e isto vai requerer uma adaptação estrutural que permita este
atendimento. Quando utilizamos as metodologias da série ISO, temos a
vantagem do alinhamento da percepção do PMI com elas.
Assim, as certificações do PMI são acreditadas tanto pela ANSI quanto pela
ISO, o que permite que a aplicabilidade seja concorrente com estas.
Feita esta reflexão podemos detalhar o escopo de certificação pelo PMI.
Certificação pelo PMI

Inicialmente uma questão pode ser levantada:
O que é então o PMI?
Veja a definição pelo próprio instituto:

“O Instituto de Gerenciamento de Projetos (Project Management
Institute PMI), é a uma das maiores associações para profissionais
de gerenciamento de projetos. Nosso trabalho para a profissão
auxilia mais de 700.000 membros, profissionais certificados e
voluntários em praticamente todos os países do mundo a aumentar
o sucesso das suas empresas, evoluir em suas carreiras e tornar a
profissão mais madura.”
O PMI pratica certificação profissional. No Brasil, este conceito vem sendo

discutido pela Comissão Interministerial de certificação profissional que é
composta pelos ministérios do Desenvolvimento, Indústria e Comércio Exterior,
da Educação, da Saúde, do Turismo, do Trabalho e Emprego e pelos Conselho
Nacional da Educação e Conselho Nacional do Trabalho.
Em 2005 esta comissão acordou o conceito de certificação profissional adotado

no país:

“A certificação profissional pode ser entendida como o
reconhecimento formal dos saberes e práticas do/a trabalhador/a,
desenvolvidos na experiência de vida, de trabalho, na escola ou em
programas de qualificação social e profissional. Seu sentido consiste
em tornar-se uma estratégia para promover a formação continuada
e ao longo da vida e para ampliar as oportunidades de acesso do/a
trabalhador/a brasileiro/a ao mundo do trabalho.”
Retirado do site: http://www.mte.gov.br/pnq/proposta_governamental.pdf

Tal conceito está alinhado com a atividade de certificação profissional

preconizada pelo PMI:
“O PMI oferece um programa completo de certificações para

profissionais de projetos de todos os níveis de escolaridade e de
qualificação. Atualmente constituído por seis certificação, o
programa demonstra tanto seu empenho em sua profissão quanto
sua perícia por meio de educação, experiência e competência
certificadas.
Rigorosamente desenvolvidas por gerentes de projetos e

mundialmente acreditadas pela Organização de Padrões
Internacionais (ISO), as certificações do PMI garantem que você e
seus projetos se sobressaiam..”
Retirado do site:
http://brasil.pmi.org/brazil/CertificationsAndCredentials/WhatarePMICertifications.aspx
O instituto PMI possui atualmente seis certificações profissionais diferentes e

que podem ser definidas como detalhamos a seguir:

Certificação PMP – Profissional de Gerenciamento de Projetos (PMP) ®
A certificação de Profissional de Gerenciamento de Projetos (PMP) ® do PMI é
a Certificação para gerentes de projeto . Veja no link a seguir o detalhamento
desta certificação:
Certificação CAPM – Técnico Certificado em Gerenciamento de Projetos®

A certificação de Profissional Técnico Certificado em Gerenciamento de
Projetos (CAPM) ® é projetada para aqueles com menos experiência no
gerenciamento de projetos, a certificação CAPM® atesta sua compreensão do
conhecimento, terminologia e processos fundamentais de um gerenciamento
de projetos eficiente segundo o Guia PMBOK® . Veja no link a seguir o
detalhamento desta certificação:
Certificação PgMP – Profissional de Gerenciamento de Programas®

A certificação de Profissional de Gerenciamento de Programas (PgMP)® do
PMI reconhece as habilidades e experiência de gerentes de programa
experientes. Ela atesta que você comprovou competência para supervisionar
vários projetos inter-relacionados e seus respectivos recursos para atingir
objetivos estratégicos de negócios. Veja no link a seguir o detalhamento desta
certificação:
Certificação PMI-SP – Profissional em Gerenciamento de Cronograma do PMI®

A certificação de Profissional em Gerenciamento de Cronograma (PMI-SP)® do
PMI é uma resposta ao aumento da complexidade e diversidade, e do uso do
gerenciamento de projetos no mundo. Ela preenche a necessidade de um
especialista em gerenciamento de cronograma no projeto.
Reconhece sua expertise e competência para desenvolver e manter

cronogramas dos projetos, enquanto ainda possui habilidades e conhecimento
em todas as áreas de gerenciamento de projetos.

Certificação PMI-RMP – Profissional em Gerenciamento de Riscos do PMI®
A certificação de Profissional de Profissional em Gerenciamento de Riscos
(PMI-RMP)® do PMI preenche a necessidade de um especialista em
gerenciamento de risco no projeto.
Ela reconhece sua expertise e competência para avaliar e identificar riscos,

mitigar ameaças e aproveitar as oportunidades dos projetos, enquanto ainda
possui habilidades e conhecimento em todas as áreas de gerenciamento de
projetos.
Certificação PMI-ACP – Profissional Certificado em Métodos Ágeis do PMI®

A PMI-ACP reconhece o conhecimento de princípios ágeis, práticas e
ferramentas e técnicas através de metodologias ágeis.
Você pode ver todas as certificações com detalhes através do site:

http://brasil.pmi.org/brazil/CertificationsAndCredentials.aspx
Outras características do PMI

Compartilhamento de valores
O Instituto fundamenta sua própria motivação de existência em um conjunto
de valores compartilhados por todos que estão alinhados com a visão PMI e
preconiza alguns valores institucionais:
“Impacto do Gerenciamento de Projetos

O gerenciamento de projetos é uma competência crítica que tem
uma influência positiva nos resultados das organizações e da
sociedade.
Profissionalismo
Responsabilidade, comprometimento e comportamento ético
asseguram o nosso compromisso com as partes interessadas do
PMI.

Voluntariado
Voluntários e parcerias eficazes entre voluntários e funcionários são
a melhor maneira para atingir os objetivos do Instituto.
Comunidade
Fortalecendo os membros da comunidade global de gerenciamento
de projetos em conjunto é a melhor maneira de avançar a profissão
de gerenciamento de projeto e facilitar o seu crescimento.
Engajamento
Incentivar diversos pontos de vista e permitir que as pessoas
contribuam para a profissão de gerenciamento de projeto e ao
Instituto.”
Retirado do site: http://brasil.pmi.org/brazil/AboutUS/CoreValues.aspx
Premiações relacionadas ao PMBOK

O instituto também fomenta uma série de premiações associadas ao uso e
incorporação das práticas do PMBOK utilizadas por profissionais certificados e
pelas empresas, como podemos ver de forma exemplificativa a seguir. No site
da referência é possível ver a composição detalhada de cada tipo de
premiação:
a) “Prêmios para Profissionais de Projeto;
b) Prêmio PMI Avanço da Comunidade através do
Gerenciamento de Projetos – Categoria Individual
c) Prêmio PMI Contribuição por Distinção
d) Prêmio PMI Excelência em Gerenciamento de Projetos Eric
Jenett
e) Prêmio Membro Honorário do PMI
f) Prêmio PMI Linn Stuckenbruck para a Personalidade do Ano
g) Prêmios para Organizações por Projetos Inovadores e Bem
Sucedidos
h) Prêmio PMI Avanço da Comunidade através do
Gerenciamento de Projetos – Categoria Organização

i) Prêmio PMI para Projeto Destaque
j) Prêmio PMI para Projeto do Ano
k) Prêmios para Pesquisadores e Educadores de Gerenciamento
de Projetos
l) Prêmio PMI para Resultados de Pesquisa
m) Prêmio PMI para Artigo do Ano sobre Gerenciamento de
Projetos
n) Prêmio PMI de Produto do Ano para Educação Profissional
Continuada
o) Prêmio PMI para Provedor de Educação do Ano
p) Prêmio a Autores de Bibliografia sobre Gerenciamento de
Projetos
q) Prêmio PMI David I. Cleland para Bibliografia em
Gerenciamento de Projetos”
Retirado do site: http://brasil.pmi.org/brazil/AboutUS/Professional%20Awards.aspx.
Atividade proposta
A partir dos conceitos estudados e dos links disponíveis no saiba mais,
pesquise as estruturas de certificação existentes no Brasil e debata com seus
colegas no fórum de debates, as dificuldades que o profissional de
gerenciamento de projetos que se certifique pelo PMI pode encontrar ao atuar
profissionalmente em organizações que necessitem ter certificações
compulsórias. Compartilhe relatos, fotos, vídeos ou links.
Aprenda Mais
Leia a tese de Fernando Ladeira que avalia uma metodologia de
gerenciamento de projetos.
Leia a dissertação de Thiago Cavalcante relacionada a Percepções de

maturidade relacionadas a gerenciamento de projetos.

Leia a dissertação de Murilo Oliveira relacionada à aplicabilidade de modelos
de maturidade em gerência de projetos.
Leia a dissertação de Débora Herkenhoff relacionada a diretrizes para

avaliação de maturidade de processos.
Conheça o Manual da Certificação PMP.
Conheça o Código de Ética e Conduta Profissional PMI.
Questão 1
Um conjunto de atividades realizadas por uma organização de terceira parte
(organização independente) para atestar e declarar que um produto, serviço,
pessoa ou sistema está em conformidade com os requisitos técnicos
especificados é conhecido como:
a) Sistematização;
b) Normalização;
c) Padronização;
d) Certificação;
e) Especificação;
Questão 2
Como estudamos, a certificação pode ser encontrada em mais de uma forma.
Aquela que é derivada de exigência legal e que está vinculada a uma decisão
do estado é conhecida como certificação:
a) Voluntária;

b) Compulsória;
c) Profissional;
d) Legal;
e) Tradicional;
Questão 3
O documento emitido, de acordo com as regras de um sistema de certificação,
para declarar a conformidade às normas técnicas ou a outros documentos
normativos é conhecido como:
a) Certificado;
b) Diploma;
c) Registro;
d) Norma;
e) Manual;
Questão 4
O PMI oferece seis diferentes certificações profissionais. A que
reconhece expertise e competência para avaliar e identificar riscos, mitigar
ameaças e aproveitar as oportunidades dos projetos é conhecida como
certificação:
a) PMP;
b) CAPM;
c) PMI-ACP;
d) PMI-SP;
e) PMI-RMP;

Referências
2008

Aula 7: Gerenciamento de integração - TAP
Introdução
Nesta aula, Iniciaremos a abordagem do Gerenciamento de Integração do
Projeto. Inicialmente compreendendo o papel do Gerente de projetos na
integração do projeto e posteriormente, conhecendo os processos associados a
esta área de conhecimento. Iniciaremos também o detalhamento dos
processos começando com o processo de Desenvolver o Termo de Abertura do
Projeto.
Objetivos:
 Conhecer os processos que compõe o Gerenciamento de Integração de
projetos;
 Identificar habilidades e características requeridas para o gerente de
projetos desempenhar o papel de integrador em projetos;
 Detalhar o processo de Desenvolver o Termo de Abertura do Projeto.
Conteúdo
Introdução
Porque Integração? Não seriam os processos e o ciclo suficientes? Precisamos
de uma área de conhecimento específica para integração?
Considerando o gerenciamento de projetos como um instrumental sistêmico

que olha para o projeto (e para a organização na qual ele se insere) sob uma
ótica de sistema aberto, os processos em si representam apenas um dos
componentes sistêmicos do modelo, assim como o ciclo representa o
deslocamento do modelo no tempo.
Precisamos considerar as relações de interdependência e modelos de

monitoramento e controle para realmente termos a percepção de sistema
aberto.

Considerando esta característica conceitual do instrumento, pode-se indicar
que estas relações de interdependências, embora ocorram de forma individual
entre as partes que compõe uma estrutura, elas causam impacto sistêmico no
modelo.
Ou seja, uma ação que se executa em uma determinada relação entre partes
impacta de forma direta ou indireta a resultante final associada ao objetivo do
instrumento.
Vejam esta percepção na ótica metodológica do PMBOK:

“Os processos de gerenciamento de projetos são geralmente
introduzidos como distintos e com fronteiras comuns definidas,
enquanto que na prática, os mesmos sobrepõem-se e interagem de
maneiras que não podem ser completamente detalhados no Guia
PMBOK”
(PMBOK 4)
Assim, esta área de conhecimento visa incluir processo e atividades que

busquem em relação a vários processos e atividades dos grupos de processos
de gerenciamento:
 Combinar;
 Unificar; e
 Coordenar;
Assim, as ações desta área de conhecimento estão relacionadas à unificação,

consolidação, articulação e integração que foquem no sucesso do projeto,
atendendo seus requisitos acordados.
Dessa forma, esta área será um dos principais espaços para que tenhamos
ações que possibilitem minimizar conflitos entre as demais áreas e onde as

escolhas relacionadas a alocações e concessões confluem com os conflitos que
aparecerem na dinâmica do ciclo de vida do projeto.
Esta necessidade se torna evidente quando temos a interação entre diversos

processos, notadamente nos desdobramentos que ocorrem com ajustes ao
planejado ao longo da execução do projeto ou em impactos decorrentes da
própria organização, de outros projetos que ocorram em paralelo e que
compartilhem recursos organizacional, de mudanças de requisitos dos clientes
ou de impactos não previstos do mercado.
Esta área também é importante para garantir a consistência do projeto e da

documentação nele associada se mantenham alinhadas com a realidade até a
entrega do objeto singular. Vejamos a seguir os processos que compõe esta
área.
Processos de Gerenciamento de Integração

Nesta área de conhecimento vamos trabalhar focados em seis processos de
gerenciamento mantidos desta forma desde a publicação do PMBOK 4:
a) Desenvolver o Termo de Abertura do Projeto (TAP);

b) Desenvolver o plano de Gerenciamento do Projeto;
c) Orientar e gerenciar a execução do projeto;
d) Monitorar e controlar o trabalho do projeto;
e) Realizar o Controle integrado de Mudanças; e
f) Encerrar o projeto ou fase.
O Gerente do Projeto como Integrador

Embora por definição da metodologia, a equipe do projeto somente esteja
formalmente definida após a aprovação do TAP, o gerente do projeto é o
ponto focal da integração em relação as atribuições do grupo social associado
ao projeto. Muitas vezes as situações de conflito e as não inicialmente

previstas somente conseguem ser percebidas ou rastreadas com a
interveniência do Gerente.
Segundo DINSMORE (2009), “cabe ao gerente de projeto coordenar a

elaboração do plano de gerenciamento do projeto, assim como sua execução e
modificações que surjam durante todo o desenvolvimento do projeto...Por ser
um integrador do projeto e, portanto, peça-chave do quebra-cabeça, é
desejável que o gerente do projeto seja alguém com habilidades de liderança,
facilitação, coordenação de tarefas, comunicação e conhecimento de gerência
de projetos.”
E que habilidades seriam estas?
Inicialmente podemos focar no que DINSMORE indica e abranger habidades de

comunicação, organização, gerenciamento de informações e de gerenciamento
do tempo (neste caso do gerente e não do projeto).
Quando falamos de Comunicação, o foco é amplo: Verbal e escrita. Pois serão

requeridas ambas nas diversas situações a que o gerente vai interagir. Falar
do gerenciamento de informações e de organização tem uma relação forte de
dependência com a gerencia do tempo.
Gerentes desorganizados e que não gerenciam bem informações na maioria

das situações também não gerenciam bem seu tempo.
O tempo é um parâmetro interessante para avaliação. O dia somente tem 24

horas de duração e alocamos coisas a fazer nesta dimensão finita.
Se a estrutura gerencial ou de informações não está bem entendida ou

gerenciada, fatalmente vamos consumir mais tempo para fazer o mesmo
conjunto de atividades.

Nesta ótica a pergunta crítica que muitas vezes fazemos não deve ser:
Como meu colega de trabalho consegue fazer o triplo da quantidade de

trabalho que eu no mesmo tempo?
Mas sim:
Como posso gerenciar melhor minhas informações e estruturar minhas

atividades? Pois vejo outros colegas que gerenciam melhor o tempo e
produzem muito mais que eu.
Podemos colocar que a gerência do tempo pessoal é uma ferramenta para

podermos entender inputs e estabelecer prioridades para eles.
O mercado possui diversas ferramentas que podem auxiliar o individuo nesta

gerência. Indo de agendas, lista de tarefas ou até técnicas mais elaboradas de
gerenciamento, mas não terá efeito se o indivíduo não buscar mudança nas
suas atitudes.
Focando na questão das prioridades, a definição de prioridades é um dos

pontos principais nesta construção de competências do gerente como
integrador.
Se a integração contém relações que mixam diferentes processos no tempo

(tanto processos endógenos ao projeto como exógenos), como identificar
prioridades distintas dentro dos diversos inputs que recebemos como
gerentes?
Dentro das diversas abordagens de tipologias de prioridades existentes no

mercado, vamos utilizar a tipologia de prioridades indicada por HELDMAN
(2005), que distingue quatro zonas diferentes de prioridades a gerenciar, para
ilustrar esta situação:

“a) Zona de Combate a Incêndio:
Na eventualidade de um Incêndio, é preciso apaga-lo na hora, senão os
problemas ficarão ainda maiores. Você precisa largar tudo que está fazendo
para solucionar os problemas que surgem a sua volta... Convém perder o
mínimo possível de tempo nesta zona, pois ela toma muito tempo da pessoa.
Você poderá safar-se dela se passar mais tempo na zona de planejamento.”
(HELDMAN, 2005)
Muitas vezes percebemos que na prática passamos a maior parte do tempo

nesta zona, o que é muito ruim para o gerente. Se o gerente já se encontra
nesta situação deve proceder esforço adicional em pró de melhorar o
planejamento para diminuir o impacto desta zona.
b) Zona de Planejamento:
Ao Planejar você obtem o controle. Dê ênfase ao planejamento de atividades,
assim se afastará da zona de combate a incêndio. Também é muito importante
revisar os itens e as prioridades da lista. O planejamento não é estático no
tempo, mas sim dinâmico e as prioridades mudam constantemente.
Uma das dúvidas que muitas vezes surgem é quando o Gerente vive o tempo
todo na zona de combate a incêndio e surge a dúvida: Como posso ir para a
zona de planejamento, se minha vida é apagar incêndios?
Um ponto importante é ter a percepção que a mudança não é imediata.

Comece planejando o dia. Organize as tarefas, faça suas escolhas logo no
início da manhã, veja neste momento sua lista de atividades e prioridades.
Depois vá antecipando o planejamento. Planeje amanhã hoje, se planeje com

2, 3, 4 dias de antecedência e continue aumentando a antecipação...

Claro que vão ter situações que não serão planejáveis com tanta antecedência
como gostaríamos, mas se o seu grau de antecipação for bom, vai ter tempo
planejado disponível para justamente atender demandas não identificadas
anteriormente: Planejar tempo disponível para combate a incêndios também é
planejamento...
Adaptado de HELDMAN, 2005
“c) Zona de Desperdício de Tempo:

O alarme dispara, mas não há, na realidade, crise alguma. Nesta zona, podem
surgir reuniões desnecessárias, e-mails e recados nada importantes, lixo
eletrônico, visitas inesperadas, e outras situações similares... Faça tudo para
ficar longe desta zona, porque ela lhe fará perder tempo e você não terá nada
concluído.”
HELDMAN, 2005
Uma coisa importante que ocorre nesta situação é sabermos se REALMENTE é

um incêndio que afeta o resultado: distinguir o que é incêndio ou não também
auxilia muito o gerente na melhoria da ação de integração. Uma das técnicas
mais conhecidas no gerenciamento do tempo de gerentes é o gerenciamento
dos “macaquinhos”.
Leia o texto elaborado por WASS e ONCKEN Jr. sobre o

Tempo do administrador.
d) Zona de procurar um novo emprego:

Não tem alarme disparando, não tem nenhuma crise, não há motivação para
fazer nada. Muitas vezes você se percebe sendo o gerador de desperdício de
tempo para os outros que estão a sua volta. Se estiver constantemente nesta
situação, se pergunte: Você gosta de seu trabalho ou está apenas matando
tempo?
(Adaptado de HELDMAN, 2005)

Um gerente com este uso do tempo corre o sério risco de nem perceber o que
está de fato ocorrendo em seu projeto e junto com o fracasso dele gerar o
próprio fracasso pessoal como gerente.
Se esta for a situação, se esforce para mudar (mesmo que seja de emprego)
para não gerar uma situação que te acompanhe pelo restante de sua vivência
profissional.
Confrontando as quatro percepções vistas, podemos perceber que se

minimizarmos ao máximo as ocorrências das zonas c) e d), temos como focar
no planejamento e diminuir o impacto dos incêndios que surgem...
Reflitam sobre isto!
Outro ponto de atenção do gerente que deseja ser integrador em seu projeto
é perceber quantas conexões existem no projeto, antes de pensar em agir na
integração de algumas.
Sem esta percepção o gerente pode achar que está promovendo integração,
mas não tendo percepção macro corre o sério risco de gastar esforço em algo
que melhore pontualmente um aspecto/processo mas que impacte
negativamente o resultado final.
Nem sempre as falhas dos gerentes são exclusivamente motivadas por ele
próprio. Devemos considerar que o gerente foi escolhido por um executivo e
se o gerente é um indivíduo que não consegue da zona de desperdício de
tempo e da zona de procurar novo emprego, o executivo que escolheu ele
também tem parte da responsabilidade pelo fracasso. A escolha do gerente
pelo executivo pode ser feita considerando parâmetros que permitam
minimizar os riscos indicados nas zonas que não sejam a de planejamento.

KERZNER, indica em sua obra “o Que os executivos precisam saber sobre
gerenciamento de projetos” alguns requisitos (fatores) que devem influenciar a
sua decisão de escolha de um gerente. Vejamos eles:
“a) Requisitos de conhecimento comercial;

b) Requisitos de conhecimento técnico;
c) Experiência em gerenciamento de projetos;
d) Capacidade de liderança;
e) Habilidade em formação de equipes;
f) Experiência anterior com exigências específicas dos clientes;
g) Habilidade em integração;
h) Reputação; e
i) Capacidade de fazer avaliações econômico-financeiras.”
(KERZNER, 2011)
Claro que na maioria das situações o executivo não vai encontrar sempre
pessoas com todos os requisitos elencáveis para ser um gerente de projetos e
parte deles deve ser desenvolvido ao longo do tempo.
Muitas vezes, o executivo, nas escolhas que deve tomar em relação aos
requisitos também avalia aqueles ainda não efetivamente visualizados no
candidato a gerente, de uma forma potencial.
Nesta situação, e ao longo do tempo que se necessita para desenvolver

aptidões, temos ações que dependem tanto do executivo que identificou as
potencialidades como do indivíduo que estiver atuando como gerente, vejamos
algumas delas:
1) Ganhar experiência, trabalhando no maior numero de projetos que

puder;
2) Obter feedback de outras pessoas (gerentes de outros projetos ou de
outras equipes);

3) Realize auto avaliações e aprenda com os próprios erros;
4) Fale com gerentes de projetos que evidenciam possuir habilidades que
você deseja desenvolver;
5) Participe de programas de treinamentos que possam te dar ampliação
de capacitação, ainda que não aplique imediatamente elas;
6) Faça parte de organizações. Se o seu foco de escolha metodológica (ou
da empresa em que trabalha) é a metodologia do PMI, participe do
instituto e obtenha certificação.
7) Leia, principalmente o que está no estado da arte; e
8) Seja voluntario em atividades distintas daquelas que executa em sua
atividade principal.
(Adaptado de GIDO, 2010)
Uma forma ampla de aglutinar o entendimento citado acima é olhar o gerente

como indivíduo proativo que deve ser. Esta visão implica em que o gerente e
também sua equipe atuem de forma contínua e interdependente em toda a
dimensão da estrutura da organização que suporta o projeto.
KERZNER na obra gerenciamento de projetos orientado a valor (2011), indica

explicitamente esta dimensão na forma do modelo da Pirâmide do Debriefing,
que pode ser visualizada na figura a seguir:
(KERZNER, 2011)

Na continuidade desta aula vamos desdobrar o processo de Desenvolver o
Termo de Abertura do Projeto, fazendo o detalhamentos dos cinco outros
processos na aula 8.
Desenvolvimento do Termo de Abertura do Projeto (TAP): Entradas

Como passo inicial precisamos formalizar os entendimentos e negociações que
o cliente e a organização vem fazendo desde que a ideia relacionada ao
projeto surgiu. Ao formalizarmos e documentarmos os requisitos iniciais que
satisfaçam as necessidades das partes interessadas no projeto, estamos
estabelecendo um marco referencial para a própria existência do Projeto.
Mas... São os requisitos iniciais?
Sim. Neste momento o escopo ainda não foi efetivamente definido e o que
temos de fato representa um conjunto de ideias consensuais, que buscam
elencar os requisitos conhecidos e entendidos entre as partes.
Neste ponto, o TAP pode ser recorrente, se pensarmos nele associado ao

projeto como um todo ou a uma fase dele:
“é o processo de desenvolvimento de um documento que

formalmente autoriza um projeto ou uma fase dele,”
PMBOK 5, 2012
Neste processo é desejável que seja identificado, selecionado e designado um

gerente do projeto e sempre que possível, este gerente participe da
elaboração do TAP. Mas quem o autoriza não é o gerente, mas sim um
elemento externo, que pode ser um patrocinador, um escritório de projetos ou
quem cuida de um portfólio em uma organização.

Como o TAP é um documento que formaliza, logo em seu início deve constar a
assinatura quem autoriza o projeto.
Segundo o PMBOK 5, temos como entradas deste processo:
a) Declaração de Trabalho do projeto (DT);

Consiste em uma descrição, de cunho narrativo do que vai ser gerado pelo
projeto. Aqui temos como base duas situações, se o projeto é interno da
organização ou se envolve uma relação direta com um cliente.
No primeiro caso (projeto interno), a narrativa deve conter 3 elementos bem

identificados:
1. Contextualização de Necessidade de negócios: indicando a pertinência

do projeto para esta(s) necessidade(s).
2. Descrição do Escopo do produto: Ainda que não seja detalhada da
forma como teremos no gerenciamento do escopo, deve conter os
requisitos que identifiquem a singularidade do Projeto; e
3. Alinhamento do projeto interno com o que está previsto e aprovado no
plano estratégico da organização.
No caso de projeto que envolve uma relação direta com o cliente (vamos
chama-lo de projeto externo), esta narrativa pode vir na forma de um pedido,
de uma proposta, de uma solicitação de preços ou como um edital e anexos de
uma licitação (pública ou privada), ou ainda como parte de um contrato mais
amplo com a organização.
b) Business case;
No Business case, devemos ter elementos elucidativos relacionados a
vantajosidade do projeto como investimento, como no DT, se o projeto for
externo, devemos receber esta contextualização também feita externamente,

caso seja interno ela deve ser desdobramento de uma escolha estratégica da
organização.
Neste Business Case devemos identificar as necessidades organizacionais, as

solicitações do cliente, a incorporação, impacto tecnológico e a demanda
conhecida de mercado, os requisitos legais (quando existirem), impactos
ambientais e sociais relacionados.
Quando temos projetos complexos, é recomendado que o Business Case seja

revisado periodicamente para ajustar o seu conteúdo à realidade.
c) Contrato;
No caso de projetos externos, o contrato a que estiver vinculado é uma
entrada neste processo. Aqui destaca-se que quando a vinculação do contrato
envolve relacionamento com o estado, ele contém um conjunto de
prerrogativas legais mais amplo que as reguladas pelo código civil e que
muitas vezes trazem cláusulas exorbitantes (que geram mais vantagens para o
estado do que para o contratado) e que devem estar explicitas a todos que
participam do projeto.
d) Fatores Ambientais da Empresa;

Aqui devemos considerar as condições de mercado, a própria infraestrutura
organizacional que ampara o projeto e padrões governamentais ou da
indústria que impactem no projeto.
e) Ativos de processos organizacionais

Nesta parte podemos considerar o próprio conhecimento histórico que a
organização possui com as lições aprendidas, politicas da organização e
processos já padronizados e modelos que podem ser aplicados ao projeto.
Desenvolvimento do Termo de Abertura do Projeto (TAP):

Ferramentas e Técnicas

O PMBOK 5 preconiza como principal ferramenta e técnica deste processo o
uso de Opinião especializada. Ela pode ser oferecida por qualquer grupo de
pessoas que a organização considere deter conhecimento e/ou treinamento
relacionado ao projeto e pode ser representada por elementos estruturais da
própria organização, consultorias, escritórios de projetos, ou outras partes
interessadas no projeto.
Desenvolvimento do Termo de Abertura do Projeto (TAP): Saídas

O PMBOK 5 preconiza que a principal saída deste processo é o próprio TAP,
devendo conter:
 Propósito ou Justificativa do projeto
 Objetivos mensuráveis do projeto e critérios de sucesso relacionados
 Requisitos de alto nível
 Descrição do projeto em alto nível
 Riscos de alto nível
 Resumo do cronograma de marcos
 Resumo do Orçamento
 Requisitos para aprovação do projeto
 Definição do gerente do projeto, suas responsabilidades e autoridade
 Nome e autoridade do patrocinador ou de quem autoriza o projeto.
(PMBOK 5, 2012)
Atividade proposta
com seus colegas no fórum de debates, as dificuldades para inserirmos no TAP
um volume de informações que minimizem riscos e aumentem a integração do
projeto em todo o seu ciclo. Compartilhe relatos, fotos, vídeos ou links.
Aprenda Mais
Leia o artigo relacionado a como estudo de caso de gerenciamento da
integração do Grupo PMI-Rio.

Artigo relacionado as habilidades requeridas de um gerente de um projeto:
http://www.pmipe.org.br/web/arquivos/Perfil_Gerente_de_Projetos_pmipe.pdf
Artigo relacionado a habilidades e competências do gerente de projetos:

INSERIR AQUI LINK PAREA O SAIBA MAIS 4.PDF
Leia o artigo O duplo papel do Gerente de Projeto.
Leia o artigo Perfil do Gerente de Projetos.
Leia o artigo Gerência de Integração do Projeto.
Leia os artigos relacionados à Organização como sistema aberto:

 Teorias da administração - enfoque acadêmico;
 A teoria geral dos sistemas na teoria das orqanizacões.
Questão 1
Stakeholders do projeto são indivíduos e organizações ativamente envolvidos
com o projeto, ou cujos interesses podem ser positiva ou negativamente
afetados pelo projeto. Com base nesta definição, qual dos indivíduos ou
grupos abaixo indicados NÃO é um stakeholder?
a) O Cliente;
b) A comunidade onde o projeto acontece;
c) O sponsor ;
d) O Escritório de Projetos;
e) Membro da equipe de um projeto

Questão 2
A empresa Drake´s S/A está finalizando a negociação da execução de um
projeto de construção de um navio sonda com um grupo petrolífero chinês.
Rafael foi escolhido como Gerente do Projeto, Juarez é o diretor da empresa,
Paula é a responsável pelo escritório de projetos da empresa, Luis é o
representante legal da contratante (empresa chinesa) e Eduardo é membro da
equipe já designado para auxiliar Rafael no início do projeto.
No TAP, quem dá a autorização de início do projeto após o contrato estar
assinado entre a empresa e a petrolífera?
a) Rafael;
b) Juarez;
c) Luis;
d) Paula;
e) Eduardo;
Questão 3
Quando um gerente está utilizando o seu tempo para receber diversas pessoas
da organização, auxiliar problemas de outros setores, participar de reuniões
desnecessárias, ler e-mails e responder recados nada importantes, receber
visitas inesperadas, e outras situações similares, ele está na zona de:
a) desperdício de tempo;
b) combate a incêndios;
c) planejamento;
d) procurar um novo emprego;
e) integração organizacional;

Questão 4
Em relação às entradas do processo de desenvolvimento do TAP, indique nas
alternativas a seguir a única que NÃO tem uma das entradas preconizadas
pelo PMBOK 5:
a) DT;
b) Business Case;
c) Contrato;
d) Cronograma do Projeto;
e) Ativos de Processos Organizacionais;
Referências
2005

2008.
GIDO, Jack. Gestão de Projetos, Ed. Cengage Learning, São Paulo, 2010
KERZNER, Harold. Gerenciamento de Projetos Orientado por Valor, Ed.

Bookman, Porto Alegre, 2011
KERZNER, Harold. O que os Executivos precisam saber sobre gerenciamento

de projetos, Ed. Bookman, Porto Alegre, 2011
DINSMORE, Paul C. Como se Tornar um Profissional em Gerenciamento de

Projetos, Ed. Qualitymark, Rio de Janeiro, 2009

Aula 8: Gerenciamento de integração - processos
Introdução
Nesta aula, daremos continuidade e concluiremos a abordagem do
Gerenciamento de Integração do Projeto fazendo o detalhamento dos
processos de desenvolver o plano de Gerenciamento do Projeto, orientar e
gerenciar a execução do projeto, monitorar e controlar o trabalho do projeto,
realizar o Controle integrado de Mudanças e do encerramento do projeto ou
fase.
Objetivos:
 Detalhar o processo de desenvolver o plano de Gerenciamento do
Projeto;
 Detalhar o processo de orientar e gerenciar a execução do projeto;
 Detalhar o processo de monitorar e controlar o trabalho do projeto;
 Detalhar o processo de realizar o Controle integrado de Mudanças; e
 Detalhar o processo de encerrar o projeto ou fase.
Conteúdo
Introdução
Depois de termos estudado o papel integrador do gerente de projetos e o
processo de desenvolvimento do termo de abertura do projeto (TAP) vamos
dar continuidade ao estudo desta área de conhecimento e desdobrar os outros
cinco (5) processos associados a ele pelo PMBOK. Seguindo a linha
metodológica do PMBOK 5, este detalhamento será realizado com a
contextualização conceitual do processo, a indicação de suas ferramentas e
técnicas associadas e o detalhamento de suas entradas e saídas esperadas.
Detalhamento dos processos do gerenciamento da integração

Este processo contém a documentação das ações relacionadas aos planos,
necessárias para:
a) Definir;
b) Preparar;
c) Integrar; e
d) Coordenar.
O Produto deste processo é um plano, mas a forma detalhada dele e o seu

conteúdo vão variar dependendo da área de negócios envolvida e da
complexidade do projeto.
(Adaptado do PMBOK)
2.1.1 – Entradas do processo de desenvolvimento do Plano de Gerenciamento

do Projeto
O PMBOK indica quatro entradas deste processo:

a) Termo de Abertura do Projeto (TAP);
b) Saídas dos processos de Planejamento;
c) Fatores Ambientais da Empresa;
d) Ativos de processos organizacionais
PMBOK 5, 2012
Este é o primeiro momento de nosso estudo em que podemos ver

efetivamente a recorrência dos processos no ciclo de vida do projeto.
As entradas c) e d) acima descritas também são entradas do processo de

desenvolvimento do termo de abertura do projeto, estudado na aula anterior e
a entrada a) é a única saída do processo de desenvolvimento do termo de
abertura do projeto.
O que podemos indagar com isto?

As entradas c) e d) deste processo também são entradas do processo que
produz a entrada a), então porque repeti-las se elas foram consideradas
anteriormente? Não seria perda de tempo?
Não. Este é típico exemplo de interdependência entre partes e uma boa forma
de visualizar como ao inserirmos o fator tempo (linearmente falando) no ciclo
de vida do projeto, surgem as relações de recorrência. O PMBOK indica
explicitamente isto na própria definição do processo de desenvolvimento do
plano de gerenciamento do projeto:
“O plano de gerenciamento é desenvolvido através de uma série de

processos integrados até o encerramento do projeto. Esse processo
resulta num plano de gerenciamento do projeto que é
progressivamente elaborado através de atualizações
controladas e aprovadas pelo processo realizar o controle
integrado de mudanças.”
PMBOK 5 – grifo nosso
Nesta definição o PMBOK indica diretamente também a interdependência com

outro processo do gerenciamento de integração (que também é objeto de
estudo nesta aula).
Este tipo de relação vamos ver ao longo dos 47 processos preconizados no

PMBOK 5 e nas suas associações com as diversas áreas de conhecimento e
com as fases do ciclo de vida do projeto e explicitam claramente a constituição
conceitual sistêmica que está presente na concepção do instrumento
metodológico.
Assim, a composição das entradas a), c) e d) já foram estudadas na aula

anterior e não precisam novamente ser detalhadas. Vamos Assim explicitar a
composição da entrada b):

Saídas dos processos de Planejamento:
Esta entrada explicita a necessidade de integração que diversas saídas de
diversos processos de planejamento que estão preconizados nas demais áreas
de conhecimento previstas na metodologia.
Assim qualquer saída de um dos processos de planejamento pode ser

considerada aqui, incluindo as alterações que ocorram ao longo do ciclo de
vida do projeto.
Percebemos então que esta é a principal entrada que vai associar a dinâmica
do fluxo temporal do ciclo do projeto à atualização do plano de gerenciamento.
Ela se diferencia claramente das entradas c) e d), que embora tenham impacto
recorrente no tempo, não possuem uma vinculação explicita a dinâmica do
ciclo, mas sim a fatores exógenos ao projeto, que podem ser ou não exógenos
à organização: a c) explicita fatores exógenos a organização (ambientais) e a
d) explicita fatores exógenos ao projeto, mas pertencentes as escolhas
estratégicas da organização que suporta o projeto.
2.1.2 – Ferramentas e Técnicas do processo de desenvolvimento do Plano de

Gerenciamento do Projeto
A composição ferramental deste processo, Opinião Especializada, é idêntica a

estudada no processo visto na aula anterior e não precisa novamente ser
detalhada.
2.1.3 - Saídas do processo de desenvolvimento do Plano de Gerenciamento do

Projeto
Neste processo a única saída é o próprio plano de gerenciamento do projeto.

Ele consolida todos os planos auxiliares e inclui pelo menos:

a) Descrição do ciclo de vida selecionado para o projeto e a indicação dos
processos que serão aplicados a cada fase;
b) Definição das adequações feitas pela equipe de gerenciamento do
projeto em relação aos processos de gerenciamento selecionados, ao
nível de implementação de cada processo selecionado, a descrição das
ferramentas e técnicas escolhidas para uso e como estes processos
serão utilizados para gerenciar o projeto, suas dependências e
interações bem como as entradas e saídas essenciais para cada
processo;
c) Como o trabalho será executado para completar os objetivos do projeto;
d) Um plano de gerenciamento de mudanças que documente o
monitoramento e controle delas;
e) Um plano de gerenciamento de configuração;
f) Um detalhamento de como manter a integridade das linhas de base de
medição de desempenho do projeto;
g) Necessidades e técnicas para a comunicação entre as partes
interessadas;
h) Definição de como fazer as revisões chave de gerenciamento de
conteúdo, abrangência e melhor momento para tratar as pendências.
Adaptado do PMBOK 5
Conceitualmente o plano de gerenciamento pode ser resumido ou detalhado e

pode ser único ou decomposto em planos auxiliares. A metodologia PMBOK
não impõe nenhuma restrição quanto a isto.
Assim o nível de detalhamento por si é uma decisão estratégica. Mas após a

definição deste nível de detalhamento e da geração do plano de
gerenciamento do projeto, as alterações devem ser obrigatoriamente
formalizadas e aprovadas usando o processo de realizar o controle integrado
de mudanças.

De forma exemplificativa podemos em relação as linhas de base, ter pelo
menos:
a) Linha de Base do Cronograma;

b) Linha de base do desempenho de custos; e
c) Linha de base do Escopo.
(PMBOK 5, 2012)
Outro ponto que sempre geram muita discussão em relação ao grau de

detalhamento é se devemos ter um plano único ou decompor em planos
auxiliares. E neste caso, em quantos?
O PMOBOK deixa isto em aberto justamente por termos complexidades e

naturezas distintas nos projetos que podem gerar modelos de projetos bem
diversos. Como sugestão exemplificativa o PMBOK exemplifica alguns planos
auxiliares que podem compor o plano de gerenciamento:
 Escopo;  Recursos humanos;

 Requisitos;  Comunicações;
 Cronograma;  Riscos;
 Custos;  Aquisições; e
 Qualidade;  Partes interessadas.
 Melhorias no processo;
PMBOK 5, 2012
Podemos perceber como as sugestões de planos auxiliares do

gerenciamento de projetos tem uma forte aderência com a forma como o
PMBOK segrega as diversas áreas de conhecimento e o foco da alteração
estar centrado no processo de realizar o controle integrado da mudança
evidencia a necessidade de termos elementos clarões e bem mapeados que
permitam integrar as áreas ao longo do ciclo de vida do projeto.

2.1 - Detalhar o processo de orientar e gerenciar a execução do projeto;
Neste processo focamos na realização do trabalho definido no plano de

gerenciamento do projeto e podemos indicar várias atividades que estão
normalmente relacionadas a este processo:
 Execução das atividades;

 Definir as entregas do projeto;
 Capacitação contínua da equipe;
 Obtenção, gerenciamento e uso dos diversos recursos;
 Implementação de padrões e métodos escolhidos;
 Estabelecimento e gerenciamento dos canais de comunicação;
 Geração dos dados do projeto;
 Geração e execução das mudanças aprovadas;
 Gerenciamento dos riscos;
 Gerenciamento de fornecedores e da área comercial; e
 Coletar e implementar lições aprendidas e implementar melhorias
aprovadas.
PMBOK 5. 2012
Especificamente em relação a implementação de mudanças devemos incluir

ações preventivas e corretivas bem como reparos de defeitos.
2.2.1 – Entradas do processo de orientar e gerenciar a execução do projeto:

a) Plano de Gerenciamento do Projeto;

b) Solicitações de mudança aprovadas;
(PMBOK 5, 2012)

A composição das entradas c) e d) já foram estudadas na aula anterior e não
precisam novamente ser detalhadas bem como a entrada a) que foi o objeto
de saída do processo estudado anteriormente nesta aula. Vamos Assim
explicitar a composição da entrada b):
Solicitações de mudança aprovadas:

Assim como no processo anterior evidenciamos pela primeira vez uma
recorrência que vinha de um processo que ocorre antes do processo em
estudo e que podia ocorrer recorrentemente ao longo do ciclo de vida do
projeto.
Neste processo aparece uma recorrência, que além de poder recorrer ao longo
do ciclo de vida do projeto, tem sua primeira citação antes dela efetivamente
ocorrer no ciclo.
Esta previsão de entrada é resultante de uma ação futura que explicita a

direção de fluxo do processo, o que, na conceituação sistêmica, se explicita
pelo conceito de FEEDBACK ou retroalimentação.
Elas podem se abranger múltiplas áreas do projeto, mas o ponto central desta
entrada é que ela deve ser um documento APROVADO, senão não tem valor
de entrada no processo.
2.2.2 – Ferramentas e Técnicas do processo de desenvolvimento do Plano

de Gerenciamento do Projeto
A composição ferramental deste processo, Opinião Especializada, é idêntica

a estudada no processo visto na aula anterior e não precisa novamente ser
detalhada.
2.2.3 - Saídas do processo de orientar e gerenciar a execução do projeto:

As saídas preconizadas no PMBOK 5 para este processo são:
a) Entregas:
Segundo o PMBOK 5 podemos conceituar entregas como:
“Qualquer produto, resultado ou capacidade para realizar
um serviço exclusivo e verificável e que deve ser
produzido para concluir um processo, uma fase ou um
projeto.”
(PMBOK 5, 2012)
b) Informações sobre o desempenho do trabalho:

Nesta saída podemos explicitar diversas informações que podem variar
com a natureza e complexidade do projeto. O PMBOK 5 indica para pelo
menos termos informações relacionadas ao andamento do cronograma,
acumulação de custos e estado das entregas definidas.
c) Solicitações de mudança:
Esta saída evidencia outra situação ligada a recorrência e à
interdependência, pois se temos na entrada mudanças aprovadas, elas
podem surgir de onde?
Um dos processos é o próprio processo de orientar e gerenciar a

execução do projeto, além de outras fontes internas e/ou externas que
solicitem mudanças.
d) Atualizações do plano de gerenciamento do projeto:

As atualizações tanto podem ser no plano ou nos seus desdobramentos
(planos auxiliares).
e) Atualizações dos documentos do projeto:

Podemos fazer atualizações em quaisquer documentos relacionados ao
projeto.
(Adaptado do PMBOK 5, 2012)
2.2 - Detalhar o processo de monitorar e controlar o trabalho do projeto

Este é um processo que vai ocorrer durante todo o ciclo de vida do projeto e
vai ser fonte de obtenção de dados para o gerenciamento do projeto.
Incluindo coleta, medição e distribuição de informações de avaliação e
desempenho.
Podemos indicar que um monitoramento contínuo auxilia a equipe a entender

melhor a dinâmica de execução do projeto e o controle é base para medidas
preventivas e/ou corretivas.
Segundo o preconizado no PMBOK 5:

“Monitorar e controlar o trabalho do projeto é o processo de
acompanhamento, revisão e ajuste do progresso para atender aos
objetivos de desempenho definidos no plano de gerenciamento. “
PMBOK 5, 2012
Assim podemos associar este processo a atividades relacionadas a confronto

de desempenho entre o planejado e o real, avaliação de alternativas de
mudanças em função do monitoramento e controle, identificação e
monitoramento de riscos (novos ou já conhecidos) e fornecimento de
informações diversas para monitoramento e controle.
2.3.1 – Entradas do processo de monitorar e controlar o trabalho do projeto:

b) Relatórios de desempenho;

(PMBOK 5, 2012)
A composição das entradas c) e d) já foram estudadas na aula anterior e

não precisam novamente ser detalhadas bem como a entrada a) que foi o
objeto de saída do processo estudado anteriormente nesta aula. Vamos
Assim explicitar a composição da entrada b):
Relatórios de desempenho:
Os relatórios podem ser dos diversos tipos, formatos e aplicações,
direcionados a um ou mais processos de gerenciamento, mas podemos
agrupa-los de uma forma macro (exemplificativa, mas não exaustiva) em
relatórios que evidenciam a situação atual de um projeto ou que explicitem
realizações significativas em um período ou que indiquem desempenhos
obtidos em atividades em curso, ou que sirvam de informações para tomada
de decisões em relação a situações futuras, dentro do ciclo de vida do projeto.
Além destes pontos de aplicação podemos ter relatórios específicos

relacionados a natureza ou a complexidade do projeto
2.3.2 – Ferramentas e Técnicas do processo de desenvolvimento do Plano de

Gerenciamento do Projeto
A composição ferramental deste processo, Opinião especializada, é idêntica a

detalhada.
2.3.3 - Saídas do processo de orientar e gerenciar a execução do projeto:

a) Solicitações de mudança:
b) Atualizações do plano de gerenciamento do projeto:

c) Atualizações dos documentos do projeto:
A composição das saídas a), b) e c) já foram estudadas nesta anterior e não

precisam novamente ser detalhadas.
2.3 - Detalhar o processo de Realizar o Controle integrado de Mudanças

Este é um dos processos que ocorre ao longo de todo o projeto e apresenta
características recorrentes que impactam em processos distintos e em áreas de
conhecimento diversas. É um dos processos em que o gerente no seu papel
integrador deve acompanhar de perto e rotineiramente pois seu impacto na
rotina do gerente e da equipe do projeto não só é constante como implica em
ações que podem afetar todo o ciclo de vida do projeto.
2.4.1 – Entradas do processo de Realizar o Controle integrado de Mudanças:
O PMBOK indica cinco entradas deste processo:

b) Informações sobre o desempenho do trabalho;
c) Solicitações de Mudança;
d) Fatores Ambientais da Empresa;
e) Ativos de processos organizacionais
(PMBOK 5, 2012)
A composição de todas estas entradas já foram estudadas ao longo desta aula

e da anterior (como entradas ou como saídas) e não precisam novamente ser
detalhadas novamente.
2.4.2 – Ferramentas e Técnicas do processo de Realizar o Controle integrado

de Mudanças

O PMBOK preconiza duas ferramentas e técnicas neste processo. Uma delas, a
Opinião especializada, é idêntica a estudada no processo visto na aula anterior
e não precisa novamente ser detalhada.
A outra refere-se a Reuniões de controle de mudanças que deve ser

organizada na forma de comitê e segundo o preconizado no PMOBK 5 deve ser
responsável tanto pelos agendamentos das reuniões como da revisão das
solicitações de mudanças, suas aprovações ou rejeições.
Seu papel e responsabilidades devem estar explicitamente definidos pelas

partes interessadas apropriadas e todo o produto de informação destas
reuniões deve estar documentado e ser comunicado as partes interessadas,
ainda que seja a título de informação.
(Adaptado PMBOK 5, 2012)
E se a mudança é no Termo de Abertura do Projeto (TAP)? É o comitê que

aprova?
DINSMORE (2009), indica que se a alteração faz referência ao TAP, quem

aprovou o TAP é quem aprova a mudança, o gerente do projeto e o comitê
podem fornecer opções e sugestões.
Neste caso, o patrocinador pode necessitar remanejar recursos organizacionais

que impactem em outros projetos ou mesmo na operação corrente da
organização, o que explicita um dilema que deve ser resolvido por alguém fora
do projeto e que detenha poder de patrocinador.
“Tirar recursos de outros projetos para ajudar um projeto que demanda

mudanças pode fazer com que outros cronogramas sejam afetados e
possivelmente resulte e problemas ainda mais sérios.”
(Adaptado de KERZNER, 2009)

2.4.3 - Saídas do processo de Realizar o Controle integrado de Mudanças:
a) Atualização do Andamento das solicitações de mudança;

b) Atualizações do plano de gerenciamento do projeto;
c) Atualizações dos documentos do projeto;
A composição das saídas b) e c) já foram estudadas nesta anterior e não

precisam novamente ser detalhadas.
Em relação a Atualização do Andamento das solicitações de mudança devemos

ter um sistema de controle das mudanças e o seu processamento deve ser
feito diretamente pelo gerente do projeto ou por um membro da equipe
especificamente designado para isto.
Aqui podemos ter uma reflexão:
Tem que ser o Gerente do Projeto?

Na maioria das situações ou naquelas em que o tipo de solicitação impacta o
resultado final do projeto, cabe ao gerente em seu papel integrador ter não só
pleno conhecimento do que está sendo solicitado em uma mudança, mas tem
acompanhamento próximo do andamento de sua solicitação. Da mesma
forma, escolher um determinado membro da equipe de forma especifica para
este processamento auxilia o papel de integrador do gerente de projetos.
2.4 - Detalhar o processo de encerrar o projeto ou fase.

Neste processo vamos finalizar todas as atividades e grupos de processo para
formalizar o encerramento do projeto. É um processo que somente ocorre uma
vez por projeto (ou por fase em projetos complexos) e que o gerente deve ter
atenção para revisar todas as informações prévias de encerramento,
assegurando que todo o trabalho está completa e que o mesmo alcançou os

objetivos. As informações aqui geradas servirão eventualmente em situações
futuras, como fonte de pesquisa ou investigação
2.5.1 – Entradas do processo de encerrar o projeto ou fase:

O PMBOK indica três entradas deste processo:

b) Entregas Aceitas;
c) Ativos de processos organizacionais
(PMBOK 5, 2012)
A composição das entradas a) e c) já foram estudadas ao longo desta aula e

da anterior e não precisam novamente ser detalhadas novamente.
Em relação às Entregas Aceitas, o PMBOK 5 preconiza que devem ser

consideradas as entregas que foram aceitas utilizando o processo “verificar o
escopo” que será estudado na disciplina de Gerenciamento do Escopo do
projeto.
2.5.2 – Ferramentas e Técnicas do processo de encerrar o projeto ou fase
A composição ferramental deste processo, Opinião especializada, é idêntica a

detalhada.
Uma das recomendações que podemos acrescentar com relação as técnicas e

ferramentas é que o gerente do projeto considere além da aplicação delas
pela equipe na geração de documentos relacionados ao projeto, seu uso na
forma individual com cada membro da equipe, antes dele ser desalocado do
projeto. Isto de forma sistemática e ao longo de todo ciclo de vida do projeto.

“O gestor do projeto deve fazer uma reunião individual com cada
membro da equipe. Estas reuniões permitem que cada participante
registre sua opinião individual, de forma aberta e sem o
constrangimento causado por uma reunião do grupo”
Adaptado de GIDO, 2010
2.5.3 - Saídas do processo de encerrar o projeto ou fase

a) Transição do produto, serviço ou resultado Final;
Esta saída, explicita o objeto singular que é o foco de realização do projeto, ou

no caso de encerramento de fase de projeto, o objeto intermediário.
b) Atualizações dos ativos de processos organizacionais;
O PMBOK 5 preconiza pelo menos 3 grupos de ativos que devem ter

resultantes desta saída:
a) Arquivos de Projeto:
b) Documentos de encerramento do projeto ou fase; e
c) Informação Histórica
O detalhamento de cada um destes grupos e dos documentos a eles

associados envolvem a verificação de que tudo ficou realmente documentado e
registrado, inclusive daquilo que não foi feito ou concluído dentro do ciclo de
vida do projeto.
Neste momento podemos nos perguntar que tipo de informações estes

registros devem conter. Também não devemos esperar até o final do projeto
para descobrir o que é importante guardar ou o que os stakeholders desejam
que se mantenha de informações para situações futuras.

Podemos considerar algumas informações que devem estar presentes:
a) Como se utilizaram de fato os processos de gerenciamento?

b) O plano e o cronograma refletiram a realidade? Se não, onde ocorreram
divergências?
c) Como foi a efetividade do processo de gerenciamento de mudanças?
d) Porque precisamos de ações corretivas? Elas resolveram a situação que
surgiu?
e) Como podemos evitar as variações de desempenho percebidas?
f) Os planos de respostas a riscos deram resultado?
g) Que tipo de risco não planejado se manifestou?
h) Quais foram os erros não esperados e os impactos que causaram?
i) Pontos de acertos e erros na integração de equipe. Quais foram?
Ajustes deram certo?
Adaptado de HELDMAN, 2005
Conclusão
Nesta aula concluímos o detalhamento e desdobramento da área de
conhecimento de Gerenciamento de integração e junto com o conteúdo
estudado nas demais aulas desta disciplina pudemos não só entender os
conceitos fundamentais de projetos, seu ciclo e processos, bem como
desdobrar o que o PMI preconiza de forma ampla como metodologia e
estudarmos uma de suas áreas de conhecimento.
Atividade proposta
com seus colegas no fórum de debates, as dificuldades para registrarmos
todas as informações no encerramento de um projeto. Compartilhe relatos,
fotos, vídeos ou links.

Aprenda Mais
Leia a tese Avaliação de maturidade relacionada a estudo de caso de
gerenciamento de projetos na área de mineração.
Publicação eletrônica com Dicas para o gerenciamento da Integração.
Leia o artigo relacionado a Percepção de valores no gerenciamento de

integração.
Leia o artigo Gestão integrada no gerenciamento de projetos

complexos.
Questão 1
Dentre as alternativas a seguir, indique aquela que representa a mais
preocupante para o patrocinador do projeto durante as atividades de
integração:
a) O custo da integração;
b) A quantidade de trabalho técnico a ser realizado em uma unidade
organizacional;
c) O número de departamentos da organização envolvidos;
d) O envolvimento do cliente durante a integração;
e) O tempo de encerramento do projeto após sua conclusão;
Questão 2
O plano de gerenciamento do projeto é utilizado para:
a) Aprimorar habilidades do gerenciamento em geral;

b) Facilitar a comunicação entre as partes interessadas;

c) Fornecer uma medida de progresso variável;
d) Desenvolver ações corretivas;
e) Finalizar as pendências do projeto ao seu final
Questão 3
Um comitê de controle de mudanças foi estabelecido em um determinado
projeto. Quando ele foi definido, ficaram estabelecidos procedimentos
específicos que irão governar sua operação. Os procedimentos requerem que
todas as mudanças aprovadas sejam refletidas no(a):
a) Estrutura Analítica do Projeto;

b) Plano de gerenciamento do projeto;
c) Plano de Garantia da Qualidade;
d) Linha de base de alteração do escopo;
e) Termo de abertura do projeto;

Questão 4
Para a Equipe do projeto, o documento mais importante para integrar as
atividades durante a execução do projeto é:
a) O Plano de gerenciamento do projeto;

b) A declaração de escopo do projeto;
c) A linha de base do escopo;
d) As curvas S
e) O termo de encerramento do projeto;
Referências
2005

2008 (ATUALIZAR PARA A 5ª Ed.)
GIDO, Jack. Gestão de Projetos, Ed. Cengage Learnng, São Paulo, 2010
KERZNER, Harold. O que os Executivos precisam saber sobre gerenciamento

de projetos, Ed. Bookman, Porto Alegre, 2011
DINSMORE, Paul C. Como se Tornar um Profissional em Gerenciamento de

Projetos, Ed. Qualitymark, Rio de Janeiro, 2009

Chaves de resposta
Aula 1
Atividade proposta
Em decorrência do tempo, os processos relacionados ao produto Biotônico
Fontoura sofreram diversas mudanças – seja pela incorporação tecnológica na
linha fabril, seja pela venda do projeto original a diversas empresas. Esses
processos estiveram associados a inúmeros outros projetos com características
próprias.
Em outras palavras, a singularidade do produto em si não foi modificada, mas

sim a particularidade dos processos relacionados a ele. Se estes se modificam
ao longo da existência de um objeto gerado por projetos, é possível que
surjam outros projetos – também singulares – referentes ao mesmo produto.
Questão 1 – C
Questão 2 – A
Questão 3 – A
Aula 2
Questão 1 – C
Questão 2 – D
Questão 3 – A

Aula 3
Questão 1 – C
Questão 2 – A
Questão 3 – B
Aula 4
Questão 1 – B
Questão 2 – A
Questão 3 – D
Questão 4 – E
Aula 5
Questão 1 – C
Questão 2 – B
Questão 3 – E
Aula 6
Questão 1 – D
Questão 2 – B
Questão 3 – A
Questão 4 – E

Aula 7
Questão 1 – E
Questão 2 – D
Questão 3 – A
Questão 4 – D
Aula 8
Questão 1 – A
Questão 2 – B
Questão 3 – B
Questão 4 – A
Conteudista
Antonio Luis Draque Penso
Mestre em Administração Pública pela Fundação Getulio
Vargas (FGV-RJ), Especialista em Engenharia Econômica e
Organização Industrial pela Universidade do Estado do Rio
de Janeiro (UERJ), Bacharel em Ciências Navais, com ênfase
em Administração de Sistemas, pela Escola Naval do Rio de
Janeiro e Graduado em Análise de Sistemas pela UERJ. Nos
últimos 30 anos, atuou profissionalmente como Chefe de
Planejamento e Controle da Indústria Naval do Rio de
Janeiro e como Superintendente Financeiro do Arsenal da
Marinha do Rio de Janeiro. Além disso, foi Diretor da área de
Logística do Centro de Distribuição Nacional de
Sobressalentes de Equipamentos Eletromecânicos e Vice-
diretor de órgão público federal na área de Educação

Corporativa. Entre as diversas atividades que exerceu, de
forma específica, na área de Projetos, possui experiência de
cerca de 10 anos com gerenciamento de projetos e
supervisão de gerentes de projetos na Indústria Naval.
Atualmente, é Coordenador Acadêmico e Nacional de cursos
de Graduação Tecnológica e de um MBA, na modalidade de
Educação a Distância (EAD), oferecidos pela Universidade
Estácio de Sá (UNESA), e Coordenador Acadêmico de dois
MBAs presenciais na unidade Centro I dessa instituição.
Atua, ainda, como docente de diversas disciplinas na área de
Gestão, nas modalidades EAD e presencial, e como
conteudista de algumas disciplinas online de Graduação e
Pós-Graduação ofertadas pela mesma universidade.

Apostila Gerenciamento de Projetos

Enviado por

Dados do documento

Direitos autorais

Formatos disponíveis

Compartilhar este documento

Compartilhar ou incorporar documento

Opções de compartilhamento

Você considera este documento útil?

Este conteúdo é inapropriado?

Direitos autorais:

Formatos disponíveis

Apostila Gerenciamento de Projetos

Enviado por

Direitos autorais:

Formatos disponíveis

Fundamentos do

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 1

AULA 2: CONCEITOS BÁSICOS 28

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 2

AULA 3: CICLO DE VIDA DO PROJETO 46

AULA 5: ÁREAS DO CONHECIMENTO 78

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 3

AULA 6: CERTIFICAÇÃO PMI 94

AULA 7: GERENCIAMENTO DE INTEGRAÇÃO - TAP 109

AULA 8: GERENCIAMENTO DE INTEGRAÇÃO - PROCESSOS 126

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 4

ANEXO 1 ERRO! INDICADOR NÃO DEFINIDO.

CHAVES DE RESPOSTA 146

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 5

Afinal, tais noções se modificam na medida em que as organizações são

Nesta disciplina, definiremos os fundamentos que sustentam a gerência de

Sendo assim, esta disciplina tem como objetivos:

 Definir os principais conceitos relacionados ao gerenciamento de

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 6

Trata-se de observar como o homem compreende a noção de projeto e como

Nesta aula, conheceremos a evolução histórica desse conceito, identificando

Quer ver alguns exemplos? Entre os primórdios, podemos citar as grandes

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 7

Assista ao vídeo A Necrópolis de Gizé.

Muitas dessas construções só foram concluídas após gerações até chegarem às

Mas será que é possível pensarmos nesses monumentos históricos sem os

Ao longo desta disciplina, entenderemos como esse conceito é aplicado na

Os exemplos mais clássicos dessa tentativa incluem projetos de Engenharia

Além disso, dados históricos registram que, desde a antiguidade, esses

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 8

A partir da criação das Escolas Politécnicas na França, surgiu o novo

Entenda, a seguir, como essa noção auxiliou o gerenciamento de projetos.

Sua principal característica filosófica foi a transição do teocentrismo – que considerava

É justamente o renascer da cultura clássica que justifica a nomenclatura desse período da

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 9

Mas, a partir da Revolução Industrial, fica claro que a metodologia para a

Em virtude do desenvolvimento da economia e do crescimento das demandas

Veja, a seguir, alguns exemplos criados dentro e fora do Brasil.

Entre os projetos que se destacaram pela aplicação de métodos de execução,

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 10

Nas indústrias, ainda existia o paradigma da elevação do esforço

Para saber mais sobre os grandes projetos construídos fora do

Metodologia aplicada a projetos – início do século XX

Entre aqueles que contribuíram para implementar os modelos atuais de

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 11

Com o objetivo de manter o bem-estar dos trabalhadores articulado ao aumento de sua

Esses gráficos de Gantt se converteram em eficientes ferramentas analíticas de

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 12

Toda essa apreensão se refletiu nos métodos de desenvolvimento de projetos,

No início do século XX, as metodologias aplicadas a projetos que associavam

Veja alguns exemplos extraídos de um relatório de acompanhamento de

Metodologia aplicada a projetos – séculos XX e XXI

O ponto de mudança foi a incorporação das seguintes metodologias:

Embora sua fonte de criação fosse distinta, ambas as técnicas matemáticas

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 13

Para saber mais sobre as metodologias de gerenciamento de

Surgimento da concepção de projeto

Embora não nomeados como tal, esses empreendimentos ou essas

A evolução dessa sistematização deu origem àqueles planos de trabalho

Você saberia definir esse conceito?

FUNDAMENTOS DO GERENCIAMENTO DE PROJETOS - APOSTILA 14

Essas estratégias, por sua vez, desdobram-se em iniciativas ou ações,

Para entender melhor essa concepção, veja, a seguir, algumas definições

Norma francesa X-50-105 (1991)