gestao_de_projetos

Prévia do material em texto

INTRODUÇÃO 
Por diversas décadas, observamos a necessidade de transformação 
por parte das organizações de qualquer negócio ou segmento em função 
dos efeitos provocados por fatores externos, hoje em dia, associado não 
somente à globalização mas também à era da informação. Passamos por 
invenções e descoberta disruptivas, como o surgimento da eletricidade 
(1753), lâmpada (1879), aviação (1906), penicilina (1928), e alguns 
movimentos importantes, como a revolução industrial (1760 a 1820 / 
1840) e a transformação digital do mundo contemporâneo, que gerou 
mudanças e impactos e, em um futuro bem próximo, irá conduzir as 
nações de todo o mundo a outros patamares tecnológicos. 
O que esses marcos têm em comum? Podemos citar algumas 
características: visão integrada, foco no resultado, inovação e 
transformação. Além disso, ambos são suportados por projetos. 
As organizações têm o desafio de, cada vez mais, implementar 
projetos para a transformação imposta pela tecnologia, globalização, 
necessidade de revisão do modelo de gestão organização e da forma de 
fazer negócios. Nesse contexto, o papel do profissional de projetos se 
torna ainda mais importante. É preciso assumir um protagonismo de 
liderança sem autoridade e conduzir um time com foco na entrega de 
resultados que irão suportar tal transformação. 
Sob essa ótica, analisaremos a importância e o valor da gestão de 
projetos para as organizações, além de estudarmos algumas práticas 
recomendadas para aplicação de forma que eleve as chances de sucesso dos 
seus projetos, ilustrando o desafio imposto aos profissionais da atualidade. 
Nesse sentido, esta disciplina oferece reflexões e possibilidades de aplicação 
de melhores práticas de gerenciamento de projetos recomendadas de para a 
maior parte do tempo, na maioria dos projetos e de qualquer natureza. Para 
tal, a disciplina tem como objetivo: 
� identificar os conceitos fundamentais sobre o valor do 
gerenciamento de projetos; 
� identificar os conceitos e as definições de gerenciamento de 
projetos; 
� relacionar melhores práticas referenciadas por 10 áreas de 
conhecimento do guia PMBOK® e 
� consolidar um plano de projeto. 
 
Seja bem-vindo ao mundo dos projetos! 
 
 
 
 
 
SUMÁRIO 
MÓDULO I – VALOR DE GERENCIAMENTO DE PROJETOS .................................................................. 7 
CONCEITOS E DEFINIÇÕES ................................................................................................................ 8 
O que é o PMI? ........................................................................................................................... 9 
O que é o guia PMBOK® ........................................................................................................... 9 
Estrutura do guia PMBOK® .............................................................................................. 10 
Estrutura do gerenciamento de projetos ............................................................................. 11 
Projeto .................................................................................................................................. 11 
Programa ............................................................................................................................. 13 
Portfólio ............................................................................................................................... 13 
Projeto versus operações ................................................................................................... 15 
Gerenciamento de projetos organizacional ................................................................... 17 
Ciclo de vida do produto versus ciclo de vida do projeto .............................................. 19 
Tipos de ciclo de vida de projeto ...................................................................................... 20 
Tailoring ..................................................................................................................................... 21 
Documentos de negócio ......................................................................................................... 21 
MÓDULO II – AMBIENTES DE OPERAÇÃO DOS PROJETOS ............................................................... 23 
INFLUÊNCIAS ORGANIZACIONAIS .................................................................................................. 23 
Sistemas organizacionais ........................................................................................................ 24 
Estruturas organizacionais ..................................................................................................... 24 
Escritório de gerenciamento de projetos ............................................................................. 27 
PAPEL DO GERENTE DE PROJETOS ................................................................................................ 28 
Responsabilidades do gerente de projetos .......................................................................... 29 
Habilidades comportamentais ............................................................................................... 30 
Partes interessadas ................................................................................................................. 31 
Gerenciamento de projetos ................................................................................................... 32 
MÓDULO III – ESTRUTURA DO GERENCIAMENTO DE PROJETOS .................................................... 33 
GRUPOS DE PROCESSOS ................................................................................................................. 33 
ÁREAS DE CONHECIMENTO ............................................................................................................ 34 
Gerenciamento da integração do projeto ............................................................................ 34 
Gerenciamento do escopo do projeto .................................................................................. 34 
Gerenciamento do cronograma do projeto ......................................................................... 34 
Gerenciamento dos custos do projeto ................................................................................. 34 
Gerenciamento da qualidade do projeto ............................................................................. 34 
Gerenciamento dos recursos do projeto ............................................................................. 35 
Gerenciamento das comunicações do projeto .................................................................... 35 
Gerenciamento dos riscos do projeto .................................................................................. 35 
Gerenciamento das aquisições do projeto .......................................................................... 35 
 
 
Gerenciamento das partes interessadas do projeto .......................................................... 35 
PROCESSOS DE GERENCIAMENTO DE PROJETOS ........................................................................ 36 
Processos – grupo de iniciação .............................................................................................. 37 
Processos – grupo de planejamento ..................................................................................... 38 
Processos – grupo de execução ............................................................................................. 39 
Processos – grupo de monitoramento e controle ............................................................... 40 
Processos – grupo de encerramento .................................................................................... 41 
VISÃO CONSOLIDADA ...................................................................................................................... 43 
MÓDULO IV – PRÁTICAS DE PROJETOS E OUTROS PADRÕES ..........................................................45 
PRÁTICAS DE GERENCIAMENTO DE PROJETOS ............................................................................ 45 
Plano de projeto ....................................................................................................................... 45 
Declaração de escopo ............................................................................................................. 46 
Estrutura Analítica do Projeto (EAP) ...................................................................................... 47 
Cronograma de projeto .......................................................................................................... 51 
Determinação do sequenciamento das atividades ............................................................. 53 
Orçamento ................................................................................................................................ 53 
Planejamento de custos .......................................................................................................... 55 
Ferramentas da qualidade ..................................................................................................... 55 
Matriz da comunicação e análise de partes interessadas ................................................. 57 
Matriz de recursos ................................................................................................................... 59 
Análise de riscos ....................................................................................................................... 60 
Respostas aos riscos identificados ........................................................................................ 61 
Processo de contratação ........................................................................................................ 63 
Administração de contrato ..................................................................................................... 64 
Planejamento ágil de projetos ............................................................................................... 64 
Execução, controle e encerramento ..................................................................................... 65 
OUTROS PADRÕES ........................................................................................................................... 65 
ISO 21.500 ................................................................................................................................. 65 
PRINCE2®.................................................................................................................................. 66 
IPMA ........................................................................................................................................... 68 
Certificação .......................................................................................................................... 69 
Scrum Alliance® ....................................................................................................................... 69 
Scrum.org .................................................................................................................................. 70 
Aplicação dos dias de hoje ..................................................................................................... 72 
CONSIDERAÇÕES FINAIS ..................................................................................................................... 75 
REFERÊNCIAS BIBLIOGRÁFICAS .......................................................................................................... 76 
SÍTIOS ELETRÔNICOS ....................................................................................................................... 77 
PROFESSOR-AUTOR ............................................................................................................................. 78 
 
 
Neste módulo, iremos refletir sobre o valor do gerenciamento de projetos para as 
organizações, e destacaremos a apresentação de conceitos, definições e terminologia de gestão de 
projetos na visão do Guia PMBOK®. 
O ponto de partida para o profissional de projetos é conhecer o básico do conhecimento 
(melhores práticas), referência para a disciplina de fundamentos de projetos. A partir desse ponto, 
será possível compreender outros padrões, métodos, abordagens, ferramentas e técnicas. 
Um dos fatores que mais influenciam de forma negativa, segundo estudos do PMI®, é a falta 
de conhecimento em gerenciamento de projetos, ou seja, existem muitas pessoas que gerenciam 
projetos sem ter conhecimento mínimo para isso – o que compromete o resultado final desejado 
pela organização executora. 
 
 
MÓDULO I – VALOR DE GERENCIAMENTO 
DE PROJETOS 
 
8 
 
Conceitos e definições 
Projeto não é algo novo e tem sido usado por centenas de anos. Vejamos alguns exemplos: 
 
Figura 1 – Exemplos ilustrativos de projetos 
 
 
 
 9 
 
O que é o PMI? 
Fundado em 1969 (USA), o Project Management Institue – PMI® – agrega valor a mais de 
2,9 milhões de profissionais que trabalham em quase todos os países do mundo por meio de 
advocacy, colaboração, educação e pesquisa globais (acesse PMI.org). Sobre o Instituto (em 2018), 
podemos destacar: 
� Possui representação em mais de 120 países/282 capítulos, dos quais 15 capítulos estão no 
Brasil). 
� Programa de certificação internacional1 – 8 credenciais (as maiores são PMP® e 
CAPM®): 
� Certified Associate in Project Management (CAPM)®; 
� Project Management Professional (PMP)®; 
� Program Management Professional (PgMP)®; 
� Portfolio Management Professional (PfMP)®; 
� PMI Professional in Business Analysis (PMI-PBA)®; 
� PMI Risk Management Professional (PMI-RMP)®; 
� PMI Scheduling Professional (PMI-SP)® e 
� PMI Agile Certified Practitioner (PMI-ACP)®. 
� É responsável pelo Guia PMBOK® (base e referência de todo o conteúdo de nossa 
disciplina, e que estaremos estudando mais a frente) e outros padrões. 
� Mais de 1.000.000 de profissionais, estudantes e pesquisadores filiados ou cerificados em 
todo o mundo. 
� Possui uma modelo de filiação profissional e de estudantes com uma taxa a ser paga 
anualmente. 
� Oferece oportunidade de trabalho voluntário em todo o mundo, inclusive no Brasil, local 
e internacional (saiba mais em VRMS.pmi.org). 
 
O que é o guia PMBOK® 
O Guia de conhecimento de gerenciamento de projetos – Guia PMBOK® (Project 
Management Body of Knowledge) – é um conjunto de melhores práticas aplicadas na maior parte do 
tempo na maioria dos projetos de qualquer natureza. O PMBOK® é atualizado de 04 em 04 anos 
por voluntários e praticantes de gerenciamento de projetos de todo o mundo. O Guia se encontra 
na 6ª edição, lançada em setembro de 2017. 
 
1 Cada certificação requer uma série de requisitos determinadas pelo PMI® para tornar a aspirante habilitado para realizar 
o exame de certificação profissional reconhecido internacionalmente e específico para cada tipo de credencial. Esse 
processo é chamado de elegibilidade e tem um custo associado. Além disso, existe o processo de renovação de certificação 
em acordo com o período determinado pelo processo CCRS – Continuos Certification RS – do instituto. Para saber mais 
sobre o programa de certificação, acesse o site oficial do PMI®. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
10 
 
É importante destacar que o PMBOK® (1) é um guia e (2) não é uma metodologia de 
gerenciamento de projetos. Nesse sentido, quando falamos de melhor prática, isso significa: 
� reconhecimento geral – o conhecimento e as práticas descritas são aplicáveis à maioria dos 
projetos, na maior parte das vezes, e existe um consenso em relação ao seu valor e à sua 
utilidade, e 
� boa prática – existe um acordo geral de que a aplicação de conhecimento, habilidades, 
ferramentas e técnicas podem aumentar as chances de sucesso de muitos projetos em 
entregaro valor de negócio e os resultados esperados. 
 
O PMBOK® é um padrão de gerenciamento de projetos suportado pela ANSI American 
National Standards Institute (Instituto Nacional Americano de Padrões) nos EUA. 
 
Estrutura do guia PMBOK® 
O Guia PMBOK® é dividido em três partes: 
 
Parte 1 – Guia de conhecimento em gerenciamento de projetos (guia PMBOK®) 
1. Introdução 
2. Ambiente em que os projetos operam 
3. Papel do gerente de projetos 
Áreas de conhecimento (capítulos 04 ao 14) 
 
Parte 2 – Padrão do gerenciamento de projetos 
1. Introdução 
2. Grupo de processos de iniciação 
3. Grupo de processos de planejamento 
4. Grupo de processos de execução 
5. Grupo de processos de monitoramento e controle 
6. Grupo de processos de encerramento 
 
Parte 3 – Apêndices, glossário e índice remissivo 
Apêndice X1 – Mudanças da 6ª edição 
Apêndice X 2 – Colaboradores e revisores do guia PMBOK® – sexta edição 
Apêndice X 3 – Ambiente de projeto ágil, iterativo, adaptativo e híbrido 
Apêndice X 4 – Resumo dos conceitos essenciais para áreas de conhecimento 
Apêndice X 5 – Resumo das considerações sobre adaptação para áreas de conhecimento 
Apêndice X6 – Ferramentas e técnicas 
Glossário 
 
 11 
 
Em nossa disciplina, estaremos abordando o conteúdo por meio de uma visão didática e 
simplificada, com objetivo da compreensão da estrutura do gerenciamento de projetos, do ambiente 
em que os projetos operam e das melhores práticas de gerenciamento de projetos. 
 
Estrutura do gerenciamento de projetos 
Nos dias atuais, em estudo realizado sobre Projetos pelo Project Management Institute – 
PMI® –, a pesquisa The Pulse of the Profession® sugere uma mudança positiva na forma como as 
organizações estão gerenciando projetos e programas. Pela primeira vez em cinco anos, mais 
projetos estão reunindo objetivos originais e intenção de negócios, sendo concluídos dentro do 
orçamento. Também houve um declínio significativo em dólares perdidos: as organizações estão 
desperdiçando uma média de US $ 97 milhões para cada US $ 1 bilhão investido, devido ao baixo 
desempenho do projeto – isso representa um declínio de 20% um ano atrás. 
As empresas empregam, cada vez mais, o conceito de Gerenciamento de Projetos com o 
objetivo de organizar e estruturar o cumprimento de demandas para o negócio, seja: 
� inovação tecnológica; 
� desenvolvimento de um novo produto ou serviço; 
� responsabilidade social ou sustentabilidade; 
� construção de um prédio ou veículo; 
� aquisição de carteira, entre outras. 
 
Projeto 
Qual seria o conceito de projetos nessa história? “Um projeto é um esforço temporário 
empreendido para criar um produto, serviço ou resultado exclusivo.” (PMBOK, 2017). 
Temporário significa que todos os projetos possuem um início e um final definidos. Nesse 
sentido, um projeto constrói entregas exclusivas, mas uma característica importante é que todos os 
projetos serão únicos. Desse modo, podemos construir dois prédios iguais com mesmo escopo, mas 
cada terá as suas respectivas caraterísticas. Vejamos: 
� possui início e fim; 
� é único; 
� necessita de práticas adaptadas a partir do guia pmbok®; 
� é elaborado progressivamente e 
� é feito por pessoas. 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
12 
 
Todo projeto é elaborado progressivamente. Á medida que o projeto avança, adquirimos mais 
conhecimento sobre ele. Por exemplo, o escopo do projeto pode ser definido, de maneira geral, no 
início do projeto e é detalhado conforme aumentamos o entendimento sobre ele, ou seja, é uma 
característica que integra os conceitos de temporário e exclusivo. 
Os resultados de um projeto: 
� alteram as naturezas das operações; 
� impulsionam mudanças; 
� geram benefícios e 
� permitem a criação de valor de negócio. 
 
Há também o conceito de subprojetos, considerados uma divisão de projetos visando facilitar 
o gerenciamento e o controle. Esse conceito é normalmente usado quando há serviços contratados 
por uma empresa externa ou outra unidade funcional na organização. 
Subprojetos: 
� divisão de projetos visando facilitar o gerenciamento e 
� normalmente, contratados por uma empresa externa ou outra unidade funcional na 
organização. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 13 
 
Programa 
Um programa é um conjunto de múltiplos projetos coordenados que possuem ou não uma 
relação entre si. Os projetos constituintes de um programa são necessariamente relacionados e, dessa 
forma, conseguem obter sinergia. Como são geridos de forma coordenada, os projetos que 
compõem o programa alcançam mais facilmente os seus objetivos. Atendendo aos objetivos 
individuais, eles conseguirão atender, eventualmente, aos objetivos do programa maior, que são os 
próprios objetivos e benefícios estratégicos da organização. 
 
Figura 2 – Gestão de programas 
 
 
Portfólio 
Podemos definir portfólio como: 
� coleção de projetos ou programas e outros trabalhos que sejam agrupados de forma a facilitar 
o gerenciamento efetivo daquele trabalho para atender objetivos empresariais estratégicos. 
 
Para exemplificar a gestão de portfólio, vamos definir um cenário clássico de uma grande 
organização que deseja determinar o orçamento para o próximo ano. A diretoria financeira ou a 
área responsável solicita a todas as áreas que apresentem as suas necessidades para o próximo ciclo 
de execução. A lista com as necessidades de todas as áreas da empresa que são candidatas a receberem 
(ou não) o recurso necessário para a sua execução. O que a gestão de portfólio faz? 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
14 
 
Com os recursos disponíveis aprovados para o próximo ciclo de execução pela alta 
administração e uma avaliação com base em critérios alinhados com a estratégica da organização 
(com pesos definidos), é definida uma lista priorizada por grau de relevância e impacto no negócio. 
A gestão de portfólio responde a seguinte pergunta: “Se pudéssemos fazer somente um projeto por 
vez, qual seria a ordem?”. 
Ao longo do clico de execução – no nosso exemplo, de um ano – a lista precisa ser revisada e 
atualizada por conta das tendências de mercado, do grau de viabilidade das iniciativas e da 
velocidade (constante da mudança). 
 
Figura 3 – Gestão de portfólio 
 
Fonte: shutterstock. 
 
 
Felipe Gorgen dos Reis
 
 15 
 
Para refletirmos sobre a integração de projetos, programas e portfólio, vamos analisar a figura 
a seguir do Guia PMBOK®: 
 
Figura 4 – PMBOK® – Interação entre projetos, programas e portfólio 
 
 
Sintetizando, o portfólio responde à pergunta “Se eu pudesse fazer sobre um projeto por 
você qual seria a ordem?”. Tal ordem seria definida com base em critério e objetivos estratégicos de 
maior impacto para o negócio, e considera os recursos disponíveis. 
Uma das principais diferenças entre programas e projetos e, que pode causa confusão em 
como e quando aplicar um ou outro é bem simples. Vejamos: 
� Programa - libera benefícios durante a sua execução. A visão de programas, ou seja, gestão 
de múltiplos projetos é mais ampla e extensa do que a visão do projeto. 
� Projeto – libera benefícios somente após o seu término. 
 
Projeto versus operações 
Podemos dividir o trabalho das organizações em dois tipos: projetos e operações. A principal 
diferença entre elas é que projetos são temporários e únicos, enquanto operações são contínua e 
repetitivas. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
16 
 
Por exemplo: 
1. as atividades de desenvolvimento ou construção de um sistema são consideradas projeto e 
2. a manutenção pós-implantaçãodo sistema é considerada operação contínua. 
 
Atenção! A visão de gestão das operações de uma organização não é contemplada pelo Guia 
PMBOK®. É importante apenas compreendermos a diferença entre atividades de um projeto (algo 
temporário) e das operações (contínuas e repetitivas). 
Quando falamos da criação de cultura do gerenciamento de projetos de uma organização, 
existem diversos fatores que influenciam a aplicação dessas práticas, além do fator humano 
(estudaremos isso mais a frente). No entanto, as operações têm alta influência considerando (mas 
não se limitando): 
� atenção da organização; 
� foco do executivo; 
� prioridade no momento de crise e 
� impacto na cultura de projetos; 
 
Por que isso acontece? É bem simples: porque o dinheiro vem de lá. Lembre-se disso! 
É importante compreendermos que os profissionais de projetos precisam ter habilidades para lidar 
com essas características no momento de aplicação de práticas de gerenciamento de projetos. 
 
Figura 5 – Portfólio, programas, projetos e operações 
 
Fonte: PMBOK® Figura 1-3. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 17 
 
Gerenciamento de projetos organizacional 
Podemos considerar ciclos desde a tomada de decisão até a implementação dos projetos 
estratégicos. Observe que, quanto maior a empresa, maior a complexidade e os atores envolvidos. 
Na figura a seguir, o PMBOK® apresenta a estrutura do gerenciamento de projetos 
organizacional: 
 
Figura 6 – Gerenciamento de projetos organizacionais 
 
Fonte: PMBOK® Figura 1-4. 
 
Usando a visão de uma grande empresa, por exemplo, podemos considerar um grupo de 
partes interessadas de alto poder versus influência que tomam da decisão do caminho a ser seguido 
pela organização no que diz respeito à estratégia. Essa estrutura necessita ser desdobrada até o nível 
de execução, ou seja, é um desafio imposto às organizações para manter a real essência da sua 
estratégica na execução e com práticas que visam priorizar (portfólio), organizar múltiplas demandas 
(programa), executar (projetos) e atingir o sucesso pleno da transformação. 
 
Felipe Gorgen dos Reis
 
18 
 
Observe a figura a seguir, que ilustra o fluxo do processo decisões uma organização. Nesse 
caso, temos uma grande empresa (lembrando que, quanto menor for a empresa, a quantidade de 
atores envolvidos do processo também se reduz). Por exemplo: em uma startup, os sócios poderiam 
fazer o papel de decidir e executar projetos, devido à limitação de recursos. 
 
Figura 7 – Processo de decisão organizacional 
 
Fonte: autor. 
 
O Guia PMBOK® determina cinco conceitos-chave importantes para compreender as 
práticas (a serem estudadas mais à frente): 
 
Tabela 1 – Conceitos-chave do PMBOK® 
ciclo de vida do projeto Série de etapas que um projeto passa, do início até o término. 
fases de um projeto Série de fases que um projeto passa, do início até o término. 
revisão de fase 
Análise no final de uma fase em que uma decisão é tomada em 
relação a passar para a fase seguinte ou iniciar uma nova fase, 
continuar com modificações ou finalizar um programa do projeto. 
processos de 
gerenciamento de 
projetos 
Série de atividades sistemáticas direcionadas para alcançar um 
resultado final, de forma que se aja em relação a uma ou mais 
entradas a fim de criar uma ou mais saídas. 
 
 19 
 
grupos de processos de 
gerenciamento de 
projetos 
Área de conhecimento de gerenciamento de projetos definida pelos 
seus requisitos e descrita em termos dos processos que a 
compõem: práticas, entradas, saídas, ferramentas e técnicas. 
Atenção! As fases de um projeto estão associadas diretamente à natureza do produto final 
previsto pelo projeto, e não são os cinco grupos de processo (iniciação, planejamento, execução, 
monitoramento & controle e encerramento). 
 
Exemplo 1: em um projeto de desenvolvimento de um sistema de informação, poderíamos 
ter as seguintes fases: 
� requisitos; 
� desenvolvimento; 
� homologação e 
� implantação. 
 
Exemplo 2: em um projeto de construção de um prédio, poderíamos ter as seguintes fases: 
� desenho básico; 
� desenho executivo; 
� obra e 
� entrega das chaves. 
 
Ciclo de vida do produto versus ciclo de vida do projeto 
Conforme estudamos anteriormente, o ciclo de vida do projeto constitui as etapas que o 
processo passa desde a sua concepção até o seu encerramento. Quando falamos de ciclo de vida do 
produto, podemos considerar desde o dia em que nasce a ideia até o dia que o produto é 
descontinuado do mercado para sempre. Observe a imagem a seguir: 
 
Figura 8 – Ciclo de vida produto 
 
Fonte: shutterstock. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
20 
 
Ao longo do ciclo de vida de um produto, existirão diversos (N) projetos que irão suportar as 
principais etapas de período – da ideia à descontinuidade. 
Para cada projeto, haverá as respectivas fases e entrega. Observa a figura 9 a seguir: 
 
Figura 9 – Ciclo de vida projeto 
 
Fonte: shutterstock. 
 
Tipos de ciclo de vida de projeto 
As melhores práticas de gerenciamento de projetos devem ser adaptadas em acordo com 
a cultura organizacional, ou seja, cada organização determinará a forma como irá gerenciar os 
seus projetos. No entanto, o PMBOK, em sua 6ª edição (2017), afirma que há dois tipos de ciclo 
de vida de projeto: o preditivo e o adaptativo. O primeiro é também chamado de ciclo de vida 
clássico, pois os esforços seguem uma ordem pré-definida até a conclusão do projeto. O ciclo de 
vida adaptativo, de forma diversa, é mais desenvolvido à medida que se desenrola o dia a dia do 
projeto, ou seja, as iterações sucessivas é que dão o ritmo do projeto e das suas entregas. 
Dentro do ciclo de vida de cada projeto, há geralmente uma ou mais fases associadas com o 
desenvolvimento do produto, serviço ou resultado planejado pelo projeto. Elas são chamadas de 
ciclo de vida de desenvolvimento. Os ciclos de vida de desenvolvimento podem ser preditivos, 
iterativos, incrementais, adaptativos ou um modelo híbrido. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 21 
 
Tailoring 
Normalmente, os profissionais de projetos aplicam metodologias de gerenciamento de 
projetos nas organizações. De acordo com o PMBOK®, uma metodologia é um sistema de práticas, 
técnicas, procedimentos e regras usadas por aqueles que trabalham em uma disciplina. Reiterando, 
o guia PMBOK® não é uma metodologia. Nesse sentido, o guia PMBOK® determina o que fazer 
e a metodologia determina como fazer. 
As metodologias de gerenciamento de projetos podem ser desenvolvidas por especialistas de 
gerenciamento de projetos da organização, ou adquiridas de fornecedores, associações profissionais 
ou governamentais. 
A adaptação das melhores práticas é necessária porque cada projeto é único. Não é uma 
verdade que todos os processos recomendados pela guia PMBOK® são necessários para cada projeto. 
Ao adaptar as práticas, o profissional de projetos deve considerar diversos fatores que irão influenciar 
no modo como a prática será aplicada dentro de uma organização. 
 
Documentos de negócio 
O gerente de projetos deve assegurar que o gerenciamento de projetos esteja alinhando com 
a estratégia da organização. Existem documentos recomendados para essa ação. Vejamos: 
� Business case – documento de viabilidade técnica e econômica que visa definir e sustentar 
benefícios, avaliar a contribuição do resultado final para o negócio e suportar a tomada de 
decisão ao longo da execução do projeto. 
 
Plano de gerenciamento de benefícios – plano que determina como medir os benefícios, ou 
seja, avaliar o pós-projeto e mediro resultado. 
 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
22 
 
 
 
 
 
Neste módulo, faremos uma reflexão sobre o ambiente no qual os projetos estão inseridos. 
Devemos considerar a cultura, os fatores ambientais e ativos que influenciam diretamente as 
organizações na aplicação de melhores práticas de gestão de projetos. 
Conhecer o ambiente que um projeto está inserido torna-se crítico para a aplicação 
(adaptação) das práticas de gerenciamento de projetos, uma vez que elementos que fazem parte de 
um sistema organizacional – algo muito maior do que o projeto – influenciam, diretamente, o seu 
desempenho. É importante compreender os tipos de estrutura, as suas características e limitações 
para determinação de como serão usadas e aplicadas as práticas de gerenciamento de projetos que 
melhor se ajustam, considerando a necessidade e a cultura organizacional. 
 
Influências organizacionais 
Podemos considerar duas importantes categorias de influência, que são: 
1. Ativos de processos organizacionais (APOs) – são planos, processos, políticas, 
procedimentos e bases de conhecimento específicos da organização e por ela usados. São 
internos à organização. 
2. Fatores ambientais da empresa (FAES) – referem-se às condições fora do controle da 
equipe que influenciam, restringem ou direcionam o projeto, ou seja, originam-se do 
ambiente externo do projeto. Nesse contexto, podemos considerar: 
� cultura, estrutura e governança organizacional; 
� distribuição geográfica de instalações e recursos; 
� normas governamentais ou do setor; 
 
MÓDULO II – AMBIENTES DE OPERAÇÃO 
DOS PROJETOS 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
24 
 
� infraestrutura (por exemplo, equipamentos e instalações): 
� administração de pessoal; 
� sistema de autorização da empresa; 
� condições de mercado e 
� canais de comunicação. 
 
Sistemas organizacionais 
Projetos operam dentro das restrições impostas pela organização por meio da sua estrutura e 
governança. Tal estrutura irá influenciar diretamente em como uma prática de gerenciamento de 
projetos deve ser aplicada, considerando a FAEs e após. 
 
Estruturas organizacionais 
Inicialmente, a visão considera três tipos de estruturas organizacionais – funcional, matricial 
e projetizada. Para estudarmos os conceitos de cada estrutura, vamos considerar duas características 
que um projeto possui em cada uma destas, a saber: grau de autonomia do gerente de projetos e 
membros de equipe do projeto. 
 
Tabela 2 – Tipos de estrutura de projetos (visão inicial) 
característica ou 
tipo de estrutura 
funcional matricial projetizada 
autonomia do 
gerente de projetos 
baixa ou quase 
nenhuma 
baixa a moderada alta ou quase total 
membro de equipe Após o término do 
projeto, retorna para a 
sua atividade funcional 
(por exemplo, analista 
de sistemas, 
engenheiro, advogado, 
entre outros). 
Tempo divido em 
atividades de projeto 
ou de operações. 
Recurso dedicado ao 
projeto. Após o seu 
término, não tem “um 
lar” garantido, ficando 
na dependência de 
outros novos projetos. 
observação Estrutura clássica 
orientada a hierarquia: 
presidente, vice-
presidente, diretores, 
gerentes, 
coordenadores, 
analistas e técnicos. 
Estrutura clássica, 
mas com atividades 
de gerenciamento de 
projetos permeando 
as áreas funcionais, 
com profissionais 
desempenhando a 
função de gerente de 
projetos. 
Estrutura orientada a 
projetos. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 25 
 
Com o passar do tempo, o avanço e o aprimoramento de práticas, ferramentas e técnicas, 
observou-se novos tipos de estrutura. A evolução da visão inicial passa para os seguintes tipos 
de estrutura: 
� orgânico ou simples; 
� funcional (centralizado); 
� multidividsional; 
� matriz (forte); 
� matriz (fraca); 
� matriz (equilibrada); 
� orientado a projetos; 
� virtual; 
� híbrido e 
� EGP. 
 
Para analisar melhor cada uma das estruturas, observe a imagem a seguir, com a respectiva 
características e configuração para o gerenciamento de projetos. É importante ressaltar que qualquer 
empresa tem projetos acontecendo em uma ou diversos tipos de estrutura organizacional. Tudo está 
relacionado em tamanho, porte, complexidade e maturidade da organização em gerenciamento de 
projetos. 
 
 
 
26 
 
Tabela 3 - Influências das estruturas organizacionais nos projetos 
 
 
 
 
 
 
 
 27 
 
 
Fonte: PMBOK® Tabela 2-1. 
 
Escritório de gerenciamento de projetos 
A sigla PMO significa Project Management Office (PMO) – em língua portuguesa, Escritório 
de Gerenciamento de projetos (EGP). 
Podemos considerar que o PMO é uma célula ou núcleo com um ou N profissionais, cujo 
principal objetivo é apoiar área, setor, departamento ou organização na gestão de projetos, 
programas e portfólio por meio de práticas consolidadas no mercado. Desse modo: 
� Os gerentes de projetos não devem, OBRIGATORIAMENTE, ficar subordinados ao 
PMO. 
� Os gerentes de projetos não devem, OBRIGATORIAMENTE, ser especialistas técnicos. 
� O PMO não CONTROLA e AVALIA pessoas, e sim MONITORA e AVALIA os 
processos de gerenciamento de projetos para melhoria contínua. 
� O PMO não deve, OBRIGATORIAMENTE, gerenciar projetos operacionais versus 
estratégicos ou simples versus complexos. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
28 
 
Figura 10 – Funções previstas para um PMO 
 
Fonte: (HILL, 2014). 
 
Papel do gerente de projetos 
Atualmente, o papel e a importância do gerente de projetos são reconhecidos em todo o lugar, 
segundo pesquisa do PMI® e outras associações. É importante ressaltar que cada organização define, 
em acordo com a sua cultura e maturidade, como será a formalização (ou não) do gerente de 
projetos. Esse papel pode ser uma função comprovada em carteira (em acordo com a CLT, por 
exemplo) ou uma função acumulada – por exemplo, um engenheiro, analista de sistemas ou 
advogado que assume o papel de gerente de projetos. A nomenclatura também varia. 
Vejamos a alguns exemplos de tipos de funções e nomenclaturas que definem o profissional 
responsável pelo gerenciamento de projetos: 
� gerente de projetos; 
� coordenador de projetos; 
� líder de projetos; 
� diretor de projetos; 
� analista de projetos; 
� coordenador técnico de projetos, etc. 
 
O papel do gerente de projetos é diferente de um gerente funcional ou de um gerente de 
operações. 
Atenção! O profissional especialista em gerenciamento de projetos está apto a gerenciar 
qualquer tipo de projeto, em qualquer área, segmento, porte ou complexidade. O fator experiência 
na função (gerente de projetos) impacta, diretamente, o desempenho de tal profissional. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 29 
 
Uma característica importante a se avaliar ao definir a contratação ou a promoção de um 
profissional para desempenhar o papel do gerente de projetos é “O profissional deve ser generalista 
ou especialista?” 
Generalista – profissional de projetos que irá gerenciar projetos cujo o produto final do 
mesmo seja de uma área diferente de sua formação. Exemplo: Um engenheiro gerenciamento 
projetos de Tecnologia da Informação 
Especialista– profissional de projetos que irá gerenciar projetos cujo o produto final do mesmo, 
seja da área de sua formação. Exemplo: Um engenheiro gerenciamento projetos de OBRA. 
Vamos avaliar quais são as vantagens e desvantagens de cada um. Vejamos a tabela a seguir: 
 
Tabela 4 – Profissional de projetos: especialista versus generalista 
perfil características habilidades importantes 
generalista 
não influenciado pelos 
“vícios da experiência” 
� capacidade de delegar; 
� usar opinião especializada e 
� desenvolver técnica de validação de 
entrega por evidência. 
especialista 
influenciado pelos “vícios 
da experiência 
� apoio a tomada de decisão técnica e 
� apoio a validação do produto do projeto. 
 
Responsabilidades do gerente de projetos 
Podemos considerar três elementos essências para o profissional que gerencia projetos: 
� Conhecimento – refere-se ao que o gerente de projetos sabe sobre o gerenciamento de 
projetos, ou seja, compreender o PMBOK®, metodologias, e ferramentas e técnicas de 
gerenciamento de projetos. 
� Desempenho – refere-se à capacidade de aplicar conhecimento em gerenciamento de 
projetos e está relacionado à experiência em gerenciamento de projetos. 
� Pessoal – refere-se ao comportamento do gerente de projetos na execução do projeto ou 
atividade relacionada. Desenvolvimento de habilidades comportamentais (soft skills). 
 
É recomendado, pelo guia PMBOK® e pelo processo de (re)certificação profissional do PMI®, 
o desenvolvimento em três tópicos: 
� gerenciamento técnico de projetos (práticas, ferramentas e técnicas); 
� liderança (comportamental) e 
� gerenciamento estratégico e de negócios (visão do negócio). 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
30 
 
O desafio do profissional de projetos é integrar, ou seja, a capacidade de entender o que 
realmente deve ser feito, organizar a visão, colocar todos os envolvidos “na mesma página”, 
desenvolver pessoas e seguir a estrutura prevista para as melhores práticas de gerenciamento de 
projetos. De fato, é um profissional integrador. 
 
Habilidades comportamentais 
A seguir, observe algumas habilidades comportamentais importantes para o desempenho do 
profissional de projetos: 
� liderança; 
� construção de equipes; 
� motivação; 
� comunicação; 
� influência; 
� tomada de decisões; 
� consciência política e cultural; 
� negociação; 
� ganho de confiança; 
� gerenciamento de conflitos; 
� coaching, etc. 
 
É importante compreender que um profissional, como qualquer pessoa, possui pontos fortes 
e pontos de melhoria que requerem desenvolvimento. A capacidade de delegar e usar o potencial 
de membros de equipe se torna um diferencial para o sucesso do projeto. 
 
 
 31 
 
Observe a figura do PMBOK® com as características de gerenciamento versus liderança: 
 
Figura 11 – Comparação entre gerenciamento e liderança da equipe 
gerenciamento liderança 
direta usando poder posicional 
guiar, influenciar e colaborar usando poder 
relacional 
manter desenvolver 
administrar inovar 
foco em sistemas e estrutura foco em relacionamentos com pessoas 
apoiar-se em controle inspirar confiança 
foco em metas de curto prazo foco em visão de longo alcance 
perguntar como e quando perguntar o que e por quê 
foco nos resultados foco no horizonte 
aceita o status quo questiona o status quo 
age corretamente faz o que é necessário fazer 
foco em questões operacionais e solução de 
problemas 
foco em visão, alinhamento, motivação e 
inspiração 
Fonte: PMBOK® Tabela 3-1. 
 
Partes interessadas 
São pessoas e organizações ativamente envolvidas no projeto ou cujos interesses podem ser 
afetados como resultado da execução ou do término do projeto. 
As partes interessadas podem ter uma influência positiva ou negativa em um projeto. Enquanto 
os interessados que exercem influência positiva veem um resultado bem-sucedido dos projetos, os que 
exercem influência negativa consideram que o projeto produzirá resultados negativos. 
As principais partes interessadas em todos os projetos incluem (mas não se limitam a): 
� gerente de projetos; 
� cliente ou usuário; 
� organização executora; 
� membros da equipe do projeto; 
� equipe de gerenciamento de projetos; 
� patrocinador e 
� PMO. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
32 
 
Gerenciamento de projetos 
Quando falamos da definição do que é o gerenciamento de projetos, consideramos que é a 
aplicação de conhecimentos, habilidades, ferramentas e técnicas às atividades do projeto de forma a 
garantir que os seus objetivos sejam atingidos. O gerente de projetos é o responsável pelo sucesso ou 
fracasso do projeto. Além disso, existe uma responsabilidade do time do projeto pelo seu desempenho. 
Entre algumas tarefas do gerente de projetos, podemos citar: 
� identificar necessidades; 
� estabelecer objetivos claros e alcançáveis; 
� aplicar as práticas de gerenciamento de projetos; 
� comunicar de maneira objetivo com as principais partes interessadas; 
� desenvolver o time e 
� integrar. 
 
O gerente de projetos contemporâneo possui desafios relacionados a: 
� aplicabilidade e adaptação das melhores práticas de forma simples; 
� habilidades comportamentais para lidar com pessoas de forma clara e efetiva; 
� conhecimento de tecnologia e 
� visão e conhecimento do negócio. 
 
A integração, ou seja, estabelecer uma visão integrada e alinhada entre todos os envolvidos se 
torna um dos maiores desafios, ou seja, é preciso colocar todos os envolvidos, seja do nível técnico 
ou do nível executivo, “na mesma página”. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 
 
Neste módulo, apresentaremos a estrutura de gerenciamento de projetos na visão do Guia 
PMBOK® do Project Management Institute – PMI®. 
O guia PMBOK® é o ponto de partida de para aplicação prática do gerenciamento de 
projetos. É importante conhecermos sua estrutura, baseada em melhores práticas, para sermos 
capazes de adaptar na prática, ou seja, criar métodos, sistemáticas ou mesmo uma solução de gestão 
de projetos para uma organização, considerando todas as características estudadas no módulo 
anterior. É importante ressaltar que a sequência das práticas que serão apresentadas neste módulo 
não representa um passo a passo (método) a ser seguido íntegra, e sim um conjunto de processos, 
ferramentas e técnicas que devem ser avaliados para adaptação e aplicação no dia a dia. 
 
Grupos de processos 
Na visão do Guia PMBOK®, temos a seguinte estrutura: 
� 05 grupos de processos; 
� 10 áreas de conhecimento e 
� 49 processos de gerenciamento de projetos. 
 
Aqui, iremos começar a presentando os grupos de processo. O PMBOK® determina cinco 
(05) grupos de processos: iniciação, planejamento, execução, monitoramento e controle, e 
encerramento. Vejamos cada um deles: 
1. iniciação – formaliza o início de um novo projeto ou fase junto com as principais partes 
interessadas; 
2. planejamento – estrutura o plano do projeto e os seus componentes auxiliares; 
MÓDULO III – ESTRUTURA DO 
GERENCIAMENTO DE PROJETOS 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
34 
 
3. execução – executa o plano com objetivo de concluir o trabalho definido para construção 
das entregas do projeto; 
4. monitoramento e controle – acompanha as ações em execução e avalia o desempenho com 
base no plano – avaliar o “planejado” versus “realizado” – e 
5. encerramento – formaliza o término do projeto,fase ou contrato junto com as principais 
partes interessadas. 
 
Áreas de conhecimento 
O PMBOK® possui, na sua estrutura, dez (10) áreas de conhecimentos: integração, escopo, 
cronograma, custos, qualidade, recursos, comunicações, riscos, aquisições e partes interessadas. 
 
Gerenciamento da integração do projeto 
O objetivo dos processos dessa área de conhecimento é definir, unificar, agrupar, bem como 
coordenar vários processos e atividades de gerenciamento de projetos. A integração é o maior desafio 
do gerente de projetos. 
 
Gerenciamento do escopo do projeto 
O objetivo dos processos dessa área de conhecimento é assegurar que o projeto inclua todo o 
trabalho do projeto, e somente o necessário, para que termine com sucesso. 
 
Gerenciamento do cronograma do projeto 
O objetivo dos processos dessa área de conhecimento é estruturar, organizar e gerenciar as 
atividades de todos o trabalho a ser feitos para que o projeto seja concluído com sucesso. 
 
Gerenciamento dos custos do projeto 
O objetivo dos processos dessa área de conhecimento é estimar, determinar e gerenciar os 
custos de todo o trabalho a ser feito. 
 
Gerenciamento da qualidade do projeto 
O objetivo dos processos dessa área de conhecimento é determinar e garantir a conformidade 
dos processos de gerenciamento de projetos e produto final do projeto. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 35 
 
Gerenciamento dos recursos do projeto 
O objetivo dos processos dessa área de conhecimento é determinar, mobilizar, desenvolver e 
gerenciar todos os recursos necessário para todo o trabalho a ser feito pelo projeto. Podemos 
considerar recursos como: pessoas, equipamento, material, dinheiro, tempo e tudo aquilo de for 
necessário para realizar o trabalho a ser feito. 
 
Gerenciamento das comunicações do projeto 
O objetivo dos processos dessa área de conhecimento é definir, organizar, coletar, distribuir 
e gerenciar todas as comunicações determinadas para o projeto. 
 
Gerenciamento dos riscos do projeto 
O objetivo dos processos dessa área de conhecimento é identificar, organizar, analisar, 
implementar as respostas e monitorar os riscos conhecidos do projeto. 
 
Gerenciamento das aquisições do projeto 
O objetivo dos processos dessa área de conhecimento é determinar, conduzir e gerenciar as 
aquisições necessário para realização do trabalho a ser feito pelo projeto. 
 
Gerenciamento das partes interessadas do projeto 
O objetivo dos processos desta área de conhecimento é identificar, engajar e gerenciar as 
partes interessadas do projeto. 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
36 
 
Na figura a seguir, podemos observar a visão integrada das dez áreas de conhecimentos. 
 
Figura 12 – Visão das dez áreas de conhecimento 
 
Fonte: (Freitas, 2017). 
 
Processos de gerenciamento de projetos 
Agora, iremos apresentar os 49 processos previstos pelo Guia PMBOK® em duas visões – por área 
de conhecimento e por grupo de processos. A apresentação dessas visões é importante para compreender 
como o PMBOK® está estruturado e como os processos estão conectados entre si. 
Os processos serão apresentados com um código identificador no início, que representa duas 
informações: capítulo do PMBOK® e número do processo da área de conhecimento. Por exemplo: 
 
4.1 – Desenvolver o Termo de Abertura do Projeto 
 
4 = Capítulo 04 do PMBOK® - Gerenciamento da Integração 
1 = Primeiro processo ou processo 01 da área de conhecimento de Integração. 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 37 
 
Cada processo possui as respectivas entradas, ferramentas e técnicas, e saídas. O detalhamento 
desses processos não será apresentado nesta apostila. Conforme estrutura apresentada no item 1.2.1 
Estrutura do guia PMBOK® desta apostila, temos os seguintes capítulos: 
� capítulo 04 – gerenciamento da integração do projeto; 
� capítulo 05 – gerenciamento de escopo do projeto; 
� capítulo 06 – gerenciamento do cronograma do projeto; 
� capítulo 07 – gerenciamento dos custos do projeto; 
� capítulo 08 – gerenciamento da qualidade do projeto; 
� capítulo 09 – gerenciamento de recursos do projeto; 
� capítulo 10 – gerenciamento da comunicações do projeto; 
� capítulo 11 – gerenciamento de riscos do projeto; 
� capítulo 12 – gerenciamento das aquisições do projeto e 
� capítulo 13 – gerenciamento das partes interessadas do projeto. 
 
Processos – grupo de iniciação 
 
4.1 – Desenvolver o Termo de Abertura do Projeto (área Integração) 
13.1 – Identificar as partes interessadas (área Partes Interessadas) 
 
O principal objetivo desses dois processos é produzir o termo de abertura do projeto com as 
principais informações (em alto nível) para o patrocinador aprovar, ou não, o projeto. Além desse 
documento, a lista das partes interessadas também será elaborada. 
A título de adaptação das práticas, no próprio documento (TAP), pode existir um tópico 
específico sobre partes interessadas. Observe que fizemos a otimização de dois processos em um 
único documento. 
As informações de um TAP estão em alto nível, simplesmente, porque o projeto ainda não 
foi aprovado e, com isso, não existem informações detalhadas. Após a aprovação, passamos para o 
grupo de processos de planejamento, no qual, a partir das informações do termo de abertura, iremos 
detalhar os itens para definir o plano de projeto e os seus componentes auxiliares. 
Vejamos exemplos de tópicos que podem constar em um termo de abertura do projeto. (TAP)2: 
� descrição, objetivo ou justificativa do projeto; 
� principais entregas; 
� tempo (estimado) ou lista de marcos; 
� custo (estimado); 
 
2 Esses tópicos são apenas exemplos de uma adaptação. Não se limite a essa estrutura. Cada organização pode trabalhar 
de acordo com a sua necessidade de informação para a decisão de aprovação de um projeto. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
38 
 
� benefícios (numérico); 
� premissas; 
� restrições; 
� riscos (geral) do projeto3; 
� critérios de aceitação; 
� gerente de projetos; 
� considerações e 
� aprovação do patrocinador (campo para assinatura). 
 
Processos – grupo de planejamento 
A seguir, vejamos os processos do grupo de planejamento: 
 
4.2 – Desenvolver o plano de gerenciamento do projeto (área Integração) 
5.1 – Planejar o gerenciamento do escopo (área Escopo) 
5.2 – Coletar os requisitos (área Escopo) 
5.3 – Definir escopo (área Escopo) 
5.4 – Criar EAP (área Escopo) 
6.1 – Planejar o gerenciamento do cronograma (área Cronograma) 
6.2 – Definir atividades (área Cronograma) 
6.3 – Sequenciar atividades (área Cronograma) 
6.4 – Estimar as durações das atividades (área Cronograma) 
6.5 – Desenvolver cronograma (área Cronograma) 
7.1 – Planejar o gerenciamento de custos (área Custos) 
7.2 – Estimar custos (área Custos) 
7.3 – Determinar orçamento (área Custos) 
8.1 – Planejar o gerenciamento da qualidade (área Qualidade) 
9.1 – Planejar o gerenciamento dos recursos (área Recursos) 
9.2 – Estimar os recursos das atividades (área Recursos) 
10.1 – Planejar o gerenciamento das comunicações (área Comunicações) 
11.1 – Planejar gerenciamento de riscos (área Riscos) 
11.2 – Identificar riscos (área Riscos) 
11.3 – Realizar análise qualitativa de riscos (área Riscos) 
11.4 – Realizar análise quantitativa de riscos (área Riscos) 
11.5 – Planejar respostaspara riscos (área Riscos) 
 
3 Observe que estamos falando de riscos de maneira geral, uma vez que o detalhamento e as práticas de gerenciamento 
de riscos somente iniciarão no grupo de processos de planejamento. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 39 
 
12.1 – Planejar o gerenciamento das aquisições (área Aquisições) 
13.2 – Planejar o engajamento das partes interessadas (área Partes Interessadas) 
O principal objetivo desses processos é estrutura o plano do projeto e os seus respectivos 
componentes auxiliares, para formar as “regras do jogo” ou o “como fazer o projeto”. É importante 
ressaltar que precisamos avaliar bem o ambiente no qual o projeto está inserido para a adaptação 
desses processos recomendados como melhores práticas. Sendo assim, podemos considerar (mas 
não nos limitarmos somente): 
� No caso de a organização possuir uma metodologia de gerenciamento de projetos – 
própria ou de alguma associação profissional –, muitos desses processos estarão definidos 
pelo método em si. 
� No caso de desenvolver o processo, é preciso avaliar os APOs e FAEs para adaptação dos 
processos. 
� Como o PMBOK® não é metodologia, tais processos não devem ser seguidos como passo 
a passo, e sim com referência para adaptação. 
� Ao estruturar o plano do projeto, as linhas de base serão definidas para o projeto e 
utilizadas como referência para medição ao longo da execução do projeto, ou seja, avaliar 
o planejado versus realizado. 
 
Processos – grupo de execução 
A seguir, vejamos os processos do grupo de execução: 
 
4.3 – Orientar e gerenciar o trabalho do projeto (área Integração) 
4.4 – Gerenciar o conhecimento do projeto (área Integração) 
8.2 – Gerenciar a qualidade (área Qualidade) 
9.3 – Adquirir recursos (área Recursos) 
9.4 – Desenvolver a equipe (área Recursos) 
9.5 – Gerenciar a equipe (área Recursos) 
10.2 – Gerenciar as comunicações (área Comunicação) 
11.6 – Implementar respostas aos riscos (área Riscos) 
12.2 – Conduzir aquisições (área Aquisições) 
13.3 – Gerenciar o engajamento das partes interessadas (área partes interessadas) 
 
O principal objetivo desses processos é executar o plano de forma simples e objetiva. Seguem 
algumas observações: 
� Não são todas as áreas de conhecimento que possuem processos no grupo de execução. 
� A partes de mobilização de recursos (inclusive pessoas), desenvolvimento e gerência de 
pessoas ocorre nesse grupo de processos. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
40 
 
� Na execução, ocorre o maior envolvimento humano do projeto, uma vez que as entregas 
estarão sendo construídas pelos membros da equipe técnica do projeto. 
� Nesse grupo, também ocorre a contratação (aquisições) determinadas pelo plano do projeto. 
Processos – grupo de monitoramento e controle 
A seguir, vejamos os processos do grupo de monitoramento e controle: 
 
4.5 – Monitorar e controlar o trabalho do projeto (área Integração) 
4.6 – Realizar o controle integrado de mudanças (área Integração) 
5.5 – Validar o escopo (área Escopo) 
5.6 – Controlar o escopo (área Escopo) 
6.6 – Controlar o cronograma (área Cronograma) 
7.4 – Controlar os custos (área Custos) 
8.3 – Controlar a qualidade (área Qualidade) 
9.6 – Controlar os recursos (área Recursos) 
10.3 – Monitorar as comunicações (área Comunicações) 
11.7 – Monitorar os riscos (área Riscos) 
12.3 – Controlar as aquisições (área Aquisições) 
13.4 – Monitorar o engajamento das partes interessadas (área Partes Interessadas) 
 
O principal objetivo desses processos é realizar as medições ao longo da execução do projeto, 
comparando planejado versus realizado, analisando as suas variações e propondo ações preventivas, 
corretivas ou mudanças que visam manter o projeto conforme as linhas de base estabelecidas. 
Seguem algumas observações: 
� Esses processos são o meio de identificar problemas antes de eles ocorrerem, levando a 
uma abordagem proativa, e não reativa. 
� Cada área de conhecimento possui a sua base para medição. Vamos a alguns exemplos: 
� escopo – linha de base – declaração de escopo, estrutura analítica do projeto (EAP) e 
dicionário da EAP; 
� cronograma – linha de base – cronograma versão 0 (ou versão mais atualizada) 
aprovada pelo cliente e 
� custos – linha de base – orçamento versão 0 (ou versão mais atualizada) aprovado 
pelo cliente. 
 
Essas linhas de bases serão a referência para o monitoramento e controle. O resulta da 
medição leva a três possíveis cenários: 
1. acima do planejado; 
2. conforme o planejado e 
3. abaixo do planejado. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 41 
 
O alinhamento do projeto é mantê-lo conforme o planejado. É importante ressaltar que 
atrasar (por exemplo, atraso de 3 meses no projeto) ou adiantar (entrega do projeto com 4 meses 
de antecedência), com grande variação, não é uma boa prática, uma vez que o seu planejamento 
não foi feito de maneira adequada, comprometendo recursos da organização que poderiam estar 
sendo utilizados em outras áreas ou projetos. 
 
Processos – grupo de encerramento 
A seguir, vejamos os processos do grupo de encerramento: 
 
4.7 – Encerrar o projeto ou a fase (área Integração) 
 
O principal objetivo desse processo é formalizar o encerramento do projeto. É importante 
ressaltar que esse processo é importante considerando dois cenários: projeto ser cancelado e projeto 
ser concluído com sucesso. 
Caso um projeto seja encerrado por qualquer motivo – por exemplo, inviabilidade técnica-
financeira, mudança de estratégica, perda de relevância – é preciso encerrá-lo da mesma maneira 
como quando ele for encerrado com sucesso. É importante realizar: 
� encerramento e pendências contratuais; 
� aprovação do cliente de entregas relacionadas a uma fase ou ao projeto; 
� desmobilização de recursos e 
� registro de informações importantes para arquivamento do projeto e uso, como 
aprendizado para projetos futuros. 
 
Um documento recomendado é o Termo de Encerramento do Projeto (TEP). 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
42 
 
A orientação é de que um projeto faça a implementação desses cinco grupos de processos, 
considerando que processos são grupos de ações e atividades inter-relacionadas e sobrepostas. Os 
processos pertencerão sempre a um dos cinco grupos ou naturezas, porém, na prática, eles serão 
realizados de forma interativa, conforme esboçado pelas duas imagens a seguir: 
 
Figura 13 – Grupos de Processos de gerenciamento de projetos 
 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 43 
 
Visão consolidada 
A seguir, observe a figura que mostra a relação entre grupos de processos, áreas de 
conhecimento e os 49 processos do guia PMBOK®: 
 
Figura 14 – Visão consolidada estrutura de projetos – guia PMBOK®. 
 
 
 
 
 
Felipe Gorgen dos Reis
 
 
 
 
 
 
 
Neste módulo, faremos uma reflexão sobre algumas práticas aplicadas do dia a dia, 
metodologias de gerenciamento de projetos de outras instituições dedicadas à disseminação do 
gerenciamento de projetos no mundo, bem como outros padrões que suportam a determinação e 
adaptação de práticas de gestão de projetos a serem aplicadas nas organizações. 
As práticas apresentadas neste módulo representam exemplos práticos de alguns processos 
estudados no módulo anterior. É importante ressaltar que não devem ser aplicadas como um 
método ou passo a passo, e sim como exemplos para apoiar o dia a dia da organização. 
Na segunda parte do módulo, apresentaremosexemplos de outros padrões que ilustram visões 
complementares ao guia PMBOK®, constituindo exemplos para aplicação práticas do 
gerenciamento de projetos. 
 
Práticas de gerenciamento de projetos 
Serão apresentados alguns exemplos de adaptação e aplicação de práticas de gerenciamento 
de projetos relevantes para a composição do plano de projeto. É importante ressaltar que não se 
trata de uma metodologia, e sim de alguns exemplos práticos. 
 
Plano de projeto 
O plano do projeto determina todas as regras do jogo, ou seja, como o projeto deverá ser 
gerenciado considerando todas as áreas de conhecimento utilizadas. 
 
 
MÓDULO IV – PRÁTICAS DE PROJETOS E 
OUTROS PADRÕES 
 
46 
 
A seguir, observe a figura com a visão do plano do projeto. 
 
Figura 15 – Visão do plano de projeto 
 
 
Declaração de escopo 
A declaração de escopo do projeto (DEP) é o documento descritivo que, a partir do termo de 
abertura do projeto aprovado, inicia o desdobramento e detalhamento do produto final do projeto. 
Por isso mesmo, a DEP é um dos documentos tidos como chave em toda a história de um projeto 
e do seu gerenciamento até a conclusão. 
A seguir, vejamos alguns tópicos que podem constar do documento de declaração de escopo 
do projeto: 
� nome do projeto; 
� objetivo do projeto; 
� produto final do projeto; 
� escopo funcional do projeto; 
 
 47 
 
� documentação técnica (por exemplo: em um projeto de obra ou desenvolvimento de um 
sistema de informação, podem ser utilizados manuais técnicos relacionados ao escopo 
do projeto); 
� documentação de referência (por exemplo: em um projeto de obra ou desenvolvimento 
de um sistema de informação, pode ser utilizada documentação de referência com normas 
da área para reforçar as informações do escopo do projeto); 
� exclusões do escopo do projeto; 
� fatores críticos de sucesso; 
� análise preliminar dos riscos e 
� critérios de aprovação do produto final. 
 
A DEP dever ser elaborada de maneira colaborativa com os principais envolvidos com o 
objetivo de levantar informações importantes para o entendimento do produto final do projeto, 
com base em informações confiáveis e na visão técnica consolidada. Ao ser completada, essa 
declaração servirá de input para a confecção da ferramenta da EAP, conforme veremos a seguir. 
 
Estrutura Analítica do Projeto (EAP) 
Umas das ferramentas mais poderosas recomendadas pelo guia PMBOK® é a Estrutura 
Analítica do Projeto (EAP) ou WBS (Work Breakdown Structure). A ferramenta ilustra, de forma 
simples, a visão de todo o trabalho a ser feito, pois pormenoriza os componentes mais elementares 
do projeto. A EAP divide o produto do projeto em partes lógicas e inter-relacionadas 
hierarquicamente. 
Apesar de estar na área de conhecimento de escopo, a EAP também é usada como ferramenta 
de comunicação, uma vez que qualquer pessoa, ao observar uma EAP, deve ser capaz de ver todo o 
trabalho a ser feito. Caso haja algo não contemplado, ou seja, que falta ser entregue pelo projeto, a 
estrutura estará malfeita, o que ocasiona diversos problemas, impactando, inclusive, o resultado 
final previsto para o projeto. Como a EAP divide os componentes do todo, discriminando os 
elementos de escopo, ela evita que qualquer trabalho seja esquecido. 
A primeira técnica a ser utilizada para a composição da EAP é a decomposição, ou seja, 
assumir a visão do projeto e “quebrar” ou “estruturar” em pedaços – são as famosas “caixinhas”. No 
entanto, existem algumas dicas para se estruturar a composição da estrutura, por exemplo usando 
as fases do ciclo de vida do projeto em questão na decomposição da ferramenta. Outra opção 
amplamente aceita é usar as entregas do projeto na 1ª decomposição. O último nível de 
decomposição ou desmembramento de uma EAP chama-se pacote de trabalho. 
 
 
 
48 
 
A seguir, observe uma estrutura analítica de um projeto simples. Nesse caso, um projeto de 
quatro fases, em que a fase 1 está decomposta em quatro entregas, a fase 2 está decomposta em 
quatro entregas, a fase 3 está decomposta em duas entregas (com a entrega 10 decomposta em dois 
pacotes de trabalho), e a fase 4 se mantém somente do mesmo nível. 
 
Figura 16 – Exemplo fictício de estrutura analítica do projeto (EAP) 
 
 
Ao elaborar uma EAP, uma das principais dúvidas é qual o limite de decomposição. Como 
dica, podemos considerar que: 
� ao decompor o nível superior, serão necessários pelo menos “dois filhos”, ou seja, o 
mínimo de “duas caixinhas”; 
� no menor nível, cada caixinha deve ter, no mínimo, oito horas de atividades e, no máximo, 
80 horas de atividade. Essa prática, conhecida como regra 8/80h, é recomendada pelo 
PMBOK®. No entanto, pode ser adaptada para 8/120h ou 8/200h, ou seja, de acordo com 
a sua necessidade; 
� se o menor nível, por exemplo, estiver usando a regra 8/80h e possuir 240 horas de 
atividades, significa que será necessário decompor em três pacotes de trabalho de 80 horas. 
Esse é o ponto de atenção e 
 
 49 
 
� para saber a quantidade necessária em horas, dias ou a forma de medição a ser utilizada 
para a realização das atividades, será necessário elaborar o cronograma de atividades (vamos 
estudá-lo no próximo item). 
 
Vamos analisar alguns exemplos de EAPs – lembrando que são projetos fictícios e que a cada 
projeto deve ser avaliada a melhor forma de decomposição. 
 
a) Exemplo 1 – projeto de seminário de empreendedorismo 
Na figura a seguir, observe a forma como a EAP está estruturada. O projeto possui quatro fases: 
Definição dos autores e temas, Escolha do local e data, Divulgação do evento e Montagem do evento. 
Na prática, o desenho de uma EAP é iniciado pela decomposição do escopo-macro do projeto, 
em blocos cada vez menores, e de entregas progressivamente diminutas. Esses desmembramentos 
chegam a um ponto ideal ou ao nível de detalhamento desejado de fim, chamados de pacotes de 
trabalho. Portanto, os pacotes de trabalho são os menores níveis de uma EAP. 
 
Figura 17 – Exemplo fictício EAP (projeto construção prédio) 
 
 
b) Exemplo 2 – projeto de mapeamento de processos de negócio: 
Na figura a seguir, observe a forma como a EAP está estruturada. O projeto possui quatro 
(04) fases: entrevistas, consolidação de processos (AS-IS), consolidação de processo (TO-BE) e 
treinamento. 
 
50 
 
Observe que, na fase 1, haverá três grupos a serem entrevistados para o entendimento dos 
processos e, na última entrega (documentação), será consolidado o material das entrevistas dos três 
grupos. 
Na fase 2, ocorrerá o desenho do processo como está atualmente, chamado de AS –IS. No 
final da entrega da integração, será produzido um mapa de processos na visão da integração das 
áreas de negócio da organização. 
Na fase 3, ocorrerá o (re)desenho dos processos de como será o futuro dos processos de negócio, 
considerando melhorias e otimização, chamado de TO-BE, com a entrega final do mapa de processos. 
Por fim, na fase 4, haverá o treinamento de todos os envolvidos nos processos mapeados e 
desenhados. Observe que todo o fluxo previsto para o trabalho a ser feito foi contemplado 
 
Figura 18 – Exemplo fictício EAP (projeto mapeamento de processos de negócio) 
 
 
 
 
 51 
 
Como dica, apresentamos o método proposto por Vargas (2009): 
DECOMPOSIÇÃO 
� para FASES, tudo em letras maiúscula (exemplo: FASE I – ESTRUTURAÇÃO); 
� para ENTREGAS, uso de substantivo em letra maiúscula (exemplo: HARDWARE) 
� para pacotes de trabalho, uso de substantivos com primeira letra em maiúsculo (exemplo: 
Servidor de Aplicação); 
� para atividades, uso verbos no infinitivo (exemplo: Configurar o Servidor de Aplicação) e 
� para marcos (milestones), uso verbo no particípio passado (exemplo: Servidor de Banco de 
Dados Configurado). 
 
Cronograma de projeto 
O cronograma é uma ferramenta que apoia a aplicação de algumas práticas e técnicas. Como 
exemplo, um cronograma de uma grande obra com 3.000 atividades. O software de cronograma 
apoia a estruturação e organizaçãodessas atividades, considerando: 
� relacionamento lógico entre as atividades; 
� recursos envolvidos em cada atividade; 
� orçamento e 
� outros itens. 
 
Como dica, devemos considerar que o ponto de partida para estruturação do cronograma é a 
EAP. Isso é muito importante! 
A estrutura inicial tem como base a estrutura analítica do projeto. Vamos a um exemplo: 
 
1. PROJETO 
1.1 FASE 1 
1.1.1 ENTREGA 1 
1.1.1.1 PACOTE DE TRABALHO 
1.1.1 ATIVIDADE 01 
1.1.2 ATIVIDADE 02 
1.1.3 ATIVIDADE 03 
1.1.4 ATIVIDADE 04 
1.1.5 ATIVIDADE 05 
1.1.6 ATIVIDADE 06 
(…) 
 
 
 
52 
 
Cada atividade deve determinar a data de início e a data de término, os recursos envolvidos e 
outras informações relevantes para o plano do projeto. Observe que, nesse momento, é definida a 
quantidade de horas de um pacote de trabalho da EAP. É um momento importante para a 
decomposição da EAP e do CRONOGRAMA. Lembrando que é importante criar um equilíbrio 
no grau de detalhamento das atividades, relacionado diretamente ao tipo, porte e à complexidade 
do projeto. Exemplo de atividades: 
 
ATIVIDADE 01: realizar instalação de sistema do data center. 
RECURSOS – ATIVIDADE 01: 
� tempo: 01 dia; 
� recursos: 02 analistas de sistemas e 
� custo: R$ 900,00. 
 
ATIVIDADE 02: realizar validação da fundação da obra. 
RECURSOS – ATIVIDADE 02: 
� tempo: 01 dia; 
� recursos: 01 engenheiro e 
� custo: R$ 1.200,00. 
 
ATIVIDADE 03: submeter documento final para aprovação do cliente. 
RECURSOS – ATIVIDADE 03: 
� tempo: 04 horas; 
� recursos: 01 gerente de área e 
� custo: R$ 1.500,00 
 
Para reflexão: sobre o grau de detalhamento de um plano, é importante criar equilíbrio para 
justificar o esforço de gerenciamento. Se for pouco, você ganha velocidade, mas não ganha controle. 
Se for muito, você ganha controle, mas não ganha velocidade. 
 
 
 
 53 
 
Determinação do sequenciamento das atividades 
Após a elaboração da lista de atividades, é importante estabelecer o relacionamento lógico 
entre elas. Isso significa sequenciar essas atividades. Na figura a seguir, observe as sete atividades e 
os relacionamentos lógicos entre elas. Porém, é importante ressaltar que, atualmente, os 
cronogramas são feitos via ferramentas (softwares), ou seja, concebidos de forma muito mais 
automatizada que antes. 
 
Figura 19 – Sequenciamento de atividades 
 
 
Orçamento 
O orçamento do projeto deve compor o valor (recurso financeiro) para todo o trabalho a ser 
feito, considerando: custos de todos os recursos envolvidos – pessoas, equipamento, material, 
capacitação, contratação, etc. – e reservas para o tratamento de riscos. 
Uma técnica simples para determinar o orçamento é feita a partir da EAP, determinando os 
custos dos componentes menores para os componentes maiores, até determinar o custo total do 
projeto. Vejamos um exemplo: 
 
 
 
54 
 
Passo 1 – determinar o custo dos componentes menores 
 
Figura 20 – Elaboração orçamento 
 
 
Passo 2 – determinar o custo dos componentes maiores 
Observe que, a partir da determinação do custo dos pacotes de trabalho, temos uma visão 
agrupada de baixo para cima. Por exemplo: 
� O custo da fase 1 será a soma de todos os pacotes de trabalho nela associados (nesse caso, 
03 pacotes). 
� O custo do projeto será a soma de todas as fases nele definidos. 
 
Figura 21 – Elaboração orçamento 
 
 
 55 
 
Planejamento de custos 
O orçamento do projeto deve compor o valor (recurso financeiro) para todo o trabalho a ser 
feito, considerando (mas não se limitando a) elementos ligados as áreas de qualidade, riscos, reservas 
orçamentárias, aquisições. 
Após a aprovação do orçamento de um projeto, é importante determinar o fluxo de caixa. O 
fato de um orçamento de R$ 1.000.000,00 estar aprovado não significa que o valor estará disponível 
em caixa no outro dia. É preciso provisionar o desembolso para os pagamentos previstos para o 
projeto. Por exemplo: 
 
orçamento aprovado: R$ 1.000.000,00 
mês 1 mês 2 mês 3 mês 4 mês 5 
R$ 200.000 R$ 250.000 R$ 150.000 R$ 200.00 R$ 200.00 
 
Ferramentas da qualidade 
Quando falamos de qualidade em projetos, precisamos visualizar dois elementos: o produto 
final do projeto e os processos de gerenciamento de projetos aplicados. É preciso definir ferramentas 
que visam atestar conformidade com os itens acima. Por exemplo: 
Ferramenta – check list – definir uma lista de itens (técnicos) a 
serem verificados para aprovar uma entrega. 
No momento da avaliação, os itens serão checados e validados por alguém – talvez, um 
responsável técnico ou mesmo o cliente. Uma vez validado e aprovado, a entrega estará concluída 
ou uma solicitação de mudanças será enviada para eventuais correções, ajustes ou alterações 
necessárias para atestar a conformidade do produto. 
Além dos check-list, existem outras ferramentas recomendadas. A seguir, observe alguns 
exemplos: 
� diagramas de causa e efeito; 
� fluxogramas; 
� listas de verificação; 
� diagramas de Pareto; 
� histogramas; 
� gráficos de controle e 
� gráficos de dispersão. 
 
 
56 
 
Para alguns projetos, o gerente de projetos deve utilizar a opinião especializada para 
inspecionar, validar e aprovar uma entrega antes de enviar para o cliente realizar a validação final. 
Esse processo requer atenção, já que impacta, diretamente, as expectativas das partes interessadas. 
É importante ressaltar que a qualidade se torna uma grande oportunidade para as 
organizações, por conta de itens como desperdício, retrabalho, perdas e outros fatores que 
ocasionam perda de dinheiro nas empresas, anualmente, pela negligência da qualidade. 
Na figura a seguir, observamos um fluxo (proposto) para a qualidade do projeto, desde a 
definição de itens críticos para aprovação, passando pela inspeção e validação da equipe técnica, 
antes de enviar para o cliente realizar a aprovação final da entrega ou produto final do projeto, 
considerando alguma reprovação ao longo do processo que leva o item avaliado ao passo anterior 
do fluxo, até que se obtenha conformidade com o planejado. 
 
 
Figura 22 – Fluxo de qualidade do projeto 
 
 
O gerenciamento de projetos é extremamente colaborativo, e a melhoria contínua se torna um 
fator importante para o desenvolvimento da cultura e maturidade do tema na organização. Buscar 
melhorias e itens que ajudam ainda mais a agilizar, simplificar e tornar a gestão eficiente é esperado 
pela etapa do processo. Por exemplo: a organização ainda não trabalha práticas de gestão de riscos. 
Uma vez que os processos básicos relacionados a escopo, tempo e custo estão em condições mínimas 
necessárias, ou seja, fazendo bem o básico, é possível trabalhar os itens premissas e restrições como 
riscos identificados e, com isso, evoluir a aplicação da gestão dos riscos ao longo do tempo. 
 
 
 57 
 
Matriz da comunicação e análise de partes interessadas 
As partes interessadas determinam o caminho a seguir do projeto. Principalmente, as partes 
interessadas de alto poder e influência. Como exemplo, apresentamos o gráfico de poder versus 
influência, que pode auxiliar a identificar as partes interessadas mais crítica e que devem ser 
gerenciadas, já que, para um projeto, o número de partes interessadas pode ser tão grande a ponto 
de se tornar inviável gerenciar todas. No entanto, para aquelas de maior criticidade, é importante 
serem gerenciadas. 
 
Figura 23 – Gráfico de poder versus influência 
 
 
Após a identificação e categorização das principais partes interessadas, a matriz de comunicação é 
elaborada. A matriz de comunicação determina uma série de eventos sobre como comunicação do 
projeto deve ser gerada, coletada, armazenada, distribuída e rastreada durante o projeto. 
Podemos considerar que a informação a ser contemplada neste processo deve gerar valor ao 
projeto. A base para esta matriz são as principais partes interessadas do projeto. Muitas vezes o 
gerente de projeto fala a mesma coisa, porém, de forma diferente. Informação para o nível técnico 
do projetoe informação para o nível executivo, ou seja, cada um tem sua linguagem específica. 
 
 
58 
 
É importante ressaltar que, comunicação em excesso prejudica da mesma forma que pouca 
informação. 
 
Figura 24 – Exemplo de matriz de comunicação 
 
 
 
 59 
 
Matriz de recursos 
Os recursos de um projeto devem ser determinados para atender todo o trabalho a ser feito 
pelo projeto. Nem mais nem menos. Durante a elaboração do cronograma e orçamento, os recursos 
devem ser determinados. Observe a integração dessa área de conhecimento como as áreas de tempo 
e custos. Nesse processo, é importante considerar: 
� Quantidade de recursos, já que, quanto mais recursos, grande é a probabilidade de redução 
de tempo e aumento de custos. 
� Sob a ótica de recursos humanos, deve-se considerar experiência do profissional para 
dimensionar o tempo estimado para realização de atividades técnicas. 
� Em uma visão integração (organização), os projetos acabam concorrendo entre si pelos 
mesmos recursos. Uma visão de mapa de recursos que prevê alocação ao longo de um ano 
nos diversos projetos deve apoiar o planejamento. 
 
Observe o mapa de recursos a seguir. Para cada recurso, pode existir uma quantidade (unidade 
– número de pessoas, madeira, aço) e custos associado a cada um para apoiar a composição de 
orçamento do projeto. 
 
Figura 25 – Mapa de recursos 
 
 
 
60 
 
Análise de riscos 
Riscos são incerteza que podem gerar impacto de forma positiva (oportunidade) ou negativa 
(ameaça) no projeto. Temos riscos conhecidos, ou seja, aqueles que são identificados ao longo de 
todo o projeto, e os riscos desconhecidos, ou seja, aqueles que não são mapeados por falta de 
conhecimento. 
 
Tipos de riscos 
a) Conhecidos, que podem: 
� ser antecipados; 
� ser avaliados com relação à probabilidade e ao impacto, e 
� ter contramedidas. 
 
b) Desconhecidos – não planejados e, até então, não conhecidos. É importante: 
� reservar contingências (esforço e custo) para, posteriormente, auxiliar no tratamento 
do mesmo e 
� aumentar a probabilidade e o impacto dos eventos positivos, e diminuir a 
probabilidade e o impacto de eventos negativos no projeto. 
 
A partir da EAP, os riscos devem ser identificados pela equipe do projeto. Após a lista de 
risco, é necessário realizar análise, que pode ser do tipo qualitativa ou quantitativa. 
 
Técnicas de identificação de riscos 
� brainstorming – técnica utilizada para geração de ideias sobre o risco do projeto sob a 
liderança de um facilitador, na qual participam, além da equipe do projeto, especialistas 
externos ao projeto; 
� técnica Delphi – especialistas participam anonimamente, buscando um consenso 
imparcial sobre os riscos do projeto sem influência da equipe interna; 
� entrevistas – Realizadas com participantes experientes do projeto, stakeholders e 
especialistas no assunto para identificação de riscos; 
� identificação da causa raiz – investigação das causas essenciais dos riscos do projeto 
possibilitando o agrupamento de riscos por causas e 
� design thinking – conjunto de técnicas de incentivo à criação, análise e ao levantamento de 
informações como apoio visual com objetivo de solucionar um problema. 
 
 
 
 61 
 
Para a etapa 1 – identificação de riscos – pode usar a ferramenta Estrutura Analítica de Riscos, 
muito parecida com a EAP. O objetivo é organizar a visão dos riscos conhecidos. Observe a figura 
a seguir. 
 
Figura 26 – Exemplo de estrutura analítica de riscos 
 
 
Respostas aos riscos identificados 
O orçamento do projeto deve compor o valor (recurso financeiro) para todo o trabalho a ser 
feito, considerando que, para cada risco identificado, será necessário: 
� descrição; 
� oportunidade e ameaça; 
� probabilidade; 
� impacto; 
� estratégia; 
� plano de resposta ao risco e 
� responsável. 
 
 
 
62 
 
A seguir, observe os tipos de estratégia de resposta aos riscos positivos (oportunidade) e 
negativo (ameaças). 
 
a) Estratégia para riscos positivos 
 
Figura 27 – Respostas para riscos positivos 
escalar repassar os riscos para o nível acima 
explorar adicionar trabalho ou mudar o projeto para garantir que as 
oportunidades ocorram 
compartilhar atribuir propriedade dos riscos a terceiros que são mais 
capazes de capturar a oportunidade 
melhorar aumentar a chance, probabilidade e os impactos positivos de 
um evento de risco 
aceitar aceitar a ocorrência do risco positivo 
 
b) Estratégia para riscos negativos 
 
Figura 28 – Respostas para riscos negativos 
escalar repassar os riscos para o nível acima 
prevenir ação para a eliminação da causa do risco 
transferir ação para transferência total ou parcial a terceiros, das 
consequências do risco 
mitigar ação para reduzir a probabilidade ou as consequências de um 
risco negativo 
aceitar aceitar a ocorrência do risco negativo 
 
 
 
 
 63 
 
Priorização dos riscos: o objetivo dessa matriz, além de detalhar a lista de riscos identificados, 
é realizar uma priorização, ou seja, avaliar quais os riscos devem ser tratados por conta da 
probabilidade versus impacto nos objetivos do projeto e de acordo com a reservas financeiras para 
o tratamento de riscos. Observe o modelo para tratamento e priorização de riscos a seguir. 
 
Figura 29 – Exemplo de matriz de riscos 
código descrição 
do risco 
oportunidade 
ou ameaça? 
probabilidade impacto estratégia plano de 
resposta ao 
risco 
responsável 
R1 (descrever 
risco) 
 alto/médio/baixo 
e... (descrever 
impacto) 
 descrever 
tratamento 
de risco) 
(descrever 
nome do 
responsável 
R2 (descrever 
risco) 
 
R3 (descrever 
risco) 
 
 
Cada Risco deve ter sua resposta que estará relacionado diretamente a atividades de 
cronograma e um custo que deve ser avaliado junto ao orçamento. 
 
Processo de contratação 
A partir da EAP, é identificado para qual (ou quais) entrega(s) do projeto serão necessárias 
aquisições, ou seja, terceiros para proverem serviços ou produtos que irão contribuir para o produto 
final do projeto. É importante ressaltar que muitas organizações possuem processo formalizado para 
compras ou contratação. Nesses casos, é preciso seguir o processo de acordo com o procedimento 
ou política interna. 
O tempo do processo deve ser considerado no cronograma como atividades previstas, ou seja, 
o ciclo de contratação deve ser considerado no tempo do projeto. 
Existem alguns tipos documentos que podem apoiar o processo de contratação do projeto, 
por exemplo: 
� carta-convite; 
� memorando de entendimento; 
� RFP – Request For Proposal e 
� edital técnico. 
 
 
Deve-se ressaltar que o que um determinado fornecedor suprirá para o projeto é apenas uma 
parte de um todo. O gestor do projeto terá que estabelecer inúmeras contratações com os diversos 
 
64 
 
fornecedores necessários para os insumos do projeto. Ademais, observe que o ciclo de contratação 
está previsto para a entrega, desde a cotação até a aquisição e entrega do produto contratado. 
Vejamos: 
 
Fase 2 – Projeto 
� cotação/10 dias; 
� contratação/15 dias; 
� aquisição/5 dias e 
� desenvolvimento produto final contratado/30 dias. 
 
Administração de contrato 
Quando um projeto conta com aquisições, ou seja, o uso de serviços e produtos de terceiros, é 
importante alinhar as atividades do(s) terceiro(s) às atividades de projeto, ou seja, no cronograma. 
Administrar um contrato é seguir e assegurar que o que está sendo entregue é exatamente o previsto 
pelo contrato assinado, de forma que relacionamento entre ambas as partes será próspero, e reiterando 
a visão projeto na visão do comprador e o projeto na visão do fornecedor. 
 
Planejamento ágil de projetos 
Para exemplificar, podemos citar o SCRUM que trata, inicialmente, de uma abordagem ágil, 
originalmente criada para suportar projetos de desenvolvimento de software. Atualmente, é fato que 
outras áreas o aplicam, integralmente ou parcialmente, os seus processos. 
 
Figura 30 – Método SCRUM (exemplo) 
 
 
A SCRUMtrata de, a partir do produto desejado, particionar pequenas entregas que serão 
priorizadas por ordem de valor e importância pelo cliente. A equipe técnica constrói testa e entrega 
dentro de um ciclo iterativo previsto chamado de SPRINT, que pode durar de 2 a 4 semanas. A 
 
 65 
 
evolução da construção dessas pequenas entregas é acompanhada diariamente em reuniões de 10 
minutos em que todos ficam em pé (o nome em inglês seria stand-up meeting). Além disso, ocorrem 
as reuniões de planejamento do próximo ciclo e lições levantadas do último ciclo, como a proposta 
de aumentar a eficiência do time. Com papéis e responsabilidades bem definidas e o envolvimento 
das pessoas certas, o método apoia a comunicação entre equipe e cliente reduzindo possíveis 
“ruídos”. Trata-se de uma aplicação prática que traz ganhos e agilidade nos processos de gestão. 
O método poderia ser aplicado a um pacote de trabalho da EAP, em que a visão seria por 
sprints, em nosso exemplo de 15 dias. Ao de final desse ciclo, algo seria entrega ao cliente com a 
percepção de valor. 
 
Execução, controle e encerramento 
Ao compor o plano do projeto, estabelecemos a linhas de base que será a referência para a 
medição ao longo da execução do projeto. Observe que foram levantadas informações importantes 
sobre cada área de conhecimento relevante para o projeto para alinhar o entendimento sobre os 
objetivos e o produto final do projeto entre todos os envolvidos, e o principal: ter condições de 
tomar decisão de forma ágil ao ser observado desvios. 
Após aprovação do plano junto às principais partes interessadas, inicia-se a execução de todo 
o trabalho a ser feito com base no planejado. Periodicamente, medições serão necessárias para 
decisão e reavaliação do projeto, além de propor mudanças para os desvios identificados. Lembre-
se de que o plano de projeto é o ponto de partida e o mesmo será versionado diversas vezes até o 
final do projeto. 
 
Outros padrões 
ISO 21.500 
De acordo com Krause (2014), a norma ABNT ISSO 21.500 foi criada para ajudar as 
organizações no desenvolvimento das melhores práticas em gerenciamento de projetos. As normas 
ISO são desenvolvidas nos seus comitês técnicos (ISO/TC), que são organizados em uma base 
temática com representantes dos seus membros 
No Brasil, a Associação Brasileira de Normas Técnicas (ABNT) é uma entidade privada, sem 
fins lucrativos, considerada de utilidade pública, fundada em 1940 e reconhecida pelo governo 
federal como Fórum Nacional de Normalização. A ABNT é a representante, no Brasil, da 
Organização Internacional de Normalização (ISO). 
A Estrutura da Norma ABNT NBR ISO 21500 é: 
� Capítulo 1 – Escopo – cobre a abrangência da norma e a sua aplicação nas organizações. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
66 
 
� Capítulo 2 – Termos e definições – contém dezesseis termos e definições relacionados a 
gerenciamento de projetos. São termos que não estão claramente apresentados na norma 
e não têm definição no dicionário Oxford English Dictionary. 
� Capítulo 3 – Conceitos do gerenciamento de projetos – descreve conceitos que 
representam uma importância relevante durante a execução dos projetos: 
� projeto; 
� gerenciamento de projeto; 
� estratégia organizacional e projetos; 
� ambiente dos projetos; 
� governança de projetos; 
� projetos e operações; 
� partes interessadas e a organização do projeto; 
� competências da equipe do projeto, ciclo de vida do projeto; 
� restrições dos projetos; 
� relacionamento entre os conceitos do gerenciamento de projetos e os processos, e 
� os conceitos estão centrados na geração de valor para as organizações. 
� Capítulo 4 – Processos do gerenciamento de projetos – identifica os processos 
recomendados, que devem ser aplicados em todo o projeto ou fases do projeto. Os 
processos são genéricos e podem ser utilizados por qualquer projeto ou organização. O 
gerente de projeto ou patrocinador podem escolher como aplicar os processos e em que 
sequência, de acordo com a cultura, os recursos e as necessidades do projeto e da 
organização. Os processos de gerenciamento de projeto podem ser vistos por duas 
perspectivas: por grupo de processos, no ponto de vista do gerenciamento de projetos; por 
grupo de assuntos, no ponto de vista de temas específicos. 
 
PRINCE2® 
De acordo com a AXELOS, o PRINCE2® é um dos métodos de gerenciamento de projetos 
mais amplamente adotado no mundo. É usado por pessoas e organizações em vários setores 
diferentes. PRINCE2® é composto por: 
� manual do PRINCE2®; 
� programa de certificação (níveis de Foundation and Practitioner); 
� serviço de assinatura de suporte e 
� outros manuais, como o PRINCE2® Agile, que combina as melhores práticas comprovadas 
do PRINCE2® com conceitos ágeis, permitindo a entrega perfeita de produtos e projetos. 
 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 67 
 
Os princípios, temas e processos existentes do PRINCE2® permanecem consistentes, mas 
enfatizamos alguns elementos em todas as orientações e exames. A atualização coloca uma ênfase 
maior na adaptação do PRINCE2® às necessidades de organizações e ambientes de projeto, 
permitindo que qualquer pessoa que esteja gerenciando um projeto obtenha o melhor da 
metodologia PRINCE2®. 
Esses são os requisitos orientadores e as boas práticas que determinam se o projeto está sendo 
gerenciado genuinamente, usando o PRINCE2®. Existem sete princípios e, a menos que todos 
sejam aplicados, não é um projeto PRINCE2®. Os princípios do PRINCE2® são: 
� Justificativa continuada de negócios – também deve haver uma razão justificável para estar 
executando e gerenciando o projeto. Caso contrário, o projeto deve ser fechado. 
� Aprenda com a experiência – as equipes de projeto do PRINCE2® devem procurar e 
aproveitar, continuamente, as lições aprendidas em trabalhos anteriores. 
� Papéis e responsabilidades definidos – a equipe do projeto PRINCE2® deve ter uma 
estrutura organizacional clara e envolver as pessoas certas nas tarefas certas. 
� Gerenciar por etapas – os projetos do PRINCE2® devem ser planejados, monitorados e 
controlados passo a passo. 
� Gerenciar por exceção – as pessoas que trabalham no projeto devem receber a quantidade 
certa de autoridade para trabalhar, efetivamente, no ambiente. 
� Foco nos produtos – os projetos do PRINCE2® se concentram nos requisitos de definição, 
entrega e qualidade do produto. 
� Adaptar para se adequar ao ambiente do projeto – O PRINCE2® deve ser adaptado para se 
adequar ao ambiente, tamanho, complexidade, importância, capacidade e risco do projeto. 
 
Esses princípios descrevem aspectos do gerenciamento de projetos que devem ser abordados 
em paralelo ao longo do projeto. Os sete temas explicam o tratamento específico exigido pelo 
PRINCE2® para várias disciplinas de gerenciamento de projetos e por que eles são necessários. 
O PRINCE2® ajuda as pessoas a aplicarem os temas, mas informando o requisito mínimo 
necessário para cada tema, e fornece orientações específicas sobre como adaptar a determinados 
ambientes. Os temas do PRINCE2® são os seguintes: 
� business case – criação e manutenção de um registro da justificativa comercial do projeto; 
� organização – definição dos papéis e das responsabilidades individuais de toda a equipe do 
projeto; 
� qualidade – requisitos e medidas de qualidade, e como o projeto os entregará; 
� planos – etapas necessárias para o desenvolvimento dos planos e as técnicas do PRINCE2® 
que devem ser usadas; 
� risco – efetiva identificação dos riscos e das oportunidadesque possam impactar o projeto; 
� mudança – como o gerente de projeto avaliará e agirá em mudanças no projeto, e 
� progresso – viabilidade e desempenho contínuos dos planos, e como e se o projeto deve 
prosseguir. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
68 
 
Esses temas descrevem as etapas do ciclo de vida do projeto, desde a ideia inicial até o 
fechamento do projeto (e a medição dos benefícios). Cada processo fornece listas de verificação de 
atividades recomendadas, responsabilidades relacionadas e orientação sobre como adaptar a um 
ambiente específico. Os benefícios do PRINCE2® são: 
� um prático guia passo a passo para gerenciar com sucesso qualquer projeto; 
� um método flexível que pode ser adaptado a qualquer organização ou função envolvida 
no gerenciamento de projetos e 
� uma certificação acessível e globalmente reconhecida que agrega valor ao seu currículo. 
 
As certificações PRINCE2® foram criadas para qualquer pessoa que gerencia projetos. Isso 
varia do gerente de projeto dedicado aos profissionais que gerenciam projetos como parte do seu 
trabalho diário. Eles também são relevantes para os envolvidos no projeto, desenvolvimento e 
entrega de projetos. As certificações são: 
� PRINCE2® Foundation; 
� PRINCE2® Praticioner e 
� PRINCE2® Agile. 
 
IPMA 
A IPMA – International Project Management Association – é uma associação internacional que 
congrega mais de 60 países. Sediada na Holanda, a IPMA foi criada em 1965, em Viena, na Áustria. 
Atualmente, a sua fica na Holanda. Representa associações de membros no nível global, 
desempenhando um papel de liderança no desenvolvimento e promoção da profissão de 
gerenciamento de projetos, fornecendo padrões e diretrizes para o trabalho de uma gama de talentos 
de gerenciamento de projetos por meio do IPMA Competence Baseline. Possui um sistema de 
certificação de quatro níveis baseado em competências para gerentes de programas e projetos, que 
é único no mundo e amplamente reconhecido pela sua qualidade. 
A visão do IPMA é “Promover competência em toda a sociedade para possibilitar um mundo 
em que todos os projetos sejam bem-sucedidos”. Desse modo, o IPMA definiu um padrão mundial 
para competências nas áreas de gerenciamento de projetos, programas e portfólios. Para os 
indivíduos, definimos o IPMA Individual Competence Baseline®, ICB versão 4; definimos o padrão 
para projetos excelentes, o IPMA Project Excellence Baseline® ou o PEB e definimos o padrão para 
organizações, o IPMA Competência Organizacional Baseline® ou OCB. Com base no ICB4, 
também definimos a linha de base de competências do IPMA para coaches, treinadores e consultores 
no campo de projetos, programas e portfólios – o ICB4CCT. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 69 
 
Certificação 
Enquanto o IPMA gerencia o esquema de certificação de 4 níveis (4LC) para indivíduos, os 
organismos de certificação das associações-membro do IPMA são responsáveis pelas avaliações 
individuais e pela certificação. O processo de certificação envolve várias etapas para a avaliação de 
um candidato e é descrito em detalhes no International Certification Regulations (ICR), que você 
pode baixar na parte inferior da página. Aqui, apresentamos uma visão geral. 
As etapas de avaliação para indivíduos são aplicadas a cada nível de competência A, nível B, 
nível C e nível D do IPMA. Quando os candidatos atendem aos requisitos de competência, eles 
podem se inscrever diretamente para o nível desejado. Você não precisa começar no nível D e 
avançar para C e B e A. 
Os fluxos de processos descrevem os caminhos oficiais, que são seguidos em todo o mundo: 
� Certified Projects Director (Level A); 
� Certified Senior Project Manager (Level B); 
� Certified Project Manager (Level C) e 
� Certified Project Management Associate (Level D). 
 
Scrum Alliance® 
Fundada em 2001, a Scrum Alliance® é a maior e mais estabelecida e influente organização 
profissional de associação e certificação da comunidade Ágil. Nossa associação sem fins lucrativos 
certificou mais de 750.000 profissionais em todo o mundo. Nossa visão é “Transforme o mundo 
do trabalho”, com a missão de orientar e inspirar indivíduos, líderes e organizações com práticas, 
princípios e valores que criem locais de trabalho que sejam alegres, prósperos e sustentáveis. Desse 
modo, buscamos: 
� Inspirar – inspiramos indivíduos, líderes e organizações a adotarem mentalidades Ágeis. 
Apoiamos as suas transformações com treinamento, e compartilhamos histórias de 
mudança e inovação em empresas em todo o mundo. 
� Habilitar – habilitamos o trabalho de nossos certificados e membros por meio de uma 
rede global de parceiros ágeis, treinadores e treinadores. Desenvolvemos oportunidades de 
conteúdo e aprendizado, incluindo webinars, eventos globais e regionais, grupos de 
usuários locais e muito mais. 
� Guiar – orientamos a aplicação de práticas, princípios e valores ágeis por meio de nosso 
caminho de certificação de longa duração. Nossa comunidade de treinadores e treinados 
está focada em fornecer conhecimento, habilidades e experiência que suportam 
transformações ágeis para indivíduos e organizações. 
 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
70 
 
Scrum.org 
Baseado nos princípios do SCRUM e do Manifesto Ágil, o Scrum.org fornece treinamento 
abrangente, avaliações e certificações para melhorar a profissão de entrega de software. Em todo o 
mundo, nossas soluções e a comunidade de instrutores profissionais do SCRUM capacitam pessoas 
e organizações a obter agilidade por meio do SCRUM. Ken Schwaber, o cocriador do SCRUM, 
fundou a Scrum.org, em 2009, como uma organização global, dedicando-se a melhorar a profissão 
de entrega de software, reduzindo as lacunas para que os produtos de trabalho e trabalho sejam 
confiáveis. 
Inicialmente, Ken Schwaber tentou desenvolver os programas do Scrum.org em outros 
lugares. No entanto, no final, descobriu que, para atingir o seu objetivo de melhorar o 
conhecimento, o treinamento e as implementações do Scrum, ele precisaria se separar e começar o 
Scrum.org. 
A seguir, você pode encontrar um trecho de uma carta de Ken Schwaber para os treinadores 
e parceiros do Scrum.org que descreve por que ele começou o Scrum.org. A carta foi escrita em 30 
de março de 2010 e publicada em 15 de junho de 2010: 
 
Por quê? 
Por que você encontrou o Scrum.org? Eu tenho feito essas perguntas 
inúmeras vezes desde que criei o Scrum.org no outono passado. Essa é a 
história da minha jornada com o SCRUM, começando com a sua criação, 
passando pelo estabelecimento e evolução, e terminando com o meu 
trabalho com Scrum.org. Essa jornada foi moldada por duas forças opostas: 
o desejo de fazer a coisa certa e o desejo de ganhar dinheiro. Eu formei o 
Scrum.org para reorientar os meus esforços em fazer a coisa certa. 
 
Criando SCRUM 
A história do começo do SCRUM é bastante conhecida, de forma que não 
vou gastar muito tempo aqui. Jeff Sutherland e eu usamos o SCRUM, há 
dez anos, antes da reunião no Snowbird, onde nós e outros assinamos o 
Manifesto Ágil. Esse manifesto, junto com o meu primeiro livro sobre 
SCRUM (Desenvolvimento Ágil de ‘software’ com SCRUM) e o surgimento 
de ambientes modernos de desenvolvimento integrado (IDEs), ajudou o 
SCRUM a se espalharcomo um incêndio no início dos anos 2000. 
 
Alguns anos depois, Martin Fowler e eu estávamos voando de volta para 
Boston em uma conferência sobre o dimensionamento de projetos ágeis na 
Universidade de Calgary. Ficamos desanimados porque muitos de nossos 
Felipe Gorgen dos Reis
 
 71 
 
clientes não entenderam o que eram o Agile e o SCRUM. Martin e eu 
decidimos que algum tipo de instrução e, até mesmo, certificação seriam 
necessárias para remediar a situação. Eu desenvolvi um curso ScrumMaster 
de dois dias, o primeiro dos quais foi conduzido no ObjectMentor, em 
Chicago, em 2002. Eu atestei os participantes como apenas isso – os 
participantes – e listei os seus nomes no meu site, controlchaos.com. 
Conduzi muitas dessas sessões de treinamento em 2002 e 2003. O curso se 
tornou mais refinado e baseado em experiência. Começou a distinguir entre 
o que é SCRUM e como o SCRUM deve ser usado. Eu considerei a aula 
um sucesso porque, no meu trabalho de consultoria, pude ver o quanto os 
melhores alunos da classe eram capazes de usar o SCRUM. Recebi um ótimo 
feedback dos participantes do curso e, quando a notícia se espalhou, os cursos 
se tornaram extremamente populares. 
 
No início de 2009, mais organizações estavam usando processos ágeis do 
que processos em cascata, e aqueles que empregavam Agile 84% estavam 
usando o SCRUM. No entanto, menos de 50% dos que usam o SCRUM 
estavam desenvolvendo iterações incrementais, que são a pulsação do 
SCRUM. Martin Fowler escreveu em seu blog que ele estava encontrando 
muitos exemplos de flaccid scrum. As equipes estavam usando o vocabulário 
do SCRUM, mas não conseguiram criar um incremento de funcionalidade 
potencialmente disponível em um único Sprint. 
 
Eu lancei três iniciativas para remediar estes problemas: criando o 
programa Scrum Developer. Um dos maiores desafios de usar o SCRUM 
sempre foi a curva de aprendizado para os desenvolvedores da equipe. No 
entanto, como o SCRUM é uma prática de gerenciamento, a maioria das 
pessoas que ensinaram o SCRUM não eram desenvolvedores atuais e 
estavam mal qualificadas para ensinar práticas de engenharia como 
desenvolvimento orientado a testes ou arquitetura emergente. Eu queria 
criar um curso específico para abordar os desenvolvedores do SCRUM, 
então entrei em contato com três organizações especializadas em ensinar 
aos outros como arregaçar as mangas e construir software usando o 
SCRUM: Accentient, Conchango e Microsoft. Nós desenvolvemos um 
curso para desenvolvedores SCRUM, visando à pilha de tecnologia .NET. 
Trabalhar com a Microsoft nos deu acesso a uma base sólida de treinadores 
e treinadores: Microsoft MVPs e Inner Circle Partners. Começando com 
a Microsoft, também pudemos começar com uma pilha de tecnologia 
 
72 
 
totalmente integrada. Depois de lançarmos esse curso na primavera de 
2010, juntamente com o Visual Studio 2010, trabalharíamos com outros 
parceiros para desenvolver cursos semelhantes direcionados a outras pilhas 
de tecnologia. 
 
Formalizar o corpo de conhecimento do SCRUM e medira sua compreensão. 
Como o SCRUM se espalhou, também a confusão e o mal-entendido do 
SCRUM. Jeff Sutherland e eu compilamos o corpo de conhecimento do 
SCRUM (também conhecido como o Guia do SCRUM). 
 
Aplicação dos dias de hoje 
A SCRUM se tornou uma abordagem ágil popular aplicada em todo o mundo, por ser um 
método sofisticado, orientado ao que é mais importante, focado em comunicação efetiva, bem 
como no engajamento e comprometimento de todos os envolvidos, considerando os membros da 
equipe técnica, o cliente e o facilitador do processo, conhecido como SCRUM master. 
É importante ressaltar que o método é orientado para desenvolvimento de produto e deve ser 
uma ferramenta usada na gestão de projetos. Atualmente, outras áreas não tecnologia da informação 
(software – segmento no qual nasceu a abordagem) aplicam técnicas e ferramentas do SCRUM nos seus 
projetos. Lembre-se de que a adaptação é fator chave de sucesso. O seu projeto pode não suar todo o 
método na íntegra, mas pode usar algumas partes da abordagem, mesmo não sendo área de tecnologia. 
 
Principios e domínios do gerenciamento de projetos 
Os princípios e os domínios (re)definirão o padrão de gerenciamento de projetos! 
 
O que são princípios do gerenciamento de projetos? 
Os princípios têm as seguintes características: 
� são verdades fundamentais; 
� possuem norma, regra ou valor fundamental e 
� tornam-se um guia para o comportamento ou a avaliação no projeto. 
 
E são: 
� acionáveis; 
� culturalmente neutros; 
� aplicados de diferentes maneiras; 
� um meio de determinar um “guardrail” claro e 
� aplicados em todo e qualquer cenário de entrega de valor. 
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
Felipe Gorgen dos Reis
 
 73 
 
Tabela 30 - Referência dos princípios 
"Guide behavior and thinking " Conduza o comportamento e o pensamento 
“Parameters in wich to operate” Identifique Parâmetros nos quais irá operar 
“Not prescriptive” Não prescritivo 
“Different ways to maintain alignment” Diferentes maneiras de manter o alinhamento 
“Apply to all projects” Aplicado em todos os projetos 
Fonte: projectmanagment.com 
 
O que são domínios do gerenciamento de projetos? 
Os domínios são um agrupamento de conceitos e de práticas com o objetivo de formar uma 
combinação de ferramentas e de técnicas, elevando as chances de sucesso do projeto. 
 
Figura 31 – Diferenças PMBOK 6ª edição versus 7ª edição 
 
Fonte: projectmanagement.com 
 
 
74 
 
 
 
 
 
É importante lembrar que apresentamos somente alguns (os mais utilizados no mundo) 
exemplos de outros padrões de gerenciamento de projetos como referência e informação. Para o 
profissional de projetos, é importante compreender que quanto mais frameworks, métodos, 
ferramentas e técnicas conhecer, maior será a sua liberdade de aplicação. 
Atualmente, o desafio está relacionado, diretamente, com compreender e conhecer bem o 
ambiente ao qual o projeto está inserido, e modelar o conjunto de práticas da melhor maneira 
possível, considerando todos os fatores que influenciam o projeto e os desafios da organização, de 
forma simples e objetiva, ou seja, criar soluções de gestão em projetos. Se a sua organização possui, 
por exemplo, uma metodologia, lembre-se de que há sempre espaço para melhoria contínua dos 
processos que visam simplificar e agilizar os processos, aumentando a eficiência e (ainda mais) as 
chances de sucesso do projeto da sua empresa. Projetos são o meio para qualquer transformação 
organizacional. Pense nisso! 
Desejo ótimos projetos de sucesso a você! 
 
 
CONSIDERAÇÕES FINAIS 
 
76 
 
REFERÊNCIAS BIBLIOGRÁFICAS 
AXELOS. Managing successful projects with PRINCE2® 2017 Edition, AXELOS, 2017. 
 
Associação Brasileira de Normas Técnicas (ABNT). Disponível em: <http://www.abnt.org.br/cee-
93> Acesso em 15 de nov. 2018. 
 
BARCAUI, André et all. PMO: Escritórios de projetos, programas e portfólio na prática. 1. ed. Rio de 
Janeiro: Brasport, 2012. 
 
FREITAS, Carlos Augusto. Certificação CAPM: para membros de equipes e novos gerente de 
projetos. 2. ed. Rio de Janeiro: Brasport, 2014. 
 
FREITAS, Carlos Augusto. Gestão estratégica por meio de projetos, programas e portfólio. 1. ed. Rio 
de Janeiro: Brasport, 2016. 
 
International Organization for Standardization. Disponível em: < https://www.iso.org/standard/ 
50003.html > Acesso em 15 de nov. 2018. 
 
PMI – Project Management Institute. Project manager competence development framework. 3. ed. 
Pensylvannia, USA: Project Management Institute, 2017. 
 
PMI – Project Management Institute. The standard for program management. 4. ed. Pensylvannia, 
USA: Project Management Institute, 2017. 
 
PROJECT MANAGEMENT INSTITUTE. PMBOK® Guide: guia do Conhecimento em 
gerenciamento de projetos. 6. ed. Pensylvannia, USA: Project Management Institute, 2017. 
 
SOURCE: HILL, Gerard. The complete project managementoffice handbook. 3. ed. [s.l.]: ESI Series, 
2014. 
 
VARELLA, Lélio; ANICETO, Cirléa; MOURA, Graciele. Aprimorando competências de gerente de 
projetos: o sucesso no desempenho gerencial. V. 1. Rio de Janeiro: Brasport, 2010. 
 
 
 
 77 
 
VARGAS, Ricardo. Gerenciamento de projetos: estabelecendo diferenciais competitivos. 9. ed. Rio 
de Janeiro: Brasport, 2018. 
 
VARGAS, Ricardo Viana. Manual Prático do Plano de Projeto. 5. ed. Brasport, 2014. 
 
Sítios eletrônicos 
Project Management Institute: www.pmi.org 
 
PMI Brasil: http://brasil.pmi.org 
 
Brightline Initiative: https://www.brightline.org 
 
Axelos – Global Best Practice: https://www.axelos.com 
 
IPMA: https://www.ipma.world 
 
Manifesto Ágil: http://www.manifestoagil.com.br 
 
 
 
78 
 
PROFESSOR-AUTOR 
Carlos Augusto Freitas é mestrando em Sistemas de Gestão 
pela Universidade Federal Fluminense, formação superior em 
Gerencia de Redes e Tecnologia de Sistemas e especialista em 
Docência do Ensino Superior em Ambientes Tecnológicos. Possui 
diversos cursos de atualização e especialização, como: Redes de 
Telecomunicações (PUC Rio), Gerenciamento de Projetos de 
Software (PUC Rio), Gerenciamento de Projetos e CMMI (UNI-
Rio) e Ensino Superior a Distância (Fundação Getulio Vargas). 
Possui mais de 13 anos de experiência em Gestão de Projetos, 
Programas e Portfólio, e implantação de Escritório de Projetos 
(PMOs) em diferentes segmentos. Também possui mais de 10 anos 
de experiência em educação, treinamento e desenvolvimento 
gerencial em Gerenciamento de Projetos. 
Nos últimos anos, implantou mais de dez Escritório de Projetos (PMOs) em áreas 
como Oil&Gas, Logística, TI, Telecomunicações, Engenharia e Industria Química, em empresas 
de pequeno, médio e grande porte, aplicando gestão estratégica e suporte à governança de 
organizações por meio de práticas de projetos, programas e portfólio. 
É fundador e diretor executivo da CAF – Facilities Management (CAFFM®) – empresa com 
foco em gestão estratégica com clientes em diversos portes e segmentos, como Tecnologia da 
Informação, Engenharia, Indústria, Turismo, Serviços e Start-ups. Também, é professor da FGV 
desde 2008. 
No PMI RIO, foi vice-presidente de desenvolvimento de projetos do PMI RIO (2010-2011). 
Em 2012, foi eleito vice-presidente executivo do PMI RIO (2012-2014), além de integrar o Comitê 
Mundial de Tradução do PMBOK® 5a edição (PMI, 2013). Foi presidente do PMI RIO, de 2015 
a 2017. Além disso, participa, junto à ABNT (ISO), no Comitê Brasileiro da norma ISO 21.500.